What do you think of "Planning Poker"? [closed]

Question

Planning Poker

Summary, in case you don't want to read the wiki article:

1. Get a list of tasks you want to do for the upcoming iteration
2. For each task:
   2.1 Discuss with the group what it entails
   2.2 Everyone writes down / selects an estimation of how much effort is required for the task
   2.3 Everyone reveals their estimation
   2.4 The highest and lowest outliers explain their reasoning
   2.5 Repeat until a consensus is reached

Usually something similar to numbers from the Fibonacci sequence like 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 are the allowed values, so you don't get long arguments over close values like 23 vs 27.

Further, the numbers represent a unit-less value of effort, whose value is determined by a baseline task that everyone agrees equals about a 1, and all else is relative to that.

Ultimately, the goal is to get a good feel for a given team's "velocity", which is the number of these points that can be completed in a given iteration. With that, it's possible to make reasonably accurate estimates of how long any given feature will take.

---

We did this at iteration planning meetings at one company I worked at, and I thought it was one of the few good things about that particular company. So, what I'm wondering is, has anyone used this? Do you think it's a useful tool for estimation? Does it work in all situations, or does it lend itself to certain teams, projects, etc?

Answer 1

We use it in our company for the project I'm involved in. Some notes about planning poker are expressed in my recent blog post, and here's a bigger list of why it's cool:

1. It makes everyone agree. People are not forced to accept any result; instead they're forced to make their own estimate! The time to defend their own estimates is also allocated, if it's necessary.

2. It keeps everyone busy. You can't slack during the meeting, while trying to show that you're so involved. Also, necessity of moving your hands constitutes a good physical exercise to keep you off of sleeping.

   However, a downside of this is that sometimes you do need to do something else (for example, take some notes and write down the details of the agreement you've just reached).

3. It keeps meetings faster. There's no need for a constant involvement of a meeting leader to keep everything on pace. The game with clear rules is way better for that. Yes, you need to make some extra moves to put cards on, reveal them, et cetera, but these pay their way.

4. A lot of people just like to play cards, especially poker :-) This increases motivation.

A company that sells decks of such cards accompanied their site with an article about Planning Poker, which is also worth reading.

Answer 2

We use it extensively. I find it has several advantages over traditional methods:

1. The team takes more ownership of estimates
2. Often programmer archetypes favor introverts - this method encourages them to contribute where they might otherwise defer to more extroverted personalities
3. When a feature has a wide distribution of estimates it is a good indicator of risk
4. Just by doing the estimate you learn more about the tasks
5. Nothing beats putting people in a room communicating effectivly

Answer 3

I agree with Pavel's points. There's also one other thing that is valuable. It levels the playing field for discussion. Often quiet people are drowned out by more verbal people in a group discussion. Planning poker gives everybody a chance to make their decision before the active discussion begin. And if it the quiet person who provides the "outlier" opinion, they have the full stage on which to present their case. Therefore the technique is empowers the quieter contributors, and ensures full team participation.

Answer 4

After having used planning poker for a few sprints, the management finally realized what all us developers had known for months, we will not finish in time.

Planning poker, or more accurately, story point based estimation, is much more accurate than traditional estimation practices because it combines an easy way to estimate the combined complexity of the entire feature set with with actual measurements of the teams actual capacity.

Answer 5

There are many good answers here already -- I just wanted to point out one other feature.

When you use planning poker, you get an instant measure of how big disagreements are on size of work. If I think it's a 2, and you think it's a 3, we can just call it a 3 and move on. But if I think it's a 1 and you think it's a 5, we'd better discuss.

Answer 6

It makes everyone talk and think about what's being done. Even if I'm not going to work on it, I have to pay attention to estimate. That helps me when 2 months from now I need to work on something that touches that area.

It's also easy to grasp. Show people a work breakdown structure and their eyes glaze over and they start drooling in their sleep. Show them a list of tasks for the next 2-4 weeks and they can understand that.

Answer 7

Another good thing: The discussions about whether task X is a '3' or an '8' help the team nail down exactly what the scope is - so later on, there isn't a discrepancy about what task X entailed.

Answer 8

I like Pavel's points and would like to add that it really helps junior developers or noobs learn a lot faster. They can't just sit back and let the senior developers rule. Their vote counts just as much and if they really focus on making their estimates accurate they will learn a lot from the senior developers.

Answer 9

I dislike it in my current team, primarily because we have people who fundamentally don't buy into it. We spend a significant portion of any grooming session debating whether pointing is worthwhile, and our product owner never breaks down epics, so we usually end up with wildly out of kilter estimates or stories where the points indicate that the thing just needs to be broken down.

Nothing like having a 40 and two 20s in a single sprint!