When I first practised Agile on my old team, one of the things I learned from the consultants was Story Points. Since then, it has been used in many product teams in my company. As all the teams use Scrum as the main framework, many colleagues even misunderstand Stories and Story Points as Scrum ideas. They’re actually from Extreme Programming.
Stories Points were invented by Ron Jeffries, one of the three founders of Extreme Programming. They were invented to abstract from hours to complete an item. With the Fibonacci series, developers can easily say the bigger the Story Point is, the more complex the Product Backlog Item is, and the more uncertainty in developing the Product Backlog Item could be. Developers can use empiricism to vote for the size of a Product Backlog Item. With the aid of the velocity trend, they can select the Product Backlog Items into their Sprint Backlog.
At first glance, Story Points make estimation easier, but as time passes, Story Points hinder a few problems. First, stakeholders and management don’t know these arbitrary numbers. No matter how much effort you try to explain, they would still try to correlate Story Points to hours. With the velocity and measurements, it’s easy to be abused by teams, managers and organisations. They start comparing these metrics among teams and judge those that deliver at low velocity. Some managers even want to take control and optimise it. I could still recall when I was working for my old team, one of the managers kept asking why we could only select such a small amount of Story Points of Product Backlog Items into the Sprint Backlog.
Remember, Story Points are just arbitrary numbers. Neither fine estimating nor debating with someone using arbitrary numbers is meaningful. Think about what would happen. Product teams would achieve a scoreboard metric rather than striving for delivering value to the stakeholders. They would instead assign a big Story Point to each Product Backlog so it would be easier to achieve a higher velocity. This weird behaviour seriously damages trust and respect, two of the Scrum Values.
The Evidence-Based Management (EBM) Guide says delivering valuable outcomes (values) is essential. Measuring the number of features (outputs) doesn’t necessarily lead to improved customer experiences (values). Story Points and velocity are output measurements. Optimising these metrics built by arbitrary numbers isn’t the most effective way to inspect if any value is delivered. Story Points are widely used and misused, not to mention Ron Jeffries wrote an article regretting inventing Story Points in 2019 and retweets it every year.
As I don’t feel good about using Story Points, I dropped them when I started working for a new team. During our journey, we never miss Story Points and velocity. We keep inspecting and adapting regularly on the Sprint Backlog. We refine the Product Backlog Items in the Product Backlog when necessary.
When the team becomes more mature, it’s time to introduce more elements to improve the effectiveness. We want to learn how well we deliver in terms of values, and how we can have a better long-term forecast. EBM, Kanban and Flow Metrics are probably the three things to dive into. I’m reading Flow Metrics for Scrum Teams by Will Seele and Daniel Vacanti. I hope to gain enough insight to coach the team towards better outcomes.