I'm just going to say it. Most so-called 'spikes' do not belong on the Product Backlog.
What is a Spike?
Spikes come in multiple flavors. There are research spikes, which is essentially Refinement by another name. And there are technical spikes, which could involve time spent by Developers to size items in the Product Backlog, or time spent researching a new technology or similar types of work.
Often, when I hear a team talk about doing a 'spike,' what they are really doing is creating Product Backlog items to justify their time. For example, I've seen individuals on the Scrum team with business analysis skills create Product Backlog items that simply state "Documenting User Story xyz."
Alternatively, Developers sometimes create separate Product Backlog items labeled 'research,' which is just time spent figuring out how to develop a particular Product Backlog item in the future.
That's a lot of busywork!
Refinement is part of the work of the Scrum team. Creating tickets to prove that the team is working is counterproductive because creating those tickets takes time and focus away from maximizing value delivery.
Instead of creating Product Backlog items to show how busy they are, teams should understand that it's okay to spend some of their time on Refinement and leave it at that. Developers should move away from proving their busyness and, instead, the organization should focus on value.
Focus on Value Instead
Rather than measuring how busy everyone is, the organization should align around value and measure customer outcomes.
Alignment starts with having a great Product Vision, which describes the desired future state of the product. Additionally, the Product Owner should create a Product Goal, which serves as a specific target for the Scrum team to plan against or a concrete step toward the larger Product Vision.
Outcome-based metrics should be identified to measure progress against the vision. Is the vision to increase sales by 50%? Then the Product Goal might be to streamline the checkout process to decrease shopping cart abandonment. Outcome-based metrics, such as the percentage of shopping cart abandonment, should be tracked to measure progress against the Product Goal.
Conclusion
By keeping spikes out of the Product Backlog and managing them within the development workflow, teams can maintain a clear focus on delivering value to users while still addressing the necessary exploratory and technical work to support future development.
To learn more about outcome-based metrics, signup for the Evidence-Based Management course.
If you want to really coach a team on the true use of a Spike, challenge them to start the implementation immediately after the time-boxed Spike is complete. Most Spikes should not take an entire sprint. I rarely let them go past 1-2 days. But, in most Sprint Planning meetings when Spikes are introduced, teams naturally schedule the work for the following Sprint. When I suggest we start immediately after completion of the Spike you tend to have some meaningful discussions on whether it was really just an excuse for continued analysis (which they intended to drag out for the length of the Sprint) or if the intentions was to arrive at an answer quickly so we can mov…