Planning Poker and wordy developers

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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).