35

We have a project manager that is adamant about planning poker. I have found that this adds stress to everyone on the team, and the times are always wrong. We have different skill levels on the team and expected to complete a task within the given time period. We estimate as a team and then take the average. I find that this adds stress to the team, and decreases motivation/morale.

How can we address this situation?

12
  • 16
    Are your estimates in hours, or in relative units like story points or t-shirt sizes? Feb 17, 2020 at 13:59
  • 13
    One thing to keep in mind: most of the time it's not about the exakt point value but the discussion leading to the point value!
    – hamena314
    Feb 17, 2020 at 14:21
  • 13
    I'd argue you're not even doing planning poker correctly (let alone Agile as Bogdan states below) if the cards directly correlate to hours. How would you vote for 4 hours? There isn't a 4 in a proper planning poker setup. Do you hold up a 3 and 1?
    – NKCampbell
    Feb 17, 2020 at 22:06
  • 10
    To reiterate on @hamena314's point: The planning poker flavor I know requires everyone to agree on one value. If there are differences then the reasons should be discussed and another "voting round" be done. This is repeated until the values have converged. The intention is to uncover shortcuts or hurdles that only some of the developers had in mind. Feb 18, 2020 at 11:55
  • 9
    The 1/4 hour precision seems ridiculous for an estimate. It's worth noting the difference between average estimates or commitments. I.e. for any reasonable software dev task the variance is such that if you estimate that a task like that usually, on average, takes 3.75 hours, then it would be irresponsible to commit to do it in 4 hours, because it may reasonably take 5 or 6 or even 8 hours, you don't get certainty with software tasks until they're done - so if you're asked for a commitment to a deadline, then you must double or triple the estimate to be sure that you can meet that commitment.
    – Peteris
    Feb 18, 2020 at 13:46

7 Answers 7

82

Is Planning Poker Bad for Software Development Teams?

This is the wrong question to ask. Planning poker is a tool. Asking if planning poker is bad for software development teams is like asking if a screwdriver is bad for plumbers. If the tool fits the job then it's a good tool, if not, then it's not.

The real question you should be asking yourself is:

Why is my project manager so adamant about planning poker?

You don't add any extra context to be able to answer this but I'm thinking at two immediate reasons:

  • they are a traditional project manager who lives and dies by schedules and deadlines. I can see that in your comments where you mention that the deadline is at the end of the sprint which is usually 3 weeks. A sprint end is not a deadline. Story points and sprints were mentioned in the comments so I'm thinking you are doing some sort of Agile? Let me tell it straight: you are not. The fact that everyone is stressed is another indicator that you are not. Another is that you estimate in hours and if something comes up as one day then you have one day to do it.
  • (as the logical continuation of the previous point) your project manager can't put pressure on the team when you use story points in the same way they can put pressure on the team if you use hours. So they prefer hours. If you estimate something at one day, they will put pressure on you to do it in one day. They want a commitment. And it doesn't matter if a senior is doing the job or a junior. You said one day, you better make it happen in one day. At this point, I think this image is should be mentioned:

enter image description here

An estimate is an approximation. The fact that you provide estimates as 3.75 hours (as you mention in your comment) means that you are ignoring this fact, you or maybe your project manager.

I suggest you read the following posts for hours vs story point estimation and why planning poker is a good tool for many teams:

Another thing to add is that planning poker is a consensus-based estimation techniques. That means that when you get vastly different estimates, the team members discuss it until they reach a number that they all agree with. They don't just estimate as a team and then take the average. An average completely destroys the discussion that needs to take place in order to reach consensus and also destroys the spread of the different estimations people provided. If a senior says 1 day, and a junior says 5 days, getting back (5 + 1) /2 = 3 days is not a good estimate because the senior will finish early while the junior will probably be late. Then what happens if the junior works on the task? The project manager will pressure them to finish the work in 3 days even though they thought it will take 5 (and that was probably wrong too and most likely they will finish in 7 days).

Planning poker is a tool. Story points are tools. Your project manager should probably learn what these tools are all about before insisting on estimating in hours and keeping people accountable for estimates that look forced from what you are describing.

