Not a fan of planning poker

I’m no longer a fan of planning poker, even though I’m entirely committed to agile estimation.

I’m referring to my dislike of Fibonacci-based estimates, you know, deciding whether a story is 3 points rather than 5, or 8. I’ve certainly been in teams that used this approach well, and I don’t feel strongly enough to advocate against that. But if nothing was in place, I would no longer choose to introduce planning poker.

My issue with Fibonacci-based estimation is that it encourages the technical team, who are often very precise, to focus intensely on assigning a single numerical value to a unit of work. Whilst ignoring the fact that individual estimates are inherently unreliable, particularly in small batches, ie. sprint planning.

I once was asked to perform an initial estimate for another team’s product backlog, circa 200 stories. I used the ‘white elephant sizing’ technique, drawing a horizontal line across the wall and asking the team to describe each story before placing it along the line in relative size to its neighbours. It was quite a day, but the thing that stuck out was how little difference adjusting estimations for individual tickets made to the overall delivery date, compared to adding one very large story to the end of the line.

From then on, identifying epics disguised as stories became much more interesting to me in refinement, than spending ten minutes discussing whether a story was a 5-pointer or an 8.

These days, I much prefer the simplicity of counting the completed number of stories at the end of each sprint and comparing that to the last few sprints (considering any team holidays). Story size and complexity should gradually be normalised during story writing and refinement with this approach, generally resulting in a better quality product backlog.

Someone once remarked, “Oh, you prefer no-estimates,” which I instantly felt was an odd and inaccurate statement as I’m a real stickler for burndown charts, reporting, etc. Just not in story points. Knowing that 25 out of 90 stories are complete, with an average of 15 stories per sprint, seems much easier to understand and comprehend. It also provides an estimated delivery date whilst requiring zero estimates to be performed.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.