How to do a Research Spike
What do you do when you don't have enough information to confidently assign a level of effort to a user story? You know that you could size the story if you had some time to do research, but 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.