I’m a big fan of relative measurements in software development. However, when teaching this idea, I’ve noticed that many developers who are used to estimating work in hours or days find it difficult to switch to using Story Points as the relative measurement of complexity. Many times I’ve heard comments like: “we use Story Points – and one point is eight hours.”
Old habits die hard
It’s always challenging to learn a new habit and break an old one. Therefore I was constantly looking for a good exercise for my Scrum training that would let people compare work items without calculating effort. The ideal solution should be quick, combinable with Planning Poker, and most importantly – fun.
Hans Solo’s Millennium Falcon and Mike Cohn’s Dog and Zoo Points
Estimating backlog for any software product usually doesn’t work well, as participants often end up comparing time anyway. During a previous training session, we estimated software for Hans Solo’s Millennium Falcon. However, this proved to be too abstract – participants couldn’t find a way to measure complexity and compare hyperdrive with laser cannons. I was also using Road Points to compare travel between cities, but this still led to thinking in hours. Mike Cohn’s Dog and Zoo Points work a little better, although developers tend to compare one dimension, like size, or create estimates for several dimensions and then just add them up. Not to mention that fun is limited here as well.
While teaching a CSM course with Robin Dymond last year, we finally came up with the idea of to compare complexity by throwing different objects. I’ve tried it several times during other courses, and found it quick and very enjoyable. Therefore I decided to create a short how-to so that you can reuse this exercise with your team.
How difficult is it to throw down?
When running this exercise, start by splitting the group into small teams of 4 to 6 people. Then describe the exercise’s goal of obtaining relative estimation by using the level of difficulty of throwing different objects as a gauge. Different objects will then be made available to team members. They must be thrown and must fly at least one meter (or one yard, if you’re throwing them in the US). These are the only conditions that you should specify in the beginning.
Next, list around six items to be estimated. I usually use completely different articles, which makes it harder to compare – for example, a stone, rugby ball, feather, sheet of paper, or rose. Other options include a pizza, rope, grenade, cake, tyre, or flagstone. You might also decide to add some rare objects such as a flamberge, so that team members must do some research on the Internet before estimating.
“Throwing in the cat”
Things always get most interesting when you end your list with the cat from the title of this article. If you have an avid cat lover in your audience, you might opt for a squirrel instead. When estimating with an extremely serious group, you should consider skipping these, as sometimes some examples just won’t fly. However if you do try them, I can assure you that the discussion will get much more intense – and you’ll have a lot more fun listening to the arguments.
What you should expect?
First of all, it’s impossible to compare all of these items in one dimension. They differ in size, weight, air resistance – or difficulty to hold and willingness to cooperate, as in the case of the cat. Team members must take this into account before estimating. Participants will share their experience with handling cats. You’ll also see a lot of assumptions coming out – as the members will be discussing how big the cat is, whether is it alive, or if it bites.
Teams get busy with their discussions and rarely have time to stop and clarify their assumptions. Occasionally, someone will ask you, the Product Owner a question to confirm his or her assumption. If this happens, only answer the question asked directly to you, and only answer the person who asked it. Ignore any questions thrown out randomly. Listen, but do not join the discussion – as there will be a lot of intense conversation taking place.
I usually run a 15-minute timer and periodically update participants about the passing time. It’s fine if they don’t estimate for all items during this time, but they should have at least four or five values. When time runs out, I collect their estimates and check their reference points. If there’s more than one group, we can compare values. As these usually differ, we talk about estimates being specific for the team. Then we debriefed, discussing what was difficult and what was easy. I check what kind of stone, rose, feather or cat they were throwing, and we talk about their assumptions that were made more visible by the process.
Throwing the Product Owner in the mix
Lastly, I ask what was missing – this highlights the necessity of the Product Owner’s presence during the estimation session. This ensures that they find out exactly what he or she wants, instead of assuming what he or she would like. This enables participants to understand that the goal of estimating is learning and that the values themselves are by-products of this process. The whole exercise, including discussion, will take less than half an hour.
You might be wondering why we don’t estimate how far you can throw objects. The reason is twofold. First of all, the distance describes an effect – the business value of throwing, not the complexity. And second, it’s one-dimensional – so people can switch back to the unit measurement, where one point equals one meter.
So at the end of your day, when a family member asks how your day was, you can say: “We had a heated discussion at the office about throwing a cat!” Be sure to have fun – and if you’ve enjoyed this exercise, let me know!
Oryginalny artykuł został opublikowany w 2014 roku na blogu Scrum Alliance.
