How to Create a Spike in Jira

Your sprint is moving. Tickets are getting picked up. And then someone flags it — nobody knows how to build this feature. The technical unknowns are real, and they’re about to stall everything.

That’s exactly what a Jira spike is built to solve.

A spike gives your team permission to stop guessing and start researching — with a clear time limit, a defined goal, and a place in your board to track it. When used right, spikes are the fastest way to eliminate uncertainty before it becomes a blocked sprint.

This guide walks you through exactly how to create a spike in Jira, when to use one, and how to run it so your team comes out with answers, not more questions.

What Is a Spike in Jira?

A spike is a special type of issue in Jira used for research, exploration, or investigation. It’s not about delivering code — it’s about answering a specific question so the real work can move forward.

The term comes from Extreme Programming (XP), where spikes were used to “spike” through a problem quickly to reduce risk. In modern Agile teams, spikes show up when:

• A story is too unclear to estimate
• A technology or integration is unfamiliar
• There’s a design or architecture decision that needs validation
• Risk from a feature is high enough to warrant investigation first

According to the Project Management Institute, schedule uncertainty and unclear requirements are the top two causes of project failure — cited in over 37% of failed projects. Spikes directly address both.

Unlike regular user stories, spikes don’t have to deliver a shippable product increment. They deliver knowledge — usually in the form of a document, a proof of concept, or a recommendation.

Why Spikes Matter More Than Most Teams Realize

Here’s the problem with skipping spikes: your team starts estimating stories they don’t fully understand. Those estimates are wrong. Work gets blocked mid-sprint. Velocity tanks.

Research from the Standish Group’s CHAOS Report shows that only 31% of software projects are completed on time and on budget. Unclear requirements and technical uncertainty are consistently among the leading causes.

Spikes fix this at the source. By front-loading the research, your team:

• Makes better estimates on actual implementation stories
• Reduces rework caused by wrong assumptions
• Keeps sprints predictable and shippable
• Builds shared understanding across the team

A spike isn’t a sign the team doesn’t know what they’re doing — it’s a sign the team is smart enough to know what they don’t know. That’s the difference between teams that consistently ship and teams that consistently slip.

When Should You Create a Spike?

Not every unclear task needs a spike. Use them selectively for situations where the unknown is blocking forward movement.

Create a spike when:

A story cannot be estimated because the technical approach is unknown. If your team is giving wildly different estimates or defaulting to “too big to size,” that’s a spike signal.

There’s a new technology, API, or third-party integration involved. Before committing to implementation, someone needs to test whether the approach actually works.

You’re evaluating multiple solutions and need data to decide. This is a classic “architectural spike” — compare options, document trade-offs, make a recommendation.

The scope of a feature is unclear and needs discovery. Sometimes the product side needs research too, not just the engineering side.

A technical risk could derail the sprint if discovered late. Spike early, discover the problem early, solve it before it costs you a full sprint.

Skip the spike when:

The team already understands the work well enough to estimate. Don’t create process overhead for things that aren’t actually unknown.

How to Create a Spike in Jira

Jira doesn’t have a native “Spike” issue type by default in most configurations. But creating one takes only a few minutes and gives your team a clean, trackable home for research work.

Here’s exactly how to do it.

Set Up a Custom Issue Type Called “Spike”

Before you can log a spike, your Jira admin needs to create the issue type (if it doesn’t already exist in your project).

Go to Jira Settings → Issue Types → Add Issue Type. Name it “Spike” and give it a description that clarifies its purpose: “A time-boxed investigation to answer a specific question or reduce technical risk.”

Assign it an icon — many teams use a lightning bolt or search icon to visually distinguish spikes from stories and tasks.

Once created, add the Spike issue type to your project’s issue type scheme so it appears when creating new issues.

Create the Spike Issue

From your project board or backlog, click Create (or press C as a keyboard shortcut).

Select Spike as the issue type.

Write a clear, specific summary. The summary should state the question being answered, not the task being done. For example:

“Investigate: Can we use Stripe’s API to support multi-currency checkout?”

is much more useful than:

“Research payment options.”

The question format forces clarity — and makes it immediately obvious when the spike is done.

Fill Out the Key Fields

Description: State the problem, the context, and the specific question the spike must answer. Include what’s already known, what’s unknown, and what a good outcome looks like.

A strong spike description answers three things:

• What are we trying to find out?
• Why does this matter right now?
• What will “done” look like?

Time Box: This is the most important constraint. Set a specific time limit — typically one to three days, or up to half a sprint. Add this directly in the description or in a custom field if your team has one.

Acceptance Criteria: Yes, spikes should have acceptance criteria. They’re knowledge-based rather than feature-based, but they keep the spike focused. For example: “Document three viable API options with performance trade-offs and a clear recommendation.”

Story Points: Teams handle this differently. Some assign points to spikes to account for time in velocity. Others treat them as overhead. Whatever your team decides, be consistent so your planning data stays clean.

Sprint Assignment: Add the spike to the current or upcoming sprint based on priority. If it needs to happen before another story can be picked up, make that dependency visible.

Labels or Components: Tag spikes appropriately (e.g., “spike,” “research,” “backend”) so they’re easy to filter and report on.

Link the Spike to Related Issues

Use Jira’s Link feature to connect the spike to the story or epic it’s unblocking. This creates a visible dependency chain and makes it easy to see what’s waiting on the spike’s outcome.

Common link types: “is blocked by” (on the story) or “blocks” (on the spike).

This is especially important in sprint planning — stakeholders and teammates can immediately see why certain stories are on hold and what’s being done about it.

Track and Close the Spike

Move the spike through your workflow just like any other ticket: To Do → In Progress → Done.

When the spike is completed, the output should be documented — either in the Jira issue itself (as a comment or description update) or linked to a Confluence page. Don’t let the findings live only in someone’s head or a Slack thread.

Close the spike only when the defined question has been answered. If new questions emerged during research, create new spikes for those — don’t extend the original one indefinitely.

Best Practices for Running Spikes Effectively

Knowing how to create a spike is step one. Running it well is what actually moves the needle.

Time-box without exceptions. The moment a spike becomes open-ended, it stops being a spike and starts being a rabbit hole. Set the limit. Stick to it. If you don’t have a full answer, present what you do know and decide as a team whether to extend, spike again, or make a decision with partial information.

Assign a single owner. Spikes work best with one person responsible for driving the investigation. Committees slow research down. One person, clear goal, time limit.

Write findings as you go. Don’t wait until the end to document. Capturing notes throughout the spike means the output is richer and the deadline pressure doesn’t compress the write-up.

Present outcomes to the team. When a spike closes, share the findings in a quick team sync or standup. This builds shared understanding and prevents the same questions from surfacing again in future sprints.

Don’t spike everything. Over-spiking creates process bloat. If your team is creating spikes for things they already understand, it’s a sign something else is off — unclear prioritization, misaligned scope, or low team confidence. Address the root cause.

According to a 2023 survey by the Agile Alliance, teams that regularly use spikes report 28% fewer mid-sprint blockers than teams that don’t use them. That’s a direct line to more predictable delivery.

Common Mistakes That Kill Spike Value

Even with the right setup, spikes can fail. Here are the patterns that sink them most often.

No defined question. If the spike’s goal is vague, the output will be vague. Start with a question that has a clear answer. “Research microservices” is not a spike. “Determine whether our current infrastructure can support 10,000 concurrent WebSocket connections without a major refactor” is.

No time limit. Without a box, the spike expands. What starts as two days becomes two weeks. Always set the limit upfront and make it visible.

Findings not documented. The entire value of a spike is the knowledge it produces. If that knowledge stays in one person’s head, the spike was wasted effort. Document every time.

Spike used as a delay tactic. Sometimes spikes get created not because of genuine uncertainty but because a team wants to avoid committing. Watch for spikes that don’t have a clear question or a time limit — those are usually avoidance in disguise.

Back-to-back spikes on the same topic. If you’re running multiple spikes on the same issue, the original spike probably wasn’t specific enough. Tighten the question before creating another.

How Spikes Connect to Broader Team Productivity

Spikes solve a narrow problem really well: eliminating technical unknowns before they block delivery. But the mindset behind spikes — investigate before committing, time-box the research, document the findings — applies well beyond engineering.

Sales teams face the same challenge. Before building a complex outbound campaign, you need to know who to target, what message resonates, and which channel delivers results. Running that discovery without a defined scope or time limit leads to the same outcome as an unconstrained spike: effort without output.

The teams that move fastest — in product and in revenue — are the ones who know how to structure their unknowns, investigate efficiently, and turn findings into forward motion.

Conclusion

Creating a spike in Jira isn’t complicated — but using spikes well requires discipline. Start with a specific question. Set a hard time limit. Assign a clear owner. Document the findings. Share them with the team.

That’s the entire system. And when you run it consistently, your sprints get more predictable, your estimates get more accurate, and your team spends less time blocked and more time shipping.

The same principle applies everywhere you face unknowns: structure the investigation, cap the time, and turn findings into forward motion. That’s what high-performing teams do — whether they’re shipping product or building pipeline.