Long ago beyond the stars a civilization rose from dust and puddles to spread the gospel of “agile software development” across many worlds. Over time these worlds diverged into two distinct tribes, known as “Team A” and “Team B” (for they were truly unimaginative beings in the ways of names). Both tribes prospered, delivering software throughout the galaxy, but over many generations Team A grew to believe the source of their success was a mysterious force known as “Story Points”. Team A evolved an elaborate ritual that they performed during their traditional bi-weekly gatherings known as “Sprint Planning”.  Team A believed these rituals allowed them to accurately predict the future. Abandoning the process of deep thought and discussion, Team A eventually focused their entire development process on these “points”, which for some reason existed only in quantities of 1, 2, 3, 5, and (very rarely) 8.

While both tribes continued to ship software, fealty to this numeric master began to visibly distort Team A’s demeanor and appearance until travelers from other galaxies could easily tell which of the two tribes they had encountered. Those from Team A came to be known as victims of "Fibonacci’s Curse".

Let us go now, across space and time in the blink of an eye to gaze upon two such parallel development efforts. 

Timepoint 1173b-2.2c: The Plannening

Behold! On our view-screens we see Team A and Team B, at the beginning of Sprint 1. Unaware of each other, both teams review prioritized backlogs, discussing each story. Through various methods (Planning Poker, Dev Manager assignment, and PM cajoling to ‘just give me a number!’), Team A assigns point values to each. On their world, Team B discusses the challenges and goals of each story, but no points are assigned. Eventually both teams commit to a set of stories for the sprint. Team A notes that these stories add up to a total of 20 points. End Transmission.

Timepoint 1173b-6.3a: Nailed It

The view-screens brighten as both teams gather in large conference rooms for end-of-sprint demos and management review. Both teams project slides with identical lists of stories completed during the sprint. After demonstrating the new functionality, Team A moves to a second slide with “Target: 20 points / Completed: 22 points” under a bright green heading of “Sprint Status: Success!” Team B has no additional slide, as their culture has no notion or need of such things. Both teams are congratulated for a job well done.

Timepoint 1173b-6.8d: The Infallible Point System

It is the next day, and the teams are seated for Sprint 2 planning. While both conversations sound similar, Team A focuses on whether each story is worth 1, 2, 3, or 5 points, while Team B spends all their time discussing design ideas and risk factors. After Team A finishes their routine, they wrap up quickly by choosing the top 22 points (based on their “velocity” in Sprint 1) as their goal. In contrast, Team B reviews the data and opinions from each team member to reach consensus on which stories are achievable during the sprint. The view-screens fill with static and go dark.

Timepoint 1173c-1.2a: A-Point-alypse Now

2 weeks of frenzied activity fly by, and both teams gather in conference rooms for their respective reviews. Again, both teams display identical lists of completed stories and perform impressive demos. But the mood for Team A is somber, and somewhere in the distance a dog-like creature barks. For on Team A’s second slide stand the words “Target: 22 points / Completed: 15 points”, under a red heading of “Sprint Status: Failure”. The team is politely interrogated by disappointed managers as to what went wrong, and encouraged to focus on getting back up to at least 20 points in the next sprint. One reviewer mentions his team of similar size completed 28 points this sprint, and is reminded that story points should only be used to measure performance of the same team across multiple sprints. The team shuffles offstage for a 2 hour retrospective on ways to improve velocity. In contrast, the faces of Team B beam with pride and excitement for their accomplishments beneath 3 mighty suns. They are thanked for their efforts, asked about a few details and given some ideas and recommendations, then head out to brainstorm additional design improvements for the next sprint. 

Timepoint 1173c-9.4f: All the world’s indeed a stage

With a crackle and a pop 14 more days of coding love zoom by and we are back in the large conference rooms. Both teams again display identical lists of completed stories and perform demos. But Team A’s second slide reveals a change! “Target: 22 points / Result: 30 points” below a green “Sprint Status: Success!” Team A is congratulated for the “big improvement” and encouraged to set a goal of 28 points for the next sprint to keep the momentum going. Meanwhile, a pleased Team B is again thanked for their hard work, asked some questions and given some ideas. End final transmission, view-screens flash once and go dark. 

Epilogue

Out of the darkness both view-screens suddenly sputter and spark back to life and we gaze in mute wonder as the next sprint unfolds in front of our eyes. Both teams again complete identical lists of stories, but despite this the perception is that Team A has “fallen short”, completing only 20 of their 28 point Sprint 4 plan. The demoralization, speeches, and retros of the previous “Failed” sprints are repeated. On their world, Team B once again demonstrates their work, is asked to explain a few details and given some ideas, and keeps on working enthusiastically towards the next release. 

Conclusion

Story points are nothing more than project management theater. We go through the motions thinking they give us predictability and control, but this is an illusion. Yes, many planning sessions where points are assigned do often include productive conversations about each story. And sometimes the list of stories we feel we can accomplish based on our conversations matches the number of points our past ‘velocity’ predicts. But often it doesn’t.

When points become the target and unit of progress rather than actual value created, everyone loses. 

In the saga above, despite completing identical lists of new features each sprint, each team is judged completely differently - Team B on the merits of their actual deliverables, and Team A on their ability to pick a number. But story points are mostly arbitrary - they depend as much on how long we’ve all been stuck in the meeting and the day’s weather as on the actual software facts on the ground. 

The result? Sprints that end with fantastic new functionality but fewer ‘points’ than expected are called failures, while sprints with limited real gains but an ‘increased velocity’ are hailed as victories. Enough of this dark ritual, this curse. Our guides shall be thoughtful words, not magic numbers. Let us rise and reclaim our ancient power. There has been an awakening...