What to do when you don't know what to do

The last story that I was working on required me to do some animation in Java3D, which I didn't how to do. So, I did a little Spike to learn a bit more about what was involved with that, and I finally finished up the story. With this on my mind, I thought I would spend some time talking about Spikes.

I think Spikes are one of the most misused parts of Agile. The general understanding of a Spike is that it is a research story. If you have questions about how to do your User Story, you spend time researching or spiking the questions that you have. I've seen different teams handle Spikes in different ways. The worst I have witnessed are spike stories that drag on from iteration to iteration. After a time, when something is finally delivered, it's not in a state that is usable, but too much time has been spent on it, so it winds up being put into the code base with no tests, no pair programing, etc. The best use of a Spike is to only use it when you don't know enough to estimate the story, then you spike until you know just enough to do the story. Any code that you write to answer those questions are considered "spike code" and you throw it out.

One really good practice to get into to avoid spike abuse is to always have your Spikes be time-boxed. You set a limit on the amount of time you will spend researching. Once that limit has been reached, the team can then review whether or not they need more time or need to possibly take a different route. If you can't learn enough within a day or so, to estimate, you really should reevaluate if that technology is worth the time. If an off the shelf product takes a week's worth of time to "spike" so that you know how to use it, maybe a simpler approach that doesn't involve that product is the better approach.

I've worked with some people that use the term "Spike" to justify taking a long time to writing crumby code that is meant to be used as a prototype. Truth is, that when they finally get to the point that they can write that code, they know enough to estimate the actual story and then begin working on it. Time spent on a spike after you have answered your question is no longer time that should be spent on spiking, but time spent working on the story.

I've also heard the phrase "architectural spike," which boils down to taking entirely too much time to write up a document to give to the team (that they'll probably never read) describing the solution with many charts and diagrams. And to me, that just goes against the concept of letting your tests drive your code and letting the design emerge from your refactoring.

So to recap, spikes are suppose to be a time-boxed (maybe a day) research efforts that answer enough questions so that you can estimate a story. Anything else, should be your standard test driven development based on satisfying acceptance criteria on your user stories.