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.

Trent said:

October 29, 2010 12:02:AM

Estimation is almost an art form. I definitely use metrics from past projects and everything else at my disposal to estimate as accurately as possible. But with most projects I also base part of the estimate on my sense of how long it will take. Sometimes this lengthens the estimate, other times is shortens it. But in the vast majority of cases it makes the estimate more accurate.

Post a Comment:

 
 

John Clifford

John Clifford is a Senior Fellow and Agile Practices Lead at Construx Software. John got his first software development job at a startup, while still in college, in the early 1980s. He started and ran a successful software company when he was 23. His career includes almost six years at Microsoft, where he was one of the original developers on the Microsoft Project for Windows and Mac team.

With more than three decades of IT experience, John has developed software across the spectrum of computing environments, ranging from desktop and mobile device applications to low-level frameworks, device drivers, and asynchronous communications protocols. Prior to joining Construx, John’s career included stints as a software development engineer, product feature team manager, group QA manager, group project manager, and development director.

At Construx, John focuses on software development, project management, product management, and team and organizational management practices, with an emphasis on Lean and Agile methodologies. As a manager, and as an external consultant, John has led numerous successful organizational transformations to Scrum and Lean/Kanban. He holds Certified Scrum Master, Certified Scrum Product Owner, and Certified Scrum Practitioner certifications from the Scrum Alliance. John was invited to become one of the charter Kanban Coaching Professionals from the Lean Kanban University, the professional association and standards group for Kanban Method training and coaching. As an adjunct instructor, John also teaches a course on applying Lean and Agile principles and practices for the University of Washington’s Professional and Continuing Education program.

Contact John