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
- Mitigate Risks Proactively: Spikes enable teams to identify potential risks and make more informed decisions to avoid pitfalls before major commitments are made.
- 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.
- Evaluate Technical Approaches or UX Design Options: Spikes allow rapid experimentation with different technical solutions or UX designs to validate assumptions.
- Determine Unknowns and Dependencies: Teams can use spikes to explore how different pieces of the system fit together and uncover dependencies.
- Enable Greater Innovation and Experimentation: With spikes, teams can explore innovative ideas or new technologies without committing fully upfront.
- Timebox Research to Avoid Analysis Paralysis: Constraining spikes with clear timeboxes prevent never-ending analysis and force focus.
- Facilitate Priority Decisions Based on New Information: Insights from spikes enable data-driven decisions on priority and investment.
- 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
What Types of Work Are Good Candidates for Spikes?
The most valuable spikes focus on reducing uncertainty around technical feasibility, performance, integration risks, and UX design options. Spikes are well suited to exploring complex user stories, evaluating new technologies, researching alternative solutions, and mitigating major product risks.
Who Creates a Spike in Scrum?
Typically the Product Owner will identify the need for a spike, often with input from the development team. The Product Owner then works with the team to define the goals and timebox for the spike.
What is the Difference between Sprint and Spike?
A Sprint delivers a potentially shippable increment of the product. A spike is timeboxed research to reduce risk and uncertainty that does not directly contribute to the increment.
Do You Story Point Spikes?
Most teams do not assign story points to spikes since they do not deliver shippable increments. The best practice is to focus spike efforts on the value of learning within the timebox, not predefined scope.
Are Spikes Part of Sprint?
Spikes are not officially included as part of the Sprint because they don’t directly contribute to the increment and should be tracked separately from Sprint Backlog items.
What is the Goal of a Spike?
The goal of a spike is to rapidly gain just enough knowledge to reduce the team’s uncertainty and allow them to estimate, plan, and make decisions regarding a complex story or risk area.
How do you handle spikes in scrum?
The best ways to handle spikes in Scrum are: Timebox spikes. Ensure there are clear goals and metrics for success upfront. Limit WIP spikes. Track spikes separately from the main work in progress. Share spike results across the team.
Why is it Called a Spike in Agile?
The term refers to a narrow, intense burst of focused effort to quickly get traction on a complex problem like a spike being driven into something.
What is Difference between Enabler and Spike in Agile?
An enabler unblocks other stories but provides intrinsic business value itself. A spike is purely investigatory to reduce uncertainty and does not directly deliver value.
Is a Spike a User Story or Task?
A spike is its own type of item, neither a typical user story nor a standard task associated with a story.
What is the Difference Between Sprint Zero and Spike?
Sprint Zero tries to perform all design and planning upfront before building. A spike is focused on a specific area, happens concurrently, and leads directly into the next piece of work.
How Long do Spikes Last?
Spike timeboxes are around 2-3 days at most. It is important to scope the spike to what can be realistically accomplished in this brief time window, rather than predetermining duration based on effort.
Should Spikes be Estimated Like Other User Stories?
Most teams don’t estimate spikes, as the emphasis is timeboxing the work to control scope rather than completing set tasks. While you can track the spike timebox, measuring velocity based on completed spikes may distort team throughput.
What are the Differences Between Technical and Functional Spikes?
Technical spikes focus on assessing feasibility, performance, risk, and effort to implement a solution, while functional spikes explore UX design options and how users might interact with a proposed feature.
How Many Spikes Per Sprint Is Ideal?
One or two spikes per sprint is generally sufficient. More than that risks reducing focus on shippable increment. You can scope spikes minimally and prioritize those that will unblock the most important upcoming user stories.
Should Spikes be Part of the Sprint Backlog or Tracked Separately?
Spikes should be tracked separately from sprint work when possible, as they don’t contribute toward the shippable increment. A spike-focused Kanban board or spreadsheet often works well for tracking.
What are Warning Signs of Ineffective Spike Usage?
Watch for spikes that drag on past the timebox, blur into full implementation, lack clear goals, introduce waterfall tendencies, or frequently derail sprint commitments. Reign in spikes that distort flow or transparency.
How Can Spikes Help Split Large, Complex User Stories?
Research and prototyping within a spike can reveal ways to break down an epic into smaller, independent chunks, allowing teams to deliver value incrementally.
What are the Benefits of Timeboxing Spikes?
Timeboxes enforce urgent action-oriented investigation within spikes to quickly gather just enough information to plan the next piece of work. This prevents spikes from dragging on endlessly and inflating their true scope.
What is Commonly Used to Explore New Ideas or Determine the Feasibility of Epics?
Spikes, which are short experiments to gather just enough information to reduce risk, uncertainty, and solve problems, are commonly used in Agile software development to explore new ideas or determine the feasibility of epics.