Agile Product Management with Scrum: Chapter 4 : Release planning
In which I summarize and discuss chapter 4 of Roman Pichler’s book, on release planning.
Summary of Chapter 4
Release planning.
The team should do it. The product owner should drive it.
Mostly focused on the next release.
Which should be soon. With less scope and more quality.
And then you should plan and execute a release soon after that.
Iron triangle
The time vs cost vs functionality vs quality thing, with quality ideally held to a constant high non-negotiable standard.
Hold time fixed (target a soon release!) and flex functionality to hit the release date.
Holding functionality fixed is a terrible idea because you do not know in detail what the functionality ought to be until you build the product. Guesses at scope in advance are going to be wrong and are going to select scope at the moment when you know the least rather than informing that selection by what you learn as you go.
Release date selection
Determine the window of launch opportunity informed by the product vision.
Consider a consistent release cadence. Like, say, quarterly.
Fixed price contracts are a bad idea
Fixed price contracts for a fixed deliverable are a bad idea. This is mostly because fixed deliverables are a bad idea.
Of course, you can do a fixed price contract for a fixed team for a fixed time, and fixing team size and release time is a good idea, so long as you’re thoroughly willing to flex what it is that that team builds in that time.
Do not compromise on quality
Develop
- a potentially shippable product
- adhering to the definition of done
every single sprint.
Do testing and QA and quality control within the sprints.
Do not save testing / code review / refactoring / documentation to "later" or "in the release process" because those either mean "never" or "we're making releasing really expensive so it's painful and we won't do it as much" or both.
Release early and often
Upsides:
- Sooner feedback
- Sooner deriving value from the product, which stream of value justifies the stream of cost of development
- Avoids going too far down the wrong roads
Ways to mitigate downsides:
- Really high quality, staving off technical debt
- Test automation, keeping the cost of testing changes and releases down
- Release automation, keeping the cost of releasing down
- Merciless refactoring, staving off technical debt
- A high quality, highly engineered, careful upgrade process, staving off release and upgrade friction.
Quarterly cycles
If you are using Scrum to build something that takes longer than a few months to build, build a subset of it in a quarter and release it to someone, even if that has to be internal.
Release burndown
Pichler talks about release burndown charts, about knowing the items remaining for a release and so being able to project, given velocity, the sprints remaining to release.
Release plan
It’s a lot like the product roadmap, focused in on that next release.
So, the roadmap might articulate a few releases spanning six or twelve months out.
The release plan is the plan for that next release that's at most three months out.
Release planning for large projects
Pichler has some thoughts on coordinating release planning between teams, avoiding and dealing with interdependencies, etc.
Common mistakes
Again, my favorite part of this book is Pichler’s calling out anti-patterns and pitfalls.
Anti-pattern: No release burndown or plan
In this anti-pattern there’s no plan and the team only thinks from sprint to sprint.
Squirrel!
Always have a release plan. Know what you’re working towards to next release. Make this visible in the team room and to those outside the team.
Anti-pattern: Product owner not driving the release plans
In this anti-pattern the product owner is insufficiently involved in release planning.
Release planning is as much a collaborative exercise as product grooming. As such, it requires the full participation of the product owner.
Anti-pattern: Big-bang release
An this anti-pattern the organization does not release early and often and instead waits to ship the product until all the functionality has been implemented.
This reduces the opportunity for feedback and learning earlier and artificially creates a high-stress, high-consequence release date.
Do not do this.
Release less, sooner.
Anti-pattern: Quality compromises
In this anti-pattern the team cuts corners and is left with a product that is more difficult and expensive to maintain and extend and that erodes user confidence and affection.
Have a definition of done, and take seriously upholding it.
Have craftsmanlike pride in your work and self-respect.
Cut scope, cut scope, cut scope, and cut scope some more until you are working at a sustainable pace on sustainable software with a sustainable release cadance. And then cut scope some more to release sooner and more often.
Read the book
It’a a good book, you should read it.
While I hope my summary is helpful, it misses nuance and examples from the book itself.
This post is part of a series
This post is part of a series of posts about chapters in Roman Pichler’s Agile Product Management with Scrum.
-
Chapter 4 : Release planning (this post)
Acknowledgements
Cover image : from Dima Pursanov : via CC-BY-NC-ND-2.0 . (It’s an iron triangle!)