Our team has been discussing the pros and cons of assigning points to a Spike, and trying to determine what our approach should be.
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 at the time 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 they have been 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 time box 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 make a decision on the value of the Spike and if it can or cannot be complete in the time that was estimated. All that being said, I believe Spikes should be used sparingly; whenever possible, simply roll a spike up into a user story.