Fibonacci Numbers & Dog Breeds?
Managers using the cost accounting method to estimate projects are often lost when it comes to calculating the cost of Agile Scrum projects. Where the cost accounting method typically uses cost of time per project task as a key variable, Scrum uses effort estimates and “time boxes”. To make matters worse, effort estimates assigned to tasks within these boxes are often measured by Fibonacci numbers or fruit, dog breeds, etc. It is easy to understand why managers can become frustrated. They are expected to reliably estimate the number of tasks, the time and cost involved and all Scrum gives them is a list of dog breeds.
A Simple Model
Based on input from the book, “Agile Estimating and Planning” by Mike Cohn, I’ve identified a simple model that works for me. I’m sharing it in the hope it may take the edge off the uncertainty involved in estimating your projects managed by the Scrum Framework.
The model is flexible enough to add any variable relevant to the project. PMI offers this high-level list…
- Cost of quality efforts
- Cost of risk factors
- Cost of project management time
- Costs of project management activities
- Cost directly associated with the project (labor, materials, training, equipment, etc.)
- Cost of physical office space or virtual office
- Profit (when applicable)
- Cost of overhead (management salaries, general office expenses, etc.)
The number of tasks is managed by the Sprint Backlog. Time is managed by the length of the sprint (“time box”). Cost is calculated by multiplying the sum of the variables by the sum of the effort applied to the sprint.
Basic formula
Variables
- C = production cost
- E = total expenses for the year
- W = work weeks in a year
- L = length of the sprint
- S = story point benchmark (decided by team)
Pseudo Excel Formula
C = (((E / W) * L) / S)
The model requires the following steps.
- Add all cost variables
- Calculate how much variables cost each week
- Identify your story point benchmark (example: highest number of story points burned down during a sprint)
- Multiply the weekly cost of the sprint by the length of the sprint
- Divide that sum by the number of story points, revealing the cost per sprint based on actual throughput.
- Use the throughput average of past sprints to calculate the cost of future sprints.
Benefits of this Model
The benefits of calculating project costs based on historical throughput are self-evident. If not I recommend you get a good book on Lean manufacturing such as, “The Goal” by Jeff Cox and Eliyahu Goldratt or “Going Lean” by Stephen Ruffa. The model uses the throughput average (mean) and not the median. Since a hallmark of Agile Scrum is continues improvement (Kaizen), our calculations should include sprints of exceptional performance.
I may cover this in more detail in a later post, but cost predictions reported by the model become more accurate as stories are better defined. The more general a backlog item or Epic the higher the effort estimate. As the stories are broken down with enough detail to create a solution and fit into a Sprint, the lower the effort estimate may become. This may mean, for example, an Epic originally estimated at 89, may actually require stories totaling only 55 points. On the other hand an Epic at infinity clearly indicates no estimate is possible, until its requirements are better understood. Epics totaling more story points than fit into available sprints (“time boxes”), confirm compromise is required.
By reaching improvement goals set during the retrospective, the model also reflects the reduced cost of production. Lower production costs present the organization with a number of market advantages such as lower cost resulting in larger market share.
There is the added benefit of team participation. Teams want to succeed and they love a good challenge. After the team gets comfortable with estimation by comparing Fibonacci numbers thy will certainly be happy to commit themselves to a story point per sprint benchmark. You can even use this as a game between teams. This moves production cost calculations from something done behind closed doors and out into the open.
It is not necessary to throw Agile Scrum out the window when calculating project costs. Embracing this framework along with Lean ideas and leveraging Kaizen an organization will soon learn, accurate projections come by being Agile.
Click here to view an example of this model.
Books I used to develop this model:
- “Agile Estimating and Planning” by Mike Cohn
- “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland
- “The Goal” by Jeff Cox and Eliyahu Goldratt
- “Going Lean” by Stephen Ruffa