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 schedule (time) is flexible.
Why Flex Schedule?
The most common reason a team would want to flex schedule instead of scope is when they are running a parity project; a project that is replacing the functionality of an existing system. Ideally the team would still only replace portions of the system at a time and use this method to plan each release. However, this planning method works even if this is not possible and an entire system needs to be released at once.
As with flexing on scope, this kind of planning requires two things. First, that you have a well-groomed and prioritized product backlog. Second, it requires the team to have been sprinting long enough to have a fairly predictable velocity. Lacking these prerequisites will reduce the accuracy of this method of planning.
Best and Worst Case Scenarios
Another similarity to flexing on scope is that this planning method requires a team to determine their best and worst case velocities. Rather than restating how to do that, I’m just going to refer back to the post on flexing on scope.
Planning for fixed scope is very straightforward. Simply add up the effort for all the backlog items that need to be in the release. We then essentially build a burn down chart for the release, plotting the projected burn given the team’s average velocity. After we’ve determined what the average burn looks like, we also draw lines for the best and worst case velocities. Now we’ve got a range of time that can be reported for completion. In the example below, we would expect the release to be finished in 5 to 8 sprints or so.
Just like with flexing on scope, we would update this burn with current data after each sprint. This will cause the date range to narrow as we get closer to completion.
What About Scope Creep?
Interestingly, I often hear the term “fixed scope” when what is really meant is “minimum scope.” The scope is rarely actually fixed; there are often requirements that have been missed, and in parity projects, not implementing those requirements isn’t usually an option.
What’s the best way to account for requirements that have been added to the release? Ok, maybe best way is a bit optimistic, but here’s how I do it. Let’s say we’re working the release from the chart above and 75 points worth of scope gets added to the release during the second sprint. I prefer adding the new scope below the original x-axis. This visually differentiates schedule changes based on newly introduced scope from those based on varying velocity. It’s important for stakeholders to understand the consequences of changes in scope and not blame changing schedules on “developer laziness.”
After adding the scope to the graph, we now draw a new baseline to get the expected schedule. We can now clearly see that adding 75 points to the scope pushed our delivery dates out to somewhere between 5.5 and 9 sprints from our start date.
I hope you find these planning techniques helpful. Let me know if there are other situations you run into that make planning difficult.