September 8, 2026 · 8 min read
TL;DR: Spike-shaped options are keyed 9 times and offered as distractors 4 times in this bank, which makes it one of the rare agile answers that leans positive. The keyed cases share one property: there is a real technical or functional unknown that no amount of discussion will settle. The distractors share the opposite one: the team is uncertain about size, not about feasibility, or already has experience that answers the question.
Most agile techniques in this bank are keyed far less often than they appear. The spike is not one of them, which makes the boundary worth learning precisely rather than approximately.
When the team has run out of things it can find out by talking.
The estimates will not converge. A Scrum team runs two full rounds of planning poker on the same story. After each round the high and low estimators explain their reasoning, and the estimates still span three to thirteen points. Keyed is splitting the story and estimating the smaller pieces separately, or timeboxing a spike to remove the unknown. The explanation makes the diagnosis rather than just naming the answer: two rounds of genuine discussion have already done what discussion can do, so if the spread survives explained reasoning twice, the disagreement is not about who has the clearer picture. Running a third round and averaging is offered and loses, because averaging a disagreement about facts produces a number nobody has grounds for.
The team cannot choose between approaches. Estimating a backlog item, a team realises it could be implemented several different ways and none is obviously best. Keyed is adding a spike to the backlog. Taking whichever alternative is fastest, or whichever is cheapest, both decide the question without evidence. Adding the alternatives to the backlog in ranked order is the subtle distractor: the explanation points out that a ranked list is one of the things the spike would produce, not a substitute for running it.
Nobody can settle a behaviour question. An agile team and its product owner argue about how a user would interact with the system and what behaviour the user would expect, and neither side can settle it because so much is unknown. Keyed is a functional spike. The retrospective is offered and loses because it comes far too late; the daily stand-up loses because it is a coordination meeting rather than a forum for design questions; a brainstorming session with the product owner loses because it exchanges opinions without producing anything either side can point to.
A serious risk sits late in the schedule. Developers flag a serious risk on a feature scheduled near the end. Keyed is running a spike to investigate the risk and find a solution, then moving that feature earlier. The explanation gives the underlying principle: risk is cheapest to address while there is still project left to react in, and a spike converts an unknown that would otherwise have surfaced near the deadline into a known the team can plan around.
The work itself is unfamiliar. A design team with a reputation for quality is given a new kind of work and its output drops. Keyed, alongside bringing in T-shaped profiles, is running a spike in the next iteration to investigate what the new work actually demands. A team-building event is offered and loses because it treats a motivation problem nobody has diagnosed.
When the uncertainty is about how big the work is, not about whether it can be done.
The clearest case runs on a rail ticketing app. Several user stories were left unfinished at the end of an iteration. More than one team member worked on each of them, and no blockers were recorded against any of them. Spending the next iteration on a team spike to establish whether the planned stories can be finished at all is offered, and it loses. Keyed is working with the product owner to break the stories down further. The explanation draws the line in one clause: a spike investigates a technical unknown rather than a sizing problem. Nothing was blocking these stories. Several people simply could not finish work that was too large, and investigating that produces no information the team does not already have.
The second trap is more interesting, because the bank uses it to bound the technique from the other direction. Halfway through a hardware-firmware project, one team member argues for a spike because the team has not used the vendor's new sensor API before, and another argues the team should estimate from its experience with a similar API. Keyed is estimating now. The explanation is worth quoting almost in full: a spike is for genuinely open technical questions, not for ordinary estimating uncertainty that experience can already answer, and treating every unfamiliar-but-analogous tool as spike-worthy would turn estimation into constant investigation.
Common trap: reaching for a spike whenever the team says it is unsure. The bank keys spikes 9 times and rejects them 4 times, and the rejections are not about spikes being a weak technique. They are about the word "unsure" covering two different conditions. If the team cannot size the work because it does not know whether something is possible, a spike answers that. If the team cannot size the work because the work is simply too big, decomposition answers it, and a spike spends a timebox producing nothing. The bank flags this by name in the hardware-firmware record, where "the team should run the spike" is written as a distractor with a superficially reasonable justification attached to it.
Split when the work is too big to finish, spike when the work is too unknown to size. The stem tells you which by saying whether anything was actually blocking the team.
| What the stem describes | Keyed response | Why |
|---|---|---|
| Estimates span 3 to 13 points after two explained rounds | Split, or timebox a spike | Both are keyed; the spread is a size or unknown problem |
| Several people worked a story, no blockers, still unfinished | Split | Nothing was unknown; the work was too large |
| Several possible implementations, none obviously best | Spike | An open technical question with no evidence |
| Team and product owner cannot agree on system behaviour | Functional spike | Opinions have already been exchanged |
| Unfamiliar API, but a comparable one used before | Estimate now | Experience already answers the question |
| Serious risk attached to a late feature | Spike, then pull the feature forward | Converts a late unknown into an early known |
The pairing in the first row matters. In the planning poker record, splitting and spiking are keyed as a single option, because a story that will not converge after two rounds may be both too large and too uncertain, and the two responses are not in competition. The exam separates them only when the stem tells you which condition applies.
What is a spike on the PMP exam? A short, timeboxed investigation whose deliverable is knowledge rather than working functionality. The team runs one to answer an open technical or functional question, for example whether an approach is feasible or how a system should behave, before committing to an estimate or a design.
When is a spike the wrong answer? When the problem is that stories are too big rather than too unknown. If several people worked on a story and still could not finish it, and nothing blocked them, the fix is decomposition, not investigation. A spike is also wrong when the team already has relevant experience it can estimate from.
What is the difference between a spike and splitting a story? Splitting reduces the size of the work so each piece carries a narrower estimate range. A spike removes an unknown so the work can be estimated at all. The bank frequently keys both together, because a story can be both too large and too uncertain.
Is a functional spike different from a technical spike? A functional spike investigates how a system should behave, for example how a user would interact with it and what they would expect. A technical spike investigates whether an approach works. The bank keys a functional spike when the team and product owner cannot settle a behaviour question because too much is unknown.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Prototypes and Pilots: 10 Keyed, 21 Distractors and Building the Schedule: Which Estimating Technique the Exam Wants. Schedule and scope tasks are mapped on the Process domain study page.
What is a spike on the PMP exam?
A short, timeboxed investigation whose deliverable is knowledge rather than working functionality. The team runs one to answer an open technical or functional question, for example whether an approach is feasible or how a system should behave, before committing to an estimate or a design.
When is a spike the wrong answer?
When the problem is that stories are too big rather than too unknown. If several people worked on a story and still could not finish it, and nothing blocked them, the fix is decomposition, not investigation. A spike is also wrong when the team already has relevant experience it can estimate from.
What is the difference between a spike and splitting a story?
Splitting reduces the size of the work so each piece carries a narrower estimate range. A spike removes an unknown so the work can be estimated at all. The bank frequently keys both together, because a story can be both too large and too uncertain.
Is a functional spike different from a technical spike?
A functional spike investigates how a system should behave, for example how a user would interact with it and what they would expect. A technical spike investigates whether an approach works. The bank keys a functional spike when the team and product owner cannot settle a behaviour question because too much is unknown.