SPIKES - 101

Using SPIKES to tackle uncertainties and unknowns within Scrum

👋 Hello,

I’m Vibhor, and welcome to my weekly newsletter, the “Winning Strategy.” Every week I answer one question from you about agile, product, roles, processes, frameworks, career growth, working with humans and anything else that’s stressing you at your office. Send me your questions here, and in return, I’ll offer actionable, down-to-earth, and straightforward advice.

Note: If you enjoy reading this post, would you mind showing your support by clicking the little gray heart below the title above? It would really mean a lot and help spread the word about this growing newsletter. 😍

On to this week’s question!

---

Q: Thank you for being such a great help on YouTube and LinkedIn. I am hoping you could provide me with some guidance on how to effectively use spikes in Scrum. I have been searching for some videos on your channel regarding this particular topic, but unfortunately, I couldn't find any. Would you mind sharing your insights on this matter?

Thanks for the question.

To understand Spikes better, imagine you're walking on a beach, and you come across a large area covered with sand.

You've heard rumours of buried treasure in the area, but you have no idea where to start looking. To find the treasure, you would need to probe and test the sand at various points to gather information and narrow down the search.

Similarly, in software development, a spike is a focused, time-boxed effort to probe and test a specific aspect of the product where there is uncertainty, lack of knowledge, or complexity.

Just like probing the sand, a spike helps the team to gather information, validate assumptions, and better understand the problem or the solution they need to implement.

---

Example

The example I often use to explain spikes is of a team building an e-commerce platform. Imagine that this team encounters a user story (the original user story for Spike) that requires integrating a new payment gateway to allow customers to pay using a specific digital wallet.

Let’s say the “specific digital wallet” is Samsung Pay. The development team has never worked with Samsung Pay before, and they're unsure about the complexity involved in the integration. To address this unknown, the Scrum team decides to conduct an experiment which, in the Agile world, we call a Spike.

The goal of the Spike is to research Samsung Pay's API, understand its requirements, and identify potential challenges in the integration process. The Spike is assigned to one member of the dev team.

During the Spike, the assigned developer reviews Samsung Pay’s API documentation, sets up a test account, and creates a PoC that demonstrates a successful connection between the e-commerce platform and Samsung Pay. This probing into the previously unknown API of Samsung Pay helps the developer identify potential security risks and any additional dependencies that need to be addressed by the team.

After completing the Spike, the team will have a better understanding of the integration process for Samsung Pay. They could then update their backlog with the new user stories (or update the original user story), create more accurate estimates, and be better prepared for potential challenges.

---

So, What do we use Spikes for?

We use Spikes to:

EXPLORE

Explore complex or unknown aspects of a project/product. Spikes enable the team to make more informed decisions and help them avoid potential roadblocks down the line.

Example: A team needs to choose the best search algorithm for an e-commerce site. A Spike compares various algorithms, guiding the team to an informed decision.

LEARN

By conducting Spikes, the team learns new techniques, technologies, or approaches which can be applied to the rest of the product/project. This enhances the team's skills and overall efficiency.

Example: A team must implement a real-time chat feature but lacks WebSocket experience. A Spike can teach them about WebSockets, boosting their skills and efficiency.

MITIGATE RISKS

Spikes help identify and address risks early in the product lifecycle. This allows the team to develop strategies to manage or mitigate those risks.

Example: A most common example is data migration from a legacy system. A Spike identifies risks and challenges early, enabling the team to develop mitigation strategies.

ESTIMATE ACCURATELY

Spikes can provide the team with better insight into the effort and resources required for a particular user story or task. This leads to more accurate estimations, which in turn allows for better planning and resource allocation.

Example: Integrating Samsung Pay API. A Spike assesses the effort needed for integration, leading to more accurate estimates and better planning.

ADAPT

As the team gathers new information from Spikes, they can adapt their approach, priorities, or backlog to better align with the product’s goals and requirements.

Example: A mobile app team exploring performance optimization tools. A Spike compares techniques, allowing the team to adapt their approach and reprioritize the backlog.

VALIDATE

Spikes can be used to validate assumptions or hypotheses, ensuring that the team is working on the right problems and solutions.

Example: A team debates using email or phone number verification for user registration. A Spike can assess the pros and cons, ensuring the team focuses on the right solution.

---

Different Types of Spikes

There are 2 main types:

1. Technical Spikes

These test “technical” uncertainty. For the Samsung Pay example above, we will require a technical Spike. Generally speaking, Technical Spikes evaluate new technology, explore a particular technical problem, or find the best solution for a complex issue.

Other examples:

1. Researching the best caching strategy for a web application or prototyping a new algorithm to optimize search functionality.

2. Database Performance: A team is unsure about the performance of a particular database technology. It can create a tech Spike to research, test, and compare various database solutions to determine which one would best meet the project's needs.

3. Machine Learning Algorithm: A team wants to implement a machine learning algorithm to improve the product's recommendation feature. It can create a tech Spike to research different algorithms, test their performance, and decide which one would be most suitable for the project.

2. Functional Spikes

These test potential features and User Experience. It can include exploring a new design, validating a user requirement, or refining the scope of a complex feature.

Examples:

1. Researching usability best practices for a specific type of UI or conducting user interviews to gather insights on a specific feature.

2. Exploring user authentication methods to identify a secure, seamless, and user-friendly solution for a mobile app.

3. Accessibility Compliance: The team needs to ensure their application is compliant with accessibility guidelines. It creates a Spike to research the guidelines, assess the application's current state, and identify areas that require improvements or modifications.

---

Should we estimate Spikes?

NO!

By definition, Spikes are unknown/uncertain/undefined. It can not be estimated relatively using story points because the team usually has no idea how much effort is required to conduct a Spike.

Having said that, it is essential to allocate a specific amount of time for the Spike within the sprint to ensure the team has a clear understanding of the time commitment.

For this reason, Spikes are time-boxed to keep the team focused and prevent them from spending too much time on research or experimentation. The time allocation will depend on the complexity of the Spike and the team's capacity within the sprint.

Scrum Master should work with the team to decide the appropriate time frame for a Spike, considering the sprint's goals and priorities.

What happens if the time box ends without any solution?

If the time box for the Spike ends without a clear solution or conclusion, the Scrum Master should facilitate a discussion with the team to review the following:

• the findings,

• the reasons for not reaching a solution, and

• the next steps.

Here are some possible scenarios and recommended actions:

1. Insufficient time: If the team feels they need more time to research, experiment, or evaluate the options, the Scrum Master can discuss with the team whether it's appropriate to extend the time box or create a new Spike in a future sprint. The team should consider the impact of the delay on the product and other priorities.

2. Incomplete or inconclusive research: If the team was unable to gather enough information or the research findings are inconclusive, the Scrum Master should encourage the team to identify any knowledge gaps or additional resources needed. The team may decide to consult with external experts, conduct more experiments, or gather further data to make an informed decision.

3. New complexities or risks discovered: If the Spike reveals additional complexities or risks that were not initially apparent, the team should discuss these with the Product Owner to reassess the priority and scope of the related user stories. The PO may decide to split the user story, defer it to a later sprint, or even remove it from the product backlog if it no longer aligns with the product goals.

4. Multiple viable solutions: If the team has identified multiple viable solutions but cannot reach a consensus, the Scrum Master should facilitate a discussion to weigh the pros and cons of each option. Using techniques such as decision matrices, dot-voting, or seeking input from stakeholders to help them reach a decision.

---

How to write Spikes? A handy template.

For Spikes to be successful, it's important to clearly define the objective, scope, and expected outcome. A well-defined Spike should answer the following questions:

1. What is the problem or uncertainty that needs to be addressed?

2. What is the scope?

3. What are the acceptance criteria (expected outcome or deliverable) from the Spike?

4. Time-box for the Spikes

Problem > Scope > AC > Time-box

If it's more comfortable for you, you can write a Spike as a user story. However, it's better to keep it simple since a Spike definition usually contains more details than a user story.

Here’s a handy template:

PROBLEM

Title: Investigate/Explore/Research [Topic/Feature/Issue]

Description: As a [development/product] team, we need to understand [the performance/scalability/usability/convenience/feasibility/viability] of various [technology/approaches] to choose the best option for our application.

OR simply,

We will research, test, and compare different [technology/approaches], focusing on [the performance/scalability/usability/convenience/feasibility/viability]

SCOPE

List the specific areas, questions, or tasks that need to be investigated during the Spike. Focus on the key uncertainties or complexities that require exploration.

1. Area/Question/Task

2. Area/Question/Task

3. Area/Question/Task

ACCEPTANCE CRITERIA

Define the deliverables and outcomes that will signify the successful completion of the Spike.

1. Deliverable/Outcome

2. Deliverable/Outcome

3. Deliverable/Outcome

TIME-BOX

Set a clear time limit for the Spike to ensure it remains focused and efficient. This can be in the form of hours or days.

Time Limit: X hours or Y days

ADDITIONAL INFORMATION (Notes)

Notes: Include any additional information, assumptions, or dependencies relevant to the Spike.

1. Note/Assumption/Dependency

2. Note/Assumption/Dependency

3. Note/Assumption/Dependency

Use the example in the above image as a benchmark.

---

How to decide if the team needs a Spike?

The decision to create a Spike often arises during the PB refinement or sprint planning sessions when the team encounters a problem, uncertainty, or risk that requires further investigation. As a Scrum Master, you can facilitate the discussion and encourage the team to identify the need for a Spike.

Here are some steps to guide the team through the decision-making process:

1. Identify the problem: Encourage team members to discuss any uncertainties, risks, or knowledge gaps they've encountered while writing user stories. It’s important to be explicit because teams usually skip discussing uncertainties in detail.

2. Assess the impact: The team then evaluates the impact of the problem on the product. Discuss whether it's crucial to address the problem before moving forward or if it can be deferred.

3. Consider alternatives: Discuss possible solutions, such as conducting research, experimenting, or consulting with experts. Determine if a Spike is the best approach or if other methods could address the problem more effectively.

4. Define the Spike: If the team decides a Spike is necessary, work together to define the problem, scope, and acceptance criteria. Ensure that the spike is time-boxed and aligned with the team's capacity.

Example Scenario

During a sprint planning meeting, the development team is discussing the implementation of a new feature that allows users to upload and process large datasets within the application.

As they discuss the user story, the team realizes that they are unsure about the best approach to handle the processing of large files efficiently without impacting the application's performance or user experience.

The team identifies several potential solutions, including using a third-party library, implementing a custom solution, or offloading the processing to a separate service.

The team realizes the lack of necessary information to determine the best approach.

Each option has its pros and cons, and the team has limited experience with the specific technologies involved.

After discussing the situation, the team agrees that a technical Spike is needed to research and evaluate the different options before they can confidently move forward with the implementation of the feature.

---

How the team handles Spikes?

Handling Spikes requires collaboration and capacity management. Here's how the team can effectively handle spikes:

1. Prioritization: The Product Owner prioritizes the Spike within the product backlog, considering its impact on the project and other priorities. Spikes should be handled with a balance between addressing uncertainties and delivering value to the end users.

2. Team Involvement: During sprint planning (or refinement), the team discusses the Spike, decides who will work on it, and allocates time accordingly. The team members working on the Spike should have the relevant skills, knowledge, or expertise to perform the research, experiment, and investigation.

3. Capacity Management: The SM and the team should carefully manage the team's capacity when including Spikes in the sprint backlog. Allocate sufficient time for the Spike without compromising the team's ability to complete the planned user stories within the sprint. Consider the complexity of the spike and the team's existing workload.

4. Time-boxing: Spikes should be time-boxed to prevent the team from spending excessive time on research or experimentation. Ensure that the team adheres to the time box.

5. Collaboration and Communication: Throughout the sprint, the team members working on the Spike should maintain open communication with the rest of the team. They must share progress, insights, and challenges with the team regularly. Suggest to them not to wait for the standups. Use emails whenever new insight is found. This is to ensure that the entire team is aware of Spike’s progress and can contribute to the decision-making process.

6. Review and Adapt: At the end of Spike’s time-box, the team should review the findings and incorporate the learnings into the product/project. This may involve updating user story estimates, refining the product backlog, etc.

---

Impact on team velocity

Introducing a Spike can indeed impact the team's velocity, as time and resources allocated to the Spike will be unavailable for working on user stories that contribute to the team's velocity.

However, it's essential to understand that the primary goal of a Scrum team is to deliver value to the end-users while maintaining a SUSTAINABLE pace of work rather than solely focusing on maximizing velocity.

In some cases, incorporating a Spike into a sprint can be a strategic decision to mitigate risks, address uncertainties, or fill knowledge gaps that could potentially hinder the team's ability to deliver value in the long run.

While introducing a Spike in a sprint may temporarily reduce the team's velocity, it can be a worthwhile trade-off if the Spike helps the team address critical uncertainties that could impact the project's success in the long term.

The key is to strike a balance between addressing these concerns and maintaining focus on delivering value to the end-users.

Tip: Treat the person working on the Spike the same as a team member who went on a vacation. If the team member becomes available in the middle of the sprint, you can always bring in additional work from the PB.

---

Example Case Study

Background:

An e-commerce company wanted to optimize its website's performance to provide a better user experience and increase conversion rates.

The development team identified that there are several areas of improvement, including page load times, image optimization, and code modification.

However, they were unsure about the best optimization techniques and tools to use for each area, given the variety of options available and the specific requirements of the e-commerce platform.

They used 3 Spikes to investigate the solutions.

