Provide a summary of what this practice is.
A Spike is a specially developed solution to a problem raised by a Story.
What is the overall goal or intention of this practice?
Creating a Spike is an exceptional experimental or investigative step used to help the team understand complex, risky or innovative stories in more detail.
Its aims may involve:
What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?
There are no specific expectations for completing a Spike. However, unless it is exceptionally small or simple, a Spike should not be carried out in the same iteration as the User Stories the Spike supports. These stories should be assigned to later iterations or releases.
What must have happened or been delivered for this practice to be considered complete?
A Spike is complete when:
What pre-conditions must be met before this practice is used?
Spikes are conducted at the delivery team’s discretion. However, they should only be created when the team are not confident that they understand enough about a User Story to estimate or develop it.
This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.
|1||Identify the problem.|
|2||Document Spike stories.||Working with the user and other participants:|
|3||Develop candidate solutions.|
|1||Identify the problem.||Developer.|
|2||Document Spike stories.||Developer.|
|At least 1 Spike Story.||Working with the user and other participants:||Spike stories should follow the same principles and methods as Stories generally|
|3||Develop candidate solutions.||Developer.|
|At least 1 candidate solution.||Typical problem solving techniques are:|
|4||Package solution.||Developer.||Agreed solution.|
|6||Update stories.||Developer.||Updated backlog.|
Issues and risks
What are the key concerns in making a success of this practice?
- Spikes are not meant to generate a formal statement of requirements. They are only designed to raise the team’s confidence in its ability to deliver the corresponding User Stories.
- Creating a Spike does not follow any standard method. A range of topics a Spike might look at or techniques an individual team might apply are described below, but the details depend on the nature of the uncertainty that made the team decide to create a Spike.
- Apart from having an internal audience rather than delivering value directly to the users, Spikes should be managed like any other story, including an internal Showcase.
- Spikes are harder to estimate and schedule than ‘normal’ User Stories.