I had this tagged for a blog post for quite a while now and since we had a similar situation come up in sprint planning for the ED tool yesterday this is a great time to post on it. Basically, the users wanted excel like row and column locking on a webpage. We have not done this in our tools before and thus our controls do not natively support it. In order to determine how long it will take and how feasible it is we timeboxed a spike effort to determine the level of effort to accomplish that, as well as what backup solutions may look like.

Spikes represent uncertainty and risk. Andrew Fuqua summarizes this very well in his article “What’s a spike, who should enter it, and how to word it“.

Spikes represent uncertainty. If our backlog is full of spikes, that means that our backlog is full of stuff we don’t know how to do. If our backlog is full of stuff we don’t know how to do, our product delivery process isn’t going to be stable. It means that we have no business making commitments at the release level, because we don’t have a credible plan for getting to done.

At the end of the day it is all about communication. The product owner needs to understand how long something will take so that they can make the appropriate decisions on what will provide the end users the most value. They get that information from the delivery / development team.

This is why I like to timebox spikes. After the set period of time the product owner can be made aware of what was discovered, what is still unknown, what the risks are, an estimate based on the approach. Using the information gathered during the spike they can make an informed decision as to whether to spend more time learning / removing uncertainty, proceed based on what we found out, or pursue an alternate course.

Have you used this approach on your projects? If not how have you handled uncertainty on your project?

Let us know in the comments below.