Using baselines for effective planning

I remember my first planning game well. I was very excited. Someone had just mentioned the need for a good bassline and I was about to jump up doing some serious air guitar to Deep Purple's Smoke on the Water, "man this is going to blow these suckers away" was the thought running through my head. Luckily they picked an 8 pointer from a previous iteration before I took to the floor.

I reckon most of the planning games I've been in haven't had baselines. I think this was mainly because we didn't think of them unless they were called for. But lets face it every planning game using the planning poker method needs a baseline.

So here's how I like to do baselines these days.  Select a small, medium and large. Ensure the  baselines were not over/underestimated. Everyone estimating needs to have a good idea of what the story entailed. If there is a new team member or its been a while since the project was worked on then someone who has worked on the stories walks the team through the effort involved. Baselines are visible in every planning game. Baselines should be relevant and appropriate. Baselines should also be recent, if your baselines have been hanging around for many iterations its likely the effort involved in the stories has become shrouded in the mists of time. 

The team should be on the lookout for potential baseline stories in every iteration. Keep a list of baseline stories that can be used or called upon when similar stories are being estimated. To help with identifying baselines it can be useful to identify stories which have been under/overestimated, for example by stickering those stories and noting the real effort involved. 

Baselines are nice as they:

• give the team a common reference point
• can cut down on haggling by comparing back to the baseline
• ensure the relative magnitude of points remains constant throughout a project
• allow different projects to have the same magnitude of points
• enable new team members to estimate as soon as they join the team.

Real Life Examples

The Baking team are having a planning session. They have 3 baselines:

Small (3 points) Almond Paste Filling

Medium (8 points) Granary and Onion Scones

Large (20 points) Sausage Rolls

There is a new product line being introduced, croissants, and the team discuss the acceptance criteria. The Product Owner wants a light, buttery and flakey pastry with a little bit of oh-la-la thrown in. As they have a relevant baseline they can quickly associate the effort to the sausage roll story. They worked on this story last iteration and know it also involved flakey pastry and they know creating this by hand is pretty intensive. They discuss the differences between the two and estimate the croissant story at 13 points because they know a yeast puff dough is easier to make than the rough puff used in the sausage roll. 

Another story estimated is yoghurt scones. The initial estimate is 8 points but the team is not in agreement on this. One of the team who feels it is less than 8 compares it to the medium baseline, the granary scones and explains this story actually takes more effort than the yoghurt scones as no onion needs to be fried and mixed in. The team then re-estimates and 5 points is the unanimous decision. 

In both examples above there may have been more discussion and more time spent on agreeing an estimate, having similar stories to compare to can speed up the estimation process. It also helps to have someone familiar with the stories and how much effort went into it. The acceptance criteria on a story may give you an idea of how much functionality was involved but it doesn't spell out the effort needed.