Single-Magnitude Story Sizing (Rather than Same-Sizing)

A practice exists in the agile community of “same-sizing” (sometimes called “single-sizing”) user stories. I tend to cringe when I hear this because it’s often accompanied by questionable guidance that it’s “required” for kanban or continuous flow or NoEstimates (it’s not). But at the recent Lean Agile Scotland conference, I heard an interesting and helpful clarification of at least one person’s version of this practice that switched on a light for me.

 

Lyndsay Prewer gave a talk on reimagining agile ceremonies in which he touched on “evolving estimation.” He noted that his teams had started following Pawel Brodzinski’s three-choice approach of “estimating”:

• 1
• TFB: Too F-ing Big
• NFC: No F-ing Clue

Sounded good — I like Pawel’s cheeky and simple heuristic. But I’ve seen teams interpret this as meaning all stories need to be a one either in terms of relative sizing (doing only the “ones” in a Fibonacci estimation session, for example*) or absolute time (doing only stories that would take one day). But here’s where it got interesting: Lyndsay then explained that, for his teams, the “single-sizing” — the “one” in Pawel’s approach — meant that the team expected the story would take between two and 10 days to finish (10 days being the total duration of the two-week sprint). This single size then wasn’t same-sizing at all: It was single-magnitude sizing. Lynsday gave me hope that perhaps not everyone who says he’s doing “same-sizing” is actually trying to make upfront guesses about uniform effort and delivery duration.

 

At the very least, though, it gives us some language to clarify things with: Single-magnitude sizing is indeed a salutary practice, insofar as it accommodates the impossibility of guessing delivery time as well as the need for predictability. A few additional points of guidance and clarification:

• Saying that any story seems likely to finish within a range of time (good use of time) is different from saying the specific time that it will take (fool’s errand). We’re not saying that Story X is a five (or whatever) but simply saying it’s likely 10 days (or 20, etc.) or less. Mike Cohn stated this well when he wrote “Try to keep most estimates, or at least the most important estimates within about one order of magnitude, such as from 1-10. There are studies that have shown humans are pretty good across one order of magnitude, but beyond that, we are pretty bad.” But Cohn goes to far, in my opinion, with his next advice, which refers to the Fibonacci sequence “That’s why in the agile estimating method of Planning Poker, most of the cards are between 1-13. We can estimate pretty well in that range.” Data is showing that we can’t (upfront estimates have little correlation with actual delivery times). Playing poker is gambling!
• The reason we care about sizing within a single magnitude is that it helps us satisfy the assumptions behind Little’s Law, which makes forecasting more reliable.
• The data should inform the sizing, not the other way around. Rather than starting with the boundary of a sprint, I would start with the actual data of observed delivery times and work backward from there. For instance, if a team finds that stories are sometimes taking up to 15 days to complete, forcing them into a two-week (10-day sprint) cycle is only going to drive counter-productive behavior.
• If you are using this approach for sprints, then I would make the sprint duration at least twice the highest number in the range. For example, if you’re observing stories to take between two and 10 days, I would make the sprint 20 days long, because you need to accommodate the possibility of starting one of those 10-day stories late in the sprint, which would jeopardize the sprint goal (remember, you don’t really know which stories are going to take 10 days because effort — even if estimated perfectly — is only one of many sources of variation). That’s if you care that everything gets finished in a sprint time box. (And if you don’t, then what are sprint boundaries really doing for you?)
• It’s not necessary to have every story fit that magnitude range. Here’s where percentile levels on scatterplot charts come in handy. You might choose to accommodate some outliers by using the 85th percentile as your upper range. In the example scatterplot below, we see that the 85th percentile gives a range of delivery times between three and 17 days.

  

  Delivery-time (aka Cycle Time) scatterplot chart from Kanbanize.com

• Sizing stories in this way is different from estimating them further, as in assigning time or story points.

So let’s single-magnitude-size our stories. Since the “one” in Pawel’s approach should not refer to the relative size (to say, other Fibonacci numbers) or a unit of time, it’s probably better referred to as something other than a number, like a color. I’ll propose green, since it indicates “go,” as in good enough to go with. So here’s my simplified magnitude-sizing proposal:

• Green: seems to be within the 85th-percentile range of previous work
• Red: something other than that

 

*It’s described by at least one person (though I’ve heard it said this way many times): “The idea, at least at high level, is very simple: slice down your tasks until they are all more or less of the same size (1 story point), then your final estimation is just a matter of summing the total number of stories.”