Release planning is defined as the process of producing high-level planning that eventually gets broken down into iterations. Whilst a lot of literature and blogs focus on iteration planning, release planning is by no means less important. 

The breakdown of a project from purpose progresses to release planning, which can roughly be 3-to-6 months, and encompasses about 8-10 iterations. It’s purpose serves to comprehend at a granular level what the development effort is and start to put ball-park scheduling (conceptually) so we can figure out when we may see a release.

The benefits of a release plan is that the entire team can sit and iron out a roadmap without having to commit at a more molecular level, whilst also setting up the expectations for the stakeholders. I also conceive of release planning as setting milestones for how we are progressing through our individual iterations, a sort of benchmarking, setting and ticking off sets of features.

Release planning is being granular enough 

The premise of release planning lies in determining at a higher-up level, based on a collection of user stories, what can be done, when. What is the development effort required, without having to drop down to the level of individual tasks. In fact, it’s a real no-no to specify or describe the planning in terms of tasks. 

Release planning is not about what tasks each developer works on, but about describing user stories–functionalities required–. Deferred delegation is essential, allowing the project team to assess individual development capacity when required, minimising the risk of roadblocks from task-dependencies.

In fact, delegation decisions should be left up to the individual developer, at the time of iteration, later on, as determining effort and capacity too early will lead to poorly assumed or understood assessments. 

what is the key success indicators?

This is something that should be determined up-front as well. In a previous article of mine, I talked about Lean Analytics as part of my review of a book, but the crux of it is that at this level, you need to determine your success criteria. Lean Analytics allows you to find that specific metric that is measurable, tangible and will help you easily understand how you are going. This is done iterative as well. 

Customer Development

I also did a previous piece on Lean Customer Development, and in release planning, we need to also determine our plan of attack, on how we will verify assumptions made on functionality, which directly correlates with the user stories we will have as part of our iterations.

User Story estimation

Whilst we won’t be estimating individual tasks, it is ideal for us to estimate indicatively the user stories, and assess whether we can plausably add the features we want in a specific iteration, and once again, prioritise and re-prioritise, organise and re-organise accordingly. Heavily linked with customer development, differences in customer engagement feedback could result in scope changes for user stories, thus forcing estimation changes.

Regularly updating the release plan

Please always ask the question, how often should we re-visit and re-vise our release plans? Whilst there is no definitive duration between re-visiting, it should be done frequently, as various factors such as project team velocity variances and feature scopes change, it requires getting back to this document, as it will always remain a living document.

I generally enjoy re-visiting the release plan after each iteration, as experience has taught me that iterations never end the way they were planned, and based on various surprises, things have to be pushed back from one iteration to another, which then tends to have a butterfly effect on other user stories.