What Is A Spike?
Many people underutilize or overemphasize the essence of a spike. Therefore, it’s necessary to gain an understanding of their advantages and disadvantages. Many organizations use it to scale their ideas or launch of a new product and features.
In this post, you’d get insightful details and understanding of how a spike works. You’d also discover the reasons many teams make use of spikes. The post also addresses the essence of creating a spike. Also, the different forms it can take during an experiment or investigation. Furthermore, the identification of shortcoming related to spikes. Along with, how to make use of the concept for better results.
So What Is A Spike?
A spike is an Exploration Enabler Story in SAFe. It has two different forms of expression. First, a spike actively seeks to unravel possible solutions to a design challenge. Second, a spike provides answers to present issues related to the product. The word ‘spike’ comes from Extreme Programming (XP).
The Agile Alliance states that a spike refers to any task that aims at collating information. Also, it answers specific questions related to products and services. A spike is an investigative story done in the absence of sufficient information. It helps when there are several approaches to decide between. In all cases, the focus is to resolve, enhance or achieve product functionality. They help with product research, design, exploration, investigation, experiments, and prototypes.
Since, spikes represent activities like research, investigation, design, and prototyping. It seeks to get the right knowledge to enhance the reliability of a story. A spike helps to reduce the risk of a technical approach, or understand the prerequisite of a task. Whenever a new story comes in, if the team knows how to approach it, they will estimate it and move forward. Without this understanding, the team will have difficulty estimating it. Hence, rework becomes an acceptable trade-off. When a spike is added, prioritize both the spike and the story in the product backlog, accordingly.
How Do Teams Use Spikes?
There are several ways to use spikes for diverse situations. They include, but not limited to the following:
Researching familiarization with a new technology
Get confidence in technical and functional processes
Lower risk and uncertainties of new products
Appraisal of product features and its potentials
Conduct feasibility studies to find out the viability and reliability of epics
Technical And Functional Spikes
People use spikes for many reasons. Typically, there are two forms of spikes – technical and functional. Let’s address their usefulness in the validation process of a product.
Functional spikes analyze solution behavior and to determine the best approach to take. You may use functional spikes to assess the following:
How to break down a process into manageable parts
How to organize your work
To learn where risks exist as well as other intricate details.
Technical spikes research various approaches and processes in the solution domain. It is used to determine the following:
To define the process in a build-versus-buy decision process
Access the implementation of specific technical approaches
Build assurance on the solution path being sought after
Let’s consider the following:
As an acute care & teaching hospital, I need to provide secure access to medical records, so we are ready for the new age of healthcare.
The story will be broken down into manageable pieces. Let’s consider user roles. There are doctors, administrators, insurance companies and many others. The patient workflow steps for hospital admissions is different than leaving the hospital. What about various HIPAA guidelines? All this and more can result in functional spikes. Furthermore, the team has to consider the technical direction. There could be a packaged software that meets the requirements or some of them. The new age of healthcare requires that we understand new ideas and technologies, like the blockchain. There is an unlimited number of paths that need a technical spike. It will position the team to make the best technical decision.
For this user story, the team would need to come up with both types of spikes. Refer to Splitting Strategies for more techniques.
When To Use A Spike?
A spike should only be used for situations that are highly uncertain. Everyday mundane work activities should not need the research process. Furthermore, they should only be used to reduce any unusual amount of uncertainty. The design of the product or functionality doubts provide great opportunities for spikes.
Spikes are used for the research process of a product and not for refinement or grooming. They negate risk or uncertainty while attempting a new approach in an experiment. A spike should be used to learn when it is necessary to lower risks. For instance, it helps handle working on some unknown code or complicated scenarios.
Guidelines For Spikes
Spikes don’t directly offer consumer value, so it’s best to use them mildly. The rule of thumb that should be adhered to while making use of spikes and they include the following:
Demonstrable: The output of a spike is demonstrable to all concerned parties. It engenders visibility to the architectural and research work elements. It helps to establish collective ownership for making decisions.
Acceptable: The result should be testable. It includes the standards that help to define the outcome.
Quantifiable: Spikes should fit into the smallest agreed upon timebox. The outcome is different from a story because the information supports a story.
Every story has uncertainties and risks associated with it. Therefore, it’s natural to be aware of the implications of research. Hence, the members of the team identify the right solution to the problem. They achieve this outcome through brainstorming sessions, negotiation, collaboration, and by conducting experiments. Every user story created has activities to determine the functional and technical risks.
Shortcomings Of A Spike
The creation of a spike points to a potential solution to an intricate design or technical problems. However, more often than not, they help to address the specific issue under investigation. But can ignore other challenges that may spring up later. Nevertheless, spikes represent risks and way to deal with it.
Sometimes, the concept of a spike is being misused and abused to a large extent by agile teams. Some team members do their regular design work masked as a spike. It leads to a waste of time and resources. Another typical pattern is open-ended spikes. Without any definite or specific goals, they go on forever. It’s unnecessary for teams to engage in doing 4-5 spikes per sprint or a spike for every user story. Spikes are best used when there’s uncertainty beyond what can be handled in the usual circumstances of work.
Spikes Pay It Forward
Everyone should regard a spike as an investment in the delivery of a product. Therefore, it goes without saying that you could increase delivery time by adding a lot of spikes. The cost of spikes is acceptable when it has a time-box. It will boost confidence in the product delivery.
It‘s essential to have an atmosphere of trust with the chance for failure. It enables team members to go faster, to innovate, and come up with creative ideas. It is a good trade-off for the team feeling safe. In the absence of an enabling environment, the team is afraid to risk anything. It will hinder their performance.
Team members use spikes to identify work processes that they don’t wholly understand. Ultimately, making the task more comfortable for them. They will reduce concern about new technology or an approach to handle an old technology for your investment to be paid in full.
Care should be employed in determining the timing of spikes. They represent uncertainty in potential stories for new technology. The key to creating and making use of spikes is time-boxing. While conducting experiments, it’s necessary to include the time-box to guide the activities for the research. At times, both the spike and the resulting story can be implemented in the same iteration.
It’s never ideal to allow a spike to take an entire sprint. Hence the need for a time-box which would serve to constrain the amount of time spent on devising a spike. Spikes intend to remove ambiguities and to understand a story to the extent of estimating it accurately. A time-box encourages the team to stay on track and adds some predictability. The time-boxed spike (not an estimate) is included in the team sprint backlog.
For clarification, spikes don’t always result in more work. It’s a fast way for management to know the worth of a specific idea. So, it’s best to limit the amount of time the team spends on spikes. Otherwise, people can fall into a rabbit hole (a situation where you chase down numerous trails without achieving anything). Agile teams carry out little experiments. When a question, uncertainty, or risk arises, a spike may the answer. Teams prefer to be precise in their activities rather than indulging in guess works regarding the outcome of their decisions. In summary, the team should know when and how to make use of spikes appropriately for best results.
To learn about a user stories to a look at the following article: