At what intervals 'Release Planning' meeting should be conducted?

Why do you need Release Planning meetings?

If every Sprint results in an Increment that is potentially releasable, why would there need to be a particular event? Every Sprint timebox results in an Increment that could be released. Also consider that one of the elements of a Sprint Review is a "review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product." Since there are key stakeholders at the Sprint Review, if there is coordination needed for a release, these key stakeholders should be able to accept the Increment that is suitable for release and be able to plan for it. If the process of releasing does take time, it can occur after the Sprint Review as a parallel activity. The Development Team, if they are involved, can consider this in their forthcoming Sprint Planning as part of forecasting their capacity.

Sumit, as the Scrum Guide makes no mention of a "Release Planning" event, can you provide more context around your intent and purpose for such a meeting?

And what does the Scrum Guide say about releases and responsibility for such?

Release frequency is going to be a consideration here as well.

If the team is releasing multiple times per Sprint they may choose to have release conversations within the Daily Scrum as it would be part of their plan for the next 24 hours. The team may also choose to add on their own event to the Scrum Framework related to release discussions if it aids in making any integration or release challenges / tasks transparent to the team. 

Is there any defined time for the Release Planning meeting?

This event itself is not defined in the Guide. 

I agree that the Release Planning is the is longer-term planning of the product. Having said that, what should be the interval of this meeting?

What is the outcome of this 'meeting/event' ? 

@Timothy - Sumit, as the Scrum Guide makes no mention of a "Release Planning" event, can you provide more context around your intent and purpose for such a meeting?

The context here is our project is getting started from scratch and we need to give rough estimate to the client that say after 10 sprint we will deliver this functionality etc.

In short, this is for the Overall project and the key milestones of the project which are agreed with stakeholders.

I got below stuff related to Release Planning on net - 

A very high-level plan for multiple Sprints (e.g. three to twelve sprints) is created during the Release planning. 

It is a guideline that reflects expectations about which features will be implemented and when they are completed.

It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or the final delivery at the end.

Looks ahead to the release of a product, often a few months (3 - 6 months)  ahead of the start of a project. 

-Defines and re-defines the product backlog, and may involve refining larger user stories into a collection of smaller stories.

-Provides the basis for a test approach and test plan spanning all iterations. Release plans are high-level.

@Sumit, 

Does your development team have any prior information they can use to forecast how long it may take to implement the items from the current Product Backlog? 

It would be important for the customer to understand and expect that as new information is learned or new work is added that this forecast will need to be revisited. 

One more reference - 

Book - Essential Scrum: A Practical Guide to the Most Popular Agile Process

Chapter 18 - Release Planning ( Longer Term Planning)

Page Number - 352

Link - 

http://ce.sharif.edu/courses/97-98/2/ce418-1/resources/root/Books/[Addi…

@Tony - Does your development team have any prior information they can use to forecast how long it may take to implement the items from the current Product Backlog? 

Development Team makes the guess based on their past experience, domain / technology involved, past velocity etc.

Then it's possible they could give a forecast for the entire Backlog if it's estimated. I'd keep in mind what I mentioned above so that emergent work is accounted for and transparent to the customer as the team Sprints. 

Nothing will likely be as inaccurate as their initial forecast. 

how much time scrum team should spend on Release Planning meeting?

Wouldn’t this be part of the 10% of a Sprint allowed for Product Backlog refinement?

What you describe - trying to estimate early what kinds of work will be done over 3, 10, or 12 Sprints - is not in alignment with the values and principles of Agile Software Development. It's a return to a plan-driven approach that has been demonstrated to be generally ineffective for most software development efforts. You may see attempts at this in various forms, like quarterly planning or SAFe's Program Increment Planning or similar constructs.

Agile Software Development is built around the idea that we cannot predict or plan in a long term. There are too many unknowns, too much uncertainty, and a lot of opportunities for learning and adjusting. If you didn't have unknowns, uncertainty, or the need to adapt to a changing environment, using any of the agile methods would simply be overhead. By using the agile methods, we are acknowledging that we can't predict or plan far out - we base our iterations on the order or days and weeks, about a month or so maximum.

You cannot both acknowledge the unknowns and uncertainty that exists and also believe that you can reasonably plan a long-term (more than one or two iterations or Sprints) effort. Those two things are the exact opposite of each other. Either you are in an environment with large amounts of unknowns and uncertainty or you are not.

Sumit,

Ken Rubin's Essential Scrum book does not support your approach at all.   Have you read his book, by any chance?

From your comments, it seems you have a fixed-scope project that you are attempting to deliver using Scrum, and that your organization has a need to set expectations with an external customer around delivery dates.   If you read Ken's book, especially the chapter you identified (18 - Release Planning), he goes into depth on various approaches to working with fixed-scope efforts, detailing the pluses and negatives in fixing some project constraints while allowing others to be variable.

In a nutshell, he echoes many of the observations already made in this thread.   You would be better off educating your customer on the unreliability of such futuristic estimations / milestones.   It is wasted effort that would be better spent developing the product and delivering on short-term expectations.

The context here is our project is getting started from scratch and we need to give rough estimate to the client that say after 10 sprint we will deliver this functionality etc.

Agree with @Ian's question . Isn't this part of product backlog refinement ? where you have all the PBIs defined and you estimate & forecast. Theoretically you can tell how much can be delivered and when, by keeping current capacity, market trends and skills as constant.

Like mentioned in several comments above with each increment delivery , your planned functionalities/scope might change or might even become irrelevant. So, what do you think how much time you should invest to give this count of Sprints ? What value you intend to drive from this forecast which is non static?