Story Point Estimation - the fine art of guessing
A Story Point is a metric used in agile project management and development to determine (or estimate) the difficulty of implementing a given story.
In this context, a story is a particular business need assigned to the software development team. Using estimations of story points rather than time allows development teams to be less precise. It may be difficult, for example, to estimate how long a particular feature will take to develop but relatively easy to understand if it is more complex than others, in which case it should be assigned more story points.
Story Points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant.
What do Story Points represent?
Story Points represent the effort required to put a PBI (Product Backlog Item) live. Each Story Point represents a normal distribution of time. For example,1 Story Point could represent a range of 4–12 hours, 2 Story Points 10–20 hours, and so on. This time distribution is unknown during estimation. By using reference PBI’s relative to which to estimate, it is not necessary to know how much time it takes. You just want to have a rough indication of how much time the PBI will take to complete.
How to calculate Story Points:
Story points can be measured by 3-point approach where time is not the criteria.
- The amount of work to do
- The complexity of the work to do
- Risk, uncertainty or bottle neck of the work to do
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).
What are the benefits of using Story Points?
Story Points allow a team to:
- Quickly estimate issues. Estimation is relative to already completed Product Backlog Items. This is faster than estimating without any reference.
- Estimate without giving a specific time commitment. When estimating in hours, you make a precise time commitment. Estimating in Story Points prevents giving an exact commitment. Nobody knows exactly how many hours you are appointing to a specific issue.
- Embrace the uncertainty that comes with estimation. Story Points specify an unknown time range. Selecting from a specific Fibonacci-like sequence of Story Points allows us to capture uncertainty.
- Accurate enough to plan Sprints ahead. This allows us to better manage the time expectations of stakeholders for future work.