Spike In Scrum: Definition, Benefits, And How To Use Them
In software development, uncertainties are inevitable, common, even. Uncertainties like unfamiliar technologies, unclear requirements, and technical challenges can lead to delays if not handled.
A spike in scrum revolves around addressing these uncertainties before they become a problem. Think of it as a preventative measure to avoid unforeseen roadblocks.
Put simply, spikes play an important role in the Agile framework. Despite that, not everyone knows exactly how it works, but that’s why you’re here. Read on as we go over the definition of Agile spikes, their benefits, why you must use them, and how. Let’s start with a brief overview.
Table of Contents
- What does spike mean in scrum projects?
- Why is it called spike in scrum?
- What is spike vs story in scrum?
- Why should you use a spike in scrum?
- When should you use spikes?
- How do you use a spike in scrum?
- Wrapping up: spike in scrum
- Machine Learning In Finance: 12 Essential Applications
- How To Create Interactive Compliance Training For Bank Employees
- How Fintech Apps Are Using Gamification To Increase User Engagement
- Top Gamification Companies for Employee & Customer Engagement
What does spike mean in scrum projects?
A spike in scrum or Agile is an original user story or task that revolves around one of two things. It either answers an unfamiliar question or explores solutions to an unfamiliar problem.
It originates from extreme programming methodology and can be categorised into technical and functional spikes.
Technical spikes correspond to technical issues like feasibility testing and technological problems. Meanwhile, functional spikes correspond to user requirements or interactions.
Either way, a spike is always made by the Agile development team to tackle uncertainties or to navigate the unknown.
Why is it called spike in scrum?
The term “spike” evoked the idea of driving a physical spike to hold something in place. A good analogy would be rock climbing. Whenever you’re unsure whether you can go any higher, you drive a metal spike into a crack or seam. This spike serves two purposes: to protect against the possibility of falling and to assist progress in climbing.
Similarly, a spike addresses uncertainty in the development process. Risks exist due to uncertainty, and a spike mitigates them, creating a smoother development progress.
Like any other Agile task, a spike is time-boxed, meaning you must allot a specified amount of time. A development team member cannot pursue the task indefinitely.
What is spike vs story in scrum?
What is a story in scrum?
Source: Justinmind
A story is a small unit of work in an Agile framework. Of course, there are other work units that may vary in scale. Epics, for instance, are larger units, while tasks are smaller units within a story. A story is essentially a description of a desired feature from the perspective of a user. It tells the development team that they must implement this hypothetical feature.
What is a spike in scrum?
A spike is likewise a small unit of work in the framework. After all, it is on the same level as user stories, hence the frequent comparison. The following video delves deeper into its definition.
However, they differ in one aspect: their acceptance criteria, a.k.a. results.
What is the difference between spike and story?
The simplest way to think about their difference would be this:
- A user story produces working code for a feature as its outcome or result.
- A spike produces information that would result in a storyboard, proof of concept (POC), prototype, or decision.
Below is a specific example of a user story and the relevant spike to illustrate what this means.
Spike vs story example
The development team wants to implement search functionality into their eCommerce platform. Keeping this in mind, the team made an original story for that functionality, which is:
I want to be able to type a product name and search for that item on the platform.
The result of this user story would be the actual code for the search algorithm. Though not always, there are cases where the team may need to investigate the variables first. For instance, if there are several search algorithms to choose from, they must ask themselves,
What is the most suitable search algorithm for this product search feature?
The process of answering this question is called a spike. And so, while a story produces working code, a spike produces information. In this case, that information results in a decision.
Why should you use a spike in scrum?
As stated in the previous section, a spike produces information. In short, you must use a spike whenever you lack critical information, or in other words, when there are uncertainties.
Doing so allows you the opportunity to reap the following benefits of a spike:
#1. It makes the development process go smoother
Source: TestingDocs
In this fast-paced technological world, new tools and frameworks emerge regularly.
There will almost always be a technology that your team probably hasn’t heard of. In that case, the development process can become messy if they intend to leverage that technology.
A spike provides you with a period where you can first explore new technology. In doing so, you make the development process go more smoothly.
#2. A spike mitigates risk factors
Every task requires time, manpower, money, and other resources.
Some tasks have benefits that outweigh their cost.
Similarly, some tasks have costs that far outweigh their benefits. A spike allows development teams to identify user stories, tasks, and other units of work that aren’t worth pursuing.
#3. It promotes objective decision-making
Every story and task must be justified objectively.
A bias can be disastrous as it may steer you away from your business goals. Put simply, design patterns, architectural choices, and other decisions must be based on hard data.
A spike allows development teams to gather said data to justify their plans.
When should you use spikes?
Spikes are really only viable under specific circumstances. Encountering a roadblock doesn’t justify a spike immediately. Some roadblocks can be resolved quite easily, after all.
So, it’s best to stick to the following situations when determining if you need to use a spike.
#1. Multiple options
You’re bound to encounter multiple options when deciding on algorithms, APIs, and the like.
It’s not exclusive to software development, either. You may also stumble upon multiple options when choosing the most suitable marketing channel. In short, there are bound to be options.
A spike allows you to review these options in any way you want. You can compare their pros and cons, test them manually, and the like. Consider the following example:
Your development team wants to implement search functionality in an eCommerce platform.
There are several search algorithms to choose from. Each option has clear differences in response times and the relevance of their search results. They may conduct a spike to identify the most suitable solution or option. They’d test the potential performance of each algorithm, and only once it’s done will they implement the new functionality.
#2. Uncertain results
Implementing new technologies, like models, algorithms, and APIs, can require huge resources. That’s why you must be 100% sure it will yield the results you expect.
If you’re not a hundred percent sure, then a spike will come in handy.
This example should illustrate this situation more clearly:
Your development team wants to implement image recognition in their mobile app.
They plan to incorporate a machine learning (ML) model as they believe it would improve the app’s image recognition capability. However, it would take months to implement it at full scale.
To confirm your theory, you decide to conduct a spike first. The spike involved testing the ML model on a small set of images first. Doing so allowed you to confirm that it indeed improved the image recognition capability. But most importantly, you didn’t have to invest much to do so.
#3. Unfamiliar problems
Your development team won’t always have the experience to deal with problems. There may be some problems that rarely occur. In this case, the team may not know how to deal with it.
A spike would be an excellent way to explore this unfamiliar situation. Consider this example:
Your development team plans to integrate a payment gateway into a web application. However, they have limited experience with the specific gateway they intend to integrate.
To address this unfamiliarity, the team decides to conduct a spike. This spike involves setting up the most basic integration with the payment gateway. This would provide them with much-needed experience. This experience will help them later when they take on more complex tasks involving this gateway.
#4. Lack of estimation
The Agile development team typically estimates how much time they believe should be spent on each task. These are called estimations, and there are several ways to estimate.
Source: Rebel Scrum
However, there are cases where they may not have an estimation, at least an accurate one, for a task. This may happen when they lack familiarity with the variables of that particular task.
A spike story allows you to make a more accurate estimation. Consider this example:
Your development team wants to integrate a third-party gamification API into their eLearning platform. However, they have zero familiarity with that API, so they’re unaware of how long its integration usually takes. For that reason, they decide first to perform a spike.
This spike involves exploring the documentation of that particular gamification API for a few hours. After which, they would have been familiar enough to make an accurate estimation now.
Other situations may require the use of spikes. It ultimately depends on the judgement of the product owner, product manager, and scrum master when to use a spike.
If you do think that it’s the perfect time for a spike, there are some guidelines you must follow.
How do you use a spike in scrum?
#1. Allocate the appropriate amount of time for each spike
The team must not pursue spike stories for an indefinite amount of time, regardless of the spike results. In short, a spike must have a time box, as per the definition of the term.
Keep in mind, though, that the time must always be proportionate to the complexity and scope of the investigation. It’d also help to establish clear goals and expectations while time boxing, much like how you set sprint goals. That way, the team knows which direction to go. Otherwise, the spike may continue even though you’ve already achieved its goal.
#2. Document the spike findings
It’s not unusual for the scrum team to require the same information for different spikes. That’s why documentation for previous spike findings can go a long way in saving manpower.
Consider the following scenario:
The development team wants to test the feasibility of integrating two gamification APIs in their platform. One API adds the leaderboard, while the other corresponds to the level system.
Coincidentally, they have already used the leaderboard API in a previous spike.
Since they have documented their findings, it is only a matter of reading them. This saved them time they would have otherwise spent testing the leaderboard API for the first time.
Needless to say, documentation allows you to minimise the possibility of spending time on an issue you’ve already resolved.
#3. Seek the help of relevant teams
Certain spikes may be relevant to specific departments. That’s particularly true if it involves domain-specific knowledge. Let’s use the example of the eCommerce platform once again.
Let’s say your development team has a user story like this:
I want to be able to check the stock available for each product in real-time.
This particular user story would require the integration of the warehouse management system. Hence, involving the warehouse management team in this spike is only fitting.
In short, don’t be afraid of interdepartmental spikes.
#4. Conduct meetings during spikes
Meetings should not be exclusive to sprints.
Source: RingCentral
Though it’s a different kind of user story, an Agile spike would also benefit from huddles and stand-up meetings. Meetings may even be more beneficial to spikes than regular tasks.
#5. Make sure you follow up with the outcomes
After every spike, there must always be a next step in the process.
This can be referred to as the spike outcome, ranging from the following:
- Create user stories or tasks by utilising the spike findings.
- Further spikes might be needed to investigate the problem if the current findings are insufficient to clarify the uncertainties.
- Product backlog refinement
- Improvement of existing user requirements.
- A more accurate estimation of tasks and other units of work.
These outcomes would then conclude the spike.
Wrapping up: spike in scrum
A spike may not be as common as regular user stories, but they are as important. They are, after all, your main weapon against uncertainties. They allow you to mitigate risks and make better-informed decisions, among many things. You have to be mindful, though, as spikes are only applicable in specific scenarios, but that shouldn’t be a problem with this guide.
Speaking of which, if you’re interested in implementing gamification API, you don’t have to use spikes to test its feasibility. Request a demo now with Mambo and see the results for yourself.
