My team is composed of 4 developers; all seasoned and skilled. One of them is a wordy, well intended chap who insists on defining the technical solution to our stories before we put down our estimates with Planning Poker. He refuses to estimate if he doesn't have a rough idea of the agreed technical solution (which sounds reasonable, right?).

The problem is that our estimating sessions are taking forever to finish!! In your experience, how do you deal with this kind of personality when playing the planning poker?


He seems to like things being defined formally, so a timer would be a good idea, since planning poker is defined as having set amounts of time for people to speak.

He's got the wrong idea about estimation too, everyone estimates against the story and not the implementation, which is why you get such variance. For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch.

  • 1
    A timer is a great idea. It reminds the speakers to be succinct and forces them to distill what they are trying to say to the very basic point. – Shane Wealti Sep 22 '11 at 15:12
  • It also helps if preliminary work on the stories is pushed out early, then technical design preliminaries can be done "offline" from the meeting itself. Poker is not the place to hash out solutions, you're wasting an entire department's time. Another idea would be to add "design this stuff" as a story gating an early timebox of "implement this stuff." Next round get real estimates for the implementation. – Patrick Hughes Sep 22 '11 at 15:38
  • 2
    Not only is a timer a good idea, I believe it's recommended (perhaps someone with Agile Planning and Estimation can confirm this). My understanding is that, like most activities, planning poker sessions are to be timeboxed to prevent situations like what the question is referring to. – Thomas Owens Sep 22 '11 at 17:28
  • 1
    For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch - Hence the discussion. Then everyone knows about it and estimates are better. – Izkata Nov 8 '13 at 16:19

You team member sounds an analyst personality. Analysts need lots of information to make a decision. The timer idea is best, but be aware, he is going to caveat the hell out of anything he gives. Work with him to explain that it's just an early estimate based on the problem NOT the solution. If he wants to ask questions ask him to keep it to the problem not the solution. You may have to cut him off or annoy him for awhile when he keeps drifting to solutions.

Make sure you hold others on the team to these same rules so he doesn't feel singled out. Analysts are a common personality in programming, so you very well may run into others like him.

  • 2
    +1, I am an analyst personality and struggle with this problem. I notice I am a lot more thorough and complete and have less bugs than my peers but I easily get stressed out and ineffective in situations with less than perfect information. I strive everyday to try and deal with the unknown in a less stressful way. – maple_shaft Sep 22 '11 at 17:23

It sounds like your colleague does not understand the difference between estimate and commitment or it hasn't been communicated to him during training. And, since you tried to attach the problem to his personality, it's possible that your whole team doesn't yet understand it. (But don't worry! Most of our industry doesn't understand it. Agile is hard!)

When we say a story's size is X points, we actually mean a probability distribution. If our estimates are correct, the story should take longer 50% of the time (and the other 50% it will take less time). If your colleague believes that, when X units of time have elapsed, he will be asked to demo the story or else, that changes his approach to estimation.

Planning poker introduces another error: instead of trying to pin down X, we match it to a discrete scale, the Fibonacci scale (1, 2, 3, 5, 8, etc.) being the most popular. It is saying what the size isn't as much as what it is. When we say the story size is 3 points, we really say "it's X plus-minus some variance and X is closer to 3 than it is to 2 or 5."

Your team could benefit from understanding how imprecise this exercise is and how estimate differs from commitment. If you want/need to study these concepts in depth, this book has that.

  • When planning if you think a story takes 3 days and an hour you should use the 5 days, not round it down. It's up to the developer to keep their discipline and make the estimate against the task, not make the plan for the task fit the estimate. – StuperUser Sep 22 '11 at 18:24
  • 10
    "It sounds like your colleague does not understand the difference between estimate and commitment" I can completely relate to this as many managers will ALWAYS take your initial estimates and turn them into commitments. Some of us like myself are so nervous about giving a rough estimate because managers have held us to them and then expected us to work long weekends with no sleep to get it done by the sprint deadline. – maple_shaft Sep 22 '11 at 18:27
  • 1
    @maple_shaft: you're absolutely right, estimate/commitment is one of the biggest misconceptions of our industry and this misconception is one of its biggest impediments. Your "nervousness", "long weekends", "no sleep" etc. are among its consequences. You can solve this problem only if you include everyone, your entire team, your manager, etc. This is why agile transition is so hard. Picking up a deck of cards without understanding these concepts is easy. – azheglov Sep 22 '11 at 18:36
  • 1
    @azheglov, sometimes Agile transition is hard because management thinks that they want Agile when in reality they are micro-managing megalomaniacs with a terrible inferiority complex and a strong desire to NEVER adjust the sprint schedules when requirements change or new information is discovered. In other words, they don't really want Agile because true Agile is so fundamentally contradictory to everything they know. – maple_shaft Sep 22 '11 at 18:45
  • @maple_shaft, you've got that right, too! I won't go into all the reasons why agile is hard in my comment ;-) – azheglov Sep 22 '11 at 18:55

I can see where your team member is coming from, but he clearly hasn't completely grasped the concept of Agile and Planning Poker. You should start by making sure everyone understands the concepts and the reasoning behind them, and then they should do right on their own.


For the teams I work with, at the start of every planning session I set a 3 minute sand timer on the table. I let the whole team know that if at any point they feel the conversation is becoming a deep dive, or irrelevant, or in any other way is going beyond what they feel is needed to estimate the story in story points, then anyone on the team can flip the timer over. Once the sand runs out, then the team immediately estimates.

This method empowers every individual on the team to limit the conversation, when they feel the conversation is no longer useful to estimate the story being discussed. At the same time, it does not immediately cut off the conversation, but does give everyone a visual indication that they conversation needs to wrap up in the next few minutes, because we are then going to vote.

Another tool which I use to help keep the planning sessions focused, is to make certain that everyone on the team has reviewed the stories at the top of the backlog at least a couple days prior to planning. The idea is that if you have a list of questions immediatly upon reading the stories, you can let the product owner know about the potential questions several days prior, so that they can clarify the story or the acceptance critiera to hopefully limit the later discussion. This also allows folks to start thinking about the potential design of the story, prior to being in planning (and trying to design during planning).

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