Spike Story – the Removal of Uncertainties in Scrum
The term “spike” can be interpreted as “sting” or “thorn”. Stings and thorns can hurt. It is similar in the figurative sense in software development with functional and/or technical uncertainties: they are unpleasant, risky, difficult to calculate and predict. Scrum offers the use of spike stories – also called spike for short – for such uncertainties. A spike story is a limited mandate to analyse a problem, to collect information with the aim of reducing uncertainties and thus project risks. As a result, a spike story – also known as a spike for short – is intended to provide one or more answers; therefore, it also differs from the classical user story, which contributes productively to the achievement of the sprint goal and the creation of the increment.
Although the Scrum Guide does not mention spike stories, their use in developments that use Scrum is not uncommon.¹
Advantages of Spike Storys
Basically, spike stories offer the following advantages
- in the calculation of user stories,
- in the minimisation of risks,
- understanding individual backlog items.
Effort Estimation for Spike Storys
The effort of a spike story is not estimated, but the development team commits itself to invest a certain amount of time to eliminate the uncertainty. The findings may then be used in the next Sprint Planning. It is also recommended to visualise the spike story as such on the taskboard.
 The Scrum Guide mentions neither the Spike Story nor the User Story, but simply refers to Backlog Items.
Often in the context of the spike story, technical stories are also mentioned.
Spike” is also used as a term outside of software development: As pins in shoes or tyres, as a play in American football or as a short-sided change in the signal voltage. Here you will find an overview.
And here you will find additional information from our Smartpedia section: