Here’s the challenge: how do you plan to release your software in Scrum? The Scrum guide says a few things about releasing the Product Increment but nothing about how to plan a release. This is likely purposeful, since it is a framework within which organizations build their own processes for these things.
I had opportunity to think through a release planning time, along with several colleagues. We toiled over an agenda for the time and facilitation techniques. During this time, something became clear to me; the point should be to determine three things,
These are business objectives e.g. increase revenue by 3%, capture 5% more market share, or reduce operating cost. Goals answer the question, “Why are we doing this?” They provide a context for every conversation to follow and help establish focus for not only the Product Owner but also the Development Team’s daily work.
Once goals are set, it’s time to set the practical exercise of determining how much time and money we have to work with. If time is fixed, then the work needed to accomplish the goals are created and refined. As the individual pieces of work are fleshed out and discussed, it becomes clearer to all the feasibility of the goals. This means it must be possible to modify the goals based on the realities unearthed.
Risks emerge once we understand not only the goal of our work but our plan to accomplish the work. These are typically technical dependencies, organizational deficiencies, dysfunctions, and market uncertainties. These are things that can be planned for, mitigated, and possibly eliminated through strategic action.
So how do you release plan in Scrum? The answer depends directly on your answer to the following question:
How often can you release working software?
Every software development activity is based on an assumption: this work is valuable because [fill in the blank]. The longer it takes you to confirm this assumptions means you are allowing risk to build.
If you release software every 30 days or less, your release planning becomes much simpler because the scope is simpler. Fewer goals are attainable and those goals tend to be smaller. This also means your risks tend to be smaller. In this environment, the Sprint Review, Retrospective, and Planning events might be release planning enough. Each of these events are opportunities to bring transparency, inspect progress towards goals, and adapt practices. Each contributes in their way to the formation of goals, forecasting scope, and mitigating risk through planning.
If you release software less frequently and you still keep to a Sprint of less than 30 days, you begin to incur additional overhead. Sprint Reviews won’t necessarily give you the market feedback you need since you only get market feedback when you have released your software. Scope becomes harder to forecast since the work horizon grows long. Risks become harder to predict and mitigate since so much may happen between when the work is planned and when it must be worked on. You should start to expect long, release planning meetings where not much happens of consequence.
…depends on you. Do you want big bang release planning or do you want light-weight release planning? There are ways to make big bang release planning more tolerable and less useless; however, facilitation improvements do not solve the problem represented when your goals are too big, your scope is too large, and your risks are too nebulous.
The answer is: have shorter releasable increments of software. This is a systematic improvement and will beat the pants off any procedural improvements you make. Here’s the short list of how Scrum helps you improve your system:
- Hold to a strong Definition of Done that ruthlessly beats back technical debt and describes a high quality increment of releasable software
- Have a releasable product increment every 30 days or less
Beyond what Scrum requires, do this: actually release your software and measure the impact.
Good luck out there.