Assigning Story Points to each Spike Story Improves Epic Planning Accuracy
In Scrum, we have a special type of Story called a Spike. The Product Owner or another team member writes a Spike Story when the team does not understand the requirement well enough to write a Story or architect a solution.
The Spike Story requirement describes what the team needs to learn or test before they can move forward with product development. Since all Stories must add value, the Spike acceptance criteria describes what must be completed or decided to provide closure.
Example Spike use cases could include:
- Install and become familiar with a new software tool.
- Compare and analyze two similar architecture solutions in order to choose one to move forward with.
- Research a long-standing issue or bug before designing a solution.
Why Write a Spike Story?
Scrum expects that the Development Team knows enough about the Story requirements to size the level of effort in Story Points to deliver the solution within the Sprint. When the team does not understand enough about how to develop the solution, the team acknowledges the fact and writes a Spike Story for the Backlog.
Use the power of the Spike sparingly. A Spike Story is not the same as Analysis and Design, which should be part of the lifecycle of every Story. A Spike Story has an outcome that allows the team to move forward with the real Story. In addition to the learning goal as acceptance criteria, another good practice is to add acceptance criteria that includes writing the successor Story and putting it in the Backlog as candidate for next Sprint.
Why Assign Story Points?
Most who practice Scrum do not assign Story Points to Spike Stories. We at GSD Mindset disagree. The output from a Spike Story is increased team knowledge that leads to better overall solution design. By assigning Story Points to a Spike, you also limit the level of effort expended to close it, so the team doesn’t get lost down some rat hole researching a new tool or attempting to resolve an issue.
It’s About Predictable Velocity for Planning
Energy expended to complete a Spike Story takes away from available energy spent to complete another Story from the Backlog. We at GSD Mindset believe everything brought into a Sprint should have Story Points, so you can better predict the total amount of work the team can complete within the Sprint.
Since Velocity is also used to estimate the length of time required to build an Epic, any background research or creation of small prototypes to try out potential solution architectures should be included in all planning estimates. Assigning Story Points to Spike Stories and including those points in the overall estimate for the Epic helps increase the accuracy of your team’s estimated time to completion.
What are your thoughts? Does your team size Spikes?
Cynthia Kahn
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500