Ditching planning poker

In a recent long-running agile project, we started out our story estimation process with a game called “planning poker”. Planning poker is a collaborative estimation technique, where all developers on a team determine estimates in stories in terms of points, and then reveal them to the team. The idea is both to root out any uncertainties, as well as come to a consensus on an estimate for a story.

A couple of years ago on this project, we noticed an interesting trend. For whatever reason, our numbers rarely deviated from the mean. That is to say, if one person estimated a 13 and another a 5, more often than not everyone else had 8. The tech lead also had 8. From story to story, the tech lead might have 3 and the team 8, but on another story it would be backwards.

The real value in the meeting was knowledge transfer from analysts to the team on what we would be building, but the actual estimation part was a waste. The conversations that came out were conversations we would have anyway as we were developing the story, and were rather inconsequential to the whole. Since the numbers all evened out at the end, the group estimation served no other purpose, other than to make developers feel good that their voice was heard.

But it’s quite expensive to take up everyone’s time to have your voice heard.

Instead, we established communication channels that when an estimate seemed too large, we’d feed that back up and make future adjustments as necessary. But as long as we were delivering stories in a timely fashion, and stories were not too large or too small, it all came out in the wash. It was a bit of a transition for developers on the team, as there was fear that this opened the possibility up for biting off more than someone else said you could chew. In the end, the trust between the team and the tech lead/analysts won out.

So in the end, we just ditched group estimation exercises like planning poker altogether. We didn’t ditch estimations, as it’s still important as a consulting company to set expectations on how much something is likely to cost. But the biggest help in estimations was simply keeping stories small, 1-3 days effort, not cathartic group estimation sessions.

Now what to do with 5 decks of used planning poker card decks…

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I also really like Capers Jones’ “Applied Software Measurement” book. It has so much industry data that it makes estimating much less subjective. It also helps to turn the estimate in functions into time based on platform used.

  • Andy Rose

    So, just to be clear, how are estimations worked out now? Are these done by the tech lead/analysts and passed onto the dev team who will then raise concerns if they have any?

    • Anonymous

      Yes – although we try not to get too worked up about it. Individual tasks might have disagreements about them, but we found that a story’s size didn’t really change at all after discussion.

      • Andy Rose

        I see, so the tech lead/analysts estimate story size and break this down into the individual tasks that make up the
        story. I take there is still some kind of sprint kick off meeting where this is presented to the devs for consideration?

        I guess a requirement for this to work is for the the technical lead to have a good understanding of the code involved as they would be key in breaking the story down into component tasks but I suppose that is why they are the technical lead.

  • In my experience, our applications have been complex enough that it can be easy for there to be a large variance that sparks discussion. If most people throw out 5′s and one guy throws out a 40, that’s something we need to talk about, since that’s not likely to wash out in the end. Thoughts?

  • Anonymous

    One thing to highlight is that your team didn’t find that planning poker was providing value wrt estimation. The key point is your team and this particular project. I’ve used planning poker with teams and projects where it was invaluable for promoting discussion and clarifying story requirements. Like any technique – agile or not – use it when it works and adapt or drop it if it doesn’t. And if you’re looking for something to do with your planning poker cards, I can send you my address. :)

    • Anonymous

      I think the difference is we don’t typically involve the team so early – the analyst is also the tech lead, so we don’t really need to get everyone’s input about sizing. Instead, it’s usually just about implementation details when we review a story together.

  • Tom

    Please help me to understand. How do you know what the mean is unless you collect estimates from the group? Or are you saying all your stories are 8s?