How to Run a Spike When Your Team Needs Research Time
How to Run a Spike When Your Team Needs Research Time
TLDR: Spikes give your team dedicated, time-boxed research time to reduce uncertainty before committing to a story, preventing mid-sprint surprises and blown estimates.
Every team encounters stories they cannot estimate with confidence. The technology is unfamiliar. The requirements are unclear. The integration has never been attempted. When these stories enter a sprint without prior research, they inevitably take three times longer than estimated and blow the sprint goal. Spikes exist to prevent this by carving out dedicated research time before the real work begins.
What a Spike Is and Is Not
A spike is a time-boxed investigation designed to answer a specific question or reduce uncertainty enough to estimate and plan the real work. The deliverable of a spike is not code or a feature. It is knowledge: a recommendation, a proof of concept, or a set of findings that makes the subsequent story estimable.
A spike is not open-ended research. "Investigate authentication options" is too vague to be a spike. "Determine whether OAuth2 or SAML better fits our existing session management architecture, and estimate the integration effort for the chosen approach" is a proper spike. The question is specific, the scope is bounded, and the output is defined.
When to Use a Spike
Use a spike when the team cannot estimate a story with reasonable confidence. During backlog grooming or sprint planning, if estimates for a story vary wildly, say one person says three points and another says thirteen, that divergence signals significant uncertainty. A spike resolves the uncertainty so the actual story can be estimated consistently.
Common spike triggers include evaluating third-party tools or libraries, prototyping a technical approach to validate feasibility, researching regulatory requirements that affect implementation, investigating a production issue whose root cause is unknown, and determining the scope of a legacy system migration.
Structuring a Spike Card
In LocalPM, create a spike card with a "Spike" label so it is visually distinct from feature and bug cards. The card should contain four sections.
Question. The specific question the spike will answer. "Can our current database schema support the proposed reporting requirements without a migration?" One question per spike. If you have three questions, create three spikes.
Time box. The maximum time allocated to the spike. Most spikes should be half a day to two days. If a spike needs more than two days, the question is too broad and should be decomposed.
Approach. A brief description of how the investigation will proceed. "Review the current schema, prototype the three most complex report queries, and measure query performance against a dataset of representative size." This prevents the spike from becoming undirected exploration.
Output. What the team will receive when the spike is complete. "A written recommendation with pros and cons of each approach, and a point estimate for the implementation story." The output is what makes a spike valuable. Without a defined output, the knowledge stays in one person's head and the spike's value is lost.
Running the Spike During a Sprint
Spikes belong in sprints, not in the gaps between sprints. They consume capacity and should be accounted for in sprint planning. Assign a story point value to the spike based on the time box, typically one or two points, so it is reflected in the sprint's velocity and capacity calculations.
Assign the spike to the person or pair best positioned to investigate. Seniority is not always the right criterion. Sometimes the person who will implement the resulting story should run the spike so they build context during the investigation.
Check in on the spike during daily standups. "I have eliminated two of the four options and am testing the remaining two today." If the spike is not progressing or the time box is approaching without clear findings, discuss whether to extend, narrow the question, or accept the current level of uncertainty.
Capturing and Sharing Spike Results
The most common spike failure is completing the investigation but not capturing the findings. The developer learns what they need to know and moves on. Two months later, a similar question comes up and nobody remembers the answer.
When the spike is complete, update the spike card in LocalPM with the findings. Include the recommendation, the evidence supporting it, alternatives considered and why they were rejected, and the estimated effort for the resulting implementation story.
During the next grooming session, the spike owner presents the findings to the team. This takes five minutes and ensures everyone has the context needed to estimate and plan the follow-up work.
Avoiding Spike Abuse
Spikes can be abused as a way to avoid committing to estimates. If every other story requires a spike, the team is either taking on work that is too uncertain or using spikes as a procrastination mechanism.
A healthy ratio is one spike per two to three sprints. If you are running multiple spikes every sprint, your backlog items are not refined enough before they reach the team. Push the product owner to do more upfront clarification before items enter grooming.
Spikes are one of the most underused tools in agile project management. When your team faces genuine uncertainty, a well-structured spike saves more time than it costs and keeps your sprints predictable.
Learn More
Ready to run effective spikes that reduce uncertainty in your sprints? Check out the complete training series:
Watch the Project Management AI Playlist on YouTube
For more project management insights and resources, visit subthesis.com