There is a moment that happens often in sprint planning: the team tries to point a story, one person says “3”, another says “13”, and a third asks “I don’t know — does IFS’s API even support this?”. The meeting runs twenty minutes over, and in the end a middle number is written down. That number is not an estimate; it is uncertainty dressed up as an estimate.
A spike is the agile answer to this situation: instead of forcing an estimate on work that can’t be estimated, you first do a piece of work — time-limited from the outset — to gather the information that will make it estimable.
What is a spike?
The term comes from Extreme Programming (XP); a spike solution means quickly driving a spike through a problem to see what’s on the other side. The Scrum Guide doesn’t mention spikes, but Scrum teams widely use them as a special type of backlog item.
Three things set a spike apart from an ordinary user story:
| User story | Spike | |
|---|---|---|
| Output | Working software that delivers value to users | Knowledge: a decision, an estimate, a finding |
| Duration | Based on the estimate | Fixed from the start (time box) |
| When done | Can go to production | The code is usually thrown away; it doesn’t go live |
In short, a spike answers a question. It doesn’t produce software; it lets you decide how the software will be produced.
Two kinds of spike
- Technical spike. Resolves a technical uncertainty: is the integration possible, is performance sufficient, will this library do the job, which architectural option fits?
- Functional spike. Resolves a business uncertainty: how does the user expect this flow to work, in which situations does a business rule produce an exception, should the screen work in a single step or as a wizard? Usually done with a quick prototype or a short session with the user.
Anatomy of a good spike
A badly written spike: “Investigate the IFS integration.” That is not a piece of work but a topic; there’s no telling when it will end.
A well-written spike has four parts:
Question : Can we create a customer order line via the IFS REST API
and make the reservation in the same call?
Time box : 2 days
Output : Yes/No + a working sample call + a list of constraints
Next step : The "Order transfer" story is re-estimated based on the answer- A single question. Narrow enough that the answer can be yes/no or a number. If there are two questions, there are two spikes.
- A time box. Usually somewhere between a few hours and a few days, within a single sprint. When the time is up, the spike ends — whether or not the answer has been found. If it hasn’t, that is a finding too.
- A defined output. What will be delivered? A decision note, a measurement result, working trial code, an estimate.
- A next step. Which story, which decision will the spike’s result feed? If it isn’t linked to any work, the spike is probably unnecessary.
These four parts are really a small-scale version of the logic we described in our CTQ note: turning a “let’s look into it” request into a measurable acceptance criterion.
Examples from ERP projects
| Uncertainty | Spike question | Time box |
|---|---|---|
| Integration | Does the e-invoice provider’s API support bulk sending and status queries? | 1 day |
| Performance | Can the monthly report on 2 million stock transactions get under 3 seconds? | 2 days |
| Data quality | What percentage of customer accounts in the old system match on tax number? | 1 day |
| Technology | Can the material and mass of every part in an assembly be read via the SOLIDWORKS API? | 2 days |
| User flow | Can warehouse staff do the stock count on a handheld terminal in one screen, or does it take two steps? | half a day + field trial |
We have collected the first places to look for performance spikes in our Oracle performance checklist; the first half-day of a two-day spike is usually spent working through that list.
Spikes in the Scrum flow
- It enters the backlog. When a story can’t be estimated, or uncertainty emerges during refinement, the Product Owner and the team add the spike as a separate item.
- It gets a time box in sprint planning. Whether to give it points varies from team to team: some teams don’t point spikes and deduct them from capacity, others write the points equivalent to the time box. What matters is consistency; the team should know how spikes are counted in the velocity calculation.
- It is done within the sprint. When the time box runs out, you stop. Extending it with “let’s look a bit more” turns the spike into something that is no longer a spike.
- The finding is shown at the Sprint Review. Since the output isn’t software, what is shown is the decision: “Yes, it can be done, with this constraint” or “No, the alternative is this.”
- The result goes back to the backlog. The original story is re-estimated, split or dropped altogether.
Where do teams stumble?
- The question isn’t written. A spike opened as “investigate” has no end. The time box runs out, the team says “we understand a bit more”, but no decision comes out.
- The time box stretches. A two-day spike spreads across a sprint. Work opened to reduce uncertainty becomes the uncertainty itself.
- Trial code goes to production. A prototype written quickly and dirtily is taken into the product with “it already works”. Spike code is written to learn; it isn’t production quality and should stay that way.
- Every uncertainty becomes a spike. If half the sprint is spikes, the team isn’t producing value but constantly preparing. Small uncertainties are resolved inside the story; a spike is only for uncertainty that genuinely makes estimation impossible.
- The result isn’t written down. The finding stays in one person’s head. Three months later the same question is asked again and the same spike is opened again.
DMADV and spikes
The two approaches come from different worlds but meet the same need. When the question “will this alternative really work?” comes up while comparing alternatives in the Analyse step of DMADV, the answer is very often a spike. The habit of producing an early prototype in the Design step also overlaps with the functional kind of spike.
The difference: DMADV is the map for building a process from start to finish, while a spike is a tool for shedding light on a single unknown point on that map.
How we use it
In ERP projects we use spikes mostly in two places: in integrations, because whether the other system’s API behaves as its documentation says can only be found out by trying; and in custom screen/application development, because the user’s workflow only becomes clear once something is put in front of them.
We close integration uncertainties with spikes in our Integration Studio work, and screen and flow uncertainties in the custom application development process, and build the sprint plan on these findings under ERP Project Management.