A Scenario
Have you ever experienced a Backlog refinement, or sprint planning meeting, when there was endless debate over whether the points for a story are 5 or 8? Has your team ever asked you if coding points are different than testing points? Has management ever compared team velocities or asked for individual story points per team member?
If the team has been together for more than perhaps 6 or 8 sprints – why are you still tolerating this?
The dysfunction
Story points and planning poker are widely embraced patterns for teams using Scrum and SAFe. Even some continuous flow teams use them. So why am I concerned with their usage?
Let’s back up a couple decades to when teams were doing waterfall development and had to provide highly detailed estimates on all development efforts. Ron Jeffries, in an effort to obfuscate time and reduce the negative effects created by these detailed estimates and the process of negotiating estimates versus imposed deadlines, created story points. These were to be used as a common unit of measure within a team to move away from the current practices of creating detailed estimates which became commitments chiseled in stone.
And for a while this seemed like a great idea and an improvement to the current system, which I experienced for quite a few years as a developer.
Impressive sounding tools and practices then evolved such as Planning Poker. Then SAFe introduced anti-patterns such as normalizing story points across teams. ALM tool vendors created all sorts of reports and dashboards for estimating, tracking and reporting velocity. These became the norm for many years and weren’t initially recognized as part of the problem – the commercialization of Agile. Now referred to as The Agile Industrial Complex.
What is also currently happening is many levels of abuses of story points and velocity such as:
- managers using individual velocity to measure people
- competition between teams
- teams chastised if they have carryover or low velocity
- even used in management dashboards where it’s human nature to compare numbers when you see them.
Teams may even say they need to do planning poker to have the conversation with the PO to identify the requirements of the story. That’s an excuse!
Consider this:
What do story points not do? They do not, in any way, measure value. And that’s where our focus needs to be – the continuous delivery of high value software and services.
So going forward, here are some things you can do:
Create a chart of velocity using story points and a plot of stories completed per sprint. They will be remarkably similar – certainly similar enough for the purpose of lightweight planning, which is the actual intended use of velocity.
The goal of backlog refinement is to achieve shared understanding of each story and to ensure the stories are “right sized”. See user story mapping by Jeff Patton to get his thoughts on proper user stories and why words alone will not lead to shared understanding – his book is on my recommended reading page with a link to purchase it from Amazon (affiliate link for me – thanks for buying the book from my link if you do!)
Switch to discussing stories from the perspective of value and ensuring that we slice the work small enough to be completed, that means tested! within a sprint, ideally in 3-5 days or less.
There should only be 2 sizes for stories – small enough and too damn big. That’s it, that’s all you need. Can the story be finished in a few days or not? Well, there is a 3rd size – “we have no idea, we need to know more”.
Smaller stories lower risk, period. They are easier to understand, easier to code, easier to verify and lead to far quicker feedback. All of these things will improve the teams effectiveness.
Yes, this is moving from using story points for estimation to simply counting stories. Perhaps you’ve heard of this called #NoEstimates – you’d be right.
Not estimating stories with points still allows you to do forecasting, still allows you to do trending, still allows discussion with the product team – all of the good things.
Simply counting stories takes seconds. It will free up valuable time that is currently spent haggling over numbers that mean nothing to anyone. Those conversations certainly do not bring value to your customers. Even Ron Jeffries, who is credited with inventing story points, now states that he wishes he hadn’t because they are so often abused and contribute to Dark Agile and Dark Scrum.
Wrapping up:
So there you have it – if you’ve been together as a team for more than a couple months, story points are likely being used as a crutch in your team. You do not need them and in all likelihood they are being misused and abused by others beyond the team, such as described in this article: Are You Weaponizing Story Points. It’s time to get rid of the excuses and enact change that will move your teams towards higher levels of effectiveness. Free your team!
Until next time!
