How We Do Spikes

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 &quot;We don&#x27;t know yet&quot; is an acceptable answer. That clearly distinguishes spikes from other development stories.<p>So often, our development stories depend on assumptions about how&#x2F;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&#x27;ve provided, we identify features&#x2F;decisions&#x2F;choices that require spikes based on assessment that they are high risk and&#x2F;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&#x2F;plan&#x2F;item has low (enough) risk, and high (enough) confidence, it needs more spikes.<p>We&#x27;ve found this model is a great way of identifying what needs spiking, and when a spike is &#x27;done&#x27;. And, it also helps to ensure spikes don&#x27;t end up consuming too much time.<p>Hope this is useful.

Great article! What did you end up replacing the asset pipeline with?

Following this approach is very effective for getting R&amp;D credits in Canada. Documenting your process in a lightweight manner like this helps tremendously.

I found this very helpful. Thank you for the advice, Sophie.