Agile Story Points
One of the hardest parts of scoping or planning a project is estimating the time it will take to complete all tasks and deliverables. Since estimation is the biggest unknown variable in project planning, Agile projects take a different approach—Story Points.
Here’s an overview of what Story Points are and how to use them to make your projects more successful.
What is a Story Point?
A Story Point is a measurement unit that represents the amount of effort required to complete a task. Essentially, Story Points take the place of hours when estimating tasks in an Agile environment.
It can be hard to look at a task such as “build a wireframe for X webpage” and know the exact amount of time it will take. Rather than come up with a time estimate that might be more of a guess than based on actual effort, you would assign Story Points to denote how much effort the task work requires, in comparison with other tasks in your Sprint or your Backlog.
Story Points typically are listed in a Fibonacci type of sequence (i.e., 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100), so the numbers are far enough apart from one another to be easily distinguished when making rough estimates. Although 20, 40, and 100 aren’t numbers in the actual Fibonacci sequence, many teams use these for quicker mental calculations. A 20-point task would be four times the effort of a 5-point task,, for example. Another option is to use a simple doubling of numbers: 1, 2, 4, 8, 16, 32, etc.
How to calculate Story Points in Agile
Many people think estimating Story Points will take just as much time as calculating hours. However, deciding on Story Points is usually much easier and more accurate.
Before calculating your Story Points, you’ll need to assign approximate values for each point. For example, in your company, 0 might equal 15 minutes or less, 0.5 might equal one hour, 1 might equal up to five hours, and so on. Establish a key and range of hours to match to your Story Points.
Next, look at your backlog and start estimating.
For instance, let’s say you have the following tasks in your backlog:
- Build contact form with conditional logic based on X amount of services selected
- Duplicate this contact field across 30 pages
- Test contact field
- Push contact field live
Each of these four tasks needs to be estimated. When you meet with your team, you might quickly determine that building the conditional logic will take the most time.
Once you know there are ten services to build this logic for, your team might realize this is a task that requires medium effort and assign it a 5. Duplicating the field might be an easy task, but doing this across 30 pages will take time, so it gets a 2. Testing the field is straightforward but could require some tweaking, so it gets a 0.5. Lastly, pushing the field live might only take seconds, so it gets a 0.
Using these numbers to represent a range of hours or effort is generally faster than calculating the exact time it can take (depending on several variables).
Datasheet: The Agile Marketing Cheat Sheet
I’ve assigned Story Points, now what?
Once your Story Points are assigned, you can begin assigning tasks to a specific team or resource. You’ll move them from the backlog into a Sprint in the order that makes sense, ensuring that no one person or team has too many high-effort Story Points in one Sprint.
Common questions about Agile Story Points
Using Story Points may take a little time to get used to, but they can save you valuable time once you adopt them into your processes. To help you work through any issues you might experience, here’s a quick Q&A about Story Points.
Can I use hours instead of Story Points?
When running your Agile project, you don’t necessarily have to use Story Points if you prefer to estimate in hours. However, what you should not do is equate Story Points directly to their number equivalency in hours (e.g., 13 Story Points should not equal 13 hours simply because the numbers are the same). This defeats the purpose of using Story Points to simplify the estimation process.
Can Story Points be adjusted during Sprints?
No, your assigned Story Points should remain the same, even if you realize during the Sprint that the original estimates were off. The right time to address these adjustments is during the Sprint Review or Sprint Retrospective, at which times you can discuss why certain tasks took more or less effort than anticipated and keep this knowledge in mind for future planning.
Should I re-estimate a task’s Story Points if it’s moved to the next Sprint?
Even if you start a task, it’s best not to adjust the estimated Story Points associated with it, even when moving it into the next Sprint. If you completed half the task in the time allotted, for instance, it might feel tempting to double the Story Point estimation, but it’s better to talk about this during the Retrospective. You might find that a task like this really needs to be broken into two parts next time, assigned to two different teams, or planned differently. Rather than adjust the Story Points on existing tasks, apply what you learn to future tasks.
Whitepaper: How to Become an Agile Agency
Whitepaper: Agile Marketing for Creative Teams
Use Story Points to fast-track your next project
If Story Points sound like they could help your team estimate required effort faster and more accurately, it’s important to find a work management solution like Workfront that can accommodate Story Points. Workfront's collaboration tools makes it easy for teams to collaborate in task boards to quickly estimate Story Points, move items into Sprints, and reassess data in Sprint Retrospectives.
Take some time to get your team up to speed on Story Points, so you can invite their input as you plan and kick off your projects.