Chapter 8. Choosing between Story Points and Ideal Days
“If you tell people where to go, but not how to get there, you’ll be amazed at the results.”
—General George S. Patton
As measures of size, story points and ideal days each have their advantages. To help you decide which one to use, this chapter outlines the key considerations in favor of each approach.
Considerations Favoring Story Points
This section outlines the key points in favor of estimating in story points. These include
• Story points help drive cross-functional behavior.
• Story-point estimates do not decay.
• Story points are a pure measure of size.
• Estimating in story points typically is faster.
• My ideal days are not your ideal days.
Story Points Help Drive Cross-Functional Behavior
One of the reasons why agile teams are successful is that the teams are cross-functional. That is, agile teams include members from all disciplines necessary to build the product, including programmers, testers, product managers, usability designers, analysts, database engineers, and so on. Often, when we first assemble a cross-functional team, some members have a hard time letting go of their departmental identity. The product will benefit to the extent that the project participants view themselves as team members first and as specialist contributors second—that is, “I am on the Napa project and am a tester” rather than “I am a tester assigned to the Napa project.” The distinction may be subtle, but the change in mindset is not.
Estimating in story points can help teams learn to work cross-functionally. Because a story-point estimate needs to be a single number that represents all of the work for the whole team, estimating story points initiates high-level discussions about everything that will be involved. Estimating ideal days, on the other hand, often involves specialty groups estimating how long “their part” of a story will take and then summing these subestimates. For example, the programmers may conclude that they need three ideal days, the database engineer needs one, and the tester needs two. An estimate of six ideal days is then assigned to the story.
This small difference in how the earliest discussions about a story occur has an ongoing impact on how the story is developed.
Story-Point Estimates Do Not Decay
An estimate expressed in story points has a longer shelf life than an estimate in ideal days. An estimate in ideal days can change based on the team’s experience with the technology, the domain, and themselves, among other factors. To see why, suppose a programmer is learning a new language and is asked how long it will take to program a small application. His answer may be five days. Now jump forward a few months and ask the same programmer how long it will take to develop an application that is exactly the same size and complexity. His answer may be one day because he has become more skilled in the language. We have a problem now, because the two applications are exactly the same size, yet they have been estimated differently.
We would like to think that measuring velocity over time would correct or account for this problem. It won’t. Instead, we’ll see a consistent velocity even though more work is being done. Suppose that this programmer is the only person on the team and that he is working in one-week iterations. The first time he develops the application, he has estimated it will take five ideal days. Let’s suppose he’s in an environment where a calendar day equals an ideal day. He starts this application on the first day of the iteration and finishes it on the fifth. He has a velocity of five for that iteration. Then, a few months later, because he estimates a similar application as one ideal day, he will complete five of them in an iteration. His velocity is again five, even though he did five times as much work as before. For some projects, especially those adopting new technologies or on which the team is new to the domain, this can be significant.
Note that both story-point and ideal-day estimates will need to be updated if the size of an effort changes based on the development of a framework, for example. However, only ideal-day estimates need to change when the team becomes better at something.
Story Points Are a Pure Measure of Size
As described in the introduction to this part, an important first step in estimating how long something will take is estimating how big it is or how much of it there is to do. Story points are a pure measure of size. Ideal days are not. Ideal days may be used as a measure of size, but with some deficiencies. As noted in the preceding section, an estimate in ideal days will change as a developer’s proficiency changes. This does not happen with story points—the size is what it is and doesn’t change. That is a desirable attribute of any measure of size.
That story points are a pure measure of size has a couple of advantages. First, this means that we can estimate story points by analogy only. There is credible evidence that we are better at estimating “this is like that” than we are at estimating the absolute size of things (Lederer and Prasad 1998; Vicinanza et al. 1991). When we estimate in ideal days, on the other hand, we can still estimate by analogy. But when estimating in ideal days, we also tend to think of the calendar and how long a story will take to develop.
Second, because story points are a pure measure of size and are entirely abstract, there can be no temptation to compare them with reality. Teams that estimate in ideal days almost inevitably have their ideal days compared with actual days. They then find themselves justifying why they completed “only” eight ideal days of work in a ten-day iteration.
Estimating in Story Points Typically Is Faster
Teams that estimate in story points seem to do so more quickly than teams that estimate in ideal days. To estimate many stories, it is necessary to have a very high-level design discussion about the story: Would we implement this in the database? Can we reuse the user interface? How will this affect the middle tier? All these questions come up at one time or another.
My experience is that teams estimating in ideal days have a tendency to take these discussions a little deeper than do teams estimating in story points. The difference is presumably because when estimating in ideal days, it is more tempting to think about the individual tasks necessary to develop a story than to think in terms of the size of the story relative to other stories.
My Ideal Days Are Not Your Ideal Days
Suppose two runners, one fast and one slow, are standing at the start of a trail. Each can see the whole course of the trail, and they can agree that it is one kilometer. They can compare it with another trail they’ve each run and agree that it is about half the length of that other trail. Their discussions of trail size (really distance, in this case) are meaningful.
Suppose instead of discussing the length of the trails, these two runners discussed the time it took to run the trails. The fast runner might say, “This is a five-minute trail,” to which the slow runner would respond, “No, it’s at least a eight-minute trail.” Each would be right, of course, but they would have no way of settling their differences other than agreeing always to discuss trails in terms of how long one of them (or some other runner) would take to run the trail.
This same problem exists with ideal days. You may think you can completely develop a particular user story in three ideal days. I think I can do it in five days. We’re probably both right. How can we come to an agreement? We might choose to put your estimate on it because we think you’ll be the one to do the work. But that might be a mistake, because by the time we actually do the work, you may be too busy and I have to do it. And I’ll be late, because it’s estimated at three days for you, but will take me five.
What most teams do is ignore this issue. This is acceptable if all developers are of approximately the same skill or if programmers always work in pairs, which helps balance out extreme differences in productivity.
Considerations Favoring Ideal Days
This section outlines the key points in favor of estimating in ideal days. These include the following:
• Ideal days are easier to explain outside the team.
• Ideal days are easier to estimate at first.
Ideal Days Are Easier to Explain Outside the Team
There is a very intuitive feel to ideal days—“This is the amount of time it would take me if it’s all that I worked on.” Because of this intuitive feel, ideal days are easy to understand, which makes them easy to explain to others outside the project team. Everyone understands that not every minute of the work day is spent programming, testing, designing, or otherwise making progress toward new features.
It is usually necessary to explain to outsiders (and the team, at first) the concept of a story point as a measure of size. However, you can often use the need to explain story points as an opportunity to describe the overall approach to estimating and planning your project will take. This is an excellent opportunity to accustom outside stakeholders to ideas such as the cone of uncertainty, the progressive refinement of plan accuracy, and how observing velocity over a number of periods will lead to greater reliability in the plans you produce.
Ideal Days Are Easier to Estimate at First
In addition to being easier to explain to others, it is often easier for the team itself to get started with ideal days. When a team chooses to estimate in story points, the first handful of stories they estimate can be difficult to estimate or have an unsettling feeling. Without a baseline such as a nine-to-five day or some previously estimated stories, the team that uses story points has to find its own baseline by estimating a few stories.
Fortunately, most teams get through this initial phase of story-point estimating very, very quickly. Usually within an hour, many teams estimate in story points as naturally as if they’d been doing it for years. However, those first few stories can feel uncomfortable.
Recommendation
My preference is for story points. I find that the benefits they offer as pure measure of size are compelling. That story points help promote cross-functional team behavior is a huge advantage. Shifting a team’s thinking from “my part will take three ideal days, and your part will take two ideal days, so the total is five ideal days” is very different from “overall, this story seems about the same size as that one, so let’s call it five story points also.” That a story point to me can be the same as a story point to you, while the same may not be true of an ideal day, is another big benefit. Two developers of different skill or experience can agree on the size of something while disagreeing about how long it will take to do.
The shortcomings of story points are indeed short. Yes, it’s easier to get started with ideal days. However, the discomfort of working with nebulous story points is short-lived. Ideal days are definitely easier to explain to those outside the team, but we probably shouldn’t choose based on how hard it will be to explain to outsiders. That ideal days are so easily understandable causes problems as well. In some organizations there will be pressure to make an actual day closer to an ideal day. Pressure for more focus and concentration on our work is fine. But organizational pressure for each actual day to be close to an ideal day will also have the effect of causing us to estimate in actual time while calling it an ideal day. That is, an ideal day will become redefined as “a day where I make six hours of progress and do other things for two hours.”
I occasionally start a team estimating in ideal days. I usually do this only with a team that cannot accept that it is beneficial to separate estimates of size and duration. Some individuals are so used to being asked for estimates and responding immediately with a date that the jump to story points is difficult.
In these cases, I have the team start estimating in ideal days, but as quickly as possible, I start to ask questions like “How big is this one compared with the one we estimated five minutes ago?” Or I’ll ask, “So this one is a little smaller than the story we just estimated?” The purpose of these questions is to shift the conversation to be more abstract and about the relative size of the stories than about how long it will take to design a screen, code a stored procedure, and write some HTML. In this way, a team can start with estimating in ideal days but gradually separate their estimates from a number of days.
Summary
A team can choose to estimate in either story points or ideal days. Each is a viable choice with advantages to recommend it.
Story points have the advantage of helping promote cross-functional team behavior. Additionally, because story points are a more pure measure of size, they do not need to be re-estimated if the team improves in a technology or the domain. Estimating in story points is often faster than estimating ideal days. Finally, unlike ideal days, story points can be compared among team members. If one team member thinks something will take her four ideal days, and another team member thinks it will take him one ideal day, they may each be right, yet they have no basis on which to argue and establish a single estimate.
Ideal days have the advantages of being more easily explained to those outside the team and of being easier to get started with.
My preference is for story points. The advantages of estimating in story points are more compelling. If a team is struggling with the concept of estimating pure size, I will start them estimating in ideal days but will then convert them to story points. I do this by asking more questions such as “How big is this compared with the other stories we’ve estimated?” rather than “How many ideal days will this take?” Most teams hardly notice the gradual switch, and by the time they do, they are thinking about points rather than ideal days.
Discussion Questions
1. Which approach do you prefer—story points or ideal days? Why?
2. How might you introduce this to your organization? What obstacles do you anticipate, and how could you address them?