Spikes in Scrum
An empirical approach
9 August 2017
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
There has been a lot of controversy related to spikes in Scrum literature. Though the basic ideas are similar, I’ve seen several different approaches related to details and how a Scrum team should handle spikes. What I am going to share here is what I have experienced, which has provided great results with different projects and teams.
A spike is a type of story that is used to reduce uncertainty and gain some knowledge in a technical area. It is different from a regular user story because it does not add value (directly) to business; it is not created by the product owner (PO). However, even though the team requires and creates this technical story, the PO is the one who finally accepts it and adds it to the product backlog.
Spikes are used for activities such as designing, prototyping, or creating a mock-up or wire frame in order to understand a new framework or technology. Then the team uses this gained knowledge to better understand a requirement. A spike helps in gathering enough information to estimate more accurately a specific potential future feature or story — but there could be more to it than that, since in some cases the information that the team obtains could be used to define whether the potential feature or story should be created or discarded.
There are different standpoints about whether spikes should or should not be estimated. The way I have handled this with many Scrum teams is simple: Since a spike requires resources from the team and takes time to be completed, it must be sized. Based on this, the team defines the spike, estimates the relative effort needed to accomplish it in regular user story points, and decomposes it into tasks estimated in hours. That means that a spike is a timeboxed element that has to fit within a sprint. Therefore, it is important that the PO understands the need for this type of story, because she or he has to agree to add it to the product backlog at the proper priority level.
In this context, if a spike is a regular product backlog item (PBI), then it must be completed and demonstrated during the sprint demo (of course, it depends on the type of spike). Since a mock-up or prototype can be demonstrated, the team should be able to explain or show to the product owner what they have done and how it will help the team perform and accomplish a future story or feature. Sometimes a successful spike cannot be demonstrated by itself, but when a dependency to a regular user story is identified, by completing the related story then the spike is demonstrated indirectly. Either way, it has to be clear to the PO and to the whole team that the spike is done and that it supports the common goal.
I would like to emphasize the fact that since the result of a spike could impact one or more user stories or features, it is important to not plan for the spike and the related stories in the same sprint. There is dependency between them, so the chances are strong that the team could have trouble accomplishing both. It is more efficient to complete the spike and then pull the related stories from the product backlog in subsequent sprints or iterations.
Last but not the least, I would like to mention that there are a lot tools and artifacts that can be used in Scrum in our pursuit of creating value by reaching efficient agility. At the end of the day, every requirement and need are unique, and the best way to work with spikes is with a tailored approach that exactly fits your team, your project, and your organization.
Current rating: 4.4 (5 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.