Forget about poker planning

Explaining agile estimating and planning is the hardest part when teaching a class.

That’s because people freak out when they hear about story points and relative estimations.

Why wouldn’t they?
If you’ve ever done a project before in your life, you know that at some point in time, you’ll need to tell your stakeholders when it’s going to be finished or how much it’s going to cost.  If you then reply: “In agile projects, we don’t care about up-front estimations.  The team plays planning poker before each iteration and measures velocity afterwards.” you’re bound to get some funny looks.

That’s natural, because you first have to explain agile release planning.

What is our goal in Agile software development?

  • To avoid investing money & time in up-front work because we know the future is uncertain and things change.

How do we address this?

  • We invest just-in-time, in focused time-boxes.

What is missing?

  • If we do everything just-in-time, we’ll never be able to do release planning.

True, if we estimate iteration by iteration, we’ll only know our cost and release date at the last iteration.

You don’t have to be a veteran project manager to know that the only way to successfully deliver a project is to continuously monitor scope, budget and time.  Depending on the primary project focus, you can work with the other constraints to keep it on track.  (Don’t let people who say they successfully manage a project with 3 fixed constraints fool you, they actually do the same because they include contingency buffers.)

This also applies to agile projects. Even better, it’s much easier to monitor these constraints.  After each iteration you’ll have new data.

  • How many person-hours have we spent?
  • How many story points were delivered?
  • How are we doing on timing?

In order to be able to use this data, you need a fully estimated (release) backlog.

If you keep your releases small, it’s not difficult to split up the requirements to a user story level.  Techniques such as user story mapping are a great way to do this.

The next thing to do is to estimate all user stories.  But because you have limited detailed information at this point, the only thing you can do is compare them, thus estimating them relatively.  This is where story points come in handy. However, stay away from planning poker!  It tends to drag you into detailed discussions, which are not relevant at this moment in the project.  A great alternative is silent grouping. The exercise on its own makes it clear to everyone involved that its goal is to get a first high level comparison, nothing more.  Which are big user stories, which are small?  Use story points as a scale, and you will have a fully estimated backlog.  Quick and without much discussion.  I still use planning poker, but only when we notice during iteration planning that a user story has a completely wrong story point estimate (which doesn’t happen a lot).

Skeptics might say : “How can this be accurate?  You’re estimating without any detailed information?”  True, some estimates might be high, others might be low.  Some might level each other out. Whatever.  Just remember, our goal is to get a first idea about the size of the backlog, nothing more.

A next step is to get an idea about the team velocity. If you can wait a few iteration, great!  If not, guess!  In both cases, you’ll have your measurements soon and you will need to adjust continuously.  But at that point, you’re in control. Iteration after iteration you can project the results onto the release planning and adjust some of your constraints if necessary.

Take a look at this burn-up chart example as a tool to monitor the release planning of a project where timing was the main constraint.  The worst case, best case and linear scenario make it visual that a plan is never going to be 100% certain.

If you think about it, agile projects are not that different.  Letting go of the illusion of a fixed plan, drives a completely different behavior.  One that focuses on creating value and making healthy decisions.  The way project management was meant to be…

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.


  1. Good post! I usually try to get a grip on the size of the backlog too, but I still want to do poker sessions at the start of a sprint. In my opinion these sessions help to get a shared vision on what it is that we are making. We tried just elaborating on the stories, but I experienced that with the pokering more information was revealed. Risks and better work breakdowns emerge from the discussions we have while pokering. Note that we usually skip the lower story points, since these most of the time turned out to be clear enough.

  2. Pingback: Five Blogs – 3 May 2012 « 5blogs

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

%d bloggers like this: