Planning poker et al

You probably know, or at least heard of Planning Poker. It’s a very funny event; the whole team gets together with the product owner, who presents the upcoming user stories one by one. After each story presented, the team have to estimate the amount of work that should be done in order to complete that user story.

There is another agile event, called task breakdown. That is the process of decomposing a user story to tiny tasks. This process is all up to the team members. The product owner usually doesn’t attend this meeting.

There can be two cases:

  1. The estimate is used for the burndown-chart scale only (how much point a task inside a story is worth)
  2. The estimate resulting from the planning poker is needed for some management reason (project schedule, for example)

If it’s the first case, the planning is a complete waste of time.  In this case one should use other velocity-measurement base (like the number of tasks done), and eliminate the whole thing. It has no added value, so it shouldn’t be done according to lean principles.

In the second case, planning can be justified. The problem comes when the poker game comes BEFORE breaking down the user story into tasks. Just imagine it: you’ve got a project with millions of lines of code. A product owner comes along and tells: “Well, you have to design a new feature that will execute different processes. How much effort?”. And that’s the point when bargaining starts. Usually there is no one in the room who’s got the whole picture; of course, the system is large, components inter-work is complicated and so on. Everybody will try their best, to fairly estimate the efforts needed; The team will eventually agree on a number, which is acceptable to everyone – and is perfectly useless. In the case of large user stories the estimate will usually be too low, in case of easy ones too high. There are really few stories for which the estimate will be OK.

The strange thing is, planning poker sessions are usually held before breakdowns, even if the estimate is really important. In my opinion the best order is the other way around. Given a huge (close to epic) user story; when can you estimate it better: when you have a dim idea about what you have to do (the big-big-big picture), or when you see how little pieces fit together in order to form the feature to implement?

To be honest, so far we’ve tried the traditional planning-breakdown path only. However, it turns out that our estimates  are closer to random numbers than to effort evaluation. Some days ago, we had yet another planning session, which made it obvious that this approach is not the one to go with. I’m really looking forward to trying out the other way. I’m really keen to see whether that approach results in better estimations or not. Hope to be able to try it soon.

Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s