For those that know this about Story Points, none of this post will be surprise, but given the current crop of consultants talking about delivering capabilities and features using story points I think it’s time to restate this simple fact;
Story Points are an Estimation of Complexity not of Time
But wait I hear you say “JIRA uses them as a measure”, unfortunately you have just revealed that you have no idea what Agile or DevOps actually is, well done for being so honest! JIRA is not an Agile tool, its a tool that existed before Agile that added some Agile terms, misunderstood the dynamics and put Story Point in as a metric (they have a better one related to financial value that can also be selected), shakes his head in despair!
It’s so fascinating all the twists and turns that Agile is taking in order to become the bureaucracy it was invented to remove!
How to use Story Points
Story Points come from the mystic art of Planning Poker, or for the initiated “that game”. The game is played by representatives from all the skills required to deliver the work (at the Idea Stage and includes both business and technical people, at the Delivery Stage and still includes both business and technical people, there is no handoff in Agile) and that creates a discussion around the median story points for a given story as a reflection of the combined complexity. These point are indicators of difficulty and dependencies but are NOT units of time. I can hear shouts of heresy, but in all honesty this relationship does not exist and it creates a huge amount of non valuable work, a huge amount of pressure on people and is a total waste.
As for the complexity of licking stamps or brain surgery, I’d have to say just reread that story because it’s crazy. It presupposes a time relationship to complexity as if time and complexity maintain a concurrent meaning and value for everyone, which is clearly not true. Complexity is a stand alone value to encourage discourse and challenges not to create unrealistic or impossible timelines. After all if we agree with this, why is one point one day, why not one month or one year, the whole thing is just so abstract that to rely on it makes no commercial or business sense. I suspect this reference is responsible for lots of developers working all night and all weekend to deliver work that has no element of true trajectory included in its planning, or delivery.
Take your story points and use them during planning, then throw them away, because as any strategist knows when the battle begins you throw your detailed planning away and only maintain your guide rails and rules of engagement. As long as you remember that Agile and DevOps does not have deadlines for delivery but is focused on a continuum of daily awareness for problem solving (with the capacity to swarm on a problem), risks/opportunities, and to elevate risks (unready work, dependencies etc.) to a wider and often more knowledgeable view.
Other Perspectives
Story Points are often linked to Effort (effort is construct that combines knowledge with available skill) and Complexity, however again there is no time element applicable for the same reasons.
How is time understood in Agile?
Time and effort is established by continuous delivery and the teams refining their working practices as the work comes through. This is why different teams can deliver similar work at a different pace based upon their upfront knowledge of the solution and the teams skills in both working and working together.
So to understand when you’ll get delivery you need to start working as over a number of sprints gain a notion of how long things take to do. It’s really simple at one level you can’t have tightly managed delivery working and Agile they are polar opposites. While I recognise that people pushing a uniformed, tightly managed and understood deadline based workflow process won’t agree with this, the simple fact is that these processes are not Agile.
Republished by the consent of the author: Karl Smith 1st April 2022