Using Spikes to Manage Risks and Uncertainty in Scrum and Agile

Spikes are an often misunderstood yet powerful technique for Scrum and Agile teams.

When used right, they enable rapid experimentation and risk reduction. However, spikes in Scrum come with common pitfalls that can reduce transparency and value.

Using spikes can empower your team to slice complexity, make better decisions under uncertainty, supercharge your team’s agility, accelerate learning, and boost your ability to delight customers.

In this article, we’ll cover what spikes in Agile and Scrum are all about, the types, best practices to use them, and how to avoid misconceptions that distort their purpose

What is a Spike in Agile?

An Agile spike is a time-boxed period of research, analysis, and experimentation used to determine how to best implement a complex story or reduce key risks and unknowns. 

The use of spikes allows the team to rapidly explore options, gather information, and make more accurate estimates before committing to full implementation.

Unlike typical user stories, spikes do not deliver functional software. Their purpose is solely to build knowledge, evaluate feasibility, and reduce uncertainty.

The result of a spike is usually an estimate, design, proof of concept, or other artifact that supports decision-making.

Benefits of Using Spikes in Scrum and Agile

Spikes are a powerful tool for Scrum teams to get rapidly aligned on the best path forward when facing uncertainty.

Here are 8 benefits of using spikes in scrum and Agile

1. Mitigate Risks Proactively: Spikes enable teams to identify potential risks and make more informed decisions to avoid pitfalls before major commitments are made.
2. Split Complex Issues into Smaller, Estimable Pieces: Research done in spikes can reveal ways to break down large stories or epics into independent, value-focused user stories.
3. Evaluate Technical Approaches or UX Design Options: Spikes allow rapid experimentation with different technical solutions or UX designs to validate assumptions.
4. Determine Unknowns and Dependencies: Teams can use spikes to explore how different pieces of the system fit together and uncover dependencies.
5. Enable Greater Innovation and Experimentation: With spikes, teams can explore innovative ideas or new technologies without committing fully upfront.
6. Timebox Research to Avoid Analysis Paralysis: Constraining spikes with clear timeboxes prevent never-ending analysis and force focus.
7. Facilitate Priority Decisions Based on New Information: Insights from spikes enable data-driven decisions on priority and investment.
8. Build Collective Knowledge and Shared Understanding: Sharing spike takeaways distributes learnings across the team and improves alignment.

When to Use Spikes in Scrum in Agile

Here are 4 situations where using spikes in Scrum and Agile can be of utmost benefit to the team:

1. When Reducing Technical Uncertainty

If the team is uncertain about the technical approach to implement a user story, a technical spike can be helpful to perform proofs of concept and determine feasibility.

By timeboxing research and experiments, the team can gather just enough data to inform adoption and estimate the full story accurately.

For example:

• Evaluating integration with a legacy system
• Assessing performance or scalability issues
• Trying out a new architecture or API
• Determining if a complex algorithm or design will work

2. When Evaluating New Technologies

When considering the introduction of new tools, frameworks, or infrastructure, spikes provide a means to safely assess options before committing long-term.

Short, iterative spikes minimize risks and costs associated with new tech. Examples include:

• Setting up a proof of concept with a new cloud platform
• Building a basic demo app with a new front-end framework
• Testing a new database for performance under load
• Comparing build/deploy times for new dev tools

3. When Exploring Potential Solutions

When the team needs to explore different technical or UX solutions before deciding which approach to take, spikes come in handy.

Spikes can be used to:

• Mock up alternative wireframes for a complex workflow
• Build prototypes to demo different user interface options
• Research different algorithms or design patterns to meet a requirement
• Analyze third-party APIs and evaluate the pros/cons of each

These types of spikes help guide decisions and provide confidence regarding the best solution.

4. When Beginning Large User Stories

For very complex user stories that will take multiple Sprints to complete, utilizing a spike to dive into details and identify risks early on is recommended.

