Spikes, huh, good God! What are they good for? Just imagine Edwin Starr singing the title. Don't know the reference ? Education time here
Anyways, the correct answer is NOT "absolutely nothing". Instead they are often "absolutely everything".
Spikes are not actually mentioned directly in the Scrum Guide. What the Scrum Guide DOES say is - "The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.". And a Spike is often times needed in order to provide clarity or direction on work needed for the product.
What is a Spike defined by the Agile world?
A story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be estimated until the development team does some investigation or actual work to resolve a technical/design problem. That work is defined in a Spike.
Mike Cohn puts it the best when he says "We want to finish a project or feature smarter than we were before. And a Spike is a time-boxed research activity"
What are the usual components in a spike?
A clear question that needs to be answered and why
Acceptance Criteria for how we will know the question has been answered
Acceptance Criteria around outputs (ex. documented research)
There is a lot of debate around how to handle Spikes. Well guess what? Since Spikes are not specifically stated in the Scrum Guide as part of the official framework, it is up to the team to interpret what works best for them.
Should we estimate Spikes?
(I’ve come across two different ways of thinking in my research)
TIME-BOX
- Since Spikes are not usually the result of a full team effort, it could conflate a team's velocity. Instead you can track time spent on Spikes in a Sprint as a separate metric.
- The time boxes should restrict how long an individual spends on something whereas Story points are a forecast on the collective effort it will take a squad to get the work to done.
- Time boxes keep team members from going down rabbit holes and focusing on getting the information needed.
RELATIVE ESTIMATION
- If it requires a team member to complete, then it should be made visible to the project and included in those estimates.
- Team velocity can be negatively skewed if an abundant amount of Spikes are in your current iteration and they have been not been assigned a measurement.
- If your team is trying not to estimate story points in terms of days/hours, this could muddy the waters for them.
BUT as a wise Agile Coach once said; "Why do we spend so much time arguing about things like tracking Spikes? Just pick one, try it out. If it doesn't work, learn why and try something different!"
Anti-patterns to watch:
If you end up with the # of spikes in a sprint trending up overtime.
If the team is spending majority of their sprint capacity on spikes.
If the team's velocity/quality is not increasing.
Spikes should help the team increase their ability to deliver quality value to your users.
So the morale of the story:
Try Spikes if the development team can't estimate the work. Ask yourselves, "What do we need to know in order to be confident we can complete this in a sprint?"
Resources: