Story points: the north star for agile teams
Ask a software developer to guess how many jelly beans are in a jar and you’ll probably get some kind of algorithmic reasoning and a frustratingly accurate response.
Guesstimation without reasoning is not exactly a strong suit for most developers.
That’s why estimating the amount of time it will take to tackle projects in order to plan for the following week is often the project most likely to break everyone’s brain.
Enter: Story Points. The quantitative answer to this ambiguous question
So, what are agile story points?
Whereas most teams estimate the difficulty of a task by time—half a day, a week, or a month— story points are a method to measure effort on a relative scale. Assigning tasks based on relative difficulty allows for a more accurate depiction of the effort expected in the task because, unlike time estimates, story points refer only to the task at hand, not unexpected emails, meetings, or delays that could affect the time it takes to complete the task.
In order to make an accurate estimation of story points, there are a few things to keep in mind:
How to measure story points: the Fibonacci sequence
Developers use a fibonacci sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, as a metric to measure story points in order to force teams to come to clear decisions. For example, if you had a project to do and someone asked you if it would take you 3 hours or 4, you may hesitate to answer that question because the difference is so slim it’s difficult to guess. On the flip side, if someone asked you if it would take you 3 hours or 6, the answer would probably be much more clear.
A few questions to consider when defining story points:
1. Does this project resemble another project we have worked on in the past? If so, what was the effort involved in completing it?
Because story points are a relative form of measurement, the process will continuously change and refine itself, but especially in the beginning, it can be helpful to compare to similar past projects for perspective.
2. Are there any potential unseen roadblocks that could cause a delay?
It is important to consider the whole cross-team journey the product will need to take until it is complete.
3. Will we need to rely on a third party to complete this?
Dependency on another team or outside contractor can result in longer delays and more back-and-forth which should be considered.
Who should plan story points: planning poker and it’s players
Planning poker is an activity meant to help come up with accurate story point estimates quickly and as a team. In planning poker, each member of the team holds a stack of cards, each of them containing a different story point. One person reads out the different projects the team has coming up, after reviewing all of the details they know about the project each member of the team lays out the card they believe represents the effort needed to complete the project.
This is a fast, efficient, and transparent process for the team to come together around sprint planning.
So, who should be invited to sit around the poker table? It is important to consider the full picture when estimating the effort involved in completing a story, and agreeing on a DoD, or definition of done. Inviting the whole team and adjacent teams such as quality assurance and user testing can ensure you don’t miss any hidden problem areas.
Common mistakes and what to avoid when estimating story points
There are a few mistakes you and your team can easily avoid when working to estimate story points. Be sure to keep an eye out for them and steer your team in the right direction if you begin to veer off track.
- Equating story points to hours
- Settling for the average
When planning story points, if half of your team picks 2 and the other half pick 4, it seems natural to agree upon 3—but simply agreeing on an average may be skipping a valuable conversation that could improve your team’s understanding of story point estimations in the future.
- Story pointing tasks that are too big or small
Story pointing small bugs or giant projects can begin to cloud the system and make relative effort allocation more difficult.
- Not keeping reference points updated
It is important that your reference PBI, or product backlog items, are always relevant and up to date. If the task items used as reference for defining story points happened 3 years ago when 70% of the team was not at the company, it’s probably time to update and make sure everyone is on the same page.
Managing story points with templates
Managing all of the product backlog items, the allocated story points for each, and who is assigned to each can get out of hand pretty quickly. Having one sharable and flexible place where your team can manage all story points together makes the process more smooth and clear.
This monday board has everything you and your team need to manage sprint planning and story point allocation. In this template, you can find a progress bar to track the progress of the item, status columns to name the type of product backlog item it is and its priority, and how many story points each item has been attributed. With the sharable board, your team can always be on the same page, and continue to use it as a reference when planning future story points.
Making such a drastic shift in how you think about your team’s projects and planning out sprints can take some time to get used to. Sitting with your team to go through what story points mean, how they will affect your team, and some basic best practices can help you implement story points and manage your sprints easily.