Skip to main content

Release Plan . Part of Scrum ?

Last post 04:58 pm May 8, 2018 by Erez Morabia
3 replies
07:57 pm May 7, 2018

Page 16 of scrum guide states

Monitoring Progress Toward Goals At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders. 

Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making

I would definitely call this a release plan.  I understand that each increment is a potentially releasable unit however, everyplace I have been involved the stake holders demand when certain functionality will be released for production.  AKA - Release Plan


06:38 am May 8, 2018

You might call it a Release Plan, sure. A better term would be "release forecast" though. Because all you do is extrapolate when something will be done based on data from the past and present that is subject to change. Both the Product Backlog and the rate of the team's progress will change (not "might" - "will"), so the forecast is weak and gets weaker the further into the future it goes. It is not a commitment and everyone involved needs to understand that.


11:16 am May 8, 2018

For specific features, a Product Owner may articulate such a forecast as a likely date plus or minus a number of days to a given level of certainty.

A simpler forecast might just use the current position and size of items in the backlog and the established velocity.


03:36 pm May 8, 2018

One for the myths related to Scrum is that we can't do project planning. As mention in the previous comment, using the velocity of the team and the remaining of the backlog items, one can forecast the project end. This re-planning would be done per sprint (here is where the empirical process kicks in...).

One note of reality: your initial plan won't be accurate, not matter how hard you would try. Even if the velocity is stable the unknown unknowns will shift your dates. So this is project forecast rather then project commitment. If you need to commit for long project (agile in waterfall organization) make sure to take some buffers, either on content or on time. 


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.