Story points are just smoke and mirrors. Yes, hear me out.

People can’t stand chaos; we crave order. Many folks view story points as a way to inject some order into the chaos of, say, agile development. This is especially intriguing for large enterprises, those companies with a waterfall mindset that decide to casually slap the word “Agile” onto their established way of doing things.

Now, let me break down why story points are nothing but a facade and share what I prefer instead.

Estimating is no walk in the park

In a perfect, predictable world, this sentence might actually make sense:

The 4-Sprint-average is (0.5 + 0.63 + 0.67 + 0.82) / 4 = 0.655. If you have 36 person-days available in your upcoming Sprint, you should aim for ~24 Story Points.

Such order. We can clearly see how much we can fit into a sprint. All we need to do is to figure out a solid way to assign precise points to stories and integrate them into the sprint. The worst implementation I’ve ever witnessed was at a company with three dev teams. After collectively estimating the tickets, they randomly assigned them to the teams until each team hit the maximum number of points. Chaos ensued. Tickets dependent on each other were spread across three teams, resulting in Team 1 being blocked by Team 2. Not ideal.

Estimating how long a task takes is a challenge. There are always surprises lurking around the next corner. A story that seems “easy” could unexpectedly turn into a two-month effort to refactor the code before it’s possible to implement the ticket. Yes, it happens. Should it happen often? No. It’s a red flag if it does. But more often than not, a ticket that is estimated for 2 days needs 3. And that’s okay. It’s not a failure. It’s just how it is. If you look at the sentence in the quote, you see the that they tried to factor in this uncertainty by averaging the last four sprints. But that’s just a band-aid. It doesn’t solve the actual problem: estimating is hard. Sometimes it’s just not possible. Adding a factor to the equation doesn’t make it any easier. Or more correct. If estimate most tickets take 2 days, but in reality, they take 3? You’ll end up with a sprint that’s 50% over capacity. And that’s not good. Usually that’s when the blame game starts.

Pressure to finish by estimated time

If you estimate a ticket takes 2 days, you’ll feel the pressure to finish it in 2 days: that’s not good. You’ll be tempted to cut corners, to take shortcuts, to do whatever it takes to finish the ticket in time. It creates technical debt. It creates bugs. It creates an atmosphere of pressure. Cutting corners or taking shortcuts can be a good thing. But only if you do it consciously. If you do it because you feel the pressure to finish in time, you’ll end up with a mess. A team that constantly feels this pressure will burn out.

Comparing teams with each other

Unfortunately, I’ve seen many managers who compare teams based on how many story points they complete in a sprint. This leads to peculiar outcomes. A team judged by the number of points it can achieve in a sprint will likely estimate tickets more generously. Maybe it’s subconscious, but they’ll do it. They just don’t want to look bad compared to other teams that finished more points. And this renders story point estimation worthless. You might see a cheerful “the team is becoming more and more efficient” chart, but in reality, it may be the opposite. The truth only reveals itself when you see what they actually delivered and try to understand why.

Long-Term Planning

If you’re sizing up everything for the next four sprints down the road (yes, I’ve witnessed this in more than one team) and just chipping away at those tickets, you’ve basically crafted a fancy version of waterfall. Agile isn’t about that. Not at all. Long-term planning calls for different tools. If you’re basing your long-term planning on the story points’ scope of tickets, you’re planning with a level of detail that’s just not practical. It’s bound to fail. Take a step back and attempt to plan with a higher level of abstraction.

Understanding Ticket Complexity

Another reason why folks fancy story points is because they’re a proxy for ticket complexity. This actually comes in handy when a team is trying to grasp the details of a ticket. If one person estimates the ticket as a 5-day task and everyone else sees it as a 3-day task, there’s a good chance the person rating it at 5 days has a better idea on the ticket’s complexity. This gives you an opportunity to understand why the ticket is so complex and perhaps reconsider the approach, or at the very least, document the complexity within the ticket. However, I think using a Fibonacci Sequence to estimate complexity for this reason is a bit much.

My Suggestion

During your sprint planning, go over the tickets and try to estimate roughly as “small,” “medium,” or “big.” This should give you a ballpark idea of the ticket’s complexity. If there’s a significant difference within the team, discuss it. Record your findings in the ticket, and then let them go.

Move tickets into your sprint based on priority and a sense of how much you can fit into a sprint. If you find you need more tickets in the sprint, pull them from the backlog (which should be sorted by priority) into the sprint. If you end up with too many tickets in the sprint, shift them to the next one. Yes, this is a bit chaotic. But it’s also agile. It’s okay to have a bit of chaos.

The crucial thing is not to feel pressured into finishing all the tickets planned for the sprint. If there’s a deadline, plan accordingly. Communicate the deadline, what exactly needs to be delivered and (most importantly) why. You might have to cut corners or take shortcuts, but do so consciously. The manager’s role is to ensure the team doesn’t burn out, but also delivers. It’s a delicate balancing act. If everyone is on the same page, it’s much easier to achieve the goal.

Still not sold on the idea?

“Estimating tasks will slow you down. Don’t do it. We gave it up over 10 years ago.”
— Jeff Sutherland (Co-Creator of Scrum) (Source)

Thanks to Andrew, Luca and Peter for reading and correcting drafts of this and to Frederic for sending me the quote of Jeff Sutherland.