How to Estimate Spikes in Planning Poker: A Practical Guide for Agile Teams

Every agile team eventually encounters a ticket that stalls an entire estimation session. Someone reads the story, someone else says "we don't know enough to estimate this," and the room goes quiet. The team argues for ten minutes, assigns a wild guess, and moves on — carrying a number that everyone privately knows is meaningless.

What that team needed was a spike.

Spikes are one of the most useful tools in agile, and one of the most consistently misused. Teams either ignore them entirely (producing fake estimates on genuinely unknown work) or overuse them as a delay tactic (creating spikes for work that's perfectly estimable with five more minutes of discussion). This guide draws a clear line between the two, and explains how to handle spikes properly in planning poker sessions.

What Is a Spike?

A spike is a time-boxed investigation whose purpose is to reduce uncertainty so that follow-on work can be estimated with confidence. The term originates from Extreme Programming, where it described short research bursts used to answer a specific technical question.

A spike is not:

• A story that you plan to estimate later
• A way to avoid committing to work you find uncomfortable
• A catch-all for anything that seems hard
• An open-ended research project

A spike is:

• A fixed-duration task (a day, two days, one sprint at most)
• Focused on answering a specific question
• Followed by a concrete output (a recommendation, a proof of concept, a decision)
• Estimable in time, even though the follow-on work is not yet estimable in points

This distinction matters. Teams that treat spikes as vague placeholders end up with backlog debt — items that cycle through refinement sessions repeatedly without ever getting done.

When to Use a Spike vs. When to Estimate Directly

The decision is simpler than most teams make it. Ask one question: Does the team have enough information to produce a meaningful estimate?

If yes, estimate it. Even if the estimate might be wrong — estimation under uncertainty still surfaces assumptions, forces discussion, and creates a baseline to learn from.

If no, spike it. But only when the reason you can't estimate is genuine technical or domain uncertainty, not a need for more requirements clarification (which is a different problem — see below).

Cases That Warrant a Spike

New technology evaluation. "Should we use Redis or Memcached for our caching layer?" Nobody can estimate the implementation until the technology is chosen and validated. Spike it.

Third-party API exploration. "Can the Stripe API support our multi-currency use case?" You cannot estimate the integration work until you've read the docs, checked rate limits, and run a proof of concept. Spike it.

Performance investigation with unknown root cause. "Our checkout flow is slow — fix it." The fix might be a 1-point query change or a 20-point architectural refactor. Spike to find the root cause first.

Security or compliance audit with undefined scope. "Make our API GDPR-compliant." Until someone maps what data you're storing and how, the remediation is unestimable. Spike the audit.

Architectural decisions with real tradeoffs. "Should we migrate from a monolith to microservices for the payment module?" This isn't something to estimate blindly. Spike the design and decision, then estimate the implementation.

Cases That Do Not Warrant a Spike

You need more requirements from the product owner. That's a refinement problem, not an uncertainty problem. Don't spike work that's blocked on missing acceptance criteria — schedule a requirements conversation instead.

The work is complex but not unknown. "Refactor the order processing module" is complex. But if your team has refactored similar modules before, you can estimate it. Complexity is not the same as uncertainty.

You're uncomfortable with the estimate. If the team thinks a ticket will take 20 points, that's an honest estimate. Creating a spike because the number feels big is avoidance, not rigor.

The estimate is good enough for sprint planning purposes. If a ticket won't be worked in the next two sprints, a rough estimate (even 13 or 20 points) is fine for backlog ordering. Reserve spikes for imminent work.

How to Handle Spikes in Planning Poker Sessions

When your team encounters a ticket during refinement that clearly needs spiking, the process is straightforward:

Step 1: Name the Specific Question

The most common mistake teams make with spikes is leaving them vague. "Research authentication options" will produce a week of generalized reading. "Determine whether Auth0's enterprise plan can meet our SOC 2 audit requirements and estimate migration effort" will produce a decision.

Before converting a ticket to a spike, the facilitator should ask: "What specific question does this spike answer?" If nobody can articulate it, the ticket needs more requirements work before it becomes even a spike.

Step 2: Estimate the Spike in Time, Not Points

Spikes are estimated differently from regular work items. You don't vote story points — you agree on a time box.

Most spikes fit into one of three sizes:

• Half a day: A quick proof of concept, reading documentation, or running a few tests
• One to two days: A more thorough evaluation involving API calls, test implementations, or research across multiple sources
• One sprint: Reserved for significant architectural investigations or security audits with wide scope

Some teams add spikes to the sprint backlog as time-boxed tasks (e.g., "Spike: 2 days to evaluate caching approach") rather than story points. Others track spike capacity separately from their velocity to avoid skewing their points-based metrics. Either approach works — what matters is that the spike has a fixed end date and a defined output.

Step 3: Define the Spike's Output

The spike must produce something concrete when the time box expires. This output drives the follow-on work. Common spike outputs:

• A written recommendation with a clear choice ("We recommend Redis because X, Y, Z")
• A proof-of-concept implementation that demonstrates feasibility
• A risk assessment or compliance gap analysis
• A revised architecture diagram
• A list of follow-on stories with rough estimates

If the team cannot define what a successful spike output looks like, the spike is not ready to start.

Step 4: Estimate the Follow-On Work After the Spike

Once the spike concludes and the output exists, the follow-on work is now estimable with planning poker in the usual way. This is the moment the spike was building toward. The team reconvenes, reviews the spike findings, and produces a grounded estimate for implementation.

Teams that skip this step lose the benefit. The spike reduces uncertainty; estimation converts that reduced uncertainty into a credible plan.

What to Vote in Planning Poker When a Spike Is Needed

During a planning poker session, when a story clearly cannot be estimated, the team has a few options depending on what tool you're using:

Vote "?" (question mark). Most planning poker tools include a question mark card for this situation. It signals the voter doesn't have enough information to estimate. If multiple people play question marks, convert the item to a spike before the session continues. On planning-poker.app, question marks appear in real time so you can redirect the conversation immediately.

Vote infinity. Some card sets include an infinity card for work that's too large or too undefined to estimate. Like ?, it signals that more information is needed. The difference: infinity usually means the item needs breaking down, while ? means it needs investigation.

Vote uniformly high. Some teams use a 20 or 40 to signal "this needs a spike" when the tool lacks dedicated cards. Less clean, but workable.

Regardless of the card played, the facilitator's response should be consistent: "We can't estimate this. What's the specific question a spike would answer?" Then write that spike story before the session ends.

Avoiding Common Spike Pitfalls

The Infinite Spike

A spike that produces another spike. This usually means the original question wasn't specific enough or the time box was too short. Require every spike to produce at least a rough implementation estimate as part of its output. If the investigation concludes with "we need more investigation," that's a failure, not a result.

Spike as Escape Hatch

Some teams — particularly teams under estimation pressure — learn to spike everything difficult. This poisons the backlog with unestimated work and prevents meaningful capacity planning. If your spike-to-story ratio climbs above one spike per sprint, audit those spikes for whether they were genuinely necessary.

Skipping the Follow-On Estimate

The spike concludes on Tuesday, the engineer who ran it starts implementing on Wednesday, and the work is done by Friday. Nobody estimates. Two sprints later, nobody remembers what the investigation found. Even a quick five-minute planning poker vote on the follow-on work creates a shared record and improves future calibration.

Treating Spike Capacity as Free

A two-day spike is two days an engineer isn't working on committed work. Teams that run spikes without accounting for the time frequently miss sprint goals. Track spike time explicitly — either as reserved capacity or as separate velocity that doesn't count toward your story point total.

Spikes and Velocity: How to Keep Your Metrics Clean

Whether to include spike outcomes in velocity is genuinely contested. Here's a pragmatic approach that most teams find workable:

Don't give spikes story points. A spike's value is knowledge, not delivered software. Including it in story points inflates velocity without representing shipped product. Track spikes as a time investment instead.

Include post-spike implementation stories in velocity normally. These are estimable, deliver value, and should count.

Track spike ratio as a separate metric. If consistently more than 15–20% of sprint capacity goes to spikes, your refinement process is leaving too much uncertainty unresolved before work enters the sprint.

Over time, teams with good spike habits find that velocity numbers stabilize because the work entering sprints is better understood. Estimation sessions get shorter too — when engineers trust that truly unknown work will be spiked rather than force-estimated, they spend less time arguing about uncertainty and more time actually estimating.

Practical Example: Spike to Estimate

Here is how this plays out in practice.

Before the spike, the team encounters this ticket in refinement: "Investigate adding single sign-on (SSO) support for enterprise customers." Votes come in at 3, 13, 20, and ?. The range is too wide and there's a question mark. Discussion reveals that nobody knows which SSO protocols the target customers require, whether the current auth library supports SAML, or whether a vendor solution (Okta, Auth0) is even in budget.

The facilitator converts it to a spike: "Spike (2 days): Determine SSO requirements from sales team, evaluate top two vendor options, produce recommendation and rough implementation estimate."

After the spike, the engineer presents findings: customers need SAML and OIDC, Auth0 supports both, licensing fits budget, implementation involves changes to the auth service and a new admin configuration screen. The team runs a planning poker session on the follow-on stories and produces grounded estimates.

The sequence — estimate attempt, spike identification, spike execution, re-estimation — is precisely what planning poker is designed to surface. The tool's anonymous reveal forced the wide vote range into view; without it, the team might have anchored on one person's guess and shipped the wrong solution.

The Takeaway

Spikes exist to reduce uncertainty, not avoid commitment. Use them when work is genuinely unestimable due to technical or domain unknowns. Keep them time-boxed, focused on a specific question, and always follow them with a planning poker session on the resulting implementation stories.

When your team can articulate what a spike should investigate and what output it should produce, you've already done most of the estimation work — you've turned unknown unknowns into known unknowns, which is exactly the right first step.

If your team regularly encounters unestimable work, Planning Poker supports question mark and infinity cards across all sessions, lets anonymous users join without accounts for quick ad-hoc refinement, and integrates directly with Linear and Jira so spike stories created in your tool of choice show up automatically in your next estimation session.