Master the terminology behind time-boxed technical spikes and investigations.
0 / 5 completed
1 / 5
At standup, a dev proposes spending a day investigating an unfamiliar library before committing to a real implementation plan. What is this time-boxed investigation called?
A spike is a time-boxed investigation aimed at reducing uncertainty, such as evaluating a library's feasibility, before committing to a full implementation. It produces knowledge rather than shippable code. Time-boxing keeps exploration from silently expanding into unplanned work.
2 / 5
During a design review, the team debates whether a spike's exploratory code should be reused directly in production. What is the usual guidance?
Spike code is typically written quickly to answer a question and is considered disposable, lacking the testing, error handling, and polish expected of production code. Reusing it directly risks shipping fragile, under-tested logic. The standard guidance is to rewrite properly once the spike's findings inform a real plan.
3 / 5
In a code review of a spike's findings, a teammate asks what concrete outcome the investigation produced. What should a good spike deliver?
A well-run spike should conclude with a documented answer or recommendation addressing the original uncertainty, such as "this library supports X but not Y." Without this, the time invested doesn't translate into decision-useful knowledge. The deliverable is understanding, not necessarily working software.
4 / 5
An incident report notes a project stalled because a spike ran indefinitely without a clear stopping point. What practice would have prevented this?
Spikes are meant to be strictly time-boxed, with an agreed cutoff after which the team reassesses regardless of how much was learned. Without this boundary, open-ended exploration can consume far more time than justified. Setting the time-box upfront is the core discipline that makes spikes useful planning tools.
5 / 5
During a PR review, a teammate asks how a spike differs from a regular feature task on the sprint board. What is the distinction?
Unlike a regular feature task, which aims to ship working, production-quality functionality, a spike's goal is to reduce uncertainty and inform planning. This difference in purpose changes what "done" means: a finished feature versus an answered question. Confusing the two often leads to under-scoped estimates for genuinely uncertain work.