Pop Quiz!

Using only Story Points, estimate how long it will take you to clean out your garage (or storage unit, or attic or other large space filled with stuff).  

Done? Great, what did you estimate? 

Now be truthful: Did your mind automatically start with how much time it would take and then you converted that into a Story Points? 

If you said yes, then you’re not alone. The vast majority of those I’ve taught estimation to do the exact same thing. Heck, I used to do the same thing. It’s built into the foundations of how our brains work. When confronted with an individual item and asked to give an estimate, the mind wants to use time.

 

Why Is Time a Bad Way to Estimate?

There has been a lot of study into this question, let’s quickly recap some of the top reasons. 

  1. Hofstadter’s law: This observation states “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” In other words, even if you think you’re being conservative in your estimates, you probably aren’t. 
  2. Optimism Bias: This is a cognitive bias that causes someone to believe that they themselves are less likely to experience a negative event. “Oh, that won’t happen to us, we’re smarter than that!” or “Hah, we learned from what that team did, we’ll do better.” 
  3. The Planning Fallacy: Here we are combining Hofstadter’s law and Optimism Bias while adding in a new dimension around historical work. Despite our best intentions, we have a strong tendency not to learn from the past. “It took us two months to stand up the last database. We’re tons smarter now, it will only take us two weeks!”
  4. We stink at estimating beyond four hours: This is based on my direct observation over three decades of project work in and out of the Agile space. Human beings stink at estimating anything that takes more than about four hours. I can tell you, with a high degree of certainty, how long it will take me to do the dishes or to clean my office. But, If you ask me how long it will take me to clean my garage, I wouldn’t have a clue. I’m sure there is some kind of science behind this, not unlike the “You can only remember seven things” principle of short term memory, I just haven’t found it yet. For now, I’ll stick with my direct observations. 

Okay, so time is a horrible way to estimate, I’ve convinced you. Now what? 

You are probably familiar with the concept of Story Points. The question is, how do you use them effectively? 

 

Planning Poker: A Standard That Needs to Be Challenged

Planning Poker has been the de facto standard for Agile estimation for nearly 20 years. Originally defined by James Grenning in 2002, it was later popularized by Mike Cohn in his book Agile Estimating and Planning. Mike went on to trademark the term, make modified Fibonacci decks for it, and even an online tool. 

What is Planning Poker? 

For those not familiar, in Planning Poker the team has a set of cards in Fibonacci sequence. A single item is introduced and each person picks the numbered card they think best represents the size of the work. Everyone reveals their chosen card at the same time. The highest card and the lowest card explain why they chose that particular number. Then the process is repeated. 

Just because Planning Poker has become the standard does not mean it is the best tool. In the spirit of continuous improvement, we want to challenge ourselves and ask, “Is this working? Is it filling our needs? Could it be better?”

I believe the answers are “No,” “No,” and “Yes.” 

Why Planning Poker Doesn't Work

  1. It’s in each person’s head: Each person in the exercise starts the conversation in their own head. If there is anyone in the world I’m likely to agree with, it’s going to be myself. Estimating in your own head also leads to each person thinking about how they would do the work when the real question is, “How will the team do the work?”  Combine these two and it makes it hard for people to change their position, especially if you take into account the various biases that can impact the conversation (see the last bullet below). 
  2. No comparison (One at a Time): Planning Poker looks at only one item at a time. That’s like hearing someone say something totally out of context and getting really confused. Unless the entire project can be done with that single item, the context of how it fits into the other work is incredibly important. 
  3. Easy for Bias to creep in: Authority Bias, Groupthink, Ingroup Bias and Availability Cascade are some common biases that can run rampant during a Planning Poker session. The most common anti-pattern I see is the recognized “expert” will give a relatively low number and a more junior person will give a higher number with the others on the team ranging in between. The “expert” will then pontificate on why it’s so easy. In the next round, everyone comes out with an estimate exactly the same or really close to the expert. The problem with that result is that an estimate should represent anyone on the team working on the item, not just the “expert.” 

Relative Estimation Offers a Solution

The guiding principle behind Relative Estimation is that the individual item doesn’t matter. What matters is the relationship between two or more items. It works for two reasons:

  1. Stories are estimated in relation to one another and not in a vacuum. “Is painting the garage door more or less effort than replacing the latch on the back gate? It’s more? All right, then, is painting more or less effort than rehanging the front door.”
  2. It’s a team activity. Nothing happens in anyone’s head. It is all out on the table and very straight forward. You aren’t sitting there arguing that the Database re-architecture will take a week or two weeks. You are just trying to decide if it is more or less effort than localizing the user interface to Japanese.

Let’s try a theoretical exercise. Imagine you are looking at four steaks sitting on a BBQ. The cook asks you, “Which one will you have?” You’re pretty hungry and you want the biggest steak. Are you going to pull out a scale and measure each steak? No, probably not. More likely, you’re going to look at the four steaks, compare them against one another and make a call on which one is biggest. If two look the same, you’ll then look at how they are cooked and pick the one that is most appealing to you. 

Next, let’s apply Relative Estimation and see how it can address the the weaknesses of Planning Poker:  

  1. It’s in each person’s head: Using the Team Estimation Framework, detailed below, you have a round robin flow that creates conversation leading to greater shared understanding. The team comes out of their heads and into the dialog. 
  2. No comparison (One at a Time): Individual items are never sized alone. They are always compared to other items with the framing of, “Is this more or less than this one? What about this one?”
  3. Easy for Bias to creep it: Again, using the Team Estimation Framework allows for every voice to be heard. The round robin format gives everyone opportunity to think and formulate their own thoughts.

The Relative Estimation Alternative: Team Estimation

So how to use the Relative Estimate instead of Planning Poker? We have a framework for that, and it’s called Team Estimation. We provide detailed instructions and Team Estimation Playing Cards in our article, How to Learn the Team Estimation Game.

Try it out and you’ll see, a Relative Estimation straight beats a Planning Poker full house.

 

More on Estimation . . .

This has been Part 1 of our ongoing series on estimation. Our ongoing series continues as follows:

Part 2 – How to Learn the Team Estimation Game – this is the article mentioned in the section above, wherein detailed instructions and Team Estimation Playing Cards are provided.

Part 3 – Relative Estimation with Reference Stories – explains how to make your Sprint planning events even better using Relative Estimation with reference stories.

More to follow . . . so be sure to check back soon! Or better yet, follow us on Linkedin, Twitter and/or Facebook to get notice of when new blogs are posted.