Teaching Relative Estimation by Throwing a Cat
A quick and fun exercise that will help you teach relative estimation
20 May 2014
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, usable with Planning Poker, and -- most important -- fun.
Hans Solo's Millennium Falcon and Mike Cohn's dog and zoo points
Estimating the 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 I was teaching a CSM course with Robin Dymond last year, we finally came up with the idea of comparing 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 short how-to, so that you can use 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 four to six 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 U.S.). These are the only conditions that you should specify in the beginning.
Next, list about six items to be estimated. I usually use completely different articles, which make it harder to compare -- for example, a stone, rugby ball, feather, sheet of paper, or rose. Other options include a pizza, rope, grenade, cake, tire, 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 the cat -- what you should expect?
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.
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 experiences with handling cats. You'll also see a lot of assumptions coming out -- as the members will be discussing how big the cat is, 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, answer only the question asked directly of 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 debrief, 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 the assumptions that were made more visible by the process.
Throwing the product owner in the mix
Last, 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, 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.
Now 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!
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.6 (7 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.