If your organization references story points in its performance metrics, then you shouldn’t be using story points.

— Cue tilted head and confused look —

You read that right. If anything related to story points is part of your performance metrics, you don’t need story points and should stop using them.

Let’s unpack what I mean.

 

Intent of Story Points

Management has always wanted to know how long a thing will take and when it will be done. We can argue the validity of that until we’re blue in the face, but let’s not. I think it’s reasonable to want to know that, but it’s led to the problem that created story points — false commitments.

Trying to satisfy this timeline need, developers provided estimates. Despite the fact that estimates are estimates, management would take the estimates that developers provided and turned them into commitments. These commitments were rarely met because software development estimates are rarely accurate.

Relative sizing (e.g. story points) was created to get away from estimates being tied to exact timelines. General ranges or sizes seemed good enough to get an idea of size and effort to make informed decisions within the team.

 

The Problem

Story points failed to realize its intent. Since management wants to know when a thing will be done, story points was equated with time and “productivity” anyway. And management tracks it as a commitment and indicator of timeline.

This voids the intent of story points.

Story points have backfired on their creator’s intent. I think this is why Ron Jeffries has said he now regrets creating them.

 

The Solution

As long as teams are going to be held accountable to their estimates and measured according to planned versus actual, there isn’t a need for story points — just go back to time estimates. It’ll make everything more clear and there won’t be a need to translate points into time units. If everyone equates a story point with a unit of time, why go through the trouble of using them and converting them?

Story points were meant to be used internally within teams to help understand size and complexity, from which the team could decide to split stories and make priority decisions. They were never meant to be used as a management metric. Where they are used as a performance management metric, they are no different than time units and aren’t needed — so stop using them.

 

Never miss a thing from me — follow me on LinkedIn.
Join my weekly email list.