Tuesday 7 June 2011

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.

1 comment:

  1. Hi Raphael,

    Interesting post and a great whiteboard snapshot!

    In my experience point estimates with cross-functional teams are no more difficult than t-shirt size estimates - it comes down to definition of "cross-functional", assumptions that go with that and the tools that you use for estimation.

    In an ideal world a cross-functional team is the one where anybody can pick any user story and move it all the way through to DONE. This would mean having some superhuman developers that can complete a user story in its entirety (in your example design, backend and frontend). As a result point estimates would be consistent and there is no need to add up the estimates for each part of the work.

    Then the question becomes - how close can we get to this ideal world in reality? The answer is - pretty close.

    I think there are three key things to achieve that. First, picking a scale with limited number of points (say 1, 2, 3, 5, 8, 13, 20, 40, 100) and agreeing on a typical range of what can be put into a Sprint (no more than 13 for example). Second, making sure estimation sessions are shared (planning poker is a great tool for that) and that team members estimate the whole story, not just their work. Third, discussing the work when estimates do not agree. Over time all developers would achieve a shared understanding of each other's effort (even if they can't actually complete certain kind of work) and the point estimates would become consistent.

    Points are also a easier to visualize than t-shirt sizes over a period of multiple Sprints - you can show growing performance of the team or effects of production support on velocity.

    ReplyDelete