Scrum is a leading framework for implementing Agile methods in any project or product development. It introduces an iterative process, with repeated ‘Sprints‘ aimed at producing useable results, then improving them. Just as in any other project, estimates are often needed for project timescales and progress. Story points are a way to do this without making unreliable specific time estimates.
It is often difficult to estimate projects timescales and duration. This is especially the case in software development. If the development has not been done before, how do you estimate how long it will take? This is complicated even more under an agile framework such as Scrum, where project requirements can change as the project progresses.
One solution, most often used in software development projects, is to use story points instead of fixed time estimates. The problem with time estimates is that all too often, they become commitments – used to measure the progress and success of the project.
Using Story Points
Each job, or task, within the project, is assigned story points according to an agreed scale. This should reflect how easy or complex it will be to complete this task. Each task is thus estimated relative to the other tasks, rather than a fixed time scale.
There is no fixed points scale that must be used. A team can define one that works best for them – as long as all team members use the same scale. For example, this could be a simple 1 to 10 scale or something that better reflects the specific type of tasks in the project.
Image Source: Visual Paradigm
Fitting Story Points into the Sprint
Under the Scrum framework, all items in the project’s Product Backlog are given a story point value. Scrum projects, of course, proceed through a series of Sprints. At the start of each Sprint, the project team agrees on how many items from the Product Backlog to deliver. This is based on their point value and the team’s capacity.
The power of this comes once each Sprint is completed and reviewed. The number of story points completed in the Sprint is totaled – this becomes the ‘Velocity’ of the Sprint. This Velocity then feeds into the next Sprint, guiding how much the team can complete.
Making the Correct Estimates
Any estimation procedure has its challenges, and story points are no different. They should, however, be intuitively easier to use than time estimates – and create less fixed expectations from project stakeholders.
Ultimately it is up to the Product Owner to control story points as part of the Product Backlog. It can take time for team members to be able to provide accurate estimates – but this is part of the nature of Scrum projects.
Some techniques can help make estimates more accurate. Giving estimates together may help avoid unconscious pressure from other members. Discussion about estimation and ensuring a full understanding of the scale being used can also help.
Story points are a useful metric within projects and for stakeholder communication. They do have their limitations, however. It is hard to compare them between teams or projects, with each potentially using different scales and estimates. It is also difficult to use them as project metrics or as part of contracts.