How do you estimate work you've never done before? One proven method is to spike it: 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. You don’t waste time, you can explore different avenues of how best to complete the task, and your team learns together.
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.