“If we knew what we were doing, it wouldn’t be called research.” – that’s what Albert Einstein said and he was correct.
All those Agile teams using the Scrum technology know this very well, because when they are encountered with some question, problem, situation, risk or uncertainty they do not jump to a solution or conclusion immediateinly, or maybe guess the outcomes, on the contrary they conduct experiments to find the right cause and to propose the correct solution. But, stories aren’t simple and short all the time. Sometimes they can be either too large or too complex, which makes the team incapable of proper estimating of the same. Further on, the completion of the story can be even interfered due to some potential blocker.
Having this in mind the agile community offered an alternative or the Spike story. Let’e begin with describing what a Spike is.
What is a Spike?
A spike is an experiment which enables developers to estimate the user story by giving them enough information about the unknown elements of the same story.
There are two types of Spikes: technical and functional.
We use the functional spikes when we want to analyze the overall solution behavior and determine the following things:
- How to break it down
- How to organize the work?
- Where risk and complexity exist
- How to use insights to influence implementation decisions?
We use the technical spikes when we want to research various approaches in the solution domain, such as:
- Determine a build-versus-buy decision
- Evaluate the potential performance or load impact of a new user story
- Evaluate specific technical implementation approaches
- Develop confidence about the desired solution path.
Same as with the other stories, Spikes are put in the Backlog, where they are estimated and sized to fit in an iteration, However, there is a difference between the story results and the spike results, since the stories result in working code and spikes into information. The Product Owner allocates a little bit of team’s capacity before the story needs to be delivered, so that when the story comes into the Sprint, the team knows what to do.
When the spike lasts only one or two hours, we don’t need to keep track of it. As for the spikes which last longer, then we should enter them into the backlog. It’s good to start the name or title with “SPIKE:“, using a tag label would work as well. The result of the spike can be demonstrated to the team, as well as to the stakeholders, which leads to greater visibility of the research and architectural efforts, and besides it builds collective ownership and shared responsibility for decision-making. What you should know about spikes is that they do not always lead to more development, they are just a quick way for determining whether a certain idea is worth it. As mentioned at the beginning the spikes only determine an estimate, they do not deliver the code for that estimate.
Every spike lasts no longer than 1 day of research. However, there are some situations when the spike might last 3 days. When the time-box finishes, the team reports the findings. There are cases when the findings might result in another spike, and the spike is again time-boxed. This continues in a circle, meaning if the question isn’t answered before the time-box finishes, the results must be reported again and then a decision what to do next should be made. Sometimes, the decision might be to define another spike.
The way we estimate defects and spikes is different than how we estimate the stories. When it comes to comparing a 1-point story to a spike with a time-box of several hours or days it is very difficult to do that. Correlated to this, defects are a different type of work than a normal development of a story.
The nature of Agile development is characterized with uncertainties and risks. The team determines the right solution through hours spent in discussion, collaboration, experimentation, and negotiation. So, every user story has a spike-like structure which helps in identifying the technical and functional risks. The ultimate goal of the Agile team is to be able to address uncertainty in each iteration. Spikes are good, but when there is a high uncertainty they can be critical.
To sum up, use spikes whenever you can use them to gain a deeper understanding of the product backlog items. When the team has a hard time of estimating a user story, it means that the story is too large or full of uncertainties. When we have a story that is too large for estimation, then the same should be split into smaller stories. And in cases when the story is too uncertain, we can use either technical or functional spike story to decrease the uncertainty and get a result of the user stories.
Sources:
1. https://www.leadingagile.com/2016/09/whats-a-spike-who-should-enter-it-how-to-word-it/
3. https://www.linkedin.com/pulse/agile-architecting-practice-architecture-spike-erik-philippus/
