Often teams are working on features over multiple sprints scheduled in a release. Planning and tracking these releases can be very difficult, but you can’t tell the business we have no idea what will be delivered. Since it is impossible to perfectly define the requirements upfront, we can’t perfectly predict when we will be done.
However, that doesn’t mean we don’t plan. In Agile, we plan all the time with a lightweight method to forecast the schedule and then revise as we obtain new information. This is why it is critical for agile teams to focus on delivering “Done Done” product increments every couple weeks. We can then use “Working Software” as our primary measure of progress and update our forecast. This also helps us better assess the impact of change throughout the plan.
You can use the following questions to assess how effective you are at Planning and Tracking Releases:
The Basics
- Is the team involved in release planning?
- Does the team do the estimating?
- Does the team have a sense of their velocity or throughput to use as a basis for forecasting?
- Are release burnup and/or burndown charts updated frequently?
- Are stakeholders involved in prioritization?
- Is an initial release plan in place before the start of the first Sprint of the release?
Good
- Is a vision or goal articulated for the release?
- Does the team plan for discovered or unplanned work?
- Is risk factored into the plan estimates?
- Does the team use an abstract relative estimation technique (i.e. Story Points or T-shirt sizing)?
- Is the release progress reported in the Sprint Review and discussed with stakeholders?
- Are release burnup and/or burndown charts visible to the team at all times?
- Are cross-team dependencies considered and discussed?
- Do stakeholders consider the size when prioritizing?
- Are the backlog items ordered?
- Are all large epics broken down into Minimally Marketable Features (MMFs) before starting the first Sprint of the release?
- Are stories understood by the team?
- Is the business and team continuing to try and make releases shorter?
Awesome
- Does the team release so frequently that release planning is not required?
- Does the team have a high level of predictability and comfort with their sizing technique?
- Does the business understand and accept the variability of working in an empirical way?
- Does the order of the backlog make learning a priority?
- Is change expected?
- Does the order of backlog items factor in risk? (i.e. deferring some items to the last responsible moment)
- Is the impact of change assessed and communicated?
Here are some ideas you can implement to help improve your Release Planning:
- Have you looked into a risk-based forecasting model? Check out a chapter from the Art of Agile Development from James Shore.
- Ensure your team is investing time in advancing its technical practices as well to shorten the cycle time of your releases.
- When you have multiple teams working on the same release consider conducting a release planning working with all teams simultaneously
- Estimate using Story Points
- Henrik Kniberg does a good job discussing the different types of risk in his video Product Owner in a Nutshell. He also discusses the concept of variability in planning.
View other posts in our Scrum Assessment Series.
What items have you implemented that improved your Release Planning?