This will ultimately reduce unknowns and lead to more accurate long-term estimation and planning.

Types of Spikes in Scrum and Agile

While any spike focuses on risk identification and information gathering, we can categorize spikes into two main types:

1. Technical Spikes

Technical spikes focus on researching, analyzing, and experimenting to resolve technical uncertainties.

Their goal is to determine feasibility, estimate the level of effort, and identify technical risks associated with a user story or feature.

Technical spikes should result in concrete artifacts such as benchmarks, measurements, prototypes, or code samples that provide technical insight.

The throughput is technical knowledge and greater confidence in chosen implementations.

Examples of Technical Spikes in Agile

Common examples of technical spikes include:

• Prototyping a technical approach or architecture
• Performing a proof of concept with new infrastructure
• Comparing solutions for integration with legacy systems
• Testing the performance, scalability, or security of an API
• Determining velocity gains from new languages or frameworks
• Evaluating compatibility across different platforms
• Researching capabilities and limitations of tools or hardware

Best Practices for Technical Spikes in Scrum and Agile

Here are some of the best practices for technical spikes in Scrum and Agile:

• Clearly define the research objective upfront
• Focus on assessing feasibility and estimating, not final implementation
• Expect spikes to produce supporting artifacts, metrics, or prototypes
• Ensure spikes include validation testing for benchmarks
• Leverage tooling for performance/load testing when possible
• Avoid gold-plating in favor of minimal viable spike

2. Functional Spikes

Alternatively, functional spikes explore UX design options, user workflows, and overall solution behavior.

Their goal is to identify optimal functionality and interactions to best meet user needs.

Functional spikes should enable a greater understanding of end-user and stakeholder needs. The throughput is knowledge to guide UX decisions and validate product direction.

Examples of Functional Spikes

Here are some examples of functional spikes in Scrum and Agile:

• Creating wireframes or UI mockups to demonstrate alternative designs
• Building a prototype to simulate a complex user workflow
• Coding barebones functionality for user testing and feedback
• Performing usability testing on key workflows
• Comparing different algorithms from a user perspective
• Analyzing user interaction patterns with new features
• Exploring options to integrate with third-party systems

Best Practices for Functional Spikes

Best practices for functional spikes include:

• Include user perspectives in defining research objectives
• Design spikes support soliciting user feedback
• Focus on assessing workflow and usability
• Document learning outcomes from user testing
• Avoid prematurely locking in design decisions
• Prioritize evaluating the riskiest interactions and flows

Best Practices for Managing Spikes in Scrum

To leverage spikes effectively without distorting transparency or priorities, consider these tips:

1. Timebox Spike Efforts

All spikes should have clearly defined timeboxes based on the minimum viable research needed to support upcoming decisions and reduce uncertainty.

Avoid open-ended spikes that drag on indefinitely.

• Define timeboxes in hours or days, not Sprint length
• Scope spikes to what can be achieved in the timebox
• Extend the spike only if value of additional research outweighs cost
• Leverage timeboxes to avoid analysis paralysis

Timeboxing spikes forces prompt actionable decisions based on information learned.

2. Set Clear Goals and Success Criteria

Before beginning spike work, clearly define the goals, research questions, and outcomes that will signal success.

Clearly articulated objectives keep spikes focused and actionable.

• What specific knowledge gap does this address?
• How will completion of the spike support upcoming decisions?
• What artifacts or measurable outcomes define done?

3. Limit Work in Progress

To complete spikes rapidly and avoid diluting focus, limit the number of active spikes at a given time.

Finishing spikes completely before shifting focus avoids diluted effort and multitasking costs.

• One active spike per sprint is ideal for most teams
• Two to three spikes may be reasonable for larger teams
• Prioritize spikes that will reduce the highest uncertainty
• Swarm to finish spikes before starting new ones

4. Track Spikes Separately

Since spikes do not deliver shippable increments, track them on separate boards from Sprint work if possible.

