If you lead software development teams, then you likely have had this reaction to the management decree of delivering some set of software features by an arbitrary date. Sometimes that is followed by therapy and/or a quick update of your resume. In an agile world, project schedules that are derived from executive fiat will ultimately lower product quality and destroy the team, not necessarily in that order. That’s what happens in the traditional world too, it just may not be so apparent.
Agile teams don’t predict progress based on intuitive estimates of “I think that takes 7 hours”. Progress is projected based on the past history of the team. In the last 5 iterations the team completed work of a certain relative size. Based on that pace, it will take x number of iterations to complete the work currently on the product backlog. An example; the product backlog has 150 points of work left and the team is completing 15 points per iteration. It will therefore take 10 iterations to complete the work on the backlog.
That sounds simple enough, but actually I don’t want a team to commit to completing certain features by a certain date, even if it is basing that commitment on their velocity against the size work remaining on the backlog. That presumes a precision that likely is not reality. Although we think the features on the backlog are 150 points, as we start doing that work we will learn more and realize that we forgot something when we sized the feature, or discovered that something else is needed to deliver a feature, or there is something on the backlog that we don’t really need to do at all.
What I want to do instead is make the schedule a shared responsibility between product management and the development team. Product management gets to say “what”; the development team gets to say “how fast”. So I want to team to commit to a velocity, actually a range. Once the team has some history, they can agree that their velocity shouldn’t fall below some number and is not expected to exceed some other number. With some confidence it could say its velocity will be between 20 points and 30 points per iteration. In his book Agile Estimating and Planning, Mike Cohn advocates calculating these two numbers by averaging past velocities for the worst three iterations for the worst case, and of the last eight iterations for the most likely case. Armed with these two numbers, product management can then easily see that if 5 iterations remain before a desired delivery date, then the team can deliver somewhere between 100 (5 x 20) and 150 (5 x 30) points worth of features and can prioritize the remaining work accordingly.
Going a step further, we could also calculate a best case by averaging the velocities of the best three iterations. Consider the iteration history shown here. The average velocity of all eights iterations is 17 points; that is the team’s most likely velocity. Best case is 20 points (average of 21+19+20) and worse case is 13 points (average of 11+16+13). Assuming the product backlog started at 250 points. That allows us project a release burndown as shown here.
Through iteration 8 the team has 132 points remaining. The team may be done with this work as early as iteration 15, as late as iteration 18, but most likely at the end of iteration 16.
Now in partnership, product management and the development team can both act responsibly to align the delivery date to meet the business needs. If the team is not finishing earlier enough, we can either work on removing whatever impediments that are not allowing the team to move faster, or we can remove some lower value scope from the release.
Either way the team is working at a sustainable pace, product management understands what is being delivered when, and that therapy session can be saved for another day.
