Scrum's Spike: Unveiling the unknown
When a User Story is shrouded by uncertainty, full of unknowns and there's too much risk involved it is time to stop doing and start gathering more information. To not take a step is faster than walking on the wrong direction.
Child of Extreme Programming, a spike is the right answer to uncertainties that the team find during a sprint planning. The spike is:
"A story or task aimed at answering a question or gathering information, rather than at producing shippable product" — Agile Dictionary
A spike can be technical or functional:
The technical spike is used more often for evaluating the impact new technology has on the current implementation that the team needs experiment a new technology to gain more confident for a desired approach before committing new functionality to a time-box.
A functional spike are used whenever there is significant uncertainty as to how a user might interact with the system. Functional spikes are often best evaluated through some level of prototyping, whether it be user interface mockups, wireframes, page flows, or whatever techniques is best suited to get feedback from the customer or stakeholders., — Visual Paradigm
During the refinement the team can identify some questions and then create a spike story. This spike should be part of the backlog and bring with it any story that depends on its outcome linked as blocked by, until the spike is resolved.
Spikes should not be estimated in story points but time-boxed in days. The outcome of a spike it's more about information than code, usually contributing to a wiki, a blog or documentation for the team.
The spike story's description should have three topics: The time-box — 1,2 or 3 days, the question to be answered and the output expected — A document, a wiki page, a knowledge session, a PoC or something useful.
Example:1. Time-box:
2 days // Usually 1, 2 or 3 days, depending on the complexity
2. Question:
How to secure user's wallet password on the database?
3. Acceptance:
A document with legal requirements for security, a user story to implement it and linked tasks to make it happen.
At the end of the sprint, the assignees should present the results to the team/P.O. and they'll decide if the task is done or need more effort. As the spike's intent is to gather information, its of the uttermost importance to share the knowledge acquired.
The story format of a spike is:
"In order to <goal>, <an actor> needs to <action>" Example: "In order to estimate the Encryption task, the product owner needs to define what are the security requirements.Example: "In order to develop a CSV ingestion system, the tech lead
needs to define the best ingestion method: Streaming or Queueing
The outcomes of a spike usually are documents and knowledge transfer, backlog items like stories, tasks and even other spikes. Sometimes a broader subject can generate another small questions that should also be answered by the same way. Some rare situations the outcome can be a PoC or some code showing the learnings.
There's always the risk of overuse and the team should be aware that spikes are not meant to create designs, plans or detail everything. They're made to unveil uncertainties around defined tasks/stories.
A spike is an exception, not the rule! — scrum.org
