You can’t show your CEO how productive your engineering org really is if your sprint planning isn’t accurate. The industry average for planning accurate sprints is under 50%, meaning your org could use some improvement.
So you try getting your teams to quantify their work, and they end up having to choose between using story points and hours during their sprint planning. But these metrics are both vague and don’t always stand up to scrutiny. They can also create issues for your org if you rely on them to gauge how productive your teams can be.
In this article, we’ll be talking about story points vs. hours in agile, focusing specifically on which metric is better and helping you avoid using them incorrectly.
Table of Contents
- What Are Story Points?
- How Are Story Points Calculated?
- Why Are Story Points Used in Agile Sprint Planning?
- Why Are Story Points Better Than Hours?
- Beware: Story Points Can Go Wrong
- Step Away from Agile Story Points vs Hours: Use the Right Metrics
What Are Story Points?
Story points help teams estimate the complexity and effort required to implement a given user story. They also have some interesting properties. For starters, they’re simply numerical points without any associated unit of measurement.
Story points also don’t have — and shouldn’t have — an absolute value. We’ll come back to this point later, but suffice it to say you shouldn’t translate points to hours or any other measure of time.
Story points are relative and are only meaningful when compared to each other. For instance, a team should expect to complete a user story estimated at one point with much less effort than another estimated at five. An eleven-point story should be much more challenging still.
Finally, story point estimates are highly contextual. They only have meaning within the boundaries of a single team. As you’ll see, the agile estimation process aims to have the whole team reach a consensus on the effort it takes to complete a story. This means one point for one team can be wildly different for another.
Source: Go2group.com
How Are Story Points Calculated?
You don’t calculate story points — you estimate them.
Generally, when one of your teams come together for sprint planning, they’ll use a set of numbers (typically in the Fibonacci sequence) to assign each user story. This is handy because they can all have a relative size to each other — something assigned a 4 will be twice as hard as a 2, and so on.
Teams can also use other methods, like the planning poker technique or T-shirt sizes as a unit of measurement. Over time, team members will better understand their skills and what they can accomplish, eventually coming to a consensus on how they value story points.
Even though story points don’t quantify the amount of work done, they aren’t going away anytime soon, even if they don’t quantify the amount of work done. As vague as they can be, they’re still a good way for teams to gauge their time to a degree. But that doesn’t mean you need to have your teams solely rely on them for sprint planning.
Why Are Story Points Used in Agile?
First, you don’t necessarily need to use story points in agile estimation. The scrum guide, for instance, says only the development team is responsible for figuring out how to turn the selected stories into an increment of value during the sprint. How they do that is up to them.
So why are we using agile story points so often?
Because they’re easy to use, it’s as simple as that. Story points are a straightforward way for devs to see how difficult tasks are and estimate their workloads in the upcoming sprint.
Story points express the value of stories relative to each other. The higher the value, the less confidence the team has in the estimate. But despite being an easy-to-use method, story points aren’t accurate.
Why Are Story Points Better Than Hours?
No two engineers will spend the same number of hours on the same task. Your new hires may spend two hours working on something, while a veteran dev may crank that same feature out in smaller amounts of time — time estimates aren’t static for all devs.
Hours just don’t factor in the skill, experience, or effort it takes to complete a task, so hours estimated as a metric can’t work.
But the story’s complexity relative to others would stay the same, regardless of the difference in developer skill. That’s why, in the story points vs. hours debacle, the consensus is that story points can provide what hours can’t.
The more your teams work together across sprints, the better their estimation skills will get. And this will improve the process, unlike tracking hours.
Beware: Story Points Can Go Wrong
You can’t figure out how your teams are performing and what they’re working on if you’re looking at things through a blurry lens. Story points can give you a loose idea of how productive your teams are, but they don’t give you a full-HD picture. And the other execs will definitely not understand what they’re looking at with those.
If teams are completing story points left and right, it means they’re being productive. But story points won’t tell you what they’re working on, just that they’re doing things and not necessarily the right things. This can quickly lead teams to value velocity over other metrics.
And this is just a disaster waiting to happen. When you focus too heavily on velocity, teams will quickly start to game the system, inflating story point values as they go. This will be heavily detrimental to your performance and your entire org’s culture.
Instead of relying solely on story points or hours, you should pivot your teams into using modern sprint planning tools to improve their overall planning accuracy. The current standard of using issue trackers, story points, and Git is just no longer good enough.
That’s why we created a six-step program to help team leaders understand and improve their development process. You can also use our Project Delivery Tracker dashboard to get all the information you could ever need.
You can then implement Team Goals to help laser-focus your dev teams, and create a continuous improvement culture. And with our developer automation tool WorkerB, teams won’t need to sweat the small stuff like creating tickets for unplanned work or alerting people for PR reviews.
LinearB’s platform will help you plan sprints with confidence, so you can be sure your teams deliver on time. And you’ll finally have a clear view of when a project will be done.
Watch this short video to get a brief overview of everything we stand for at LinearB!
Step Away from Agile Story Points vs. Hours: Use the Right Metrics
As vague as they may be, story points are a good way to loosely plan your sprints and estimate team workloads. But you should absolutely not be using them to concretely measure team performance.
You can bring your sprints back into alignment with a developer productivity platform. Our WorkerB bot, for example, automates tedious tasks to keep devs on track while our Project Delivery Tracker gives you insight into how your software development teams are performing across the board.
LinearB gives you the power you need to visualize and take action over your teams’ performance. So the next time your CEO asks you for a plan to improve productivity, you’ll already be a step ahead. Get started with us.
