Scrum story point estimates are a failure

While noble in intent, story point estimates from Scrum have been a failure in our industry.

- In my team recently, the murky topic of software development estimates has raised its ugly head again.
- I am on record as stating that I don’t believe in estimates, as I believe they are all made-up numbers that are rarely, if ever, accurate.
- For example, in my article “Project estimates are useless” back in 2016, I wrote: “Human beings are terrible at accurately estimating the time required to carry out work, even for tasks that they carry out on a regular basis. So in the software industry, why do we waste so much time and effort trying to estimate projects?”
- Ref: https://techleader.pro/a/484-Project-estimates-are-useless
- And yet nine years later, I am still getting dragged into this futile discussion.
- The recent discussion was around the benefits of using story points to estimate upcoming work, so rather than me dismissing it out of hand, let me instead engage with this topic once again in a neutral manner by examining the pros and cons of the story pointing methodology.
- Story points are an agile estimation technique used in Scrum to estimate the relative effort, complexity, and uncertainty of a task (or "user story").
- They are not a measure of time. Instead, a team assigns points based on how much effort they believe a task will take compared to other tasks.
- Now let’s compare the relative pros and cons of this approach:
Pros of Story Points
• Focus on relative effort: Story points encourage teams to think about a task's size and complexity relative to other tasks, rather than trying to guess a precise number of hours or days required. This is more accurate for complex or uncertain work and avoids the pitfalls of time-based estimates, which can quickly become inaccurate.
• Encourage collaboration: The process of assigning story points, often through a method like Planning Poker, requires the entire team to discuss and agree on an estimate. This promotes a shared understanding of the work, uncovers hidden complexities, and fosters team alignment.
• Discourage fixed deadlines: By using an abstract unit, story points help shield the team from the emotional pressure and rigidness of fixed time-based commitments. This allows for more realistic planning and less "padding" of estimates.
• Factor in complexity and uncertainty: Story points are a holistic measure that accounts for not just the amount of work, but also the complexity, risk, and any unknowns involved. A task that might be quick but highly complex can be given a higher point value.
• Adapt to team velocity: As a team works through several sprints, their "velocity" (the average number of story points they complete per sprint) emerges. This velocity can then be used to make more reliable forecasts about future work without converting points to hours, since it's based on the team's actual performance.
Cons of Story Points
• Lack of intuition for stakeholders: The abstract nature of story points can make them difficult for people outside the development team, like business stakeholders or clients, to understand. They often want to know "when will it be done?" in terms of days or weeks, which can lead to confusion, or the team being pressured to convert points to hours.
• Inconsistency between teams: A 5-point story for one team might be a 20-point story for another due to differing skill levels, experience, or definitions of a story point. This makes it impossible to compare the productivity of different teams using story points.
• Risk of misuse: Story points can be misused by management to compare individual developer productivity, which is antithetical to the principles of a self-organizing Scrum team. They may also be artificially inflated to show higher "velocity" without any real increase in output.
• Initial overhead: It can take a new team several sprints to establish a stable velocity and a consistent understanding of their story point scale. During this initial period, estimates may be inaccurate, and the process can feel confusing or time-consuming.
- In my opinion, the cons outweigh the pros with this approach, particularly the abstract nature of the points, their inconsistency across teams, and the fact that the values are not “grounded” in something intuitive like time.
- In reality, business stakeholders will attempt to hold the team to timelines regardless of story point estimates, so what’s the point in going to all that effort to estimate in points, only for it to be largely ignored by stakeholders?
- I remain open minded however and allow my teams to continue to estimate in points if it makes them happy.
- But I don’t believe in it, as I don’t believe it is in any way scientific or reliable.
- In fact, I believe all estimates are a waste of valuable time that could be better spent building something.

#leadership #tech #leader #team #management #manager #teamlead #techlead #software #estimates #scrum #story #points