Pointing spikes. It’s a hotly debated topic in the world of agile software development. Both sides of the do-or-don’t argument have solid reasoning behind their stance. But there is one thing that everyone agrees on: spikes are a necessity.
What is a spike, anyway?
A spike is a task aimed at answering a question or gathering information, rather than at producing shippable product value. As Kent Beck of XP (Extreme Programming) explains, “A spike solution is a very simple program to explore potential solutions.”
As developers, we often have questions about user stories, like, Why do we need to build this? What do we need to build? and How can we build it?
In any sort of software development, you won’t know the answers to some of those questions, for some of the stories. Sometimes, there are so many unknowns in a given user story that it’s difficult to provide anything close to a reasonable estimate.
In these cases, conducting a spike can help to better understand the level of effort required to complete the user story, and/or can help solve a design problem.
Given the usefulness of spikes in the development process, it is likely that sprints will contain a mix of stories and spikes. Which brings us to the real question: Should developers account for spikes in a sprint?
The short answer? It depends.
To better understand how pointing spikes might impact your planning, let’s take a look at both sides of the argument: Do Point Spikes and Don’t Point Spikes.
Why Do?
Time and effort always need to be visible to the project, which means that your team's velocity—in this case, the points delivered per sprint—can be negatively skewed if using a lot of spikes in the sprint that aren’t associated with points. The effort you’re putting into a spike takes away from time that could be spent on another story during the sprint, without a way of recording the value that spikes provide. In the case of spikes, value isn’t usually direct user value, but rather documentation, increased team knowledge, or improved design, which in turn help you deliver greater user value later.
Why Don’t?
However, the lack of direct user value is exactly why those who are against pointing spikes are…well…against pointing spikes. While a spike does have clear indirect value, and the knowledge gained from conducting a spike can be applied to more than one story, spike valuations are not the same as user story valuations. User stories can be estimated based on things like volume, complexity, uncertainty, and knowledge, while spikes don’t have all of those characteristics. If spikes are pointed the same way as user stories, the value that you deliver at the end of a sprint won’t be correctly assessed.
Showing time and effort on any project is important. So, which approach should you take when it comes to pointing spikes? Luckily, the world of Agile is very situational. It's kind of like the improv show, Whose Line Is It, Anyway?, “where everything is made up and the points don't matter.”
My advice when trying to decide whether to point spikes… ask your team a few key questions, including:
- What do the points mean?
- What are the points used for?
Each team has its own way of planning and accounting for capacity. Each team has its own way of measuring value. And each team uses measurements, whether story points or something else, for different purposes, such as predicting certain features or milestones. Deciding whether to point spikes really does depend on how your team is using points. Understanding this first can help point you toward the choice that works best for your team, for that particular project.
One way to approach spikes is to timebox them, rather than using the same point system as a user story. My team recently used this method on a customer project, when we were doing refinement for a sprint in which there were a lot of spikes but not a lot of user stories. While we considered pointing spikes to ensure high velocity, we ultimately decided to keep story points separate from spike points. Instead, we timeboxed spikes, associating spike points with a time interval (e.g., hours or days) and limiting the number of spike points that we could assign per sprint. This way, our story points continued to represent the user value that we delivered per sprint and our stakeholders were able to continue using our story points to understand when certain features were going to be delivered, or at least comfortably expected.
A colleague of mine offered a word of warning about this approach, though: for it to work, points have to mean something different from solely temporal effort. Else, you risk assessing spike points in exactly the same way as user story points, which defeats the purpose of this mixed approach.
Brian Lam
