Your Agile Team Should Stop Using Story Points. Here's Why.
Story Points measure productivity (at best), not value
The road to hell is paved with good intentions. Ron Jefferies - credited with the invention of story points, seems to treat them with the same disdain that Einstein might share for atomic fission. The general idea was that because software developers seemingly are incapable of communicating when something will be delivered versus how long something will take to do, and business people were tired of guessing - we would invent some proxy for this to fit within the traditional agile sprint: story points. They were nebulous units of work, meaning they meant nothing in the real world. Sometimes they were compared to an ideal day.
But points weren't enough to forecast when work was going to get done, so we needed to add the dimension of time back into the process. This became the idea of velocity. Within a timebox, how many story points could a team deliver?
This falls right into the non-agile management trap of measuring productivity - not value delivered. If you had a way to track which cars (or teams) went the fastest around the track, why wouldn't you optimize for speed? So then we started comparing team's velocities, which then forced teams to bend the other variables - none of which were are we delivering value to the customer?
Optimizing velocity is not a principle of agile. It is a product of attempting to industrialize software development as if all units of work were created equal. And this is indeed the core fallacy - there is no ideal day. So attempts to use story points as a measure of productivity, counter to all agile principles to begin with - is fundamentally flawed in that the measurement unit is flawed.
Story points insulate teams and create culpable deniability
While estimation is a fool's errand (particularly in any sort of cognitive work), the introduction of story points as an estimation mechanism actually serves as a method for teams to manipulate the definition of delivery success. At the very least in other attempts to standardize development estimation (derivation of fixed effort) it's clear when work is underestimated. Either objective risk was not accounted for, the "do-it" effort was not well understood, knowledge risk was not well identified, sick time wasn't included, etc. But with story point estimation and the idea of the "ideal day" - there's no way to account for where the estimation was actually wrong. It's all gets amalgamated into "undersizing."
Additionally because story points are nebulous, the idea of "partial credit" was adopted by some teams, fully throwing out the idea that working software was the best measure of progress and going all in on the idea that velocity was the benchmark. Unscrupulous team leads and scrum masters would end a sprint and try to negotiate with the business around what was done, not done, and "almost done." Splitting work in agile is supposed to be function of deriving the highest value and eliminating scope creep. Instead, teams would split stories to attribute the most amount of points to their velocity. A failed delivery was a successful sprint because velocity targets were met.
The Last Estimation Tool You Will Ever Need
Software project estimation may be an exercise in guesswork, but it is imperative for almost any company in the business of developing software on a fee for hire basis or teams looking to plan budgets to develop a software project estimate that from the ground up has reasonable assumptions, scientific wild-ass guesses, and an accounting for things that could go wrong. Let me save you some time and share with you how I've estimated for projects in the past.
Story points require effort that is not value-added
The process of deriving story points, like any other estimation exercise - is of questionable effort. While it is valiant to look at work and determine whether or not it is feasible on a set schedule, applying a science to any estimation effort is at best, highly questionable. Even in my history as a consultant for companies that wore their ability to price projects on fixed time because of their estimation abilities - I can tell you that those companies wallpapered over this by using standard scope negotiation to eliminate work from the project, or simply accepting the margin erosion that would otherwise result. Customers don't pay for story points, they pay for software.
Whether its a "planning poker" exercise with a team getting into a room and nominating their thoughts on the size of a task, or arguing over how many points were "delivered" even when no software has been fully delivered - all of these activities are absorbing time when a better understanding of the customer needs could be done. When we think of all of the time that some agile teams use for ceremonies - few are as wasteful as planning poker and sprint planning meetings, particularly when they are driven by agendas that promote Parkinson's Law. If the goal of a team is to generate the most value quickly, then the best way to do that is to discuss the purpose of the work and strategies for reducing the effort. This requires no quantitative analysis of the size of the work, solely a discussion of what is absolutely needed to deliver.
Story points discourage change
One of the most detrimental principles that scrum introduced to agile was the idea that the plan for an iteration, once finalized - could not be changed. The team had pulled a certain amount of work into the sprint, governed by a story point budget and certain sprint objectives. Work could not be added to the sprint, though work may be replaced if it didn't effect the total story points budgeted for. Early in the sprint, this may not be an issue. But after a few days of work, replacing work becomes more and more difficult as to not raise the spectre of partially delivered stories. While unfinished work is not desirable, it should not because of potential impact on velocity.
If agile is truly about finding ways to maximize value delivery, just-in-time delivery becomes an avenue of pursuit for agile development teams. The unit of work is no longer a story point and instead becomes "a bug was fixed" or "an experiment was launched." In this world, we don't need ideal days or story points, we need to stress "quickly with limited technical debt." This gives customers and stakeholders an optimal amount of flexibility. Having a queue instead of a backlog or sprint plan allows for some restriction on changing priorities (to avoid starting and stopping work consistently) while focusing on scope management to limit impact on lead times.
Give teams agency to deliver value, not points
Story points ultimately are a distraction for both teams and stakeholders, a false idol of what success is measured by, and a distraction that leads to pointless negotiation and management. Agile is based on the idea that teams and customers collaborate to deliver value. We reserve negotiation to discuss how discrete value can be delivered with the least effort, not to have time spent recognized as a deliverable itself. Organizations adopting agile should push back against coaches or consultants that want to introduce the idea of story points early on (if at all), instead focusing efforts on building a culture around an agency to partner with stakeholders and clients directly.
Measuring key business objectives and ensuring that the organization and vendors are aligned and incentivized by those metrics is hugely more effective than putting proxy productivity metrics for them to achieve. With one of my teams, when we made it so that their annual, quarterly, and near-term goals were directly connected to the executive level company goals - they outdelivered their counterparts handily, exceeding the key business objective by 2x in 70% of the time. But another team where there was an insistence by upper management to track velocity missed every deadline over a 10 month period while consistently hitting story point goals for each sprint. The difference was as clear as day: you get what you measure.
In larger organizations with established products and teams, certain scenarios may call for measuring productivity. Service organizations or customer success teams where service level agreements are key to revenue recognition probably need to be measured by productivity, but with some other competing metric. So a commercial support team of 5 engineers may have a scrum-like velocity target for every two week sprint - but also probably should be measured by bug re-open rates.
But generally speaking, most software engineering teams are in the business of creating new value, not story points. Instead of story points, work with your teams to create goals that are aligned with what the organization is trying to build for value. Then collaborate with your teams to get them to innovate ways to deliver on a schedule instead. Let your teams own scope with the constraints of time and team size. The results will surprise you, and you will never have to debate between a 3 and a 5 point user story again.
Ryan is the former Chief Product Officer at Medullan, CTO at Be the Partner and Vitals, and now is a CTO consultant at Osmosis Knowledge Diffusion and has projects in alternative education, digital therapeutics, and patient engagement.