In this series of posts, I’ll be addressing the misconception that it’s not possible to plan releases using agile methodologies. In a previous post, I talked about the three sides of the “Iron Triangle” that can be adjusted when project milestones start slipping. In this post, I’ll talk about planning releases for a Scrum team where scope is flexible.
Why Flex Scope?
A team might choose to be flexible on scope when they are making releases on a regular schedule, or if requirements need to be implemented by a hard date. In this situation, because the release date is set, if milestones are slipping, the product owner will need to make decisions on which features must be in the release and which can be postponed for a later release. Let’s talk about how the business can make plans around which features are likely to make it in a release and which won’t.
Planning in this way assumes two things. First, it assumes that you have a well-groomed and prioritized product backlog. Second, it assumes that the team has been sprinting long enough to have a fairly predictable velocity. If these prerequisites are not met, this method of planning will not be particularly accurate. This inaccuracy isn’t a symptom of trying to plan for an agile methodology, though. Planning without those prerequisites would be similar to trying to plan a waterfall project without having good requirements and without knowing your resource availability.
Best and Worst Case Scenarios
With this kind of planning, the team must first decide on a best and worst case velocity. This can usually be done informally because these values will be refined as sprints are completed.
Let’s imagine a team has an average velocity of 40 story points. After some discussion, the team decides that if a sprint goes horribly; if everything that can go wrong does, then they would likely get a velocity of about 25 points. Then the team talks about an amazing sprint. One where the Scrum gods smile upon them and absolutely everything goes right. They decide that if that were to happen, they might have a velocity of around 55 points.
The team then uses these numbers to determine a range of points they can complete by the release date. In this example, let’s assume the release is to happen after six sprints. The team calculates the number of points they should be able to complete for the best case and for the worst case.
Worst case points: 25 * 6 = 150
Best case points: 55 * 6 = 330
The team then draws lines on their backlog at those values. All the stories above the worst case line will definitely be ready by the release date; even if everything goes wrong in every sprint, the team will still complete those stories. All the stories below the best case line will definitely not be done by the release date; even if everything goes perfectly in every sprint, the team cannot get to these stories. The stories between the two lines are maybes; the team may or may not complete them depending on what happens during those sprints. At the beginning of the six sprints, the team can’t be more precise that this; they will continue to refine the estimate as they sprint, though.
After each sprint, the team will recalculate the best and worst case lines based on how many sprints are left. For example, after three sprints, with three sprints remaining, the worst case will be 75 points (25 * 3) and the best case will be 165 (55 * 3). The team then redraws the lines for the backlog items that have yet to be completed. As the release approaches, the number of stories the team knows they will complete will increase. Similarly, the number of stories the team knows they will not complete will also increase while the unknown section will shrink. This will allow the product owner to be more and more confident about what will and will not be in the release as the development progresses.
Planning With the Customer
As the scope estimates are refined, the product owner, working with the customer can determine if the stories are still prioritized correctly. Sometimes there are features the customer feels must be in the release, but after a handful of sprints it becomes apparent that they will likely not meet the cut. When this happens, the customer can start working with the product owner to re-prioritize as soon as this is discovered.
Take it to the Next Level…
Some people may feel uncomfortable with the team just deciding what their best and worst case velocities should be by using the old “wet finger in the wind” method. If this seems a little unscientific, it is possible to add some rigor if you have historical data on the team’s velocity. If this is the case, you can calculate the mean and standard deviation for the velocity over a period you feel comfortable with and use these values to come up with minimum and maximum velocities with given confidence levels.
By taking this data-driven approach, it is now possible to produce scope estimates that also include a general confidence level in that estimate based on historical data and typical variation in velocity.
Hopefully this has gotten you thinking about the kinds of information you can share with your project stakeholders for schedule-driven efforts. I’ll demonstrate a similar technique for scope-driven planning soon.