5
  • 21
    I was half expecting that last paragraph to say "Your project manager is a tool" and I'm not sure I'm happy or sad it didn't. But the answer is spot on +1
    – Erik
    Feb 19, 2020 at 13:37
  • 3
    +1 for reaching consensus, not taking the average.
    – CJ Dennis
    Feb 19, 2020 at 22:50
  • 1
    @Erik Organizations are emotionless. To them, any(one|thing) is a tool. So it goes without saying that the PM is a tool (and so is me and you). Feb 20, 2020 at 12:59
  • 1
    Great answer. You might also want to add that story points were literally invented as a way to obfuscate estimations from managers so they wouldn't convert them into deadlines, and that Ron Jeffries himself (the creator of story points) and most manifest signatories have already moved away from story points and towards NoEstimates Feb 20, 2020 at 14:50
  • +1 just for the graphic
    – David
    Sep 17, 2020 at 20:12
11

Planning Poker isn't the only way to estimate and lots of teams get on well with other methods. More experienced teams may find they can reach a consensus estimate via a quick conversation instead.

The idea of poker is that it encourages the whole team to contribute an estimate and that everyone's opinion is important. Averaging is reasonable if the deviation in estimates is small. If there is a large spread of estimates then averaging is just a way of ignoring a confusion rather than clearing it up. Whatever method you use, the priority is to ensure the team feel that they own the estimates and that they have confidence in the numbers agreed.

Trying to do absolute estimates with 15 minutes precision(!) is surely a huge part of your problem. Of course that puts unreasonable pressure on the team, it encourages them to "game" the estimates and is not transparent ("ideal hours" are not really hours so why pretend they are?). On the evidence you say that method is failing, so fix it. If poker is unpopular then maybe don't use it straight away but you can still do relative estimation with story points instead of hours, use modified Fibonacci numbers, encourage discussion, look for consensus and avoid averaging.

9

We estimate as a team and then take the average

Good grief, don't take the average! That's not how planning poker is played.

Here's how I teach my teams:

  • start with a brief discussion of the work involved
  • play round 1: everyone shows their card.
  • then the highest vote and the lowest vote each explain their rationale. Perhaps further discussion ensues.
  • then play round 2: everyone shows their card
  • repeat until there is consensus
    • consensus does not necessarily mean everyone shows the identical card (altho we always enjoy it when that happens). If all votes are close but not identical, we sometimes define a rubric like "let's be conservative, take the higher number" or "let's go with what the domain expert said". (But don't "defer to expert by default" on the first round, at least not until the team gets good and comfortable with the whole process.)

Junior devs may feel uncomfortable when they are first asked to participate, and may need some coaching and encouragement that it is okay their estimates are different, and that it is helpful if they ask what might seem to them like "dumb questions", because their question will prompt an explanation that might bring up something that no one else had been thinking about when they made their estimates. When played this way, there is less pressure on junior devs because if they "get it wrong", that will be clarified during the discussion and this is an opportunity for them to learn by doing.

I don't feel strongly about whether to play in story points or in ideal days, but I do feel strongly that a Fibonacci deck should be used. Not only because the increasing bin sizes reflect how uncertainty grows as a function of size; but also because it's a lot easier to choose between 5 and 8, say, than between 5 and 6. The bigger gaps make the choices starker and therefore easier.*

*At least, it's easier once everyone gets used to the idea that it's not "accurate". It's not supposed to be accurate; it's an estimate. When you are estimating how much money you'll spend at the grocery store, you don't use accurate prices, "bread costs 2.23 and kleenex costs 3.86 and a candy bar costs 1.25". You say "ok, bread is about 2, kleenex about 4, candy bar about a buck, I want 2 candy bars so that's about 8, better bring $10 to be sure."

I introduced planning poker to my teams in order to help them be more comfortable with estimation, and learn from each other how to do it well. But honestly, the benefit in knowledge sharing and scope clarification is so high that at this point I almost consider the estimation to be a secondary goal.

I hope this helps! Good luck, and try to have fun when you play.

4

It's no bad, and neither is stress, but since you're asking the question, it may be the source of a larger issue.

I've been on teams where I've liked planning poker and teams where I've loathed planning poker, so I would say that generally "it's good", but in the wrong context, "sometimes it's bad".

When I said it may be part of a larger issue, such as misunderstanding the story. If when pointing you get wildly different numbers as you say, you have to make a decision of what to do. Do you:

  • Spend time right there to have everyone defend their estimate
  • Throw out the high or the low since they misunderstood something
  • Take time outside of the meeting to get a better understanding of the complexities of the story

I'd encourage you to go with the third option. Simply state that the team doesn't have a clear grasp of the story, and you'd like to take some time outside of this meeting (to save everyone's time) to get a better understanding. The next time you play planning poker, that story should be less stressful, but maybe another one comes up where you need to make a decision on what to do.

