Comparison
Known unknownsvsSpike
Known unknowns
you could list what you did not know about the vendor's API, and that list was the plan.
The risks you know you have not resolved yet, as distinct from the ones you cannot see at all. The useful move in planning is to make the first list explicit and attack it early with spikes, because a known unknown is schedulable and an unknown unknown is only survivable through slack. A plan that contains no known unknowns has not been examined, it has been asserted.
Full entry →Spike
you spent two days finding out whether the library could do it at all, and threw the code away.
A timeboxed piece of work whose only deliverable is an answer to a question. The code is explicitly disposable, which is the part teams get wrong when a spike quietly becomes the foundation of the feature. It is the standard tool against a known unknown, and the discipline is the timebox: a spike without an end date is just an unplanned project.
Full entry →