Need to Learn More about the Work You’re Doing? Spike It!

[article]
Summary:

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.

User Comments

2 comments
Allison Pollard's picture

I love that your article includes what to do with the code afterwards because I've noticed some teams treat a spike like a chance to get a "head start" working on a future story rather than focusing on the learning.

May 26, 2014 - 1:28am
Johanna Rothman's picture

Hi Allison, thanks! Yes, I'm a firm believer that the spike is for thet learning, not a head start.

May 26, 2014 - 7:43am

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09