Agile teams have a valid need for sizing or estimating user stories. Most teams use a dimensionless scale such as story points for estimating. In some quarters “Ideal Days” are often held out as reasonable replacement for story points. When we look at the reasons for sizing stories and the ways in which ideal days open (or leave open) doors to traditional management styles that don’t support Agile development, we see that there is no real advantage to using ideal days and they tend to retard some of the paradigm shifts that need to happen for successful Agile adoption.
Why do Agile Teams Estimate?
Agile teams, with the Product Owner, estimate or size user stories for two reasons.
• Product Owners need to know how big a story is so that she can compare its relative worth to other stories. That is, in order to properly groom and prioritize the backlog the Product Owner needs to know both the value and the cost of completing the story.
• Teams use story estimates, in conjunction with an understanding of their historic velocity, to gauge how much work they can reasonably commit to when planning a sprint.
In both the cases we don’t need anything beyond relative consistency of estimates. Relative consistency means that, for example, any stories with a size of 5 are all about the same amount of work for the team to complete. Similarly, we would expect a story of size 10 would be about twice as much work as a size 5 story. A dimensionless relative size is all that is needed.
Agile “Estimates” are Intentionally Imprecise
It is a good practice to use predefined sequence of numbers such as a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc) or a geometric sequence (e.g., 1, 2, 4, 8, 16, 32, 64) for story sizes. This practice is good for two reasons.
First, it tends to reinforce “just enough” when it comes to estimates. Any estimate is, by definition, likely incorrect. Teams can waste a lot of time chasing an illusion of precision and accuracy when in practice, unknowns will almost always cause estimates to be inaccurate. They need to be good enough for the purposes discussed; any work to go beyond that is waste.
Second, sequences like Fibonacci Numbers or a geometric sequence, provide values that get further apart as they get larger. This helps build uncertainty and risk into estimates of larger pieces of work.
Story Points or Ideal Days?
Story Points are a true dimensionless measure. Any given team’s notion of what constitutes a “point” is independent of any other team’s estimates. My five point story may be twice as much work to complete as your five-point story. As long as my sizing is relatively consistent within my team and our stories it doesn’t matter if they are consistent with yours.
Ideal Day estimates are not really dimensionless. They are effort estimates, not abstract, dimensionless sizes. The standard for an Ideal Day varies, but for the sake of our discussion we will assume this definition: one Ideal Day represents the amount of work an average developer could complete in one eight hour day completely free of interruptions such as drop-ins, phone calls, meetings, etc. So, what is wrong with using Ideal Days? Ideal Days open the door, intentionally or not, to managers and PMS who seemingly can’t keep themselves from “doing the math” with Ideal Days.
Well, let’s see here. You are telling me that the team will produce 42 Ideal Days in the two week sprint. But I see that you have a 7 person team, so if we assume an 80% loading factor, the team’s output should be 56 Ideal Days (80% x 7 developers x 10 days). Shouldn’t the team be able to include a few more stories in the sprint?
Needless to say, such conversation seriously undercuts the team’s decision making and self-management!
Ideal Days also encourage comparisons between teams, since the basis for estimating is presumed to be standard.
Mary, I see that your team is averaging a velocity of around 7 Ideal Days per team member for the last few sprints. Bills team is averaging 8. That’s about 15% better! How come your team isn’t as productive as Bills? Can we boost their productivity a bit?
Given the intentional imprecision in Agile estimates, even with Ideal Day estimates much of the difference between Bill’s and Mary’s teams may be accounted for by that imprecision.
When managers and PMs start “doing the math” with Ideal Days we easily fall into a game where developers estimate not based their view of the work, but based on what they think the estimates should be to keep voices outside the team happy. That kind of lack of transparency is anything but Agile!
Managers and PMs are not, as a class, evil or stupid. The shift to a team-based, high trust paradigm is hard. Ideal Days allows them to more easily stay in the old paradigm and to keep using the tools they know how to use. Story points encourage us to shift our thinking to a more Agile mindset. Managers and PMs have a legitimate function. When they push back on dimensionless “estimates” in Agile our response should be to point out the risks inherent in things like Ideal Days and help them develop the skills and techniques to manage in an Agile environment.