Skip to content

Workshop: Estimation Techniques

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.

  1. Sometimes they get very caught up in the actual number. Forgetting itโ€™s just an estimate and wrong anyway.
  2. 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.

bookseries

28 thoughts on “Workshop: Estimation Techniques”

  1. 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.

    1. I like to remind teams that all estimates are wrong anyway. Repeating this every time they get hung up on the numbers helps.

  2. 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.

    1. 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.

  3. Pingback: Agile Aufwandsschรคtzung – Abseits von Planning Poker | Patrick Kiwitter

  4. 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!

  5. 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! ๐Ÿ™‚

    1. 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.

  6. What if your team is used to estimating with hours?
    How do you translate these exercises to using hour estimations in real life?

    1. 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.

  7. Frederic Vandaele

    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.

    1. 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.

  8. Pingback: Agile Boost Camp Workshop | Yuval Yeret on Lean/Agile/Flow

  9. Pingback: LL: Understanding Estimation | Self-Trained Agile Teams

  10. 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!

  11. Pingback: Backlog Refinement or Backlog Grooming | AgilePath

  12. Pingback: Are you the “Scrum Police” ? | Growing Agile

  13. Pingback: Techniques for improving Product Backlog refinement

Comments are closed.