In a recent estimation workshop, one of the participants asked, “How do we estimate something we’ve never done before?”

“Is it a feature or a project?” I asked.

“A feature,” she said.

“How do you do things now?” Based on her previous comments in the workshop, I suspected she was pretty good at what she did.

“I take a little time, do a proof of concept, and then I know how long the rest of the work will take.”

That’s the general idea of a spike. You timebox a little work, do some research—just enough to know how long it will take to finish the rest of the work—and then you can estimate the rest of the work.

How Does a Spike Work?

I like to timebox the spike for these reasons: You don’t want this to become a research project that never ends. If you can’t gain some answer in a reasonable amount of time, that’s data, too. If you learn enough before the timebox is up, you can stop early. And you might want to explore in a different direction if you have extra time. Maybe you’ve only one tried one design and you want to try another.

But that leads me to my second point about spikes. When you have multiple people work on spikes together, you have options to explore multiple designs. You don’t waste time, and you learn together.

Spikes are for learning. There’s always a tradeoff between the time you spend learning and actually completing the work. The more time you spend learning, the closer you are to completing the work, so it’s important that you timebox the learning. You don’t want the learning to go on and on and on. . . . You might go off into uncharted territory and do something unrelated. No, in a spike you want to stay focused on the problem under research.

In the same way, because you are learning, you want to share that learning with other people. If you’re the only one who understands the proof of concept, you have to explain it in words. That’s where code or tests can come in mighty handy.

Back in the workshop, my participant described how she used a proof of concept to explain a particularly gnarly piece of security code prototype to a colleague.

“It wasn’t until we both got in there and went through it line by line that he understood it. By explaining it to him line by line, I understood it better, too. It’s almost as if we had a code review on it together.”

I asked, “What if you had paired on it?”

“That might have been even better. He would have had suggestions as I wrote it. I bet it would have been better.”

Spikes Are about Learning

Because spikes are about learning, it makes sense to use all of your learning techniques during them. I’m a big fan of pairing during spikes. When you work with another person, you may discover, as I have, that your work is different—and, often, better.

You might use TDD (test-driven development) also—not to make the code better, although that might happen. When you use TDD, you drive the design through tests. The tests inform your design. The tests suggest alternative questions and drive your learning.

You might also consider BDD (behavior-driven development) as an option. Again, this might make your code better, but that’s not the point. The point is to see what happens with your experiments and learning.

What Happens to the Code at the End of the Spike?

You’ve timeboxed your experiment. You have a proof of concept and you have a prototype or something you can show other people. They like it and say, “Wow, that looks great! Let’s use it. Pop it in the system and be done with it.”

Now what?

You have to say, “No, it’s a proof of concept; an experiment. It’s got holes a mile wide in it. It doesn’t account for all of these cases,” and then you name several. “It needs real testing. I did an experiment.” Maybe you even experimented with another developer or tester, but the code isn’t done. If you put that code into the system, you’ll create technical debt up the wazoo. What do you do?

You can throw out the code. You can use the code as a basis for real development. Or you can refactor the code to get to something reasonable. It all depends on where you start. Any of those will change the estimate of how long the rest of the work will take.

Whatever you do, you will need to estimate how long the rest of the work will take. But you have the learning from the original timebox. You have feedback from your users or product owner and part of your team. You know enough to explain to the team what this feature will take and where the risks are, or you know enough to do another spike.

“Use the Code As Is…”

After a spike, I bet many of you hear, “Use the code as it is. It’s good enough. You can refactor it in the future.” That’s enough to make anyone concerned about planning for spikes.

Your code might be quick and dirty because you planned to throw it away. Your code might be a small proof of concept that is very narrowly implemented and would be very hard to refactor. You could do it, but the cost would be high.

The idea is that you use the learning from your spike, not your code. If you can use your code, great. But that’s not the goal.

How Many People Were Involved in the Learning?

The real question is this: How many people were involved in the spike? The more people in the spike, the more people were involved in the learning—and the more easily those people will be able to estimate the real work.

A couple of years ago, I consulted to a team about a difficult performance issue. Because their entire product was based on performance, they weren’t sure what to do. They thought it was a process problem, which is why they asked me to help.

In a sense, it was. I suggested they spike their problem and spend no more than one day as a team researching it. When they met the next day at their standup, they each had much more data. Now, they could begin formulating a solution.

They developed three candidate algorithms as developer pairs. That took two days. They developed five different test scenarios as a team, then automated the tests in tester-developer pairs. That took them two more days. They could now spend one more day running the tests against their candidate algorithms.

After one team-week, they had an answer. It was not the answer they expected, but they had the data they needed to know how to proceed. The entire team had been involved, so when the product owner said, “Just use the code,” the entire team could say, “No, we need to evolve the design and the tests,” and explain why.

Spikes aren’t for everything. But when you need to do research and discover what’s going on, they work. Put them in your estimation toolbox and see what you learn.