A lot, it turns out. Or, maybe, not “go wrong”… But the result you get might not be the result you expected.

This article is part of the series Planning Software Development.

Suppose your team must estimate the effort of the work packages (User Stories, …) it is supposed to work on.

I know, sometimes the estimates are not needed at all and sometimes the need for estimates hints some deeper dysfunctions. Let’s put that aside for now.

Your team must or wants to estimate, and you are doing “Planning Poker”.

Planning Poker

In Planning Poker, some person (often called the Product Owner) presents a user story to the whole team. Then, every team member (developers, testers, …) secretly select a “poker card” that shows an estimate. Everyone turns their card simultaneously. Then they discuss why the numbers differ so much. After that, they play another round.

Often, those poker cards do not contain all possible numbers, but some exponential sequence (Fibonacci, modified Fibonacci, power of two), so that for larger numbers, there will be more uncertainty.

The benefits of this method are that team members do not influence each other when picking a number (some agile consultants call it a Wideband Delphi Technique for this reason). And still the numbers will be more accurate, because everyone’s opinion was heared during the discussion. And the whole team will commit to the estimates, because they created them together.

Those good things are happening… In the very best case. Which is probably not happening in your team.

Bored People

The PO discusses the user story - It’s the tenth of today. Your have small stories, as you are supposed to. The Scrum Master says “Everyone select your card. And turn your cards in 3… 2… 1… Now!”

The cards show 2, 2, 3, 3, 3, 5, 5, 5.

Someone on the team says “Let’s just make it a five and move on”. And everyone agrees “Yes, this is definitely a five!”.

Doing planning poker for lots and lots of small stories can become boring for everyone involved. People just want to get done - Assign a number - any number - to those stories, and get back to work. So, they become sloppy, like in the example above.

But, on the other hand, you should have small stories that go into development. And, as we already have established, your team must or wants to estimate the work packages they will be developing.


Commitment to an estimate is a real problem.

I have listed it as a potential benefit above: When the estimates or deadlines come from outside the team, people will happily ignore them at best, or become very sarcastic and stubborn at worst. They will only do exactly what is instructed - even if it is stupid. So, the estimates must come from the team themselves.

But commitment to an estimate creates more problems than it solves. When people are committed to an estimate - instead of to an outcome - they will push back very hard against changes that would prove their initial assumptions wrong.

Yes, this is again a hint there might be a problem with the engineering culture of this team or organization. So, the problem is not only caused by planning poker.

But I have seen this in several teams that used planning poker, so it is a real danger. And this problem is caused, in part, by the team commitment that planning poker creates.

Power Dynamics

People always follow their leader. Even if they do not know it. So, if there is a leader, that person’s opinion will dominate the estimates.

And I am not talking about somebody with formal authority. Someone who forces their opinion on others. That would be a major dysfunction in an agile team - one that you should address.

I am also not talking about team members who think they have no authority at all, who think they should submit to the group opinion, who do not dare to speak out. This is also a dysfuntion in your team. It is harder to detect and address, and you must be careful when addressing it, but you should work on it.

I am talking about the person everyone trusts. The most senior or the most talented person on the team. The person who always helps and mentors others. Who is there for everyone else.

The cards show 2, 2, 3, 3, 3, 5, 5, 5. That person showed a 5.

There is a short discussion, where everyone is heared. Then there is a new round of estimating. Suddenly, all cards show 5.

If this happens once, it is OK. If this is happening often, examine your biases.

To Recap…

Planning Poker should, in theory, eliminate a lot of biases and make estimating quick an painless. But in reality, it often fails to achieve that.

The results that you are getting are probably not what you expected. They are often not an un-biased, thoughtful estimate where everybody’s voice was heared. And the shared commitment to the estimate - and not the outcome - creates its own problems.

I do not want to advise against Planning Poker. If you must estimate, it is still the most painless method that I know of. And it is easy to get started for unexperienced teams, so it moves one obstacle - “But we need numbers!” - out of your way quickly.

But after you did it for some time, examine the problems I have outlined above. If you have them, see if you can solve them (iteratively, over multiple sprints, in retrospectives). And also examine whether you can completely do without workpackage-level estimates.