Agile projects are, at their heart, undertaken to develop new functionality. In other words, we want to finish a project with more capabilities than when we began the project.
At the same time, teams and agile organizations also undertake a project to become smarter–to finish each project smarter than when they began.
Most work during a sprint will be directly related to building new features, and that is as it should be. It is also important, however, that Scrum teams plan for and allocate time for getting smarter. That's where spikes come in.
Agile Spike Definition
What is a spike? In agile projects, a spike refers to a time-boxed research activity that helps teams make better decisions & deliver better products. Put more simply, a spike is an activity a team performs to get smarter about something.
With a spike, a team isn’t trying to immediately deliver a new capability; instead, they are building the knowledge that will allowthem to deliver the new capability later.
Spikes are a concept adapted from Extreme Programming (XP). Spikes give agile teams the technical and functional information they need to make decisions about the best approach to certain user stories. Teams can then use this information to provide a more accurate estimate and/or deliver the most effective solution.
Spikes are a great tool, and I’d expect every team to use them...but not too often and certainly not on everything they work on. Overusing spikes is a common mistake.
Agile Spike Example
As an example of a spike, suppose a team is trying to decide between competing design approaches. The product owner may decide to use a spike to invest another 40 (or 4 or 400) hours into the investigation.
Or the development team may be making a build vs. buy decision involving a new component. Their Scrum Master might suggest that a good first step toward making that decision would be a spike into the different options available for purchase, their features, and their costs.
Because spikes are time-boxed, the investment is fixed. After the predetermined number of hours, a decision is made. But that decision may be to invest more hours in gaining more knowledge.
When to Use Spikes
So when should teams use spikes?
The best use of a spike is to reduce excess uncertainty. This could be uncertainty about how a feature should work or about how it will be built. A team may opt, for example, to spike the user interface for a particular feature. Or it may use a spike to determine if a technical approach is feasible or will perform at the required level.
Notice I said excess uncertainty. Spikes should be used only in cases of extreme or excessive amounts of uncertainty. Spikes should not be used to reduce the typical, garden-variety uncertainty that exists in all work.
Further, spikes should not be used to eliminate uncertainty. Teams need to be comfortable with uncertainty, with bringing work into their sprints or iterations with open issues remaining. (This is also one of the reasons why I prefer a set of ready rules to a definition of ready.)
Is your team reluctant to allow work into a sprint with any remaining uncertainty? That’s sometimes the result of team members feeling excessive pressure to estimate perfectly, to always achieve the sprint goal, or to always deliver everything that they brought into a sprint.
If that is happening, a Scrum Master or coach needs to work with outside stakeholders or whomever is creating these unrealistic expectations. Sometimes it’s even the team members putting this pressure on themselves.
How to Prevent Excessive Use of Spikes
Spikes are a great tool for agile teams. However, one of the more common mistakes I see teams make is relying too much on spikes.
Why is this a problem? Because overuse of spikes extends your time to value. This is especially true when the spike is done in one iteration and the rest of the work in a subsequent iteration.
Overuse of spikes also reduces the extent to which teams overlap work. This can increase the burden on testers.
For example, consider the case of a programmer who uses a spike to reduce the uncertainty of a backlog item. If that item is brought into the next sprint, the programmer’s work has been made simpler by the spike, but the tester’s has not.
If your testers are struggling to keep current with the programmers, consider whether the team is doing too many spikes. It’s a good question to ask yourself even when the testers don’t seem overburdened, if you want to succeed with agile.
Spikes & Backlogs
Where do spike stories live? Some agile software development teams opt to put a spike story on the product backlog along with user stories. Other teams take the approach that a spike is really part of some other product backlog item and will only expose spikes as sprint backlog items.
However you treat them on your backlogs, spikes are an essential way for agile teams to acknowledge the importance of learning in a successful project.
Spike results can give teams the information they need to move their product development effort forward successfully. Just be cautious that you use them sparingly, and only in times of excess uncertainty.
