Release Planning
Last updated
Last updated
We use this to evaluate how the last time-box or work item/release went, specifically around the team dynamic, processes, and tools, so that we can articulate and stack rank the items that went well and those items that did not implement a plan for improving the way the team does work.
"If you're doing it by yourself, you are doing it wrong!" Sharon Robson.
The whole team needs to be involved in this process.
This is a dynamic plan - that is it needs to be updated as things change or we learn more about the work that we are doing.
It is naive to think that you know everything that can happen at the start of the project and that all your estimates will become actuals. Therefore you must continually update the release plan - at the end of each iteration is a great time to review it as you have some more data to use.
A release plan is a larger timebox plan, usually taking up enough work for 3-4 iterations. As it is about 3 months of work it can also be considered a quarterly plan.
As seen in the following image, the roadmap (~12 month view) breaks down into releases (~3 month view), which breakdown into iterations (2 Week view), which breakdown into stories and tasks (~0.5d - 5d).
The prerequisites of release planning are as follows −
A ranked product backlog, managed by the Product Owner.
Team's input about capabilities, known velocity or about any technical challenge
High-level vision/roadmap
Business/Division/Team objectives and goals
Acknowledgement whether new product backlog items are needed
The list of data required to do release planning is as follows −
Previous iterations or release planning results
Feedback from various stakeholders on product, market conditions, and deadlines
Action plans of previous releases / iterations
Features or defects to be considered
Velocity from previous releases/ estimates.
Definition of Done (story, iteration, release levels)
Organizational and personal calendars
Inputs from other teams and subject matter experts to manage any dependencies
The output of a release planning can be the following −
Release plan (this is not a document in the traditional project sense)
Commitment
Issues, concerns, dependencies, and assumptions which are to be monitored
Suggestions to improve future release plannings
By creating a matrix of work breakdown to release/iterations we can start to map out what can be done in each iteration and release. This helps to work out what the iteration goals are, how much work the team can do, and when the work will be done. If there are multiple teams working from the same backlog or working towards the same goal then we can also start mapping out what team is working on which pieces of work.
Similar to Story Mapping buckets can be used to see what work will be done in each iteration.
Firstly, figure out what sizes the buckets are - team leave, historical data, risk, etc. can all help determine what the size of the buckets. Bucket size should be a story point value, but for new teams issue count might be acceptable.
Then starting filling the buckets from left to right - based on the sum of story points until the bucket is full. Don't over fill the bucket - it's usually best to go as close to the lip as possible but don't go over.
Avoid creating a Gannt chart for your release plan as this will almost always end up with a Analysis/Dev/Test waterfall (and test will always be bumped into the 'next iteration') - this doesn't lead to thinking about "team work". Instead by thinking about what done means we can plan to complete all the things required to finish the work items within the timebox - if we can't complete everything then maybe its too big or maybe there is another way to split the work so that there is something valuable ready at the end of the timebox.
The release burn-up is a great tool that can be used to see how you are tracking against the plan.
As new work is added or removed then the "total" line moves up and down - the target is very rarely set in stone. Remember, in agile, we are flexible on scope more than time as we are working on the highest priority work items first - therefore, if we don't get to those at the end, it's not a big deal, and we can start looking at the cost/benefit of doing the work.
The burndown can also be used to project the estimated completed work to answer the question - when will we finish? The sooner that we can publicly announce that we are on track (or are not!), the better it is for everyone.
