Scrum is like communism, it doesn’t work. Myth 2.

Published on
3 minute read

Unraveling the Story Point Myth in Scrum: A Path to Clarity 🚀

Hello, Agile practitioners! Today, I’m tackling a pervasive myth that has become a common stumbling block in Scrum teams: the Story Point Conundrum. This myth often manifests as confusion and frustration around the use of story points, with many questioning their value and relevance in Scrum. Let’s dive deep into this myth, understand its origins, and explore how we can navigate beyond it to foster more effective and meaningful Agile practices. 🌟

The Proxy Myth of Story Points in Scrum 🎭

A common narrative I encounter in Scrum circles revolves around the extensive time spent on estimating story points, which measure complexity rather than time, and then trying to fit these points into a sprint. Here’s the catch: Story points are not inherently a part of Scrum. They’ve been adopted as a complementary practice, but they’re not prescribed by Scrum itself.

Understanding Story Points: Beyond the Misconception 🛠️

Story points were conceived as a tool for developers to facilitate discussions around unknowns in a project. The essence of using story points—through practices like planning poker—is not about assigning a numerical value to complexity but about uncovering what the team doesn’t know.

The Apology from the Creator of Story Points 📜

Interestingly, the individual generally credited with inventing story points has publicly apologized for their creation, due to the way they’ve been misapplied within organizations. Instead of serving as a tool for insight, story points have often been used as a quasi-measure of time, leading to undue pressure on developers.

Refining Our Approach to Story Points ✨

The primary utility of story points lies in their ability to facilitate conversations during backlog refinement. They help teams gauge the relative complexity of tasks and identify gaps in understanding. Here’s how we can shift our perspective and practices around story points:

  1. Focus on Conversation, Not Quantification: Use story points as a catalyst for discussion among team members to explore uncertainties and align on understanding.

  2. Keep Context in Mind: Story points should primarily be used during backlog refinement to help right-size backlog items and assess whether they fit within a sprint.

  3. Discard After Use: Once story points have served their purpose in fostering understanding, let them go. They’re not meant to be a persistent measure or a tool for comparison beyond their initial context.

Moving Beyond Story Points: Practical Steps 🚀

If you find that story points are adding more confusion than clarity to your Scrum practice, it’s time to reevaluate their use. Here are steps to navigate away from reliance on story points:

  • Experiment with Alternative Estimation Techniques: Consider methods like T-shirt sizing or even #noestimates to focus on delivering value without the overhead of detailed estimation.

  • Embrace Empirical Process Control: Shift the emphasis from upfront estimation to inspection and adaptation based on actual progress and emerging insights.

  • Cultivate Open Dialogue: Encourage team members to share their perspectives and uncertainties openly, creating a culture where learning and adaptation are valued over adherence to arbitrary metrics.

Conclusion: A Return to Scrum’s Essence 🌈

The story point myth highlights a broader challenge within Agile practices: the tendency to cling to specific tools or metrics at the expense of the underlying principles of empiricism and collaboration. By revisiting the intent behind story points and refocusing on the goals of Scrum, we can foster more resilient, responsive, and effective teams.

Remember, the true measure of success in Scrum isn’t how accurately we estimate complexity but how well we deliver value to our customers through collaborative effort and continuous learning.

If you’ve found this exploration of the story point myth enlightening and wish to delve deeper into Agile, Scrum, or DevOps practices, don’t hesitate to reach out. Let’s continue the conversation over a coffee chat and uncover more ways to enhance our Agile journeys together.

One of the common myths in Scrum is kind of a proxy myth. This proxy myth is, you know, why do we spend so much time working on story points when story points measure complexity and not time? And then we have to figure out how many story points fit in a Sprint, right? And I 100% agree with that. That part is not a myth. The bit that’s a myth is that story points are even a Scrum thing in the first place. They’re not. Story points have nothing to do with Scrum. It never has, apart from as a practice, potentially a complimentary practice that teams choose to take on in order to get to an outcome.

When you find complimentary practices are not adding value, you should be stopping doing them, not continuing with them. So if you’re in that position where you find that story points are not adding value, great! Stop doing them and choose something else. Choose a different way. The guy that invented story points, or that is generally accredited with inventing story points, has a public apology online for creating them in the first place because of how they tend to be used within organisations as a pseudo proxy for time to beat developers around the head with.

Right? They were originally invented as a reasonable way for developers to sit and have a conversation and figure out what they don’t know. That’s the purpose of story points. We can all get together. We maybe use another complimentary practice called planning poker, and all that really is, is we keep our cards to ourselves, right? We’re not going to tell each other what story point we’re going to pick, how complex, t-shirt sizes, right? Whatever you pick, how complex this thing is.

And you’ve got one developer that says this is a small or a one, right? You’ve got four developers that say that this is a five or a medium, and then you’ve got one developer that says this is an extra large or a 21, right? And the idea is, what do they know that we don’t, or what do we know that they don’t? That’s the purpose of story points and complexity conversations. It should be used almost solely during refinement in order to enable teams to right-size their backlog items and decide, do they fit in a Sprint? Do we understand them, or do we not?

After that, delete the numbers. They’re useless. Don’t use them anymore. That’s their purpose for that one context. Don’t bring them into the wider context. Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else, add Scrum or DevOps, then please book a coffee with me through Naked Agility.

Backlog Refinement People and Process Estimation Agile Project Management Software Development Agile Frameworks Software Developers Pragmatic Thinking

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

New Signature Logo
Brandes Investment Partners L.P. Logo
Genus Breeding Ltd Logo
Emerson Process Management Logo
Slaughter and May Logo
Alignment Healthcare Logo
Trayport Logo
DFDS Logo
Capita Secure Information Solutions Ltd Logo
Higher Education Statistics Agency Logo
Jack Links Logo
Sage Logo
Schlumberger Logo
MacDonald Humfrey (Automation) Ltd. Logo
Teleplan Logo
Kongsberg Maritime Logo

NIT A/S

Flowmaster (a Mentor Graphics Company) Logo
Washington Department of Enterprise Services Logo
New Hampshire Supreme Court Logo
Ghana Police Service Logo
Royal Air Force Logo
Nottingham County Council Logo
Department of Work and Pensions (UK) Logo

NIT A/S

Slaughter and May Logo
Milliman Logo
Brandes Investment Partners L.P. Logo
Healthgrades Logo
Qualco Logo