Chapter 5. Estimating in Ideal Days
“To achieve great things, two things are needed: a plan, and not quite enough time.”
—Leonard Bernstein
How long is a game of American football?
You could answer that it has four fifteen-minute quarters and is therefore sixty minutes long. Or you could answer that it is somewhere around three hours long. Either answer would be correct in its own way. The difference highlights the distinction between ideal time and elapsed time. Ideal time is the amount of time that something takes when stripped of all peripheral activities. In that sense, a football game takes sixty minutes. Elapsed time, on the other hand, is the amount of time that passes on a clock (or perhaps a calendar). A football game requires around three hours of elapsed time.
Each way of measuring duration serves its own purpose. In a football game, ideal time is used by the officials to know when the quarters and game are complete. Certainly, that is a necessary function. On the other hand, if you’re going to the game, and your spouse asks how long you’ll be gone, it does you no good to say you’ll be gone sixty minutes. Rather, you’ll be gone for three hours (plus whatever travel time is needed).
It is almost always far easier and more accurate to predict the duration of an event in ideal time than in elapsed time. Suppose you are asked to estimate the duration of a specific football game this weekend. If you choose to give your estimate in ideal time, you can give a quick, off-the-cuff answer of sixty minutes. If you want to give a more precise estimate, you might look up the number of overtime games last year, crunch some numbers, and announce that, based on historical averages, this weekend’s game will last 62.3 minutes.
On the other hand, suppose you choose to express your estimate in elapsed time. Some games last year took two-and-a-half hours; other games took over four hours. Some of the difference is based on random events such as injuries, but another part of the difference can be attributed to the playing styles of the teams, how many penalties each receives, and so on. Televised games take longer because of extra timeouts for commercials. Weather can either prolong or shorten games, depending on the teams involved. To come up with an estimate that will be as accurate as your off-the-cuff ideal time estimate, you would need to consider each of these factors.
Of course, if I look at the programming guide on my television, it tells me that the game starts at 1:00 and ends at 4:00. Clearly, someone at the network has made a prediction in elapsed time. What do they know that we don’t know? A number of things. First, they plan to add or remove a few commercials based on how quickly the game is progressing. Second, most games are somewhere close to three hours. If the game finishes earlier, the network will run extra commercials, interviews, or other filler. If the game goes long, so what? Viewers interested in the game are likely to continue watching for another fifteen or thirty minutes. They won’t turn the game off simply because the program guide said it should be over at 4:00. Viewers who aren’t interested in the game but have tuned to the channel to watch a different show at 4:00 will also likely wait if the delay isn’t too long. Finally, after decades of televising football games, the networks have accustomed us not to expect a precise finish time.
This last difference is an important one. After years of this, most football fans know that when a football game is scheduled to end at 4:00, that is only an estimate. No one is surprised when the game goes till 4:15 (an overrun of 8%). They may be frustrated or annoyed but not surprised. Why, then, are we surprised when a software project estimated at twelve months takes thirteen (an equivalent 8% overrun)? Which duration seems harder to estimate?
Ideal Time and Software Development
On a software project, ideal time differs from elapsed time not because of timeouts, incomplete passes, and injuries, but because of the natural overhead we experience every day. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering email, making a support call to a vendor, interviewing a candidate for the open analyst position, and attending two meetings. More examples of why ideal time does not equal elapsed time are
• Supporting the current release
• Sick time
• Meetings
• Demonstrations
• Personnel issues
• Phone calls
• Special projects
• Training
• Reviews and walk-throughs
• Interviewing candidates
• Task switching
• Bug fixing in current releases
• Management reviews
Additionally, in looking at why ideal time does not equal elapsed time, consider that managers are able to work an average of only five minutes between interruptions (Hobbs 1987). Even if the typical developer is interrupted only one-third as often, that is still an interruption every fifteen minutes.
Problems can arise when a manager asks a team member the inevitable question: “How long will this take?” The team member responds, “Five days,” so the manager counts off five days on her calendar and marks the day with a big red X. The team member, however, really meant to say, “Five days if that’s all I do, but I do a lot of other things, so probably two weeks.”
On a software project, multitasking also broadens the gap between ideal time and elapsed time. A football player is never told by his coach, “Since you’re not busy on every play, I want you to play in this high-priority hockey game at the same time.” A software developer who is told to multitask loses a great deal of efficiency while switching between two (or more) tasks.
On a software project, we may choose to estimate user stories or other work in ideal days. When estimating in ideal days, you assume
• The story being estimated is the only thing you’ll work on.
• Everything you need will be on hand when you start.
• There will be no interruptions.
Ideal Days as a Measure of Size
When we estimate the number of ideal days that a user story will take to develop, test, and accept, it is not necessary to consider the impact of the overhead of the environment in which the team works. If developing a particular screen will take me one ideal day, it will take me one ideal day regardless of whether I’m employed by a start-up with no overhead or other demands on my time or by a huge bureaucracy. The amount of time that elapses on a clock (or calendar) will differ, of course. I may be able to achieve close to an ideal day of work at a low-overhead start-up. As additional demands are placed on my time, I have less time to work on deliverables for the project, and the amount of elapsed time to complete one ideal day of work will increase.
When considerations of organizational overhead are ignored, ideal days can be thought of as another estimate of size, just as story points are. Then an estimate of size expressed as a number of ideal days can be converted into an estimate of duration using velocity in exactly the same way as with story points.
One Estimate, Not Many
If you choose to estimate in ideal days, assign one aggregate estimate to each user story. Some teams are tempted to estimate a number of ideal days for each individual or group who will work on a story. For example, such a team might estimate that a particular user story will take two ideal days from a programmer, one ideal day from a database engineer, one ideal day from a user interaction designer, and two ideal days from a tester. I’ve seen teams then write the estimate on the story card with a different-colored marker for each role or on a different-colored sticky piece of paper for each role that is affixed to the story card.
In the vast majority of cases, my advice is not to do this. This level of focus on the individual roles on a team shifts team thinking away from the “we’re all in this together” mentality we’d like to exist on an agile team. Further, it vastly increases the amount of work necessary to plan a release. If each story is assigned an estimate for each role that will work on the story, the release plan should realistically take each role into account. This means we’d have to track velocity and remaining work for each role as well.
While this is rarely worth the additional effort, it may sometimes be necessary. I was with one client recently who is working on three versions of a product—one for the Macintosh, one for Windows, and one for handheld computers. In this case, it is absolutely critical that each version be released with exactly the same functionality. Further, the individuals on this team do not currently have the skills to switch among Mac, Windows, and handheld development. A team in this situation may want to estimate the ideal time for each role on each story. They should, however, be aware of the extra administrative burden this will require.
Summary
Ideal time and elapsed time are different. The ideal time of a game of American football is sixty minutes (four fifteen-minute quarters). However, three or more hours will typically pass on a clock before a sixty-minute game is finished. The reason for the difference, of course, is all the interruptions that may occur during the game.
The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days. Estimating in elapsed days requires us to consider all of the interruptions that might occur while working on the story. If we instead estimate in ideal days, we consider only the amount of time the story will take. In this way, ideal days are an estimate of size, although less strictly so than story points.
When estimating in ideal days, it is best to associate a single estimate with each user story. Rather than estimating that a user story will take four programmer days, two tester days, and three product owner days, it is better to sum those and say the story as a whole will take nine ideal days.
Discussion Questions
1. If an ideal day is eight hours of uninterrupted, focused work, how many hours of elapsed time in your environment equates to one ideal day?