So, since we are astute enough so that we're not expecting a story’s size (In Story Points) to be an accurate reflection of the effort it takes for the story – even though we expect a correlation on average – what is our expectation of what a story’s size reflects? This is a very good question, and causes us to think about the four factors that influence estimates: intrinsic difficulty, robustness of the solution, viscosity of the code we’re working with, and team ability.

Here’s what I think.

I think that we’re trying to size the intrinsic difficulty of the story. That is, we’re trying to get a relative estimate of how hard solving the problem will be in an ideal world, not how much work it will actually take to provide a solution. There are two major reasons I believe it should be done this way and here they are:

• This type of size can be estimated with the information we have. When we are sizing the story, we are discussing the story without thorough, or detailed, knowledge of the codebase or who will be actually working on the story. We can ask a question like “how hard is this story, given a reasonable definition of ‘done’, clean code to work with, and an ideal team?” Since we are looking for a fairly ambiguous answer, we can give it. If we can’t understand it well enough to agree if it’s XS, S, M, L, or XL, then we just say it’s an epic – it’s too difficult to size right now… and we wind up with an analysis story/spike to figure it out.


• I know that the other three factors can’t help but creep into the estimators’ minds, but if we know that all we’re looking for is intrinsic difficulty, the others can’t dominate the conversation – they’re technically out of scope for the discussion. And, if they do creep in, the sizes just get better (more accurate, more consistent, etc.)… which is a good thing.

Anyway, what we’re trying to do is to estimate the intrinsic difficulty of the story. We like to ask questions like the “how big is the pile of rocks?”, or “how many miles as it?” I like this type of metaphor for a story’s size, because it clearly separates the story’s intrinsic difficulty from the other variables.

If we are running a mile, for example, it’s always a mile. However, some miles are harder to run than others. Sometimes we’re in a park, on the grass, the sun is shining, and there’s a gentle breeze. Sometimes we’re in the woods, going up and down hills, crashing through the underbrush, it’s snowing, it’s dark, and the monster is after us. Sometimes the runner is an Olympic-class runner, sometimes it’s a fat old man like me. But it’s always a mile…

In order to make sure a mile is always a mile, and that there’s not some extra stuff hiding in there, I have another basic rule that applies to “coding stories”. I like to think of a story as being a single scenario, a single thread, a single interaction, a single case or state, or as having a single “positive” test. This notion limits the scope of a story within a feature, and prevents scope creep within the story. It also focuses the “sizing” conversation about a story on aspects of the story itself, rather than on things we can’t be expected to know right now.

Because a mile is always a mile, we have some notion about how fast we can run it, under reasonable circumstances. Basically, we would expect a mile to be run in a matter of minutes, not hours or days. This type of expectation is also true for teams, and this is why I sometimes think about story sizes in terms of effort, the 2-3 people for 1-4 days concept. I have these expectations based on teams I’ve worked with; however, your mileage may vary (pun intended).

I know that these two notions of size are inconsistent with each other: intrinsic difficulty of problem versus amount of effort. Sorry ‘bout that… but one of the strengths of human beings is that we’re able to keep two perfectly good, though incompatible, ideas in our head at one time.

This is one of those times.

We have a team working in iterations, so we need the team to work on stories that are the right size (in effort) so that they get them “done” in a single iteration. We must have faith that stories that are understandable (intrinsic difficulty of XS thru XL) can be done in a single iteration. If they can’t, the team must adapt: lengthen the iteration (usually the wrong choice), have more people swarm on the story (not a bad choice), or start estimating with different thresholds for difficulty estimates (what usually happens automatically).

I have never found this issue to be a problem. A fear, yes. A risk, yes. A good multi-beer conversation, yes. A problem, no. People adapt. Agility happens. And it just works out…

Thanks, Dan ;-)
dan@danube.com