Story Points Under Fire: Are They Still Relevant in Agile?
As an Agile Project Manager, I’ve found myself caught in the crossfire of the Story Points debate. It’s like choosing between coffee and tea in the morning — some of us can’t imagine starting our day without one, while others swear by the other. Yes, I prefer coffee, but that does not mean tea is the wrong choice (or does it?).
Let’s dive into this controversy together and see if we can make sense of it all.
What are Story Points to begin with?
Scrum Alliance states Story Points are “Team-specific units of relative size used in estimating requirements” [1]. A lot can be taken from this definition, so let’s discuss its main dimensions.
First, it is supposed to be team-specific, which means the team’s definition of a Story Point is meaningless outside that team’s context. The team estimates the effort required for each requirement, and so the perceived level of effort is influenced by the team’s size, expertise, background, and how long they have been working together. Therefore, a different team will likely have a different perspective and, hence, a different estimated value for the same work.
Second, it states that Story Points are a way to size requirements in relation to others. Therefore, an arbitrary value must be assigned to one or a few requirements to compare and measure the rest against it, regardless of how one implements Story Points (or any relative sizing, for that matter). In practice, teams hold a planning poker session, analyze requirements together, compare them to other known requirements, and assign a Story Points value based on the relative effort required.
Third, what are they used for? A big part of the conversation is about that. Ron Jeffries, one of the founders of Extreme Programming (XP) and likely the father of Story Points, said that when they started using the points, they “only used the points to decide how much work to take into an iteration” [2]. Today, the same mostly applies. Teams use these estimates to decide how much work to include for the next sprint (iteration) by reflecting on how much work they have been able to complete historically. This allows the team to set a realistic goal within the boundaries of their own capacity.
The Argument for Story Points: A Measure of Velocity
Let’s start with the pro-Story Points side. The argument is that Story Points are essential for measuring velocity. By assigning points to user stories, teams can estimate how much work they can tackle in a sprint. Users register the Story Points as earned when they complete each user story. It’s like going to the gym and recording the weight you can lift each time. Next time you go, you know what you are capable of.
Key Benefits of Story Points:
- Team Collaboration: Sizing estimation with Story Points often happens in a planning poker session. This encourages team discussions, fosters collaboration, and ensures everyone is on the same page and has enough information about the requirements.
- Relative Estimation: Story Points allow teams to estimate requirements relative to each other, making it easier to gauge effort while avoiding the pitfalls of time predictions.
- Predictability: After completing a few sprints, teams can track their velocity (average points completed per sprint) and estimate future capacity. This helps in planning and managing stakeholder expectations.
Why do we need to estimate?
Whether you are for or against Story Points, it’s important to understand why they exist. Most teams pursue a goal and face time, budget, quality, and scope constraints, even in an Agile environment. While these constraints are flexible, negotiation is still needed, and expectations must be managed.
Estimating, whether using Story Points or not, allows teams to become predictable and plan toward a goal, which helps set clear expectations, identify risks, and facilitate communication with stakeholders.
The Case Against Story Points: Finding Alternatives
Have you heard the phrase “Story Points are Trash” or the story where Ron Jeffries apologizes for creating them? Well, there’s a growing movement against Story Points. Critics argue they’re an unnecessary abstraction that can lead to estimation fatigue, inconsistent results, and mismanaged expectations. Some organizations have even used these estimates to measure performance and compare different teams.
Key Criticisms of Story Points:
- Overhead: The process of estimating Story Points can become time-consuming, detracting from actual development work.
- Focus on Output: Critics like the #NoEstimates advocates argue that Story Points can shift the focus to completing points rather than delivering value.
- Misuse: Comparing teams, using them as performance measures, setting a target, establishing a time equivalent, and others are just some examples of how managers have been known to “weaponize” Story Points.
Influential voices like Woody Zuill and Neil Killic, proponents of #NoEstimates, argue that teams should focus on delivering valuable software incrementally rather than getting caught up in estimating effort. [4]
So, balancing the pros and cons, should we drop estimates altogether? What are the alternatives for a team that wants useful data to know their capabilities and optimize value delivery?
Alternatives: Are they really?
Several authors, as well as some tools [5], promote the use of the following data points instead of Story Points and label them as alternatives:
- Flow-Based Metrics: How long and where do items spend time in the pipeline?
- Cycle Time
- Lead Time
- Time to Deploy
- Aging items
- Time to review - Engineering Investment: Where are the teams spending their time? New features, Improvements, or bug fixing and troubleshooting?
- Batch size: How big are the changes included in each item
- Rate of return: number of items returned versus those sent for testing
- Deployment frequency: number of times a release reaches the production environment per day, week, etc.
By this point, you have probably noticed these are not alternatives to estimates but complementary data that allows teams to understand how the work is flowing. These have proven valuable for seeing the bigger picture, analyzing issues, and adjusting if needed. Check out Sherley Brito’s two-part article on Data-Driven Delivery Management for a deep dive into some of these data points.
- Beyond Velocity: Data-Driven Delivery Management for Agile Teams (Part I) (gbh.tech)
- Beyond Velocity: Data-Driven Delivery Management for Agile Teams (Part II) (gbh.tech)
Alternative estimation techniques
As discussed earlier, most teams need to estimate to plan, set, and manage expectations, and facilitate negotiation with stakeholders. If you and your team need estimates and want to enjoy the benefits of estimating requirements — such as promoting discussions, fostering collaboration, and managing expectations — but want to avoid the pitfalls, it is worthwhile considering alternatives. Here are just two of them:
Ideal Hours:
Imagine a world without interruptions, distractions, or other work to deal with. That’s what Ideal Hours aim to capture: the estimated time a task would take under perfect conditions. It’s more concrete and easier for everyone to grasp. However, it can be mistaken for absolute time, creating pressure and stress. It’s like thinking you can cook a meal in 30 minutes because that’s what the recipe says — without accounting for the time you spent looking for that one ingredient in your pantry (or even at the grocery store).
T-Shirt Sizes:
Think of T-Shirt Sizes as a cousin of Story Points. Instead of using numbers, use sizes like S, M, L, and XL to express the relative size of requirements. They’re easy to understand and flexible, making them perfect for fostering collaboration and discussion. Plus, since adding sizes together is not intuitive, it’s less likely these will be misused as a performance measure. However, for the same reason, they might not be as useful for understanding team capacity.
By exploring these alternatives, you can find a method that keeps your team aligned and motivated.
Leading an Agile Team: With or Without Story Points
Whether you’re for or against Story Points, your goal should be to deliver value. And there is merit in the critics. Estimates must not be used to measure performance or to say that a team is slow compared to others, nor should managers use a “conversion table” to micro-manage team members.
However, flow-based data points and quality metrics shouldn’t be considered only by teams that decide to move away from estimates. Using them enables teams to see the bigger picture and read the full story.
Finding Neutral Ground
So, where does that leave us? Whether you swear by Story Points or think they’re evil, the key is to find what works best for your team. By using alternatives, you can take advantage of the benefits of estimates while doing your best to avoid the pitfalls. Complement your dashboard with flow-based data points and other information such as deployment frequency, rate of returns, etc.
Ultimately, the goal is to deliver value, foster collaboration, and continuously improve. Different teams have different needs, and there is no one-size-fits-all approach. Adapt and iterate your approach to match your team’s and your stakeholder’s needs while keeping an eye on the prize: delivering value.
Sources
https://resources.scrumalliance.org/Article/story-points-explained
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
https://scrumguides.org/scrum-guide.html
https://ronjeffries.com/xprog/articles/the-noestimates-movement/
