An agile release plan only has to include the best- and worst-case final release dates, but many plans also include smaller releases along the way, including end-of-sprint releases and quarterly releases. I have even scheduled daily releases when working on a sustained engineering team supporting a production system. What makes sense for your release plan depends on the specifics of your project and the reality of your situation.
I approach release planning in a very systematic way.
- 1. Sketch a preliminary roadmap.
- 2. Add a degree of confidence.
- 3. Include dates and adjust as needed.
- 4. Update the plan every sprint.
To build an agile release plan, you need three inputs:
- 1. An estimated, ordered, and prioritized product backlog
- 2. The team velocity
- 3. A sprint timeline
Don’t attempt a release plan until the team and the product owner have estimated, ordered, and prioritized the initial product backlog.
Once you have a prioritized and estimated product backlog, you need to know your team velocity, how much work a team can do over time. This number can either be pulled from historical data or estimated. (See Chapter 4, “Determining Team Velocity,” in The Scrum Field Guide on how to do this).
The last thing you need to know is your sprint timeline, the intervals at which your sprints start and end. This could be one week, two weeks, three weeks, or four weeks. Regardless of the interval, once you determine your sprint length (see Chapter 6, “Determining Sprint Length,” in The Scrum Field Guide on how to do this).
With this data in hand you can sketch a best-case and worst-case scenario for how much of the product backlog the team can accomplish within a certain number of sprints.
Remember, release planning does not go away in agile projects, it is just done differently. And "agile means no planning" goes out the window.
For more on how to do effective release planning, order your copy of The Scrum Field Guide: Practical Advice for Your First Year today!