As was mentioned in another answer, let it be what it is: a tool for not only estimating, but for determining if the team has an understanding of the complexities involved in the story. Further, I'd suggest that when you take time to come up with the complexities of the story, write them in the story; that way the next time you do planning poker you can say "Here's the story, and here are it's complexities, what are your estimates?"

3

How can we address this situation?

This depends on whether your project manager is willing to adjust his approach to planning poker or not. But she needs to understand that her approach is not just creating stress, but also includes bad math and is a bad tool to make predictions. Here is the approach I would suggest to her:

At the end of the current sprint, count all the tasks that were completed (according to whatever you define as 'completed') and add up the hours you have assigned to these tasks. Take this number and use it as a prediction of how much "hours" your team can realistically get done next sprint. Now is a good moment to accept that "hours" is not really hours and you rename "hours" to "points". Next thing you do is that you treat points as a prediction for the aggregated team performance over the next sprint, but don't use it as a hard deadline for task.

Let's say you completed 66 hours worth of tasks. That means that your team can do 66 points of tasks per sprint. Next sprint you will add tasks to the backlog until you reach 66 points and you have a realistic prediction of how much the team can achieve in that time. This should work for your product manager, because now she can more realistically predict how much of the workload will be done. You can even estimate stories for months ahead and get an idea of what will be done by the end of the quarter etc. (with some caveats of course).

Moving away from estimating hours, which can be wildly different depending on the individual, will also make sure that the estimates are aligning better. Developer who are usually lower in their estimates should calibrate to higher estimates and developers who are usually higher should calibrate down, points are just becoming an abstract unit of work: A junior might estimate a story as 5, if it takes him three days, while a senior sees the 5 as something that can be done in half a day.

If your product manager does not agree to changing her approach I would try to get together as a team and fix it unilaterally: Agree that to make estimates that everyone can follow, everyone cannot estimate how much time they would need themselves to finish the task, but how much time the team member with the least experience on that task would need. This way every team member can stay within the given estimates, as it is easier to work slower than full capacity than to go faster.

Either way, you should reach a situation in which everyone roughly comes to the same estimates.

3

As @NKCampbell points out in a comment, normally a planning poker deck doesn't include a 4. This is not a bug but a feature (no pun intended): the idea is that as complexity increases, the associated effort increases exponentially rather than linearly.

Also, in my experience, the numbers are typically treated as story points or some other abstract unit of work (as pointed out by @Helena). Agile practitioners (coaches) in my experience usually recommend this (and strongly recommend against doing estimates in hours) -- precisely because "8 hours" is usually interpreted as "one calendar day", and very few people are actually productive for 8 hours per workday.

And the idea is to measure how many story points the team can get done in a sprint; that's your "velocity". Measuring at the team (rather than individual) level tends to eliminate the discrepancies due to difference in experience and/or skill.

I'd also note that most agile practitioners I know consider it an important rule of thumb to not adjust an estimate down: if a more senior person says 3 and a more junior person says 5, the team should go with 5 (because the junior person might end up working that particular task). This may be a sgnificant factor in why your estimates are off.

So I am/ we are sorry to be the bearers of bad news, but it sounds like your manager is doing it wrong. That said, they may be reacting to pressure from their superiors.

How to approach your manager would probably be better asked on The Workplace. But for what it's worth, my advice would be:

  1. Arm yourself with as much knowledge as possible. Read Kent Beck, Martin Fowler, Bob Martin, Mike Cohn et al. Encourage people on the team to do likewise -- maybe several of you can each read a book or a few articles and report to the others on what they learned.

  2. Come up with one or two specific recommendations based on agile best practices. For example, trying out story points instead of hours-based estimates.

  3. Approach your manager, as non-confrontationally as possible. For example, say that you don't feel your team is getting the most bang out of agile; you think the team could be more productive and morale would be improved if <<insert your recommendation here>>. Point to your research and show that your recommendation reflects best practices.

I would emphasize that you're making these suggestions because you want the team to succeed, but also because you want your manager to succeed. If you haven't already, you might ask about their goals and how you can help them achieve those, etc., etc., etc.

0

Planning poker is a simple tool for estimating, and it works well enough:

  • People think differently, if they speaks up to share concerns and explain their vote, this puts forwards multiple perspectives for the whole team
  • If everyone will understand how that specific PBI fits into the Sprint, it will reduce the chances of tunnel vision.
  • Socially it brings the team closer to each other because they aim for a good estimate for themselves as a team

It also helps building trust and and respect for other team members.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.