Home > Articles > How to do an Agile Research Spike

How to do an Agile Research Spike

Want to receive these updates in your inbox? Sign up for my mailing list using the form on the right. (or below if you're reading this on your phone)

What do you do when you don't have enough information to confidently assign story points to a user story? You know that you could size the story if you had some time to do research, how do you know how long the research will take? And how do you prevent the research from spiraling out into irrelevance?

With a Research Spike, you force yourself to stay laser-focused on a single question, and build in a mechanism that keeps the research from droning on indefinitely.

How To Do a Research Spike

Create a new card on your development board, and put these 5 questions on it:

  • Which feature is this spike in service of?
  • What specific question needs to be answered in order to reduce uncertainty?
  • How will you go about answering that question?
  • How will you know when you are done?
  • Time boxed at: X hours

I know, I know. That's four questions and a statement. Regardless, each of these bullet points serves to keep your research focused on a pre-defined goal of reducing a specific element of uncertainty. Answer them in as much detail as possible before you begin your research.

Which feature is this spike in service of?

This is an easy one. It's not a trick question. Answering it here on the card makes sure the research retains its context. This is especially helpful if the research won't be started right away.

What specific question needs to be answered in order to reduce uncertainty?

For example, maybe you're not sure whether you can perform a particular task with some 3rd party API. Identify the most valuable piece of information that you could generate or uncover, which will make it reasonable to size the original card and begin work.

How will you go about answering the question?

State your preliminary ideas for where you'll start your research. This needn't be comprehensive, but should show some forethought. For instance, in the case of the 3rd party API example above, you might say Begin by consulting api docs at dev.someapi.com/docs. If it can't be reasonably determined through docs alone, attempt to build a minimal prototype

How will you know when you're done?

This is critical. Just like standard user stories have acceptance criteria, you need to know when you've achieved your goal. It's too easy once you're in research mode to keep going and going. You might start fleshing out your prototype into a half-built feature, or you might start researching other things that catch your fancy. The purpose of the spike is to quickly reduce uncertainty so you can get back to the user story. For this reason, you define your end state up front, and when you reach it you STOP.

Time Box: X Hours

It might take a lot longer than you think to answer the question. Put a time box on your spike of some reasonable number of hours. When you reach the time limit, even if you haven't yet answered the question, STOP. You still may have learned enough to proceed with the original user story. Present what you've learned to your team, either in the moment if it seems reasonable, or at the next standup. Together as a team decide whether you now have enough information to size and begin work on the original user story. If not, give your spike another time box and do it again. It may even make sense to revise the guidelines of the spike.


Research spikes deliver value to your product in the form of reduced uncertainty, and better planning of upcoming user stories. Use them to your advantage whenever you're staring down a story where you aren't sure how to proceed.

Ben Wilhelm

Do you want to introduce an Agile workflow to your team, but you're not sure where to start? I can help.

Sign up for my free 5-day email course detailing a minimal agile setup for small to medium teams.
"What we got from Ben was more than just expertise: it was expertise plus organized thinking, clear communication, good humor, and an obviously habitual willingness to listen before advising. We recommend him without reservation, and look forward to the next time we work with him ourselves."

Work with Me

You want to ship quality software consistently? You want to confidently tell your stakeholders when you'll reach the next development milestone? You want a tight-knit, self-organizing team that takes initiative so you can focus on long-term strategy?

I want these things for you too. I've helped other teams achieve them and I can help you.

For your convenience, I'm offering my best consulting services as low-risk, fix-priced packages. If you don't find a package that meets your needs, drop me a line at [email protected] to discuss a custom engagement.

1-Hour Strategy Call

Sometimes you just need the right advice at the right time. A Strategy Call can be just the ticket.

Find Out More

Individual Coaching

I'll meet with you 1:1 each week to help you build and execute a plan for improving your team's output.

Find Out More

Full Team Consulting

I work directly with your entire team to build routines that deliver results.

Find Out More