How to play planning poker… Badass Mode!

1 minute read

Planning poker and story points often turn into a power struggle where everyone loses. Here are 2 winning strategies for how to play planning poker as dev teams

Drawing explaining dangers of exposing story points outside the dev team. Story points leak outside the team -> Estimates get challenged -> Team cuts on refactoring and clean code -> Team gets slower -> Trust erodes -> Estimates get challenged -> ...
By Philippe Bourgau, under CC BY-SA 4.0, high resolution image

The large scale trap!

We must be extra careful with any flavor of large-scale agile. It’s too tempting to compare or even display velocity figures of different teams. It can even create an artificial sense of competition that will make things even worse.

Velocity was invented for team internal planning, not to commit.

💡 If we need predictions, #NoEstimates and Lean management tools will work better.

Don’t forget who has the story point printing press!

💡 Keep story points inside the team, and you’ll have a lot more control over technical debt and refactoring

As developers, we are the only ones able to keep the code base in a sustainable state. Unless our company is on the brink of bankrupt, we should think for the long term! Whenever our estimates gets challenged, we have 2 strategies:

Say NO!

As a team (or as a team of teams) we should meet before the encounter and agree that we will refuse to reduce our estimates. When everyone refuses, business people will have no choice but to accept it.

Say YES!

The idea here is to reduce the estimates, but fail until business people listen.

  1. First, you’ll need to explain why you think these estimates won’t work. Using metaphors and references will help here.
  2. Second you’ll need to stick to clean code and refactoring. Even if this means that you will not meet the estimates, do it anyway.
  3. Third, explain again to business people why estimates where not realistic. Compromising on clean code should not be an option.
  4. Repeat…

During this summer, I’ll post a few similar infographics. Next one is Does Programming equal Refactoring?

Comments