In my previous article “Spike 101” I introduced the concept of Spike and it’s general use in Agile. In that article we saw that:
- Spikes are investigation activities -e.g: research, design, investigation, exploration, prototyping- to gain the knowledge to solve a problem.
- As Scrum doesn’t prescribe any particular type for Backlog Items, it is up to the team to decide wether they Spikes useful or not.
- Spikes shall have ACs, are time-boxed and should be estimable, demonstrable, and acceptable.
In this article I will provide further details and suggestions to make the best use of this practice and avoid pitfalls.
Different type of spikes
Often Spikes comes in these 2 forms: functional and technical.
Functional spikes are used to analyse overall solution behaviour and determine:
- How to break it down
- How to organize the work
- Where risk and complexity exist
- How to use insights to influence implementation decisions
Technical spikes are used to research various approaches in the solution domain and aim to:
- Determine a build-versus-buy decision
- Evaluate the potential performance or load impact of a new user story
- Evaluate specific technical implementation approaches
- Develop confidence about the desired solution path
What is the difference between Spikes and Tasks?
(Engineering) Task or “Dev Stories” (in a pre-Jira project) – represents a set of engineering work that is not directly related to a user story. The team should try to anticipate “Dev Stories” and add them to the backlog sooner than later so the PO can plan milestones.
Examples of engineering tasks are:
- Setup Github project repo.
- Setup Cloud account, containers, and services. There might be sub-tasks for these too
- Setup Jenkins CI pipeline.
- Design overall high-level system architecture.
- Research and decide on unit test and mocking framework.
Spikes are the Exception, Not the Rule
Every user story has uncertainty and risk; that’s the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Thus, in one sense, every user story contains spike-like activities to identify the technical and functional risks. The goal of an Agile team is to learn how to address uncertainty in each iteration. Spikes are critical when high uncertainty exists, or there are many unknowns.
If you are using Jira to manage your product backlog, you may not have by default the “Spike” issue type. Here a guide on how to add new types.
Spikes at glance! How to get them right?
- The time and energy invested in the Spike are intentionally limited so that the work can be completed within the Sprint while other User Stories are minimally impacted.
- You may consider a spike as an investment for a Product Owner to figure out what needs to be built and how the team is going to build it.
- The output of a Spike should be an answer to the question being posed. If the experiment is more difficult than anticipated, then maybe the answer is negative. That’s why the Spike should be limited in time.
- Since spikes do not directly deliver user value, use them sparingly.
- Since they represent uncertainty in one or more potential stories, planning for both the spike and the resulting stories in the same iteration is sometimes risky. However, if it’s small and straightforward, and a quick solution is likely to be found, then it can be quite efficient to do both in the same iteration.
If we knew what we were doing, it wouldn’t be called research.
Albert Einstein
Other benefits of Spikes
Spikes encourage break down problems in small batches separating the unknown-unknown part of the problem from the rest.
Spikes explicitly support innovation, research, experimentation while
time-boxing allow this in transparent, safe, time-costly controlled way.
Would you like to know more about Spikes?
Here some useful resources:
- Mountain Goat Software Spikes
- Scrum.org Forum How to Integrate a Spike
- Scrum Alliance Spikes and Effort-to-Grief Ratio