The idea of putting a timebox around a spike is really good. Then the spike is done whenever you get an answer or the timebox runs out, and "We don't know yet" is an acceptable answer. That clearly distinguishes spikes from other development stories.<p>So often, our development stories depend on assumptions about how/if a new technology is going to make the change we want to make work. It might not work, and estimating with unfamiliar tech is really hard.
Nice article, thanks for sharing.<p>In addition to the great information you've provided, we identify features/decisions/choices that require spikes based on assessment that they are high risk and/or we have low confidence in our estimate. In addition, we sometimes use spikes to break xxx-large estimates into smaller pieces.<p>That way, until a project/plan/item has low (enough) risk, and high (enough) confidence, it needs more spikes.<p>We've found this model is a great way of identifying what needs spiking, and when a spike is 'done'. And, it also helps to ensure spikes don't end up consuming too much time.<p>Hope this is useful.
Following this approach is very effective for getting R&D credits in Canada. Documenting your process in a lightweight manner like this helps tremendously.