In your journey as a product manager, you’ll likely come across customer pain point with complicated solutions — unfortunately not as simple as getting the squad together to brainstorm and execute. When this occurs, the question mark is usually around what the solutions could even be. This stems from what we call the “unknown unknowns” — in other words, we do not know whether this solution is either technically or functionally possible based on how the product is built today.
As such, a well-written agile spike story can help you determine whether your proposed solution(s) are either technically or functionally feasible.
Taking the time to write and execute a spike can save your squad from creating anything that they are unsure about. Additionally, executing something new without using an agile spike to investigate first can lead to technical debt. This debt will need to be paid out sometime in the near future.
In this article, we’ll explore what agile spikes are, their different types, their benefits, and how to write them.
To put it simply, an agile spike story — or spike for short — is a type of user story that, instead of detailing out a work component that contributes to a broader epic or initiative, focuses on figuring out whether it’s even possible to build and develop the chosen solution(s) at all.
Usually written by a responsible engineer in the team, it’s an investigation conducted by 1–2 engineers within a limited amount of time. They are allowed to do anything (within reason!) to figure out if any of the discussed or chosen solutions can be developed within the framework of the existing product.
The practical application of the spike can take many forms, depending on what the team is keen on figuring out and learning about potential solutions. It can range from reading through support documentation or previous product requirement documents (PRD) to creating your very own low-fi prototype and testing it to determine if the product can “handle” it.
As a product manager, it is your responsibility not only to figure out when a spike is required to scope out the feasibility of a solution, but also to set parameters for the responsible engineer executing the spike.
There are predominantly two different types of spikes, technical and functional:
| Type of spike | Description | Situation |
| Technical | This is where the responsible engineer(s) run an investigation to determine the specific technical feasibility of the chosen or discussed solution.
The goal is to provide a level of confidence for whether it can be implemented based on the project’s current framework or infrastructure. |
A technical spike is usually required when it is clear during discussions that there are either “known unknowns” or “unknown unknowns” regarding the actual feasibility and implementation of the chosen solution.
As such, an investigation is required to determine whether it is possible in the first place and, if so, what kind of effort and work is involved in order to do so. |
| Functional | This is where the responsible engineer(s) run an investigation with the goal of determining whether there are any business and product risks or rabbit holes associated with the chosen or discussed solution.
They also determine how the work should be categorized and broken down into user stories. |
A functional spike is usually required when you already have some level of confidence that your chosen solution will technically work, but you are unsure as to how this work should be split into its various components (i.e., user stories and tasks). With this, you are also unsure about the types of risks and rabbit holes that may be associated with the components. |
Next, we’ll discuss key benefits of conducting a technical or functional spike.
Spikes are usually timeboxed to a few hours or a couple of days, at most.
They help your team gather information at a quicker pace, enabling faster but more informed decisions for next steps of the execution of your user story.
By conducting a spike before even thinking about the execution and implementation of a user story, your team can confidently determine if a user story is possible in the first place and set parameters for the effort and type of work needed.
A technical spike is particularly useful for surfacing a new solution — one that might be much better at addressing the customer pain point than what was previously discussed.
Based on my experience, I’ve acquired a few tips and tricks to write your own agile spike story. Let’s go into detail below.
Timeboxing is one of the key ingredients that make spiking out a solution so effective. Not only are you getting more detail about the technical or functional feasibility of your chosen solution, but you are also getting all of that detail within a limited amount of time. This helps unblock the team and aids them in making a decision with the findings of the spike. It also ensures that there is a way forward to implementing the solution as well.
On the other hand, you want to be careful about not giving enough time to the responsible engineer(s) to succeed in the technical or functional spike. Depending on the complexity of what they are investigating, you want to give them enough breathing room to untangle the complexity and not feel pressured to come up with quick, under-investigated answers.
Most spikes should last only one sprint and, even in that case, the spike itself should be timeboxed to two days at most. This should be more than enough time for most responsible engineers to figure out what’s wrong.
If not defined properly, spikes tend to take a life of its own. There can be multiple different risks, rabbit holes, and ways of splitting up work. The responsible engineer can find themselves running down different pathways in a vain attempt to figure out all of the problems associated with the spike.
Provide guidelines in terms of what you want to know from the spike and keep the responsible engineer focused. Ensure that everything they investigate only relates to the guidelines that you’ve set forward for them.
Finally, even if you have multiple different spikes, remember to pace them out over a period of several sprints. One of the reasons for this is that you don’t want to end up dedicating a whole sprint to just spikes. Sprints are meant to conclude with pieces of shippable work for your customer.
Instead, make sure that each sprint has at least one, but at most two, spikes that are related to the top prioritized user story moving from your backlog into your sprint. This helps you focus your investigation on a customer pain point or opportunity that you’ve determined to be the top priority, but also allows the rest of the team to focus on other pieces of work too.
Agile spikes can save you and your team time, energy, and resources. They’re a great way to prevent your team from creating anything they are unsure about and are a proactive way to flesh out ideas early.
Follow the tips above and you’ll be able to write and define your spikes in no time! If you would like to access resources or services that I’ve created for product managers, please feel free to visit this link to my website.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
WAgile integrates the structured, sequential phases of waterfall with the iterative, flexible practices of agile.
Ryan Lee talks about how to focus on building your background, personal brand, and track record of success.
While you probably hear a lot about MVPs, two MVP concepts — a concierge and the Wizard of Oz — rarely receive much attention.
Maria Cuasay, Director of Product, Growth at Ancestry, talks about building MVPs and running experiments as fast as possible.