Spike 1: Page Load Time Optimization Objective: Research and evaluate different techniques and tools for reducing page load times on the e-commerce platform.

Time Box: 24 hours

Outcome: The team discovered that a combination of lazy loading, server-side rendering, and leveraging Content Delivery Networks (CDNs) would significantly improve page load times.

Spike 2: Image Optimization Objective: Investigate various image optimization techniques and tools to reduce image file sizes without compromising visual quality.

Time Box: 16 hours

Outcome: The team found that using modern image formats (e.g., WebP), implementing responsive images, and using image compression tools would help optimize image file sizes while maintaining visual quality.

Spike 3: Code Minification and Bundling: Evaluate different code minification and bundling techniques and tools to reduce the size of JavaScript and CSS files.

Time Box: 16 hours

Outcome: The team concluded that using specific minification and bundling tools, along with removing unused code and adopting a modular approach, would reduce the overall size of JavaScript and CSS files, resulting in faster load times.

After completing the three Spikes, the development team had a better understanding of the most effective optimization techniques and tools to use for their e-commerce platform.

---

Some Common Myths Related to Spikes

I have encountered several myths and misconceptions about Spikes in the context of Agile and Scrum. Here are a few of them:

1. Spikes are a waste of time: Some people believe that Spikes take time away from delivering user stories and providing value. However, when used judiciously, Spikes can be instrumental in addressing uncertainties, and filling knowledge gaps, ultimately contributing to more informed decision-making and improved project outcomes.

2. Spikes are only for technical issues: Although Spikes are often used to investigate technical uncertainties, they can also be employed to explore non-technical aspects, such as design decisions, business requirements, or even market research. As long as Spike helps the team make informed decisions and reduces uncertainties, use them.

3. Spikes should always produce a final solution: Spikes may not always result in a complete or definitive solution, but they should provide valuable insights, learnings, or recommendations that inform decision-making. Sometimes, the findings of a Spike may lead to further research or additional Spikes, which is still valuable progress.

4. Spikes should be estimated like user stories: Spikes are time-boxed. Since the primary purpose of a Spike is to gain knowledge or explore uncertainties, it can be challenging to estimate the effort required accurately.

5. Spikes should be part of every sprint: While Spikes can be valuable, they should only be used when necessary to address uncertainties, risks, or knowledge gaps. Including Spikes in every sprint without a clear purpose can detract from the team's focus on delivering value to the end users.

6. Spikes are only for developers: Although Spikes often involve technical research or experimentation, they can be relevant to other team members, such as designers, testers, or business analysts, depending on the nature of the Spike. Encouraging cross-functional collaboration on Spikes can lead to more diverse perspectives and better outcomes.

---

How to use Spikes in Jira?

One of the ways to manage Spikes in Jira is to establish them as their own issue type and then, once solved, convert that issue type from a Spike into a story when you are ready to begin work. You can link it back to the Spike using the JIRA issue links for record keeping. To start your first Spike, follow these steps: 

1. Assign the Spike to a team member: Decide which team member is best suited to handle the Spike based on their skills, knowledge, and availability.

2. Create a Spike issue: In your project's backlog, click on the "Create" button or the "+" icon. Select the appropriate issue type, such as "Task," "Story," or a custom "Spike" issue type if your team has one. Provide a clear title and description for the Spike, including its scope, objectives, and acceptance criteria.

3. Timebox the Spike: Set a time limit for the Spike to ensure it remains focused and efficient. This could be in the form of hours or days.

4. Work on the Spike during the sprint: The assigned team member should complete the necessary exploration or design work during the sprint

5. Close out the Spike: Once the Spike's objectives have been met, mark the Spike as "Done" or "Resolved.”

6. Convert the Spike to a story: If necessary, convert the Spike issue type to a "Story" in JIRA.

7. Link the story to the Spike: Use JIRA issue links to establish a connection between the original story and the Spike for record keeping and traceability.

---

This is it 🙏

Note: 🌟 If you share parts of the post on social media, I request you to please use proper credits. I won’t be as frequent in sharing this kind of content if I have to track copies of it floating around on social media.🌟

Also, if you have any questions (related to this topic), don’t forget to use the comments section (on the website) to ask the community. I will try my best to get you an answer.

---

🙋🏻‍♂️ Your Questions!

If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.

If you’re finding this newsletter valuable, consider sharing it with friends or subscribing if you aren’t already.

---

Till next week!

Sincerely,

Vibhor 👋

P.S. Let me know what you think! Is this useful? What could be better? I promise you won’t hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.

---

“I share things I wish I knew in the starting years of my career in the corporate world"

Vibhor Chandel