Stop Estimating Spikes!
One of the most common question that teams face when first working with user stories is how to best approach estimating spikes. Luckily the answer is simple...don't.The whole point of spikes is to help us learn more about stories that we don't yet know enough about to estimate well. This very unknown nature means that estimating the spike itself would be fruitless. Instead, our goal is to learn enough during the spike that we can estimate the associated story in an upcoming sprint.
Do Spikes Still Count Towards Our Velocity?
Whether a spike still counts towards a team's velocity is a hotly debated question. After all, if a spike isn't estimated then how could it? To answer this question we must first understand that although we don't estimate spikes...we do timebox them.
Timeboxing Spikes
Each of our spikes should be timeboxed, in story points, and that timebox should contribute to the team's velocity for that sprint. For example, if we decide that a certain spike should be timeboxed to 3 points then we count that 3 points towards the team's forecasted velocity for that sprint. This is important because if you're tracking historical velocity to help better predict what the team can accomplish in future sprints, then deducting the time spent on those spikes will skew your velocity which unnecessarily complicates those measurements.
We do this since while a spike may not produce something as tangible as a feature story for a sprint, it may produce value which ultimately benefits the customer...assuming it ties directly to a slated story. In this way, a spike contributes business value in the same way that the first iteration of a particular UX design contributes business value...i.e., it provides useful knowledge that helps improve later versions of the feature, even if its only to define the path that we shouldn't take.
Knowing What You Want
However, to timebox a spike correctly we need to first know what we want out of it. This means that we need to define the end goal...i.e, what we want to have learned by the end of the spike. A great exercise for doing this is to simply ask "Why can't we simply estimate the associated story today?" The answers to this question then become the spike's acceptance criteria. As an example, the acceptance criteria for a spike to learn more about the implementation of a new feature may include criteria such as...
We have an understanding of the components necessary to build the feature
We have an understanding of the impact on existing code
We have an understanding of the dependencies necessary to complete the feature
Is this criteria a big vague? Sure. But it at least gives you a direction to better understand what you need to have learned during the sprint and the direction that you should be going.
Keeping Spikes Short
Although we are timeboxing our spikes and including them in the sprint, they do have an impact on our overall velocity. Therefore it's to our benefit to prefer shorter spikes whenever possible. Not only does this minimize the impact of the timeboxed points alongside the "actual" points of a sprint, but keeping our spikes short also discourages open-ended "exploratory" spikes which may not yield tangible value at the end.
On the contrary, shorter spikes force us to keep them well-defined, which means that they're more likely to produce something of meaningful value to both the team and the customer.
Spikes are an incredibly helpful tool to have our scrum toolbox. Assigning meaningful timeboxes to them not only help us better understand the impact that they have on our sprint, but it also forces us to better define our desired end result which dramatically improves our odds of getting there.