This week I ran an estimation techniques workshop to help my teams understand different ways of estimating. Iโve run it once before at my previous company and people found it useful. This timeย Samย and I prepared together, and she ran the same workshop with her teams. We agreed to blog about the results to see how it compared.
Goal
So why run the workshop? Currently my teams all use planning poker, however Iโve noticed 2 things starting to happen. I think these are fairly common in teams using planning poker.
- Sometimes they get very caught up in the actual number. Forgetting itโs just an estimate and wrong anyway.
- Sometimes people get emotionally invested in being โrightโ. People start โdefendingโ their estimates, or giving in to the majority without discussion.
I like to remind people that what we care about is getting a shared understanding and consensus, not necessarily worrying too much about the actual number. Remembering that this is just a way to plan, and help us know where we are against that plan. When we have large numbers of stories, and work with an average velocity, it turns out that if one particular story is a 3 or a 5 doesnโt matter all that much.
So what I wanted the teams to see is that you can get estimates about 80% right with 20% of the effort, and itโs not worth the other 80% of the time. I also wanted them to understand that we really are better at relative estimating than at absolute estimating. And finally, I wanted them to try some different techniques to see if they could learn something that might work better for them in the future.
The workshop
The format of the workshop was 4 exercises, each time boxed to 10 minutes. For each exercise the teams had to estimate items using a different technique. Each team got a set of cards with the items written on the cards. Each team got the same items so we could compare between teams at the end. When each team had finished estimating I wrote up the results of each team and we had a discussion about that technique. I also shared the โcorrectโ answers with them, because I know that people always want to know how right they were. At the end we had a general discussion about all the techniques and decided where weโd go from here.
Absolute Estimates
For exercise 1 we did absolute estimating, and the items to estimate were dogs. Teams had to estimate the weight of the dogs in kilograms.
Here are the results:
Exercise 1: Absolute Estimates | TIME | 3:18 | ||||
Group 1 | Group 2 | Group 3 | Group 4 | Group 5 | Correct | |
Chihuahua | 1 | 1 | 1 | 1 | 7.5 | 3 |
Great Dane | 75 | 80 | 70 | 60 | 75 | 90 |
Staffordshire Bull Terrier | 16 | 10 | 50 | 25 | 40 | 17 |
Appalachian Mountain Dog | 45 | 60 | 70 | 35 | 30 | 0 |
Border Collie | 20 | 20 | 45 | 20 | 35 | 34 |
American Cocker Spaniel | 15 | 12 | 35 | 30 | 50 | 13 |
Although to my surprise this turned out to be the fastest technique at 3minute 18 seconds, when I asked for feedback people commented that they were โpure guessesโ, and that looking at the results they wereย โquite bad at itโ. At the end of the discussion I pointed at that there is no such thing as an Appalachian Mountain Dog, and yet everyone thought they knew how big one was!
Planning Poker Estimates
Exercise 2 was planning poker, a technique the teams where pretty accustomed to. If you havenโt heard of it before, here is a quick intro. You need a set ofย planning poker cardsย for each estimator. Next you need a reference point. Since planning poker is unitless everything is estimated relative to something else. In this case we chose Spain as the reference point and assigned it a value of 3. The item to be estimated is discussed, then each person chooses a card from their set that they think is the closest fit. e.g. if something is nearly twice as big, you would select a 5. Everyone displays their cards at the same time (the idea is that people are not influenced by each other). Then people discuss the outliers, usually the highest and lowest numbers to see if the people who selected them had a different understanding to everyone else. After discussion people re-vote taking into account anything uncovered in the discussion. Once everyone converges on a number that is selected as the estimate. Usually if convergence is not reached by the third vote you take the highest number or majority number.
Here are the results:
Exercise 2: Planning Poker | TIME | 4:51 | ||||
Group 1 | Group 2 | Group 3 | Group 4 | Group 5 | Correct | |
Spain | 3 | 3 | 3 | 3 | 3 | 3 |
China | 40 | 40 | 40 | 20 | 40 | 40 |
Luxembourg | 5 | 0.5 | 1 | 0.5 | 1 | 0 |
Denmark | 13 | 1 | 2 | 1 | 2 | 1 |
South Africa | 20 | 5 | 5 | 5 | 5 | 8 |
Belize | ? | 1 | ? | ? | ? | 1 |
The discussion this time commented that โit looks like we copied each otherโ, โsomewhat easier to get consensusโ, โestimates were closerโ. I asked what happened with Belize, and most team admitted they didnโt know where it was or how big it was. I asked them why they didnโt estimate anyway, as they did with the Appalachian Mountain Dog, and we concluded that having a ? in the pack of poker cards made it seem okay to not know. We also talked about whether there was a difference between 100 (large estimate) and ?. If you estimate ? it means you donโt know enough to estimate. If you estimate 100 it means you think it is huge. Itโs important for a Product Owner to know the difference. For a ? he can provide more info before he decides itโs too huge to consider. If you use 100 instead of ?, a PO might discard the story as too expensive, rather than having a conversation to see what is not understood.
Affinity Estimation
Exercise 3 was affinity based estimation.ย This was new to everyone in the session. Here is how it works. You lay out one set of planning poker cards so that you have all the numbers. You agree a reference story, and place it next to the reference point. In this case convertible went next to 3. Then you give the stack of story cards to the first person in the team. Each person has a turn. For your turn you can either: take a new card from the stack of story cards and place it where you think it fits, or you can move a card already on the table to a new spot if you donโt agree with it. You must always move a card if you donโt agree with the estimate rather than playing a new one. So if you play a new card it means you are happy with every card on the table. After your turn of either moving 1 card, or placing a new one, you hand the cards to the next person. If you do a full circuit of the team and one card has been moved each time, then you discuss it before continuing. You can let people explain why they are placing a card at a certain number however, last time I tried to teach this technique people seemed to forget about the donโt debate it unless it moves, so this time I went a bit further and insisted on silence unless a card had been moved by everyone.
Here are the results:
Exercise 3: Affinity Estimation | TIME | 4:51 | ||||
Group 1 | Group 2 | Group 3 | Group 4 | Group 5 | Correct | |
convertible | 3 | 3 | 3 | 3 | 3 | 3 |
motorbike | 0.5 | 0.5 | 1 | 0.5 | 1 | 1 |
starship enterprize | 100 | 100 | 100 | 100 | ? | 100 |
SUV | 8 | 5 | 5 | 8 | 13 | 5 |
minivan | 8 | 8 | 8 | 13 | 5 | 8 |
bus | 13 | 20 | 13 | 20 | 20 | 20 |
This time someone felt like it took a lot longer. I pointed out that it had actually taken exactly the same amount of time as planning poker. Others commented that โit makes you think moreโ and that they were โless affected by those around youโ.
Relative Estimation
The last exercise is a technique I invented myself, although I think itโs probably a fairly common evolution in estimating. I like to call it relativityย ย I like it because it focuses people on the relativeness of the estimates over the numbers. Hereโs how it works. You take all the story cards and arrange them on the table in ascending size (ignoring the reference point for now). Just decide what is bigger and whats the same size. You can all do this together. Usually there is less debate about what is bigger, the debate is how much it is bigger by.ย Once you have arranged all the cards, only then do you assign numbers, starting with the reference point.
Here are the results:
Exercise 4: Relative Estimation | TIME | 5:52 | ||||
Group 1 | Group 2 | Group 3 | Group 4 | Group 5 | Correct | |
impala | 3 | 3 | 3 | 3 | 3 | 3 |
elephant | 40 | 40 | 100 | 100 | 100 | 100 |
giraffe | 13 | 20 | 13 | 10 | 20 | 40 |
elephant shrew | 0 | 0 | 0.5 | 0 | 0 | 0 |
crocodile | 5 | 8 | 20 | 20 | 8 | 13 |
snake | 0.5 | 0.5 | 1 | 0.5 | 0.5 | 1 |
So how did people feel about this one? Interesting one team thought it โsuckedโ because they โcouldnโt agree on the numbersโ, however on reflection they agreed that they had implicitly done the relative ranking in the previous exercise. Others felt they had โa clearer idea when ranking firstโ.
What did we learn
At the end I asked them to look at all the results and see what they noticed. Someone pointed out that the lower the estimate the closer they were to the truth. The implications for our sprints -> Keep the stories small! We also discussed the importance of having the same reference point if we were working on a single backlog with 3 teams. Finally I asked if they would change anything about the way we estimate based on this. The answer: They are keen to give affinity estimation a try in our next estimation meeting.
Try it out
If you want to run this workshop yourself here is what you will need:
- Cards with the items on them for each team
- Planning poker cards for each person
- A flipchart and marker to write up the results of each round for people to see
- A stopwatch or cellphone with timing functionality
- Some team members keen to learn about estimation, I did the workshop with 5 groups of 3-4 people.
- An hour time box is sufficient if your team are used to estimating. Maybe more if your teams are new to it.
I have a PDF you can print out with the cards, and sheets to track the results here:ย Estimation Techniques
If you try do it, Iโd be keen to here about your results.
If you enjoy this workshop – check out more of them in our Growing Agile: A Coach’s Guide Series.
Excellent post, love the ideas and will be sure to give them a try with the new teams we have set up.
Awesome! Please leave some feedback here on how this worked with your teams ๐
With te first team I tried the affinity estimation. Team seemed to be hung up about the points, but once they got over that, the entire backlog was estimated pretty quickly. I plan to try the Relative estimating technique with the second team later today.
I like to remind teams that all estimates are wrong anyway. Repeating this every time they get hung up on the numbers helps.
I find your article very interesting though I could not find any reference anywhere on the internet concerning the affinity estimate method. From what I could find so far it seems that it is like the relative estimation. Could you perhaps send reference on the 3rd method you talk about? I’m interested to try it out with my team.
If you google affinity estimation technique there are a number of posts about the technique. This one gives step by step instructions: http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/. Affinity estimation is a relative estimation technique, what is unique about it is that it is mostly done in silence, and people only need to discuss the items where there is a difference of opinion on size. This makes the technique much faster than planning poker.
Great post. Nice examples as well.
Pingback: Agile Aufwandsschรคtzung – Abseits von Planning Poker | Patrick Kiwitter
I think my comment on the previous post didn’t get moved here ๐ I love this workshop and have used it very successfully with almost every team I’ve worked with! Thanks for making it public! I thought of it today when stumbling across this amusing graphic: http://lexinator117.deviantart.com/art/Size-Comparison-of-EVERYTHING-391005636
(I hope the link doesn’t get me stuck in moderation)
Karen
Excellent article and hope to use this in my future projects. Thanks for sharing.
this article was my first source of info that answered all the questions I had into putting some estimation techniques and info together for the team . nice post ! going to try these next week at sprint planning. Thanks for sharing!
Great to hear. Let us know how sprint planning goes!
Excellent exercise, Sam and Karen! I’ll be using this soon. Just one question — maybe the border collies here in the States are smaller than those in your area, but are you sure they run to 34 kg? Even my big male isn’t that large. He’d eat me out of house and home! ๐
Hi Jen. Thanks for the feedback. I just googled it and I think you are right. I think the earlier reference I found must have been in pounds. It’s actually 15 to 20 kgs.
Hi guys, amazing work !!! I did a presentation with the content of your post that I’m sharing with you http://www.slideshare.net/jesusmendez77770194/estimation-techniques-workshop-february-2014
Awesome material, thank you for sharing your experience, I’ll let you know the results after I’ve done the workshop.
All the best.
Jesus Mendez
Thanks for sharing Jesus, glad you found it useful. Looking forward to seeing your results.
What if your team is used to estimating with hours?
How do you translate these exercises to using hour estimations in real life?
Hi Lily, I general use the workshop to help teams see the benefits of relative estimating and to move away from hours. Round 1 “Absolute Estimates” is analogous to hour estimates. Do all 4 rounds and then get them to reflect if absolute or relative estimates are more accurate.
Hi Karen,
Thanks for this great article.
I’m preparing a workshop for my company based on it. I’ll share slides and results with pleasure next week.
Karen, thanks for this great posting.
Hi Frederic, I am planning to do the same for my company this week or next. Do you mind sharing your slides and what was the outcome when you carried out the workshop?
Thx.
Are there any plans to do a “coaches guide on agile estimating and planning? ” ๐
Hahaha – not at this time ๐
Pingback: Agile Boost Camp Workshop | Yuval Yeret on Lean/Agile/Flow
Pingback: LL: Understanding Estimation | Self-Trained Agile Teams
Great article, Karen! And thank you for sharing yours and Sam’s experience (and resources) with all of us ๐ I was wondering whether you have heard about the Zmey Planning (http://www.agify.me/the-zmey-planning/)? Itโs quite new and not so popular estimation technique. In addition to complexity it also takes into account uncertainty and vagueness of requirements โ all of which might have significant impact on the estimates. It would be interesting seeing it in any of your next workshops ๐ Cheers!
Pingback: Backlog Refinement or Backlog Grooming | AgilePath
Pingback: Are you the “Scrum Police” ? | Growing Agile
Pingback: Techniques for improving Product Backlog refinement
Comments are closed.