Your team has been working together for several sprints. Things are going fairly well. You're delivering stories each sprint and the product owner is content. But there's always technical debt accumulating, or a problem lurking in software. How do you know when your team should tackle something that purely focuses on addressing some technical issue, instead of delivering a market-facing feature to the user? When do you need a spike?
What's a spike?
First let's start with a definition of a spike. There are many out there, but here's a simple one from the Agile Dictionary: A story or task aimed at answering a question or gathering information, rather than at producing shippable product.
In practice, the spikes teams take on are often proof-of-concept types of activities. The definition above says that the work is not focused on the finished product. It may even be designed to be thrown away at the end. This gives your product owner the proper expectation that you will most likely not directly implement the spike solution. During the course of the sprint, you may discover that what you learned in the spike cannot be implemented for any practical purpose. Or you may discover that the work can be used for great benefit on future stories. Either way, the intention of the spike is not to implement the completed work "as is."
There are two other characteristics that spikes should have:
- Have clear objectives and outcomes for the spike. Be clear on the knowledge you are trying to gain and the problem(s) you are trying to address. It's easy for a team to stray off into something interesting and related, but not relevant.
- Be timeboxed. Spikes should be timeboxed so you do just enough work that's just good enough to get the value required.
Indications a spike may be needed
It may not always be obvious that you need to take on a spike. Here are some indications that your project team could benefit from spike work:
- Trouble estimating
- Your team is having trouble estimating stories effectively. Lots of dissension and differing opinions on how big certain stories are. This can lead to . . .
- High point estimates
- Your story point estimates are very high for what the product owner sees as easy items. The team sees much more work than is immediately apparent. This could be an indication that there's technical debt or something that the team is working around to try to deliver stories.
- Patterns of difficulty
- Stories from specific areas of the application are consistently late or difficult for the team to complete.
- There are lots of bugs and QA items from certain types of stories.
- There's a pattern of feedback from retrospectives in which the team refers to difficulty with a technology or implementation used.
- The team speaks out
- Your team flat-out tells you that there's a problem and it has to be fixed or else.
- More subtly, the team seems worried about creeping technical issues. You may start hearing rumblings during planning or retrospective meetings. Is the platform scaled well enough?
Scrum teams are supposed to be self-driven. Sometimes they need empowerment and guidance with spikes. They may feel guilt taking time away from market-facing features to work on something that may never be delivered. The product owner may indirectly discourage this type of work. You, as the ScrumMaster, need to empower them to declare what needs to be done and assist them in advocating for this work with the product owner.
Where to find the spikes
- Has the team already told you what needs attention? Are there backlog items that are labeled with technical debt? Many teams will express what needs to be done.
- Are there backlog items that keep getting pushed to the bottom by the product owner because he or she doesn't understand their value?
- What are your team's pain points? Do they have the same problems sprint after sprint in completing stories or certain types of stories?
- Is your software deployment process difficult? If so, where is it in need of attention?
After you've gone through this exercise, you'll probably find several candidates for spike work. Unless you stop the presses, you can't do them all at once. To help the product owner find the nuggets, I do an exercise with the team to determine the effort-to-grief ratio.
Items causing the most grief to the team should be looked at as top candidates. Host a session with the team to get them to express issues that are causing grief. Have them rank the items on a scale of 1 to 5 (1=low pain, 5 = high pain). Finally, get the team to size the effort to work on a spike that can help them learn or understand how to solve the problem. Then lay out those items in a table similar to the one shown below:
Looking at the items this way will make it immediately clear which spike candidates are the best choices for inclusion in your upcoming sprints.
You may notice that the effort/point scale does not show stories in the 1-point range. Small issues causing your team pain should be quickly researched and handled without question. Product owners should not protest small research items, and your team should be empowered to handle them on their own during sprints.
Spikes can be very useful during the life of your project. They can be especially useful early on, when your team is still getting comfortable with the technology and with each other. Teams need a way to determine how to come up with proper stories and solutions for the project where the tool or technology is not well known. They give your team permission to spend time on value-driven research. They're a good tool to have in your arsenal to find out if something is possible or not.