WIP: What is a Research Spike?
Recently we've started using the term Research Spike to capture the research work to be done on an issue before it can move to the build phase. I think it would be helpful to align on a definition of what a Research Spike is and what the outcome should be.
Background
The GitLab Product Development Flow describes two tracks in which work gets done - Validation & Build.
A Research Spike is part of the Solution validation phase:
- Validation
- Validation backlog
- Problem validation
- Solution validation <-- Research Spike
- Build
- Plan
- Develop & test
- Launch
- Improve
Purpose
The purpose of a Research Spike is for Product, UX and Engineering to allocate time to work through the proposed solution at a more detailed level and make a determination about the technical complexity, risks, and user impact of the proposed solution before beginning the build phase. There are 3 potential outcomes from a research spike:
- Move Forward - the proposed solution is well understood and any major concerns or risks have been addressed
- Revalidate - the research spike uncovered additional information that requires additional problem or solution validation, or the research spike determined the proposed solution too complex or impractical
- More Research Required - more time is required to make a determination, or research was blocked due to an external dependency
Process
- Assign Participants and a DRI - when begining a research spike, all of the necessary participants should be assigned to the issue. In many cases this will be UX, Frontend, and Backend, but depending on the feature, this could also involve individuals from other teams such as Quality, SRE, Support, or any other product team the feature may overlap. Once the group is determined, a DRI should also be assigned.
- Identify Unknowns, Risks, and Challenges - each participant should review proposed feature and provide detail on any unknows, risks or challenges they perceive within their functional area, and based on their understanding of the product area. All of these concerns should be added to a checklist to be tracked in the issue. Once completed, that list should be groomed and prioritized.
- Investigation - each item on the list should be investigated and the results should be captured or documented in some way. This could be a simple as a comment in an issue with a link to some part of the code, or it could be captured in another issue. For more complex investigations, building a prototype may be necessary. In this case linking to an MR or code sample would be appropriate. It is important to note that during the investigation step, it is likely that additional unknowns, risks or challenges will be identified. In that case they should be added to overall list and investigated as well.
-
Conclusion - when all the investigations have completed, the participants should be able to make a determination about the outcome of either
Move Forward
,Revalidate
, orMore Research Required
. If the outcome of the research is toMove Forward
, the particpants should work with PMs and EMs to define a development plan for the feature. This will result in one or more issues for the engineering team to work on in upcoming iterations.