Spikes

Goal

The Agile Extension to the BABOK Guide sets the spike this purpose: to time-box a research, design, exploration, investigation or prototyping activity in order to understand the effort that delivering a backlog item or an initiative will take. The Guide names the trigger: an item or an initiative that cannot be estimated.

What it produces is knowledge: an estimate that has become possible, an answer on feasibility, a design decision, two approaches compared on evidence. The Agile Extension excludes the deliverable increment from what a spike produces. Code written during a spike answers the question put and stops there.

That limit places it against the two sessions that frame the iteration: the retrospective examines how the team works, where the spike examines an unfinished item of work. The iteration review shows stakeholders a finished increment; a spike produces none, and its answer is put to use between the team and the product owner, during backlog refinement or planning.

Table 7.0.1 of the Agile Extension lists the spike among the requirements management techniques and places it on the internal-team side, with no entry for stakeholders outside the team. What it produces explains that placement: a technical or organisational answer meant for the people who will do the work.

Usage

When to use it

• An item relative estimation does not settle: the spread of views comes down to an unknown no discussion resolves.
• An interface, library or platform never integrated before: a technical prototype answers in hours what a discussion leaves open.
• A user story too large to split on sight: a functional spike locates the risk and the points where it can be cut.
• Organisational risk before committing to an initiative: an exploratory spike measures the impact on processes, roles and compliance.
• Several competing approaches or tools: comparing them on evidence costs less than a choice argued from memory.
• A team that is forming: the Agile Extension counts among its strengths the mutual and technical knowledge an early spike brings about.

When not to use it

• A question a phone call would settle: ask the architect or the supplier, then estimate.
• A result meant for production: the outcome is known, so this is an ordinary backlog item, planned and delivered.
• Recourse to it at every iteration: fix backlog refinement.

Description

The two elements

The Agile Extension gives the technique two elements: the goal and the type. The goal is a defined outcome that says when the research is finished, and the business analysis practitioner sets the duration of the spike (time-box in the wording of the Guide) inside one iteration. A goal is written as a question whose answer can be verified: "does library X cover format Y at our volumes?" closes, "study the integration options" never closes.

Running a spike

The spike goes into the backlog as an item of its own, with its goal and its duration visible, and it is planned into an iteration like everything else. One or two people run it. Mike Cohn sizes the spike itself in hours (4, 40 or 400 depending on what is at stake) and keeps it for extreme uncertainty. An ordinary difficulty of estimation is settled by refining the item.

The duration expires, whether the question has been settled or not. A spike that returns "no answer in sixteen hours" has produced a result: the item is riskier than the team believed, and the decision to carry on falls to the product owner. The answer is reported during refinement or planning, the item is re-estimated, then the spike is closed.

What makes a spike fail

The duration too long or the item too large

The Agile Extension names this limitation: too wide a duration or too bulky an item leaves the spike without clear objectives and without a clear result. Two weeks of research on "the migration" return a report nobody converts into an estimate. If the question cannot be put in one verifiable sentence, the item is still too large and is split before any spike.

The word laid on a follow-up conversation

The Guide notes that the term is wrongly applied to follow-up conversations. "Let's spike that" becomes the phrase that pushes a decision from one iteration to the next. A spike has a written goal, a duration and a person running it; whatever lacks those three attributes is a task, a question or a postponement.

The prototype shipped to production

Kent Beck, who named the spike solution, describes it as a minimal program built to answer a design question and then discarded. The code of a spike is written fast, with no tests and no error handling, because the question put does not call for them. Delivered as it stands under the pressure of a deadline, it becomes debt whose origin is forgotten within two iterations. The answer of the spike is kept; its code is thrown away.

The spike in every iteration

Frequent recourse signals, according to the Agile Extension, backlog refinement that does not meet the needs of the team. Items arrive at planning without anyone having looked into what they presuppose. The correction bears on refinement: capping the number of spikes allowed leaves the cause in place and weakens the estimates.

AI considerations

