TL;DR
Mapping story points to time is an anti-pattern. If you must do this because your work environment requires it then you have work to do to educate and evangelize agility at your workplace. Q.E.D.
To be successful at agile estimation, make sure that the whole team and the stakeholders within the organization all agree on what your estimating techniques actually measure. Furthermore, be sure to routinely sanity-check the results of your planning techniques to ensure that the iteration time box is being respected!
Story Points Measure Effort
So, what do story points measure? They measure effort. To a lesser extent, they also measure complexity, risk, and uncertainty insofar as those things may influence effort, but the metric itself is only about the level of effort involved in completing a deliverable. For example, in his blog post "Don't Equate Story Points to Hours," Mike Cohn says:
Complexity influences an estimate, but only to the extent the extra complexity affects the effort involved in doing the work. Walking to the one-point building while singing “Gangnam Style” is probably more complex that walking there without singing. But the extra complexity of singing won’t affect the amount of time it takes me to walk there, so my estimate in this case would remain one.
If you're only going through the motions of treating relative-sizing as an unanchored level-of-effort estimate, then stop doing it and just measure time directly. You won't be any more accurate in your planning activities, and in fact may be less so, but at least you won't frustrate everyone by calling a comb a "dinglehopper" as Princess Ariel does in The Little Mermaid.
Measuring Time with Boundaries
Even Mike Cohn admits that story points indirectly measure time, but only indirectly. That's because in agile frameworks like Scrum, we really only care about two time boundaries:
The daily standup. We care about whether coordinated tasks are on track or not, and can use the 1-2 day rule of thumb for tasks to determine whether or not a story is on track or at risk. However, the standup-to-standup timebox is a process control, not a measure of velocity or a benchmark for team accuracy.
The Sprint or iteration size. In the final analysis, all that matters is whether the Sprint Goal can be met. If the goal can't be met within the timebox, then the the level of effort exceeded the team's capacity and the work was improperly planned.
The only essential measure of time within Scrum is whether or not planned work is done or not-done at the end of the Sprint. Ideally, you use your velocity to ensure that the team doesn't take on more work than can be done in a single Sprint and to do release planning, but these measurements are about per-Sprint capacity for work, not directly about time.
Scrum is about using forecasts of team capacity to manage the scope of work to fit into predictable time boxes. It is not about highly accurate task-level time estimates, or about flogging the team to work harder or faster. The key is to develop a predictable cadence!
Sanity-Checking Workloads Using Sprint Boundaries
Okay, so pretend for a minute that you're actually drinking the Kool-Aid. That means that you accept the following a priori:
- Story points yield better per-Sprint estimates of capacity than "accurately" measuring task time.
- Scoping work to fit team capacity yields a sustainable cadence that is successful roughly 80% of the time.
- Measuring success by goals met rather than number of tasks performed is the organization's measure of success.
Given all that, how do you validate your relative sizing? Again, we go back to the key unit of time measurement in Scrum: the Sprint.
Story points are really just an intermediate value to estimate capacity. They work well, but there are other estimation techniques. On of my favorites is TFB/NFC/1, which is a system where you determine if a story or set of stories:
- fits into a single Sprint (1)
- is too big to fit into a single Sprint and should be decomposed or refactored (TFB)
- can't be estimated as-is or with the team's current knowledge (NFC)
You can use this type of technique alongside traditional story points, too. By looking at the Sprint Backlog as a gestalt and determining whether the whole book of work can reliably be done within a single Sprint, great! If your other estimation process yields a backlog that results in a gut check of "too freakin' big" for a single Sprint, or (worse yet) "no frackin' clue," then you should revise the plan until the planned goal and associated work do fit within a single Sprint.
Whether you use use TFB/NFC/1, a gut-check, or another estimation technique isn't what's important. They key strategy is to ensure that the team (and the rest of the organization) respect the time box. Plan only enough work to fit the iteration, and continuously refine your planning and estimation process until you can do that reliably most of the time. That's the essence of agile planning!
