So you’ve been assigned a technical spike — where do you start? Completing technical research in a fixed amount of time can feel quite daunting. I recently worked on a spike to determine whether we should build or buy a calendar scheduling solution for my project. I had less time allocated than I would normally like to spend on something like this, so it was important to stay as organized and focused as possible. The following is my general process for tackling technical spikes.
Stage Zero: Prepare your tools.
Spikes are all about gathering information so you can decide how to move forward. The product of your spike is generally what you’ve learned during all of this research. So, to get the most out of that time, along the way, you’re going to need to take good notes, which you may need to deliver at the end of the spike. I use a combination of tools to capture what I’ve learned. A simple Google Doc provides the backbone, containing most of my notes. But, I also love to use a whiteboarding app (my favorite is Miro) to diagram possible software workflows. Sometimes I’ll incorporate a spreadsheet if I need to build a complex comparison matrix.
Stage One: Gather requirements (the what).
Now that your tools are ready, start by writing out your requirements. These should generally result from a direct conversation (or two) with your product owner, delivery lead, or other key stakeholder. Even if you’re starting from a well-documented ticket, try to get a few minutes with that stakeholder to discuss your understanding of the requirements and gain as much context as possible. Document not only what the software flow should do, but also what else your stakeholder will want to know at the end of the spike.
I like to isolate all these original requirements at the top of the document, without adding my own impressions or ideas yet. This keeps them straightforward and legible, and that, in turn, makes them easier to reference throughout my research.
Once I have my requirements written out, I like to start a new section containing my initial thoughts. Generally, this will be a stream-of-consciousness reaction to the requirements, incorporating any background knowledge I might have, questions I would like to answer, and thoughts on an initial software workflow. No judgment here, just brainstorm!
Stage Two: Scan the field (the who).
Now it’s time to get an idea of what’s out there. I start with a quick Google search to help jog my memory of anything I might have heard of or used in the past that could fit the criteria. G2 is a great resource for finding and vetting SaaS products that might align with your goals. If I’m looking for an open-source library, I take to npmtrends.com, which allows you to compare the relative popularity and GitHub activity of different packages. Once you have some interesting leads, try searching for direct competitors as well. This can be one of the trickiest parts of a spike, so if you have other favorite resources for finding software solutions, please share them in the comments!
As you gather options, start noting key features, pricing models, API availability, relative popularity, support, etc. I try to take notes that will help me directly compare each option, so this is a good time to start up a comparison table or pros-and-cons list. At this stage, I’m trying to get an idea of whether this option is worth a deeper look. For example, one lesser-known competitor I reviewed looked promising in its feature set until I peeped through the API docs and found that some of its key endpoints were completely undocumented.
Break: Check in.
You’ve done some initial research and are starting to get a lay of the land. If you haven’t already, now is probably a good time to check in with your stakeholder(s). Spend a few minutes discussing your understanding of the requirements and how the solutions you’ve found so far might fit in with that. Have the requirements changed since that initial conversation? Have you made any assumptions about the ideal solution that must be validated? Are some strong contenders emerging from the fray? You may be able to start eliminating some options at this point based on their alignment with the project goals.
Stage Three: Dive deeply (the how).
Now that you’ve identified some good options, dig in further. This is when I dive into architecting possible solutions using each of my top contenders. How would the user interact with software built using this solution? What ancillary UX would we need to make this solution work? How would we incorporate this into our existing codebase and architecture? Is there a GET or a POST available to do the thing I’m trying to do? What data can we use to refine a request, and what do we get out of the response?
Many paid SaaS solutions offer a trial membership that will give you access to their dashboards or test data. If time permits, test out the solution yourself with API calls in Postman or even a proof-of-concept branch in your app. Keep in mind that, in general, the goal of your spike is not to integrate or build the feature but to understand what the development process will be like in either case. Be on the lookout for potential pitfalls or deal-breakers that might have been difficult to assess until this point.
Stage Four: Summarize your findings and deliver.
Now, the time you’ve committed to this spike is coming to a close. Remember, the major goal of this spike was to gather knowledge and pass it on, so make sure you save time to synthesize your findings and organize your notes. There’s no right or wrong way to do this, but, at a minimum, ensure that your documentation includes a) requirements; b) options reviewed; c) how the options compare; and d) your recommendation for further action.
Due to the time-boxed nature of a spike, you may finish your research with more questions than a detailed path to development, and that’s okay! In that case, your recommendation will be to continue researching to uncover answers to those specific questions.
Apart from that, I like to keep the “raw data,” the notes I took along the way, intact. I like to know that anything that seemed important enough to write down will still be available for reference, even if it isn’t part of the deliverable documentation.
Strategies for Technical Spikes
I wrote this up as a linear process, with one stage following the other, but in reality, I’ve found it to be more fluid than that. Sometimes I’ll dip my toes into Stage Three while still early in Stage Two. However, I’ve found that keeping the mindset of defined stages can help me avoid going too deep into one solution before I’ve gathered a broad set of options.
What are your strategies for technical spikes? Please share in the comments!