Agile release planning can be approached in a number of ways depending on the nature of the organization’s business. If the organization is developing software to a customer contract then the contract is the backlog. The team will typically have little flexibility with scope and will likely be held to delivering a specific feature set at a specified cost within a defined schedule. In this case the team may need to estimate the entire feature set up-front. However, contracts can be structured to deliver subsets of the total scope using, say, quarterly releases. Most software businesses are however roadmap-driven, that is, product capabilities are set as goals in a multi-year plan, with periodic product releases planned to deliver subsets of the roadmap to market. In this kind of environment, planning would be carried out at three levels – Roadmap, Release and Iteration. One way of looking at the product roadmap is to consider it to be a high-level plan for how the product backlog gets delivered over say, the next twelve-month period. Release plans are derived from the overall product backlog, and iteration plans are derived from release backlogs. The following diagram illustrates this.
The Product Backlog is a release-independent list of every conceivable requirement, feature request, enhancement, and wish-list item for the product. This list is derived from a variety of sources, including, product management, sales and marketing, customers, engineering, customer support, and virtually anyone who feels they have a stake in the product. For reasons of budget, engineering resources, market windows, and other constraints, not all product features can (or should) be delivered in a single release. Therefore a plan is required showing how features in the product backlog will be brought to market over a series of product releases. This high-level plan is usually referred to as the product roadmap. The product roadmap shows how major new product capabilities get rolled out over time. The product roadmap is the product backlog turned on its side. The time increments for each release are ideally based on a regular tempo or fixed timebox – just like scrum iterations – with perhaps a release every calendar quarter. The release content for each release is usually stated in terms of major product functions, not user stories.
The product roadmap will be validated by discussions with customers on the one hand to get the priorities right, and internal stakeholders on the other hand to confirm the technical and budgetary feasibility of delivering in the timeframes targeted. The product backlog is constantly revised and updated as customer and market requirements continue to evolve.
The starting point for release planning is a set of features proposed for the release. Initially, these may simply be high-level statements about the general intent of each feature, however it is important that the features be ranked in order of business importance. Next, beginning with the highest ranked feature, we work to flesh out the details. This step is a collaboration between the product owner, the product architect and the development team (at least those individuals from the team that can participate effectively in this exercise). This exercise could be done by getting everyone together in a room for 1 or 2 days, with whiteboards and post-its, or, it could be done more asynchronously using tools that support collaboration. In the case where we have a highly complex system and each feature requires a detailed analysis and subsequent review, then this is going to take longer. The overall goal is to get each feature into what we described earlier as the ‘Defined’ or ‘Development Ready’ state – one from which development teams can start creating user stories and test cases. Do we need to wait until all features are ‘Defined’ before proceeding with user story creation? Of course not. User story creation should begin as soon as the first feature is defined.
Agile planning is designed to be adaptive. The principles behind this approach are:
- Plans should only be as detailed as the depth of information currently available
- Planning must be continuously adjusted as project knowledge improves.
1. Get Features Defined
As a prerequisite, begin the process of getting features properly defined as described in the last chapter. ‘Defined’ (or, ‘Development Ready’) means that there is sufficient information for development teams to begin creating user stories and test cases.
Creating user stories from poorly defined requirements amounts to waste, and teams must adhere to the discipline of getting requirements accurately stated before proceeding with development. Unlike classical waterfall, development can begin as soon as enough features are defined to feed the first one or two iterations.
Refinement of the release backlog to get features into a defined state and to re-rank items as circumstances change, is a process that should be done continuously throughout the release.
2. Create User Stories
For those features that are sufficiently defined, break them down into iteration-sized user stories, beginning with the highest-ranked features. User stories should be small enough to be deliverable in a single iteration. Thus, each story needs acceptance criteria. As input to the release scoping process, stories need to be sized . The use of ‘story points’ – a technique for establishing the relative sizes of each story – has become a popular practice for this step. (For more on story points see below). When user stories for all features have been defined and sized, we are ready to set the initial scope for the release. Note, for large programs it may be unrealistic to plan every feature into this level of detail in a single step – that’s the waterfall approach. However, for fixed-price contracts, a team may need to come up with an initial, non-binding, estimate that is firmed up over time. One approach may be to only commit say, 90-days (6 * 2-week iterations) of functionality in a single cycle, and deliver all of the required features via a number of these 90-day cycles.
3. Continue Release Backlog Grooming
Remember that in contrast with classical waterfall development, agile development can begin as soon as we have enough features defined to feed the first one or two iterations. As the release proceeds more features become fully elaborated into user stories, and become available for sprint planning. Also, sometimes feature priorities may shift and this needs to be reflected in the plan.
Backlog Grooming or, Backlog Refinement, is a process to get the top of the release backlog into shape for sprint planning. This means having features broken out into user stories with size estimates for each story. Although not identified as one of the core activities in scrum, it is acknowledged to be a key process to ensure that the flow of a project proceeds smoothly without delays or interruptions. Hence this should be an ongoing activity throughout a project with perhaps one meeting per week dedicated to it. Participants should include the product owner and team. The output of the process may include a re-ranking of features and stories, addition of new features/stories, and removal of ones no longer considered essential to the program. Features are split out into user stories, and user stories elaborated into sufficient detail, including acceptance criteria, so that the development team can proceed with sprint planning and execution without delay.
Release-Level Scope Setting.
It is important to note that adaptive planning does not mean that cost and schedule remain an open question for the duration of the project. It is expected that by then, the team will have completed analysis of all requirements within the first few iterations. In the case where we have fixed-price contracts, the contract should be structured to include an early milestone where requirements are agreed by both customer and supplier, and baselined. Mechanisms for changing requirements beyond this baseline, should be defined in the contract.
Scope setting example (assume 2-week iterations):
- Project start: Jan 01
- Project finish: Jun 30
- Duration: 26 weeks
- Iterations: 13 (26/2)
- Team Velocity: 20 (points per iteration)
- Maximum deliverable points: 260 (13 X 20)
In this example, and assuming the team’s velocity is fairly accurate, and that the features are correctly ranked, they can only deliver the first 10 features (a total of 249 story points). To complete all 12 features the team would require a further 3 iterations. This team now has a good set of data to go back and work with the business stakeholders to reach agreement on a scope/schedule trade-off.