I’ve been using Ideal Days to help teams and help me plan work and measure progress since 1999. In most environments, this agile tool is far superior to the use of any duration or date-driven approach. Now, however, I much prefer the term Effort Days.
Durations and Dates Don’t Add Up
Here’s a simple thought exercise. Take three hypothetical tasks that each take two days to complete. Now, assume that the two days we are talking about for each task is two days duration. How long (in duration) will it take to complete three tasks that each take two days duration to complete? Six days? Two days? Pi? There is in fact no one true answer.
Each task might take only an hour of effort that must be spread over two days because of other dependencies. For example, creating a new test environment might take five minutes to file a request to have a DBA copy the production database and another 55 minutes hooking things up to that database. The two days duration is spent waiting for the DBA to complete your work request, and you could still spend that time completing other tasks that also have a two days duration estimate.
The difficulty with duration estimates is that they cannot be summed up in a simple manner.
Now, take our three hypothetical tasks and assume that the estimates are two effort days for each task. These estimates can be summed right up. Two plus two plus two equals six. There’s no guessing here. These three tasks will take a total of six effort days to complete. But I still haven’t answered my original question: how long (in duration) will it take to complete these three tasks?
To convert from effort days to duration, we need one more piece of information: velocity, an agile technique used to measure how much work an individual or team can complete within a specific increment of time. For our example, I am going to assume that one individual is completing this work and that this individual can complete work at a velocity of three effort days per week. So the answer to my original question (from an effort day perspective) is two weeks.
Here’s the math:
|Total Effort Days||6|
|Velocity (Effort Days Per Week)||÷||3|
|TOTAL DURATION:||2 WEEKS|
Every duration estimate is based on an implied effort estimate. If you ask me for a duration estimate on a task I will first think how much work the task actually takes me (the bare effort estimate) then add on padding to account for wait-states and distractions caused by the other tasks I may have to complete (the final duration estimate).
If we capture individual duration estimates then we lose the bare effort estimate and cannot convert back from duration to effort in order to sum up multiple duration estimates. If, however, we collect the bare effort estimate we can always add up multiple tasks and then derive a duration from them. It is these derived durations that enable us to commit to large deliveries of functionality within a given period. Meanwhile, the underlying effort estimates enable us to create powerful tracking mechanisms like the Burnup With Forecast graph that I discussed in my previous post.
The Difference Between Ideal and Effort Days is Subtle Yet Significant
Ideal Days come off as too abstract, difficult to grasp and too … well … ideal. I’d argue that any serious agile practitioner has, on more than one occasion, been too afraid to take ideal day estimates to management or even the customer, for fear of confusion between ideal days and real days.
The term Effort Days provides an immediate foil to duration. Management and stakeholders immediately recognize “Oh, we are talking Effort not Duration”. Now we can expose our estimates–even to management–so they can better understand our progress and better participate in prioritization activities. With the term Effort Days we no longer have to explain the nuances of ideal nor live in fear that our ideal estimates will be confused for duration-based commitments.