Separate tracking improves transparency into team bandwidth allocated to spike research.

• Consider a Kanban board or spreadsheet for spike tracking
• Avoid diluting Sprint burndown with spike effort
• Review spike outcomes at Sprint Reviews
• Retire completed spikes promptly

5. Use Spikes to Split Stories

Large, complex stories can often be split into smaller chunks based on knowledge gained from a spike.

Let spikes guide the decomposition of work into smaller, value-focused increments.

• Does the spike reveal logical segmenting points?
• Were distinct solution options identified?
• Can part of the story now be estimated independently?

6. Leverage Automation

Leverage automation tools to reduce manual effort spent on spikes. Automation amplifies team knowledge by allowing more permutations to be tested faster.

• Use scripts for benchmarking and load testing
• Leverage CI/CD for rapid sanity testing
• Automate provisioning of test environments
• Create reusable templates for common scenarios

7. Avoid Analyzing to Death

The goal of a spike is to learn just enough to plan the next piece of work, not finalize a perfect solution.

Focus on targeted, incremental knowledge to avoid analysis paralysis.

• Determine the minimum viable spike scope
• Identify the one or two biggest risks to test
• Favor frequent decision points over detailed analysis
• Don’t mistake spiking for implementation

8. Build Collective Knowledge

Ensure spike findings are shared across the team to build shared understanding as socializing spike outcomes distributes knowledge across the team.

• Host spike demos at Sprint Reviews
• Capture spike takeaways in team wikis
• Inspect and adapt based on feedback
• Add spike artifacts to the team knowledge base

Spike Misconceptions and Pitfalls

While spikes can provide significant value, they can also degrade transparency and distract from delivering shippable value when misused.

Common misconceptions and pitfalls include:

1. Using Spikes as Placeholders

Spikes should not serve as placeholders for unknowns or missing requirements. Placeholders distort forecasts and reduce the reliability of plans.

• Spikes enable researching options, not deferring detail
• The Product Backlog should capture upcoming stories
• Use spikes for proactive risk reduction, not as IOUs

2. Implementing the Full Solution

Avoid implementing the complete solution under the guise of a spike. Doing the full work early distorts velocity and delays feedback.

• Spikes should build just enough to estimate and decide
• Minimal viable spikes prevent overproduction of waste
• Don’t inflate spike scope without clear added value

3. Lack of Clear Goals

Every spike needs clearly defined goals and success metrics before work begins. Unclear goals lead to unfocused spikes that deliver limited usable information.

• What questions will this spike answer?
• How will the work reduce uncertainty?
• What does finished look like?

4. No Timebox

Don’t allow spikes to drag on indefinitely. Constrain them within clear timeboxes, as this mitigates endless analysis and drives decisions.

• Open-ended spikes reduce urgency and inflate effort
• Shorter timeboxes force focused investigation
• Extend timeboxes only when value clearly outweighs cost

5. Spiking Every Story

Do not spike every backlog item by default. Use selectively when uncertainty is high. Smart scoping of spikes prevents misuse as a crutch for uncertainty.

• Spike only the riskiest 20% of stories
• Most stories can be directly estimated
• Excessive spiking delays delivering value

Conclusion

Used intentionally, spikes in Scrum and Agile are incredibly effective for mitigating risk, enabling innovation, and guiding teams to optimal solutions.

By timeboxing spikes to focus on targeted learning and experimentation, teams can gain key insights faster and make better-informed plans. However, misuse of spikes can negatively impact transparency and productivity.

Ensure spikes have clear goals, remain separate from main work tracking, and are limited to reduce wasted effort and focus on the smallest spike possible to enable the next most important decision.

In the end, spikes empower Agile teams to stay nimble when facing uncertainty and encapsulate the iterative learning mindset that enables teams to adapt quickly and deliver value sustainably. When leveraged appropriately, spikes exemplify the inspect-and-adapt heart of agility.

FAQs