Organizations taking on agile almost always struggle with estimating. Years and decades of experience has taught the typical project manager that work is proportional to the difficulty of the task. This complexity is then expressed in hours to determine how long the project will take and how much it will cost.
Expressing a small project forecast as tasks and hours might look something like:
Task 1 22 hours
Task 2 12 hours
Task 3 14 hours
Task 4 9 hours
Task 5 17 hours
Total 60 hours
Duration 60 hours/6 productive hours per day = 10 days
Cost 10 days * $800 per day = $8,000
Does this look familiar? I am sure it does to most of you.
Now Scrum comes along and redefines this same work as a set of stories. I realize that this is not a perfect translation, but let’s redefine these tasks as stories. Let’s also assume we held a planning game and sized these stories in both story points and Ideal Person Days (IPDs). This looks something like:
Story 1 3 points 3 IPDs
Story 2 3 points 2 IPDs
Story 3 3 points 2 IPDs
Story 4 1 point 1 IPD
Story 5 3 points 3 IPDS
Total 13 points 11 IPDS
Cost (points) 1 point/day = 13 days = $10,400 ($800 per day)
Cost (IPDs) 11 * $800 per day = $8800
Finally, Kanban teams would estimate this as 5 stories. If your typical cycle time is 2.5 days, the duration for 5 stories would be 12.5 days and the cost would be $10,000.
A couple of interesting things are happening, as the estimating measure becomes less time-based, the estimates go up. In reality, they are probably becoming more accurate since most hourly-based estimates are low. Systems thinkers will tell you they are low since they do not factor in the inefficiencies of the system. Agile estimates get closer to reflecting the true velocity of a team.
The chart below shows the comparison side-by-side.
Task 1/Story 1
|Task 2/Story 2||
|Task 3/Story 3||
|Task 4/Story 4||
|Task 5/Story 5||
Now before the Agileists in the audience write me hate mail, I understand that tasks and stories are completely different things! I am just using this as a vehicle for comparing estimates. In practice, you would never just re-express tasks as stories.
Barriers to Agile estimates
Here are a few barriers you should expect when migrating to Agile estimates:
- Most senior managers and program managers have many, many years of experience working with hourly estimates
- Most managers don’t understand the inefficiencies that exist in the development environment
- Other projects in the organization use traditional estimating and they need a way to compare multiple projects for size, cost, and progress reporting.
- People just don’t understand them so they have difficulty comprehending the size of the project. It is like a foreign currency. If a cost is express in Czech korunas, an unfamiliar currency to many, they are going to want a way to translate this to something familiar like Euros, US Dollars, British Pounds, or Yen.
Some tips for migrating
In the initial roll out, I would suggest estimating both traditionally and using Agile methods. This will provide some comfort to the organization, but it may raise questions if the Agile estimates are higher. Be prepared for the statement – “I thought Agile was supposed to makes us faster”. At that point you may want to point to the “Actuals” for traditional projects, not the estimates! Most likely, the “Actuals” were much higher than the estimates.
Be sure that a champion has been identified that is committed to the Agile estimates and can field any questions and concerns.
Another type of estimating that can be used with more objectivity is function point analysis. If you are not familiar with this technique, a system is described as a set of functional components (screens, database tables, interfaces, reports, etc.). Estimating tools then compare this to historical data through the CoCoMo database to estimate a range of probabilities for project cost and duration. Other factors such as team cohesion and experience are also factored in. When first moving to Agile, I used function point analysis as a comparison point for our Agile estimates. Tools such as CostXpert work well for this purpose.
Final 2 cents on estimating
After working with many different estimating and project management systems, I can say unequivocally that moving to an elapsed time estimating system (cycle time) is the most accurate and efficient way to estimate projects. When I first saw Kanban and its use of Cycle Time, I had the same reaction as I did when I saw Lotus 1-2-3 running on an Apple II for the first time. I felt that both were game changers that fundamentally altered (for the better) the paradigm we’ve been using to do our job.
Remember that estimating is waste in Lean terms. Also, time spent on estimating has diminishing returns. You learn far more about the complexity of a system by building it than you do thinking about estimates.
And here’s another clue for y’all – there is little correlation between the estimated size of a story and the time it takes to implement it! A large development project was analyzed recently and it was determined that size of the story estimate did not translate directly to cycle time. The actual cycle times from previous projects was a better predictor than the size estimate.
So knowing your typical cycle time, your work in progress value, and the estimated number of stories, you can quickly create an estimate that is probably as accurate as any other technique. If you need to build 60 stories, your cycle time is 10 business days, and your work in progress is 5, Little’s law will compute the completion time as 120 business days (60 stories divided by 0.5 stories per day throughput). Refer to this article for more information on Little’s Law.
I would suggest moving to Kanban as quickly as possible. But along the way, you may need to estimate in multiple ways to provide your organization comfort with the Agile estimating process.