One of the most typical problems we will find during the execution of a sprint are the spike tasks. They are by all means necessary, but… should they actually count as part of the team capacity, therefore provide them with story points? Or is it just a fake way to inflate our velocity?
A spike is a piece of work that requires investigation in order to define an assessment or achieve an outcome.
I can see why many teams do add story points to spikes. After all, it’s time and effort from a team resource. However, spikes do not have complexity, just research time. With that in mind, how can we add relative story points to spikes since you can’t compare them? The very existence of a spike means you are trying to discover knowns within unknowns.
Spikes are a controversial within the Scrum framework. In an ideal world, we never do spikes. These should be covered by backlog refinements. But sadly, this isn’t always the case. Time and effort is needed to understand the nature of an upcoming piece of work. What’s the best technology to use? How do I create that database structure? What are the necessary steps so we can implement that security feature and what risks will I find?
I’ve done research for quite a long time about sizing spikes, and I’ve read almost everything you can think of in favour and against it. And I have been forced to accept story points within spikes as well in my work position in quite an inconsistent way in the past.
My view? Yes, we should be able to include spikes within our sprints where needed. Should we size them with story points? Absolutely not. We need to timebox them, but never add complexity to a task that is simply and purely investigation. Nothing else.
Now, if your team isn’t making time estimations to stories, you have a problem. Stories should have story points as well as time estimations (I will elaborate a bit on that later), but spikes should only have time estimations.
Imagine you have a sprint with ONLY two user stories and one spike, three issues in total. Unrealistic, I know, but this is a good example.
- One of the stories has one story point, and its subtasks (coding, QA, documenting, etc.) have been estimated in one day.
- The other story has three story points, and its subtasks have been estimated in four days.
- The spike doesn’t have points at all, but it’s subtasks have been estimated in two days.
Remember: these times are estimations. We do them because we want to improve in our estimates, but these times are not deadlines. Can take less, can take more. Accuracy, but not precision.
With these stories and spike, we have a sprint with 4 story points, and a length of 6 days. No points for the spike, but we do have the time it takes for our sprint estimations. Because, in order to understand a team’s capacity, three factors are essential to get the full picture:
- Velocity trend (average)
- Focus factor (Availability of the team – Available time vs Ideal working hours)
- Confidence level
Each one of these factors are just one dimension, useless if used individually, very powerful if combined.
When it comes to the spike itself, it is important to remember that its outcome will likely be one or several user stories, to which we will end up adding story points in future sprints. Or at least will let us identify pieces of work needed or not needed, contributing to a better agility in the backlog definition and work to be done.
I strongly recommend this brilliant article by Jeremy Jarrell regarding spike estimations. It’s the closest to my actual belief. But hey, who am I to disagree if you use spikes in your teams with story points?
I simply challenge you with my reasoning before: how do you compare spikes in terms of relative complexity? It doesn’t make sense, when you come to think about it.