There are so many flavors of jelly beans now that we categorize them. Is this necessary? The same question applies to typing spikes.
Kent Beck initially coined the term ‘spike,’ which Extreme Programming subsequently popularized. Spikes are just research tasks. Any descriptive word we put in front of ‘spike’ is mainly a way to categorize the effort and add some context to the work.
Although being familiar with the types of spikes can elevate your understanding of their usefulness, the act of categorizing them provides little value. A spike is just a spike. Agile teams don’t need a different Jira issue type to organize them. Finding a different color of post-it to use for a risk spike versus an architectural spike isn’t necessary.
Understanding the different categories may help you appreciate all the situations where spikes may be helpful. Still, there is little value in categorizing them as they flow through your process.
As it turns out, jelly beans also have categories. Knowing that the jelly bean you hold in your hand is of the Superfruit Flavors versus the Harry Potter™ Bertie Bott’s Every Flavor Beans™ variety might give you some idea of what flavor to expect. Most of us aren’t jelly bean connoisseurs, though, and the best part of the experience is the surprise.
When it comes down to it, all jelly beans are sugary snacks, and all spikes are research tasks. Although there are different types of spikes, the ultimate goal will be to gain knowledge we didn’t previously possess. Knowing the spike category doesn’t help us accomplish the research any more than knowing the category of a jelly bean helps us consume it.
Some agile approaches don’t even acknowledge the different types of spikes. SAFe, for example, only recognizes functional and technical spikes.
Functional spikes focus on understanding the customer’s need or usability.
Very often, it’s hard to understand requirements from a user’s perspective. When first created, user stories tend to be vague. Understanding the problem we’re trying to solve is crucial to success. Working with the Product Owner to stamp out excessive ambiguity can increase an agile team’s chances of completing the user story in a single Sprint.
You can think of functional spikes as “what are we building?”
Questions that a functional spike might answer:
What’s the most user-friendly way to implement this in the UI
What is the business value this need solves?
Given a particular edge case, what should happen?
How can we split this epic into smaller, more manageable chunks that can provide value incrementally
Technical spikes focus on implementation details.
While functional spikes are more customer-facing, technical spikes focus on the technical aspects or the best way to make things work. You can think of technical spikes as “how do we build it”?
Questions that a technical spike might answer:
Is it better to build custom functionality or buy off-the-shelf functionality?
Can the increased system load be supported by the current system design?
Given our implementation options, which is the better choice?
Are there potential performance impacts this change will introduce?
Is a new technology compatible with an existing technology used by the system?
Architectural spikes focus on technical excellence.
One of the twelve principles of the Agile Manifesto states:
“Continuous attention to technical excellence and good design enhances agility.”
I think of architectural spikes as a way to maintain our technical excellence and, therefore, our agility. We need to be thoughtful about how we design the system. Determining how to best fit the pieces together early will help ensure we have a nice picture in the end and not a garbled mess. Following best practices and good design takes time and research that the team may choose to account for in the form of a spike.
Questions that an architectural spike might answer:
What’s the best pattern to use to implement an upcoming request?
What small proof of concept (POC) can we write to prove the feasibility of a potential technical approach?
How does this new technology work?
How should this new component fit into our current architecture.?
Most research tasks in this category could also arguably be considered technical spikes, so some approaches do not differentiate them.
Risk spikes focus on avoiding or mitigating risk.
Depending on the risk specifics, these spikes may also arguably fall into either a functional or technical spike category.
I’ve worked with downstream reporting and analytics teams at the mercy of changes implemented by upstream source systems. Field changes at the data source could impact downstream reporting.
We often had to perform impact analysis to determine what (if any) impacts upstream changes would have on our system. Since we were ultimately looking to maintain feature parity, this could also be considered a functional spike.
I’ve also worked with development teams with massive legacy code bases that had become very brittle after years of focusing on feature delivery to the detriment of technical excellence. It was not uncommon for this development team to require research before making changes to certain parts of the code that they knew to be very convoluted or complex. We could also have considered these spikes to be technical spikes.
Questions that a risk spike might answer:
How can we mitigate the risk?
What is the likelihood that the risk will occur?
Does this change include an excessive amount of risk?
In my opinion, all jelly beans are alike. We can categorize them by color or flavor category, but they’re all still slightly chewy flavor bursts that stick to your teeth.
The principal value in being familiar with the types of spikes in agile is that it helps to remember all the things we can use spikes for, but when it comes down to it, a spike is just a research task. The spike’s acceptance criteria will define its true purpose, and knowing its particular type doesn’t add much value beyond what we’ll find in the acceptance criteria.
When you eat a jelly bean, your experience isn’t changed by knowing what category its flavor falls into.