What is a spike?
A spike is a research-and-analysis task for a complex epic or story. A complex epic or story cannot be broken or estimated in the right way until the development team investigates the details. A spike addresses the uncertainties around the epic or story. The output of a spike helps with providing the estimate for the original epic or story and unblocks ways to disintegrate the uncertainties.
What causes an epic or story to form a spike?
While discussing an epic or story in the backlog refinement session — or even before that — if the team realizes any one of the following inadequacies or gaps, the team should form a spike:
- A technical understanding of the story is necessary before the team can assign story points to it in the refinement session.
- The team must gain the necessary knowledge of the user story and remove the risk of potentially applying an unknown technical approach to the iteration, timebox, or sprint.
- The team must attempt various technical approaches in the solution domain before finalizing an approach for development.
Guidelines for spikes
Because spikes do not directly deliver business value, they should be used only when the team needs clarity about an epic or story.
The following guidelines apply.
Make them estimable, demonstrable, and acceptable
Like stories or epics, spikes are put in the backlog, estimated in person hours, and sized to fit an iteration, timebox, or sprint. If the team is working in Kanban, it should use a timebox of 20 hours maximum for the spike items, which is a ballpark figure and can be adjusted as and when required.
The spike must develop sufficient information to resolve the uncertainty around the understanding and development of the epic or story. The output of a spike must be demonstrable to the team and to any other stakeholders. This brings visibility to the research and architectural efforts and helps build collective ownership and shared responsibility for the key decisions.
Time the spikes
(Here and in the following section, I am indebted to the Scaled Agile discussion of spikes at http://www.scaledagileframework.com/spikes/
.) Because a spike represents uncertainty in potential epics or stories, planning for both the spike and the resultant stories in the same iteration becomes risky. Even if the spike is a small effort and a quick solution is likely to be found, it can be beneficial to complete a spike, and to groom and develop the story in the following iterations.
Consider the exception, not the rule
Every user story has some amount of uncertainty and risk — that is the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. This is a pragmatic approach that improves over time. Thus, in one way, every user story contains spike-like activities to identify the technical feasibility and functional risk. The goal of an Agile team is to learn how to embrace and effectively address this uncertainty. A spike task should be reserved for the critical and larger unknowns.
The following quote — often attributed, though without much evidence, to Albert Einstein — is a good one for understanding the value of spikes: “If we knew what we were doing, it wouldn’t be called research.”