Assigning Epics effort estimates is risky business. However, since organizations usually require schedules and budgets when uncertainty is at its highest, continuously defining effort as the decomposition process evolves may work. It must be remembered, no estimate is completely accurate but this process does offer a consistent measurement. This model begins by assigning high estimates and reducing the value as decomposition progresses. As with PBI’s, Epics efforts are determined by expressing uncertainty and difficulty through Fibonacci numbers. The sum of these represent the Epic estimate. This is not the only method, but it is one which I currently prefer.
How decomposition works
Agile Scrum is brilliant in how its simplicity forces the right questions to the surface. If the Epic is too uncertain or complex or both it is foolish to estimate its effort. The Product Owner reduces complexity by creating Product Backlog Items (stories). Generally, the more stories supporting an Epic, the less the overall uncertainty and complexity. As these stories are further decomposed into more stories, each story approaches an effort estimate in line with the development capacity benchmark. As the benchmark is reached, the PBI (story) can be allowed into the Sprint. For example, for some teams past burn down capacities (throughput) may confirm no single PBI (story) may be greater than 13 points.
How estimation works
If the diagram below represents an Epic, think of each section as a decomposition phase. The first box contains a story with 144 points, it is clear no development effort can be undertaken. As the PBI (story) passes through further decomposition, we see it is reduced to 89, then 34 and 21. Finally at 13 the benchmark is reached. It is development ready, however no story should be assigned an effort estimate of 13, if it is not clear enough to create a solution. At 13 points, the developer should be able to read the story and have a good idea what to do. Additionally, the story must contain a clear definition of done. (The ultimate demonstrable outcome of the story.)
Budgeting and Scheduling
Budgets and schedules can be calculated using production benchmarks, for example the maximum story points burned down during a sprint. Multiplying the cost per story point by the total points of the item at its current state of decomposition gives the cost of that backlog item. ($567 per point times 89 gives a price of $50,463 for this item) This same benchmark also indicates how long it will take to complete the task. If 309 story points, for example, are the maximum that can be burned down during a three week sprint, divide the item’s story points by the benchmark. (89 points divided by the benchmark of 309 demonstrate it will take .0288 sprints to complete the item.) The better the story is decomposed, the more accurate the cost and schedule becomes. In this example, it is important to remember a story with 89 points is still too uncertain and complex to include in a sprint.
Never simply guess
Asking a developer how much time something will take is not only unfair but unwise. If a developer simply gives an answer, they are likewise being unjust and unwise. They may also be committing themselves to 80 hour work weeks until something halfway workable finds its way into production. Continuously estimating each stage of the decomposition process is based on actual production performance and not a wild guess. This process is not perfect, but it is much more accurate than establishing budgets and schedules based on a series of wild guesses and generous estimation padding.
Resources used to create this example: