Should Your SCRUM Team Assign Story Points to a Spike?

The Great Debate

Our team has been discussing the pros and cons of assigning points to a Spike and determining our approach.

In case you are unfamiliar with the term Spike (in regards to agile development), the definition, according to agiledictionary.com, is:

A story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog.

The philosophy when I joined the team was that a Spike always got assigned 3 points since there was too much uncertainty in a Spike to estimate the work correctly. Naturally, we started questioning whether or not we should even be pointing Spikes? Here are some of the pros and cons of assigning points to a Spike that our team discussed.

Reasons to Point a Spike

• A Spike should be assigned points because it requires a team’s resources to complete. Also, anytime effort is put forth on a task, it should be made visible to the project.
• Team velocity can be negatively skewed if an abundant amount of Spikes are in your current iteration and have not been assigned points.
• Spikes have acceptance criteria, whether it be documentation or a demonstration of what was learned via the Spike; therefore, a Spike creates value for the project.
• Spikes are just special user stories. They are accepted by the product owner and are put in the backlog and sized to fit into an iteration just like any other story.

Reasons to Not Point a Spike

• Completing a Spike does not directly deliver value to the customer.
• Spikes should be assigned a short timebox limit. If the spike drags on, it can actually slow down the iteration.
• Story points are a way of estimating complexity and size to the customer. Over time the customer may be able to learn what is expected out of an iteration. So if you start doing more spikes than story points, the customer could become confused.

I believe that Spikes should have story-point estimates. I also think it’s important that each task included in the Spike have a time estimate. If a Spike task starts to drag on, it should be brought up in the daily standup then the whole team will decide on the value of the Spike and if it can or cannot be completed in the estimated time. All that being said, I believe Spikes should be used sparingly; whenever possible, roll a spike up into a user story.

Questions?

Please leave your questions in the comments below, and check out our blog on assessing your Agile processes!

Written by Mark Salvino.