If you’ve ever experienced traffic in Los Angeles, you know that the amount of time it should take you to get from Arcadia to Santa Monica is subject to a number of forces including traffic, weather, construction, time of day, and the whims of other drivers. It’s a 32-mile distance that could take 41 minutes or 4 hours.
The items in your Scrum product backlog are subject to a similar number of variables, often making Agile planning as frustrating as sitting in Southern California traffic.
And that’s a massive problem. If you fail to accurately and consistently estimate the time or velocity during Agile planning, it can lead to missed deadlines, bottlenecks, roadblocks, scope creep, and sometimes even the failure of a project.
The good news is that there’s a better way to estimate the time it takes for Agile planning: story point estimation.
Downsides of other time estimation methods in Agile projects
Before we get into the value of story point estimation, let’s consider other estimation techniques used in Agile planning.
Many teams assign an estimate to projects and items by the hour, and then they assign a total number of hours per sprint. But, if we return to the driving analogy, this practice is similar to only looking at distance when driving and not accounting for other factors.
Another way to estimate is the “ideal day” technique. Each workday consists of emails, chats, and meetings, which means that your developers aren’t going to be available to work for 8 hours every day, even though they’re still at work. The downside to this estimation method is that it still relies on hours, not effort.
What are story points?
So how does story point estimation give your team a more accurate estimate of the time user stories will take to complete?
With story points, teams take into account the effort and complexity to assign each item in a product backlog with a numerical value. Story points are much more comprehensive than looking at only one factor—time—to estimate sprint planning.
Story point estimation includes three main components:
- Risk: The risk of a particular project or item includes vague demands, dependence on a third party, or changes mid-task.
- Complexity: This component is determined by how difficult the feature is to develop.
- Repetition: This component is determined by how familiar the team member is with the feature and how monotonous certain tasks are within development.
By incorporating the three points above, your team can more accurately plan sprints, include cushion for uncertainty, better estimate issues, and avoid leaning too heavily on time commitments. Story points allow for consistency not just in teams, but across departments.
3 steps to Agile story point estimation
Follow this process to more accurately plan out your sprints, give realistic expectations, and push projects through faster.
1. Use Fibonacci sequence numbers
It’s tempting to assign items with a linear scale, but those integers aren’t differentiated enough to clearly define an estimate.
You’ve likely encountered this at the doctor’s office with a pain scale. If 1 on the pain scale represents “totally fine” and 10 is a pain so severe it feels like you may be dying, what is 4? And, furthermore, how is 4 different from 5? And where does a kidney stone fit in on the scale if you’ve never experienced severe pain before?
Fibonacci sequence numbers eliminate those minor jumps. As you might remember, the Fibonacci sequence is a series of numbers where each number is the sum of the two previous numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.
For Agile, the sequence is typically modified to 0.5, 1, 2, 3, 5, 8, 13, etc. Using these numbers, it’s much easier to decide if an item is 3 story points or 5 story points.
