I have been working with a team that had a go at relative estimation of their work rather than absolute or duration based estimation. We had some difficulties that I may cover in another post - when I get my act together - but the most enlightening part of the process for me was coming up with a scale they were willing to adopt.
The team members were more comfortable with duration based estimates for their work, but it was hoped to move everyone away from this to a scale that didn't carry any commitment baggage. During the discussion on estimation this came up
"If I am doing this work then it will take a day, if someone else does the work it will take longer"
this gave us a basis to talk about using a different scale that does translate between people and tasks.
Story points didn't mean anything to the team as they are not working on user stories. I flippantly suggested Gummi bears, and this was quickly changed by the team into chocolate. The chocolate scale - based on Cadbury's chocolate blocks - has been adopted.
From smallest to largest:
- Furry Friends
- Chunky
- Half block
- Family block
- Half slab
- Slab
Potential problems with the chocolate scale
How do you calculate velocity? Is it 5 furry friends and chunky? What does this mean? The team lead is looking at using the net weights of these blocks as a numerical measure, we'll see how it goes.
What about inconsistency across teams because of different scales? In the longer term I think this would be a big issue, currently there are only two teams using relative estimates (this team and one developer working solo) so it's not an issue now. At present this is traded off against having the team start to think about their work in a different way. Eventually it may be required to standardise for communication and metrics, the risk of this approach is to give the team control of something and then take it away.
How do you calculate velocity? Is it 5 furry friends and chunky? What does this mean? The team lead is looking at using the net weights of these blocks as a numerical measure, we'll see how it goes.
What about inconsistency across teams because of different scales? In the longer term I think this would be a big issue, currently there are only two teams using relative estimates (this team and one developer working solo) so it's not an issue now. At present this is traded off against having the team start to think about their work in a different way. Eventually it may be required to standardise for communication and metrics, the risk of this approach is to give the team control of something and then take it away.
What did this achieve?
The team now has a scale that is their own, I think ownership is important when you are asked to change. It might be flippant, but it is relative and there can be no confusion as to whether this is a commitment or an estimate. (Though I'd love to hear the usual please reduce your estimates conversation "4 family blocks and a chunky, come on that's way too big, surely it's only 3 blocks and a furry friend".)
The team have also estimated 2 weeks of work using this scale. Previously the estimation process stalled now using their own scale it was estimated very quickly.
2 comments:
Actually ones upon a time a team where I was a Scrum Master adopted a similar strategy for task size estimations. Estimating in ideal hours did not appeal to the team so people invented "small task, normal task, big task" represented by papers of different size. Normal task was *physically* a half of large task, small task was "physically" a half of normal task.
Clear physical relationship allowed us to use numbers (1, 2, 4) when calculating burndowns yet avoid the during plannings. Burndows and estimations were super precise, but precise enough.
Actually because of highly visual size representation sprint burndown became less needed - state was rather clearly seen from where on the taskboard was more paper.
Consider utilizing similar approach. A am not a choco fan, but I guess the different choco bars differ in size. Then just assign approximate point numbers to them. You won't have to use numbers when planning and doing business, but still will be able to summarize, have a big picture overview of effort left and report when needed. It won't be super-precise, but possibly precise enough. Estimations are anyway not super-precise in nature.
Yes, that's a nice idea. I'll suggest it to the team.
thanks,
Lachlan
Post a Comment