tech·nic·al·ly agile

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

Uncover the truth about story points in Scrum! Join Martin as he debunks myths and reveals their true purpose as a tool for team conversation. 🚀📊

Published on
3 minute read
Image
https://nkdagility.com/resources/l3NhlbM2gKM

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.

Empirical Process Control Agile Planning Agile Product Management Agile Philosophy Software Development
Comments

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.​

Qualco Logo
Epic Games Logo
MacDonald Humfrey (Automation) Ltd. Logo
Sage Logo
Deliotte Logo
Slaughter and May Logo
DFDS Logo
New Signature Logo
Philips Logo
Xceptor - Process and Data Automation Logo
Genus Breeding Ltd Logo
Kongsberg Maritime Logo
Lockheed Martin Logo
Brandes Investment Partners L.P. Logo
Healthgrades Logo
Workday Logo
Schlumberger Logo
Ericson Logo
Washington Department of Enterprise Services Logo
Royal Air Force Logo
Nottingham County Council Logo
New Hampshire Supreme Court Logo
Washington Department of Transport Logo
Department of Work and Pensions (UK) Logo
Healthgrades Logo
Slicedbread Logo
Alignment Healthcare Logo
Graham & Brown Logo
ALS Life Sciences Logo
Emerson Process Management Logo