TL;DR Evil Story Points and our love & hate relationship with them.
Story Points within agile software development have been with us for a while, and they are going to stay for a very, very long time for many good and bad reasons. That’s a fact.
Many people, especially those who learnt agile by the book and courses, will tell you amazing stories about Story Points and how they solve all our life problems, including world hunger and climate change. And yes, they are right about it to some degree. They solve multiple issues, help plan work better, and bring some predictability, and it’s a tool to measure the output (or velocity if you like). Having the classic, relative Story Points makes our life somehow easier and better. It gives some insight into what is going on within a delivery team.
But I do not love Story Points…
Some people genuinely hate Story Points and how useless their relativity is. It is hard to resist the impression that relative scoring has been created only to control engineers and hide the truth from product managers. When an organisation correlates these Story Points closely with their reward system (bonuses), it gets even worse. Engineers have the right to be annoyed by them. They deserve hate as, in the end, they are not accurate, don’t fix missed deadlines, and their lack of real time relevance creates confusion.
But I don’t hate Story Points…
Finding the balance.
Polarisation brings nothing good to our lives, so let’s not treat software engineering like politics. Having a white & black approach to Story Points will not benefit humanity, nor a regular frontend developer Steve. Said that every organisation, team, and even some projects have their requirements for estimating effort & time needed to accomplish all the tasks. Applying the relative Story Points to everything is often a mistake, but not having any scoring in place is probably worse and not something we should pursue.
So, where is the balance?
We need something that allows us to talk about the effort required for tasks during “dev cycles” (I don’t call them “sprints” as it’s not always the correct name) and encourage discussions, collaboration and commitment. Estimation of our work is necessary to set the right expectations. Not only for engineers but also for people whose work will be impacted — usually product managers responsible for a new feature in front of the wider audience (a client, a whole company, a user).
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.
- Relative Story Points give more accurate estimates.
They give very low accuracy since points are relative to other tickets, and none is defined in time. We have no clear indication of how long something will take, and actually, the same task could have different points depending on a team. Relative Story points are great if we want to hide facts from others — committing to doing something, but without any guarantees or promises.
- 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?
Most of the arguments against Story Points brought up by devs are not related to Story Points themselves but against planning in general. I’m not sure if there is any point to comment on them, so I picked only a few most common.
- 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?
Relative points introduce a lot of confusion and boomerang discussions about their value and approach. They are designed to obfuscate the real completion time. Nevertheless, teams are often forced to use them and don’t enjoy it until it becomes “yet another annoying part of their job”. So why are we still pushing for something that people don’t want? Wouldn’t it be better to find alternatives?
Keep it simple
We started using points that reflect actual time. 1 point = half a day, but we kept the Fibonacci sequence to limit our options. That’s all, and now it makes sense to engineers, project managers and everyone else…
So how that benefits us?
- Points are tied to time (but not hours).
A whole week of points for a person is 10 (two weeks 20).
- 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.
In the end, it is all about behaving as #oneteam. If we believe something is not correct or could be better — we should fix it. Waiting for someone else to tell us how to do things results in the frustration of unfulfilled expectations. Instead, take things into your own hands as a team and remember that a good team is solving not only engineering bugs.
Have fun as the only way to make a difference is by trying new things, occasionally failing, and learning in the process.