What Size Are You? Experimenting with T-shirt sizes in Story estimation

There’s a lot of negative energy surrounding story estimates in most Agile organisations.

Developers tend to fear the process of estimating their work more so than other Agile elements that should in theory be much scarier – such as sacred deadlines or standing up in front of their peers every morning.

When I joined Mind Candy, I noticed that there was too much unnecessary noise focused on estimates – in particular story points.

Estimates are *supposed* to give the product owner / producer a broad steer towards the size of the work required; this additional context allows a firmer sense of priority in terms of product direction.

Unfortunately, estimates are too often treated as contractual obligations that serve to be an imaginary stick hovering mentally over developers’ heads. As a result, you find sprint teams needlessly getting their knickers-in-a-twist. The problem with using days or hours as a unit for estimating tasks is that these units mean the same for everyone and are comparable.

Ben estimates 2 days for a task – Jon estimates the same task at 1 day. Without context, this tells you that Jon is twice as good/quick as Ben. But it doesn’t give the whole story. Ben might have lots of meetings whereas Jon might have a clear run at his desk for a day. Ben might be a junior. Whatever the reasons, time as an estimate metric is misleading.

Story points, as an Agile artifact, was supposed to counter this. You’d estimate a story and assign a numerical value to it – and this number meant nothing other than a relative value to the other stories. For example:

STORY A = Estimate is 2
STORY B = Estimate is 10
STORY C = Estimate is 2
STORY D = Estimate is 100

The above set of estimates are deliberately meaningless – they only serve to indicate the size of a story when compared to the other stories. We can see that Story D is massive – about ten times the size of Story B. We can also see that Stories A and C are roughly the same amount of work.

However, story points prove difficult when you are dealing with cross-discipline teams. You are adding two estimates together that don’t share the same value system.

Let’s say a story requires some Front End and Back End and Design work
Front End estimate = 2
Back End estimate = 5
Design estimate = 4

You’d add the estimates together and come up with TOTAL = 11. However, you are essentially adding 2 apples to 5 oranges to 4 pears. They are different metrics because the Design team have only estimated 4 compared to other Design tasks.

Recently, we’ve been experimenting at Mind Candy with throwing out numerical values in the Estimate process and replacing them with T-shirt sizes.

Essentially, sprint members are allowed to give a story estimate in one of five sizes:

SMALL
MEDIUM
LARGE
EXTRA LARGE
TENT

How do you measure progress? Well, we’ve trialled drawing a T-shirt on the white-board that corresponds to each story – and when some progress is made – the team member merely colours in a part of the T-shirt. When complete – we draw a smiley face on the T-shirt.

We’re seeing how this goes – it’s very indicative and visual and the teams are responding well to it. We’ve thrown out the burndown chart and just using the whiteboard as a quick visual guide to how coloured in the T-shirts are.

Most importantly, the sprint teams are no longer getting their knickers-in-a-twist.