TL;DR Evil Story Points and our love & hate relationship with them.



But I do not love Story Points…


But I don’t hate Story Points…

Finding the balance.

So, where is the balance?

Having some traceability and accountability brings responsibility to the team and helps to simplify the mechanics of the engineering world to plain numbers. But of course, if a company relies only on these numbers (often they do), that’s not helpful. Story Points are only a tool, not an ultimate solution to replace common sense, good communication and proper planning. As a result, the tool can be still misused.

Let’s talk about The Good and The Bad, and later I will explain what worked for my teams.

A little bit more about what I don’t agree with.

  • Reduce planning time.
    It’s not uncommon for teams to waste 4 hours of planning because they follow Scrum by the book. I agree they have the potential to reduce planning time, but often, the reality is different. I would argue that reduced planning time depends more on people than Story Points themselves.
  • Predictable release dates.
    It is easier to predict but still not very accurate.
  • Consensus and collaboration.
    I agree, as having discussions about Story Points forces teams to talk about tasks and challenge assumptions. But it also can create a lot of waste. When team members are highly specialised, scoring tasks during planning can result in a lot of guessing, poor accuracy and wasted time. But since that’s not a side effect of Story Points, it doesn’t matter.
  • Improve performance.
    Conscious planning should improve performance, and it is not specifically unique to Story Points within agile teams.
  • We know how many points the team can deliver (velocity).
    Yes, and that means points are magically translated into time per person. It’s good to use Story Points if the alternative is nothing, but they are far from ideal.
  • They are better than hours.
    Well, no argument about that. I have a hard time imaging estimation by hours in any situation unless we are talking about a freelancer working on a simple WordPress site. It wouldn’t work in a scrum team of 10 people working on a complex application.
  • No artificial deadlines.
    Story Points do not solve this problem at all. Not sure why someone would use this as an argument for Story Points but never mind.

So what haters hate so much, and why they are usually wrong?

  • Relative Points are stupid, and we don’t understand them!
    Yes, they are.
  • It slows the team down.
    People often see planning as a waste of time, but they don’t realise that the better they get with preparation, the more time they will save later. I saw it so many times in action! Sometimes to speed up, we need to slow down.
  • We do our job, why do we need extra admin work?
    There is a little more work initially because the expectation is to adequately describe tasks, discuss challenges, add points… basically, do proper planning, which involves moving things on the board. Story Points will enforce it, but every team serious about planning will face this challenge.
  • Our estimates are never accurate, so why we should do it?
    It’s not the accurate plans that matter, but proper planning as a process. It helps to identify challenges that otherwise would go unnoticed. Teams will less likely end up with tasks that go for weeks where they apparently should be a two-day job.
  • We work Kanban. We don’t need points.
    Kanban is a great approach to get things done. Perfect! I love it, but it requires an amazing team to stay in the flow and cooperate perfectly with non-technical teams, which rarely happens. So far, I saw Kanban mainly used as a way to deal with poor requirements, lack of focus and no predictability (often described as “we need to be agile!”). A lot depends on the organisation itself.

What I’ve learnt with my past teams about Story Points?

Keep it simple

So how that benefits us?

  • Tasks are properly sized.
    We avoid tasks estimates over 8 points so they can be completed within a week. Of course, occasionally, there is a valid reason why it has to be bigger, so let’s be it.
  • Team’s output prediction.
    It is easy to measure as we know each person = 10 points. New joiners or juniors might be counted as 5 for some time. It’s also easy to re-adjust prediction based on holidays and other external factors.
  • All teams use a similar approach.
    Teams might vary on cycle length, size, expertise, but at least all points have the same baseline, making it easier to work cross-team and migrate people between teams where they can bring the most value based on company needs.
  • Overestimation and underestimation are easier.
    Both will still happen, but from my experience, teams tend to underestimate initially because the number of points on the paper seems high. It is also easier to understand why we miss-estimated, how much and what we can do to avoid it in the future.
  • Truly agile.
    We can easily change the direction when something unexpected happens. It’s a quick decision, and we immediately understand how changes impact the team.

I’ve been using the above approach for many years and tested multiple times in different sized groups with a mixture of frontend, backend, qa and designers, across various companies. The most important to me was giving estimates connected to time to build commitments and understanding, but at the same time, teams having more flexibility and autonomy.

It’s a good starting point, but I didn’t discuss many aspects of Ways of Working that would make this approach stand out even more and help you create the most efficient software engineering teams. I guess that’s an idea for another few blog posts and topics like asynchronous estimations and rapid development cycles.

“I like to say that I may have invented story points, and if I did, I’m sorry now.” — Ron Jeffries, a possible creator of Story Points.

That should give you something to think about…

If things are not perfect, take matters into your own hands.

Have fun as the only way to make a difference is by trying new things, occasionally failing, and learning in the process.

I am a London-based software engineering consultant and change-maker who helps companies solve genuine challenges and remove limitations. From guiding how a healthy organisation looks like, including the best structure, attitude and culture, to find the right balance between creative freedom, processes and true passion amongst teams. The #oneteam culture is at the core of everything I do and everything an organisation should strive for to succeed.

I help individuals to become better leaders and professionals. I’m coaching and mentoring software engineers and teams to help them reach their goals and prepare for the future unknown. I went through this journey myself, and I understand how hard it is to let go of who we are to become who we want to be.

Highly accomplished and results-oriented professional with background in leadership, software engineering, automotive, photography and design.