A language model shortens the documentary part of a technical spike: it lists the libraries that handle a format, condenses a specification of several hundred pages around the question put, produces the skeleton of the throwaway prototype in a few minutes. It also helps to write the goal: submitting a wording and asking under what condition one would know it had been reached brings out the goals that do not close.

A spike exists to produce evidence on the technical stack of the team, with its versions, its volumes and its data; a model describes a library as it stood in its training data, and it invents interface options with the same assurance it cites real ones. The answer counts once the code has run on the team's own machines. The estimate that follows stays the estimate of the team that will deliver.

A spike often handles what the organisation holds most sensitive: internal code, interface schemas, sometimes production data pulled out to reproduce a case. This material does not go to an external service without the use being covered; the Federal Act on Data Protection (FADP) applies to personal data sitting in a test data set as it does anywhere else.

Examples

A team at a payment company in the canton of Vaud puts into the backlog the reconciliation of QR-bill payments with the entries of the core system, through an ISO 20022 interface it has never integrated. Relative estimation stalls: the numbers proposed run from 3 to 13 points. The team opens a technical spike. Its card reads as follows in the tool, completed at closing.

The developer sets up a separate repository and runs the already licensed library over a batch of camt.054 credit advices, the ISO 20022 message by which a bank notifies the entries booked to an account, drawn from the test environment of the company's account bank. The simple advices pass with no intervention. Partial payments return amounts the reconciliation does not explain, and payments carrying a SCOR reference come out with no key to trace the original invoice. She writes a trial parser for those two cases, measures what it would take written properly and stops at the sixteenth hour. A third case spotted in the batch, the grouped advices, was not looked into: the duration expired before the list of questions was exhausted.

The row of the card that carries the most is the last: the item leaves the entry "unknown" for 8 points, which is what the outlay was for. The 16 hours return no deliverable line of code.

Visualisations

A spike is visualised first through its own backlog card: two columns that fill in two passes, the goal and the duration at the opening, the answer and the decision at the closing. Kept over several iterations, this series of cards shows where the team loses its capacity to research and whether the same unknowns come back.

The sequence is drawn as two parallel lanes. The upper lane carries the ordinary flow, from the backlog item to the work of the iteration and then to the deliverable increment. The lower lane starts from an item the team cannot estimate, crosses a box of fixed width carrying the goal and the type, then rejoins the backlog by returning an estimate. No arrow links the lower lane to the increment.

Cost

Tooling

The throwaway environment carries the technical spike: a separate code repository, a sandbox at the interface provider, a container set up for the occasion. Separation from the repository of the product is what makes the code of the prototype impossible to ship by accident.

The backlog management tool (Jira, Azure DevOps, GitLab and their equivalents) takes the spike as an item in its own right, with a type of its own or a label. The budget in hours is recorded there; the answer and the re-estimated item stay attached to it, which is what lets someone find out six months later why a number was settled on.

The specification of the provider and the sets of sample messages decide the quality of the answer, as much as a measurement taken on the actual volumes of the organisation. A spike closed on documentation read returns an opinion; a spike closed on code executed returns a fact.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.16 Spikes: the purpose of the technique, the trigger of an item impossible to estimate, the exploratory character and the exclusion of the deliverable increment, the two elements that are the goal and the type, the duration fixed inside one iteration, the three types functional, technical and exploratory, along with the strengths and limitations stated there, among them the focus the duration brings, the mutual knowledge at the start of team formation, the duration too long or the item too large, the misuse of the term for follow-up conversations and the too-frequent recourse that signals failing refinement.
• IIBA, Agile Extension to the BABOK Guide, §7.0, table 7.0.1 Selecting the Right Technique: the spike listed among the requirements management techniques, on the internal-team side.
• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition, Addison-Wesley, 2004: the origin of the term and the spike solution, a minimal program built to answer a design question and then discarded.
• Mike Cohn, What Are Agile Spikes? When and Why Do Teams Use Spikes?, Mountain Goat Software: a practitioner's catalogue, not normative; the spike itself sized in hours, the order of magnitude given as an example and the rule that keeps it for extreme uncertainty.