Not Only Planning Poker

The most common agile way of estimating the relative size of tasks at hand is the Planning Poker. Some even think of it as the only or best way. There are also people who think that Planning Poker is a part of Scrum or some other agile framework. Is it?

 

#ProEstimates

On one hand, there are plenty of great methods for estimating tasks, User Stories and backlog items. On the other, at least one movement advocates getting rid of estimates at all (#NoEstimates). Who’s right? When it comes to Scrum, it’s painfully obvious:

“Product Backlog items have the attributes of a description, order, estimate, and value.” – Scrum Guide

According to the Scrum Guide, estimating Product Backlog items is mandatory. If we want to work in Scrum and not ScrumBut, we should do it. And if it’s required then we can safely assume it’s useful. How?

Our estimates help the Product Owner and everyone else to manage the Product Backlog and do any sort of reasonable long-term planning. Knowing our velocity (amount of the work done per team per Sprint) and having requirements estimated in the same units we know when we’re going to work on what.

That doesn’t mean we know when we will complete it but the closer to the present day we look, the more we can assume. Looking at the work that we’re going to do in the next Sprint or two is usually safe.

 

H What Do We Estimate?

Estimates in agile environment should include risk, uncertainty, complexity and the amount of work to be done. If we know who’s going to work on the task then we can also factor in their experience. All those aspects affect the estimate in a similar way because they’re related.

The more complex the requirement, the larger the effort and the bigger risks and uncertainty. Conversely, dealing with a well known or a simple task will not be risky at all, it’ll probably be easier and won’t take that much time.

Bigger/smaller are relative ways of estimating. It can’t be any other way if you want to factor in uncertainty, complexity and the workload. Those factors will differ for different teams, sometimes wildly. You cannot objectively estimate the size of your requirements but you can do so relatively.

 

How To Estimate Using Story Points?

The most common ways of estimating work in agile methods are money, hours (or man-days) and story points. As we’ve just mentioned, you have to include factors like uncertainty and complexity. That doesn’t make any sense when you think about dollars or hours. You’d never say “I estimate risk to 6 hours”.

What’s even worse, when you use big numbers (dollars, hours) you can’t help yourself but to round up. You’ll never estimate anything to be worth $12834,91. You’ll simply say it’s $13000 or even $15000. Therefore, you can’t say you’re estimating using money but a money-derived discrete unit. But why lie to yourself (and others)?

Because of those problems with numbers, the most common way to estimate is to use Story Points. They are, by definition a relative measure and they don’t have any meaning other than that. You can use them to show how the requirements relate in size to each other in one backlog that’s owned by one team.

If requirement A is worth, according to the team, one Story Point and requirement B – three Story Points, then you can safely assume that B is around three times bigger. That means there shouldn’t be any problem to complete two A-sized requirements in the time it takes to complete one B-sized. Why not three? Remember about the context switching costs!

 

The Famous Fibonacci Sequence

To distance yourself from the problems with rounding big numbers and to include in your estimates vague variables like risk and experience, most teams use the Fibonacci Sequence. Each item in that sequence is made from adding the previous two items. For our agile purposes, we replace the leading one with zero:

(0), 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …

The bigger the task and the less we know about it, the bigger margin we need. Of course, we try to split all the tasks so they’re small and well defined. But if somehow we can’t do that, the Fibonacci Sequence takes care of the unknowns. It doesn’t matter whether we think the task is worth 9 or 10 points as we always round up. Therefore, both 9 and 10 become a 13.

It’s a perfect way to relatively estimate work we’re facing. We know that 8-point task is “more than two times bigger” than that estimated at 3 points. Everyone can feel the difference between a 5-point and 13-point requirement. We also have a pretty good idea of how many tasks of different sizes we can fit in one iteration.

 

Planning Poker

Planning Poker utilizes Story Points and is so common that some people even think it’s part of Scrum or agile. It is not but still, it’s very popular. Why?

First, it’s simple and fast. It also protects you from few cognitive biases and makes sure no one is left unheard. To “play” Planning Poker you only need some post-its, smartphones or a dedicated deck of cards.

Dedicated Planning Poker decks are simply playing cards with all the numbers from the Fibonacci sequence. Sometimes they even include zero (“it’s already done”) and infinity (“not enough info to estimate” or “I don’t understand the requirement”).

We have to remember that for one team requirement A might be worth 5 points and for the other – 13. It doesn’t matter as long as the relative rations hold true. If requirement B is worth 2 points in the first team, then it should be worth around 5 in the other. That’s very important and it’s the most common mistake when using Story Points. Never compare values across different teams.

Relative estimation is easy but you have to start somewhere. If you have a brand new backlog then pick one item at random and assign it an average value, e.g. 5. It’s just the starting point, you’ll re-estimate that one in the end.

Now, go through all the requirements one by one, discussing each and then estimating it using your cards. Every team member picks a Planning Poker card with an estimate and places it facedown. Alternatively one can write down a number and keep it secret until everyone made up their mind.

When everyone is done, it’s time to reveal the estimates. If all the team members assigned the same value – congrats, you’re done. If not, then those who proposed the lowest and the highest estimate should say why do they think that way. They might see risks or opportunities that others missed!

That effect is unique to the Planning Poker but you have to remember that you’ll get everyone’s opinion only if you keep all the estimates secret until everyone decides.

 

Anchoring

Anchoring is a very common cognitive bias, an imperfection of our human brain. Just by showing someone a number, even if it’s not related to task at hand, you’ll influence his decisions. His thoughts will be drawn to that number.

There is a great illustration of that effect mentioned in a brilliant book “Thinking, Fast and Slow” by Daniel Kahneman. Visitors of San Francisco Exploratorium were asked to guess the height of the highest giant sequoia in that park. For half of those people that question was preceded by asking “do you think the highest sequoia is more or less than 1200 feet high?” The other half of visitors were asked the same question but with 180 feet as the anchor.

Both propositions are absurd but the average guess of people that were anchored with 1200 feet was 844. Those who were asked about 180 feet guessed on average 282. That huge difference is a result of one not-so-innocent question that preceded the estimate.

Back to Planning Poker. The example above clearly shows why it’s so important to keep the cards face-down and your estimates secret. By showing or saying out loud a number you’ll influence everyone in the room. Even if you wanted to pick the same card, you’ll simply stop thinking. If you wanted to show something wildly different, you’ll adjust to the anchor. Most people won’t show “13” when they’ve seen someone pick “2”.

If you value your team’s expert opinion then you have to be very careful. Even describing the requirement as “easy” or “hard” will inevitably influence estimates and decisions. That’s why Planning Poker when done right is so powerful.

 

Relative Mass Valuation

We have to admit that our favorite estimation technique is Relative Mass Valuation, not the Planning Poker. Despite it’s scary name and large number of steps it’s hands down the best way to estimate the relative size of tens or hundreds of items.

It’s not unusual to accurately estimate a hundred requirements using Relative Mass Valuation in two hours of less.

To make this game work we need all the requirements and all the proposed sizes (for example the Fibonacci sequence) on separate pieces of paper. You need some information for all the requirements – just enough to make everyone else understand what needs to be done. Pieces of paper with numbers contain only those numbers, preferably in a big font.

Because it’s a game, we also need a board. In our case, this will be the wall, the table or – if you have a lot of items in your backlog – the floor.

The goal of the first phase is to rank all the requirements from the smallest to the largest. Each player takes a requirement, reads the description to everyone and puts it in the desired place. If you put it on the far left side, you mean “it’s smaller than all the others”. If you put it between items X and Y it means “it’s bigger than X but smaller than Y”.

Instead of adding new requirements, a player can move an item on the board to a new place. To do this you have to say why you think it’s bigger/smaller than others. After a short discussion, you rearrange one card. Phase one ends when no one wants to rearrange anything and you’ve ran out of requirements. Congratulations!

Rules for phase two are very similar but instead of backlog items, you place and arrange numbers. By doing so you’re setting up cutoff points that mark the start of a certain size. This means that when you place a card or a piece of paper with a number “5” all the items to the right are of size “5”. Of course, until the next number (presumably “8”).

Phase two is really fast, because we already have all the items sorted. You only need to look for the cutoff points. Brilliant, isn’t it?

 

Not Only Planning Poker

Relative Mass Valuation is the fastest way to estimate a big backlog. However, Planning Poker is perfect for one or few items. That doesn’t mean that there are no other “agile” ways to estimate. Ultimately, you’ll end up comparing the item to those with already known size. That’s how our brain works, it always compares.

But it’s not how Scrum works. Planning Poker and Relative Mass Valuation aren’t a part of Scrum or even agile methods. But they are popular for a very good reason – they work. If you found something else that brings you desired results – stick to it. Empiricism is an integral part of agile mindset. If it works – keep it.

“Do not replicate what successful people are doing now. Replicate what they did years ago, when they were just like you.”

Remember that Scrum Guide explicitly says that all backlog items have to be estimated both when it comes to size and their value. If you discard those estimates, you lose the ability to optimize work done. And endless optimization is one of the primary aspects of Scrum.