Part 1 of this post is here, from earlier this week.

Although Mike Cohn offers “ideal days” is a unit of measurement, I have always preferred a scale of story points (also a Cohn idea) that the team is comfortable with. Typically, something like the popular Fibonacci number sequence (1,3,5,8,13,20 . . .). Planning poker then helps us to gain a fast consensus on the team’s estimate.

The theory is that human beings are good at comparative size estimates, but not time estimation. From experience, I’d say the theory is pretty sound. The trouble I have found though, is that most people have a hard time conceptualising “idea sizing”. It’s one thing to ask a person which of two cars is smaller or “which is bigger, a chicken or a lion?” It’s another thing, much harder, to say “this idea is 2 story points larger than this idea”.

For this reason, I have recently begun to steer teams toward T-shirt sizing. A bit more on this later . . . .

I have also moved my once rigid opinion (slightly) on insisting that relative sizing does not relate to time. Wait! Do not change channels! I have my reasons. It’s another concept that’s really hard for some people to get their heads around.

Inevitably, even if one manages to eliminate discussion of duration during estimation or planning, you will find people at all levels of the organisation that inevitably do the math.

Velocity divided by available resource hours = each story point represents a particular number of hours work, right?

That’s no crime either, it’s a basic requirement of business that we understand the cost of development. So it is understandable when people try to equate duration with the size estimate. Even developers seem to like to do this as they visualise themselves completing the proposed user story during grooming and estimation.

In the name of pragmatism then, and as a way of easing a team into estimation, I believe there is a compromise.

CollabNet use video training for staff new to Scrum. If ever you get a chance to review these vids, don’t pass it up. They’ve spent a lot of time and done a great job simplifying (admittedly, in some cases oversimplifying) the concepts, roles and their own techniques. The estimation section got me thinking.

Introducing the concept of relative sizing to a team always means establishing a base unit, to which other items can be compared. In other words, you need to establish your archetypal “three-point story”, “five-point story” etc, examining the characteristics that make one “bigger” than the other.

A conversation about complexity, levels of difficulty and examples of situations in which conceptual work is quantified are where I usually start. CollabNet take a different approach. Because their training is delivered by these short videos, they don’t have the opportunity to enter into such conversations. They can’t explore the concept with the team, let them kick it around with a facilitator. So they cut out all the fat, suggesting that a team start by finding, from their history, a feature that could be achieved by the entire team, four times in one sprint.

I think this is a good place to draw the line of compromise. Depending on your sprint length, we have of course immediately labelled a feature with a duration of one quarter of that time. In the past, I would have said that this is the last thing I wanted to do. But I can see that this technique allows a new team to very quickly establish their unit of currency.

I believe the key is in what follows.

Go one step further. Next asked the team to find four “stories” like the one they just identified. This might even be the time at which the idea of the user story is introduced. Four stories that they could happily commit to completing in one sprint. The number of four is suggested in the CollabNet model, but any number would do, as long as it helps the team picture the right features.

Now, Let’s call these “Medium” stories (here come the T-Shirts). Rather than attempt to be precise in differentiating between story duration, let’s move the conversation to size. Let’s call everything smaller than this “Small”.

If it is bigger? That’s right, “Large”. Large ends when the team feels that an item is so big and/or vague that no more than a couple of that type would fit within the one iteration. Stories that big get the X-Large moniker.

Get the backlog in reasonable shape, and estimate all of the stories in this way.

Presenting the concepts of Agile estimation to a new team in this way, will also give them a starting point for their first iteration. They have a guide, by virtue of their method, as to where they might draw the line on their commitment – about for medium-sized stories.

It might become clear during planning that the calibration is wrong. The team might select one large story and two medium ones, realising only then that they could not possibly complete all of that, or maybe it’s not enough. That’s fine. Work through the first few sprints, measuring velocity/capacity, and keeping up with grooming and estimating your backlog. (Velocity can be calculated by aligning a T-shirt size with a number if desired – 2, 4, 8 for example).

What we have found

Limiting the number of sizes available to a team, combined with making the labels non-numeric, speeds estimations sessions incredibly. We switched to T-shirt sizing about 2 months ago. Since then, estimation has become much quicker, with less nitpicking over the relative difference of a few story points. During estimation, we now limit discussion on any one story to 5 minutes. If after five minutes, an estimation cannot be made, ask that the product owner take the story away for clarification or deconstruction. We’ll look at it again tomorrow, for 5 minutes. There’s no way we could have done this before.

Note: Our teams have an established baseline, as well as an understanding of their velocity & capacity. We aligned the previous Fibonacci numbers with the new T-shirt sizes, eliminating 1 and 2 point stories. 1’s became free, and 2’s were lumped in with the 3’s as “Smalls”. This allowed us to maintain a comparison of velocity/capacity from previous sprints.

Key points:

• Use only Small, Medium and Large labels for estimation.
• Anything smaller than a Small is Free. A few of these can be added to any Sprint
• Anything bigger than a Large is X-large. An X-large story must be broken down. Large is the biggest story that can go into any sprint
• Establish a baseline for Medium stories that the team believes would equate to the completion of four (pick your number) Medium stories per iteration
• Measure Velocity, and keep reviewing estimation calibration until you have swinging

Finally, don’t get weighed down by estimation. Keep it light, keep the team engaged, and tried to encourage it as an opportunity for developers, testers and designers to better understand (and contribute to defining) the work that they will soon perform.