Spikes from meetings
When the answer in the room is "we need to find out", that is a spike.
Every planning call has a moment where the team hits something nobody knows. Most teams nod, write a story anyway, and pay for it mid-sprint. Backlog.cloud hears the uncertainty and drafts the honest artefact instead: a spike with a question to answer, a time-box, and exit criteria. You review it, then push it.
What a spike is
A time-boxed investigation with a question, not a feature
A spike is work whose output is an answer. Not software, not a screen, not an endpoint. An answer. You raise one when the team cannot design, estimate or safely start a piece of work because a specific fact is missing: does the legacy API support this, will the queue keep up, can the data actually be migrated in place.
Three parts make it a spike rather than vague research. A question phrased so it can be answered. A time-box, because investigation expands to fill any container. And exit criteria that say what counts as done, including the version where the answer is no.
The trap is that spikes rarely announce themselves. Nobody in a meeting says "raise a spike". They say "I cannot tell from the docs" or "we should not estimate that yet", and the moment passes. Then the unknown gets buried inside a story estimate that was never real.
Before and after
Four lines about a legacy CRM API become a spike
A fictional sprint planning exchange from a CRM migration project, and the spike Backlog.cloud drafts from it. This is a curated demonstration of the real output shape.
What was said
Ray (Eng lead): The contact sync piece depends on the old CRM exposing modified-since filtering. I have read the vendor docs twice and honestly, I cannot tell if the v2 API supports it.
Femi (PM): If it does not, what happens to the migration plan?
Ray (Eng lead): Then we are polling full exports nightly, which is a completely different design and probably a different quarter. We should not estimate the sync stories until someone has actually hit that endpoint.
Dana (Eng): I can get a sandbox tenant and find out. A day, maybe two. Either the filter works, or we know the fallback is full exports.
Highlighted statements are the ones the extraction engine anchored the spike to.
Confirm whether the legacy CRM v2 API supports modified-since filtering on contacts
The contact sync design assumes incremental fetches via a modified-since filter. The vendor documentation is inconclusive. If the filter is not supported, the sync moves to nightly full exports, which changes the architecture and the timeline. The sync stories are blocked from estimation until this is answered.
Question to answer
Does the v2 contacts endpoint honour a modified-since filter, and does it behave correctly against a realistic data volume?
Time-box
2 days in a sandbox tenant, as proposed in the meeting. Stop at the end of day two regardless of state.
Exit criteria
A written yes or no with evidence from real API calls, and if no, a one-page note on the full-export fallback. Findings shared before next refinement.
"I have read the vendor docs twice and honestly, I cannot tell if the v2 API supports it."
Note what did not happen: no story got invented for work nobody can design yet, and no estimate got attached to the sync stories. The unknown became a capped, owned piece of work instead.
How detection works
The phrases that give uncertainty away
Backlog.cloud listens for load-bearing uncertainty: unknowns that block design or estimation, not idle wondering. These patterns, in context, are what turn into spike drafts. Every draft cites the verbatim quote, and a human approves it before it goes anywhere.
"We do not know if the API supports it"
A stated unknown blocking design. The clearest spike signal there is.
"We should not estimate this until..."
The team itself is refusing to size the work. The prerequisite is a spike.
"It depends on whether..."
A fork in the plan hanging on a fact nobody in the room has.
"Someone should try it in a sandbox"
A proposed experiment with an implied owner and duration. Half a spike already.
"Last time we assumed, and..."
Scar tissue. The team recalling the cost of skipping the investigation.
Spike vs story
Different output, different definition of done
The confusion is understandable because both sit in the same backlog. But they are governed by different rules, and applying story rules to a spike is how a two-day question becomes a three-week wander.
| Spike | Story | |
|---|---|---|
| Output | An answer: a document, a decision, a proven approach | Working software a user can touch |
| Sized by | A time-box you stop at, whatever the state of the answer | Estimated effort to reach done |
| Done when | The exit criteria are met or the time runs out | Acceptance criteria pass |
| Risk it removes | Building the wrong thing on a false assumption | The absence of the feature itself |
When the unknown is big enough that even the spike decomposes, you are probably looking at an epic with a spike as its first child.
Why this matters
Spikes are the antidote to estimate theatre
Estimate theatre is what happens when planning pressure meets an unknown. The team knows the sync design hinges on an unanswered question, but the sprint needs numbers, so the stories get five points each and everyone moves on. The numbers look like information. They are decoration.
Then the sprint starts, someone finally hits the API, the filter is not there, and three stories worth of design is wrong. The retro will call it "unexpected complexity". It was not unexpected. It was said out loud in planning, by name, and nobody wrote it down as work.
A spike makes the honest move cheap. Two days of capped investigation, a written answer, and the dependent stories get estimated against facts. Backlog.cloud makes the honest move automatic as well as cheap, because the moment of admitted uncertainty is captured while it is still on the record.
Want to get better at surfacing the unknowns on purpose? See the good questions that flush out spikes on the blog.
Common mistakes
How spikes go wrong
Spikes without a question
"Investigate the CRM API" is not a spike, it is a licence to browse documentation for a week. A real spike names the question: does the v2 API support modified-since filtering, yes or no. If you cannot phrase the question, you have not found the uncertainty yet.
No time-box, or a time-box nobody enforces
The time-box is the whole discipline. Research expands to fill whatever you give it. Two days means two days, and if the answer is still unclear at the end, that itself is a finding: the risk is bigger than assumed, and the plan should say so.
Spikes that quietly become implementation
Dana gets the sandbox working, then keeps going and builds half the sync engine inside the spike. Now there is unreviewed production code wearing a research badge. The exit criteria exist to draw that line: the spike ends at the answer, the story starts at the build.
Estimating the dependent stories anyway
The team knows the sync design hinges on the API answer, but planning pressure wins and the stories get pointed regardless. Those numbers are theatre. Raise the spike, park the stories, and point them when the answer exists.
Letting the answer evaporate
The investigation happens, the answer lives in a Slack thread, and four months later someone asks the same question. A spike is only worth its time-box if the finding is written down where the next person will look.
FAQ
Spikes, answered
- What is a spike in agile?
- A time-boxed investigation raised to answer a specific question the team cannot design or estimate around. The output is knowledge, not shippable software: an answer, a proven approach, or a documented dead end. The term comes from Extreme Programming, where a "spike solution" was a narrow throwaway experiment driven through the whole problem.
- How does Backlog.cloud detect that a spike is needed?
- It listens for stated uncertainty that blocks work: phrases like "we do not know if", "it depends on whether", "we should not estimate this until", and proposals to test something in a sandbox. When that uncertainty is load-bearing, it drafts a spike with the question, a time-box taken from the conversation where one was mentioned, and exit criteria. The draft lands in the review queue like everything else.
- What does a generated spike contain?
- The question to answer, phrased so it can be answered. A time-box. Exit criteria that say what counts as done, including the negative result. The context of what depends on the answer. And the verbatim quote from the meeting it was anchored to, so a reviewer can check the source before approving.
- What is the difference between a spike and a story?
- A story delivers working software and is done when its acceptance criteria pass. A spike delivers an answer and is done when the exit criteria are met or the time-box expires, whichever comes first. You estimate stories. You cap spikes. Confusing the two is how research eats a sprint.
- Should spikes carry story points?
- Most teams give a spike a fixed cost equal to its time-box rather than estimating it, because you cannot estimate your way to an unknown answer. What matters is that the time-box is visible in sprint capacity and actually enforced. Backlog.cloud records the time-box explicitly so it survives the push into your work management platform.
- How do spikes prevent estimate theatre?
- Estimate theatre is pointing work everyone privately knows is unknowable, so planning feels complete. The numbers are fiction and the sprint discovers it the hard way. A spike converts the unknown into a small, honest, capped piece of work, and the dependent stories get real estimates one time-box later. Cheaper than a blown sprint every time.
- Which meeting types produce spikes?
- Sprint planning and backlog refinement most of all, because that is where estimation pressure exposes the unknowns. Discovery workshops and project kickoffs produce them too, usually about integration points and legacy systems. Backlog.cloud knows the meeting type and listens accordingly.
- Do spikes push to Jira and the other platforms?
- Yes. After review, a spike pushes to your work management platform like any other backlog item, with the question, time-box and exit criteria in the description. In Jira that description is written in Atlassian Document Format, mapped to the issue type your project uses for spikes.
Keep going
Related workflows and resources
Epics
When the work is big rather than uncertain, it needs a frame instead.
User stories
What the spike unblocks: INVEST stories with real estimates.
Good questions for spikes
How to flush out the unknowns before they hide inside estimates.
Sprint planning meetings
Where estimation pressure exposes the unknowns, and spikes surface.
Product backlog guide
Where spikes sit in refinement and Definition of Ready.
AI backlog generator
The wider capability: every artefact type from one conversation.
The unknowns were admitted out loud. Capture them.
Create a free account, run Backlog.cloud on your next planning call, and review the spikes it drafts from the uncertainty in the room. 3 free generations, no card.