What this template is for
Spikes are how teams stop arguing about technical decisions in refinement meetings and start answering them with bounded investigation. Done well, spikes save weeks of wrong-direction work. Done badly, they become open-ended projects that consume sprints without delivering anything.
This template prevents the second outcome with two structural defences:
- Hard-required fields on the create screen - the question, the time-box, the success criteria, the explicit out-of-scope. You cannot create a spike ticket without committing to what answer you’re looking for and how long you’re willing to spend finding it.
- STM-created sub-tasks that mirror the spike protocol - define the question, list candidates, investigate, write up, peer review, link follow-ups. The last sub-task is the one teams skip without help: linking the stories that implement the decision.
When to use it
Use this template whenever the team can’t estimate a story confidently. The spike resolves the uncertainty so the story can be estimated next sprint. Common triggers: new third-party integrations, performance unknowns, “is this even possible?” architecture questions.
Don’t use spikes as a hiding place for work the team doesn’t want to commit to. A spike that keeps getting renewed past its time-box is signalling that the question is wrong or the problem is bigger than a spike - file a project instead.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Spike: evaluate gRPC vs REST for service-to-service in checkout | Yes |
Question to Answer (custom) | What single question must this spike answer? | Yes |
Time-Box (custom) | 3 days max - hard stop | Yes |
Success Criteria (custom) | What does 'done' look like? A doc, a benchmark, a prototype? | Yes |
Story Points | Sized to the time-box, not the underlying problem | Yes |
Out of Scope (custom) | What this spike is explicitly NOT doing | No |
Owner | @engineer.who.owns.the.decision | No |
Linked Epic | The work this spike unblocks | No |
Components | checkout-api | No |
Labels | spike, research | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Define the single question this spike answers (refine summary if needed)
- List 2-3 candidate approaches before doing any work
- Investigate / prototype within the time-box - stop when time is up
- Write a recommendation: what to do, why, what to NOT do
- Review recommendation with at least one other engineer
- Link follow-up stories that implement the decision
Common questions
What's the difference between a Jira spike and a story?
A spike answers a question with a fixed time-box. A story builds working software with a fixed scope. Spikes end with a decision document, recommendation, or proof of concept - never production code. If you're shipping the output of a spike, it wasn't a spike.
How long should a Jira technical spike be?
Days, not weeks. The whole point is to time-box uncertainty. A 3-day spike that ends without a decision is a successful spike (the answer is 'we still don't know enough'). A 3-week spike is a project, and projects need stories not spikes.
Should spikes be estimated in story points?
Yes - but the estimate reflects the time-box, not the underlying problem. A 5-point spike means 'we are spending 5 points of capacity on this question, regardless of whether we find the answer'. This is what makes spikes safe: the cost is capped before the work starts.
What deliverable comes out of a Jira spike ticket?
A written recommendation. Bullet points are fine; a slide deck is fine; a small benchmark or proof of concept is fine. What's not fine is a closed ticket with 'we figured it out' as the only resolution. Attach the doc to the ticket so the next person asking the same question can find the answer in 30 seconds.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →