Skip to main content

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

Last post 11:36 am September 18, 2019 by Harshal Rathee
13 replies
01:11 pm September 17, 2019

Is there any defined time for the Release Planning meeting?

E.g.

Daily Scrum - Everyday

Sprint Review - When Sprint (2 weeks) is over

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?

After every sprint end? Monthly?

 

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

E.g. If I consider it 4 hours, then half day of my entire scrum team will go in this meeting only.


01:34 pm September 17, 2019

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.


01:37 pm September 17, 2019

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?


01:48 pm September 17, 2019

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. 

 

 


01:49 pm September 17, 2019

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' ? 


05:18 pm September 17, 2019

@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.

 


05:28 pm September 17, 2019

@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. 


05:28 pm September 17, 2019

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…

 


05:33 pm September 17, 2019

@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.


05:57 pm September 17, 2019

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. 


06:40 pm September 17, 2019

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?


07:17 pm September 17, 2019

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.


08:10 pm September 17, 2019

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.


11:36 am September 18, 2019

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?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.