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.
Historically, sprint teams tend to suffer from a lot of 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.
Ted estimates 1 day for a task – Dougal estimates the same task at 2 days. Without context, this tells you that Ted is twice as good/quick as Dougal. But it doesn’t give the whole story. Dougal might have lots of meetings whereas Ted might have a clear run at his desk for a day. Dougal might be a junior. Whatever the reasons, time as an estimate metric is misleading.
Story points, as an Agile artifact, were 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, 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:
- EXTRA LARGE
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 simply 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.