Epic Estimation Blindspot

Executive Summary

The key message of this document is that we must use only the teams' STORY POINTS velocity, ignoring bugs/tasks/subtasks points, when estimating the number of sprints to implement an epic.

Today’s formula

We use our team sprint velocity to estimate the number of sprints to complete an epic. We calculate team sprint velocity by averaging the team’s last four (4) sprints’ velocity. then divide that into the total point estimate for the epic to estimate the number of sprints required to implement the epic.

Estimated Number of Sprints required to implement an Epic = 

     Total number of points estimated to implement the Estimate

      / 

      Team Velocity 

Our team velocity calculations use the average of the unqualified sum of the points in the last few sprints. By unqualified I mean that, when calculating the number of points in a sprint, we add up the points for all issues completed in the sprint, including stories, bugs, spikes, and issues that we decided not to implement.

Sprint Points = 

      ∑ story points + 

      ∑ spike points + 

      ∑ bug points + 

      ∑ won’t do points

Our estimate to implement an Epic is the qualified sum of all the stories we identify as required to implement it; by qualified, I mean we include only the sum of its story points, without also estimating the bugs and spikes that we will have to implementing during the sprints to build the Epic.

Epic Points = 

      ∑ story points

The Blind Spot

There is a blind spot in these calculations!

Our blind spot is that we mix apples (numerators) and oranges (denominators) when computing the number of sprints to implement the epic. The numerator – the estimate to implement the epic’s stories – accounts only for story points, whereas the denominator – the team’s velocity – accounts for all points in the sprint, including stories, bugs, spikes and issues that we decided not to implement. Since velocity is a denominator, the higher it is the less sprints are required to implement the epic; in our case we estimate an artificially low number of sprints to implement an epic. 

Let's assume we have a team with a velocity of 57 points, and an epic estimated to require 121 points. Using our formula, 

Number of sprints to implement a 121 points Epic =

121 / 57 = 3 sprints

Now, using only story points to calculate the team’s velocity - lets pick 37 for the sake of calculation. Using our formula:

 Number of sprints to implement a 121 points Epic =

121 / 37 = 4 sprints

The growth from 3 to 4 sprints represents a 33% increase on the amount of time required to implement the epic, and we cannot underestimate its importance.

Improving our calculations

In order to improve the accuracy of our estimates we have to fix either the numerator or the denominator in our formula to estimate the number of sprints required to implement an epic.

If we choose to fix the numerator, we would have to estimate the points for the bugs, spikes, and issues that we will decide not to implement. If we choose to fix the denominator, we can change the way we compute our team’s velocity by using only story points. 

It is obvious that, being a data-driven calculation,  changing how we compute our team’s velocity is a lot more rigorous than trying to estimate the points for the bugs, spikes, and issues that we will decide not to implement for an epic.

Therefore, I recommend that we change our methodology to compute the number of sprints to implement an epic, and use our teams’ story point velocity, instead of their velocity:

 Estimated Number of Sprints required to implement an Epic = 

      Total number of points estimated to implement the Estimate

      / 

      Team Story Point Velocity 

Actual Numbers

Next, I include a brief analysis of our team’s impedance levels, as measured by their last four sprints, and how these relate to the teams’ actual sprint performance. Starting with calculating our teams’ velocity including bugs, spikes, and issues that we decided not to implement:

Then recalculating our teams’ story velocity, Taking into account only the stories they implemented:

Finally, comparing:

With these calculations, it becomes even more obvious that we must recalibrate our formulas to estimate the number of sprints required to implement an epic.

Dealing with impedance

Although some of our team’s impedance is natural – we will always have bugs and spikes – whatever we can do to reduce the number of non-story points in our sprints, the more efficient we will be.

How about the difference

We might be tempted to complement our teams’ sprints with enough points to add it up to the team velocity instead of leaving it at the team story velocity. Although we might want to address some bugs and have some spikes, we must keep them to a minimum, leaving a buffer to account for inevitably mid-sprint unplanned work.

When we load up our teams, we end up with many unfinished issues in our sprints, which is another phenomenon I’ll address in a future document.