Determining Duration on Scrum Projects

1. Posted on August 6, 2010 5:41:PM by John Clifford to Retrospectives
2. 
   Methods & Processes, Technique, project management, Agile, Scrum, planning, estimation, Management

One thing I’m often asked is, how do you come up with valid project estimates in Scrum? After all, Scrum doesn’t want you to worry about more than the current sprint, does it?

The basic rule of estimation is, estimate size/effort/complexity and then derive duration. For Scrum, we follow the industry best practice of using story points, an arbitrary measure of relative effort/size/complexity that is not time-based. Let me explain by using one of the analogies from my training.

It’s much harder to estimate duration (how long something will take) than effort (how much work it will take). And, duration is a product of effort times specific ability (velocity). For example, if I asked a group of people to give me an estimate of how far it is from Los Angeles to New York, I’d get answers that were considerably more accurate than if I asked that same group to estimate how long it would take to travel from Los Angeles to New York. Am I going by plane, or by train, by automobile, by bicycle, or am I walking? Similarly, while all of us could reasonably accurately estimate how far a mile is, could we reasonably estimate how long it would take to run that mile? The point is, the amount of work to be done is a constant while the time required to accomplish that work is dependent upon the people doing it. And, while a mile remains a mile, our ability to run that mile improves as we get in better condition. Similarly, a software development team’s ability to accomplish work improves as their knowledge and processes improve. You can’t do more than 24 hours of work in a day, but you can run further in ten minutes next week than you can this week, because your velocity (ability to do work over time) has increased.

So, recognizing the reality of the Cone of Uncertainty (that we really can’t provide precise commitments at the beginning of a project because we simply don’t know enough, and the only way we will know is to do enough work to discover most of what we don’t know), we estimate the effort of each backlog item in our product backlog (decomposing items that we are having difficulty estimating because the work is too large) using estimation by analogy, estimation by consensus, wideband Delphi variations, and other estimation techniques (favoring the simpler approaches because we care more about accuracy than precision and we know the Law of Large Numbers will be our friend), then determine an initial team velocity (the rate at which the team can fully implement functionality), and then we do the math, e.g., if the estimates for all of our backlog items totals 500 points and we believe we can accomplish 50 points per 2-week sprint, then we have roughly 10 sprints worth of work. Of course this is an estimate, and thus should have either a range or confidence figure attached. As an example, I might provide the formal estimate as ’10 sprints +25%/-10%’ based upon my experience with the team and my evaluation of their understanding of the work.

The most accurate information one can use to predict performance on a project is historical data on that project. We get that with Scrum because we track the implemented functionality for each sprint, and so we’d update the projected number of sprints to release after every sprint using the moving average of the last two or three sprints’ project velocity (team velocity, defined above, minus scope velocity, defined as the rate at which new functionality, in terms of items and their associated story points, are being added to the backlog for this release). For example, we may find that after two sprints our team velocity averages 45 points per sprint, but we have added 20 points of additional scope, making our project velocity 35 points per sprint (45 – 20/2), and if our remaining points equals 430 points (500 – 90 + 20), then assuming our project velocity remains constant we have another 13 sprints to go (430 divided by 35 rounded up to the nearest integer). If we’d stop adding scope, we’d only have another 10 sprints to go; another way of saying this is that we’ll push the release date out by 30% if we keep adding scope at the current rate.

I know this sounds simplistic, but I have seen in my own experience how well it works. If you think about it, Agile estimation and tracking is a simpler relative of EVM, and it is based on the same sound principles.