Agile : Should You Estimate Spikes with Story Points


There are a number of questions that come up when I'm introducing new team members or people from the business to our Agile Software Development process.  That question is... "Should we estimate a Spike with Story Points?".  Since I've started by definitively answering the question, let me explain.  

First, lets remind ourselves what a Spike is:  A Spike is a time-boxed piece of work who's goal it is to answer a difficult technical question SO THAT the developers can properly illuminate a User Story or Epic.  By illuminate I mean; the ability to estimate those User Stories or break down Epics into estimated User Stories.  There should be no other real purpose.  Even if the spike is about making a broad architectural decision, that decision should have been required because there were multiple user stories that would depend on that decision.  The result of a Spike is deeper understanding and estimates.  The physical manifestations of a Spike is usually some whiteboard diagrams, a page on your wiki, or even some simple throw away code to test a hypothesis.  

Remember this item from the Twelve Principles behind the agile manifesto:

Working software is the primary measure of progress.


Completing a spike does not directly create working software so it does not directly deliver value to the customer. Given that a spike is not about delivering  actual customer value (completing a User Story) then it should not be estimated in Story Points.  Story points are how we broadly estimate, and communicate size and complexity to the business.  The business comes to understand what a story point is and they learn in general what they can expect in an iteration from the development team.  If you spend iterations delivering 30 points worth of spikes instead of 30 points worth of User Stories then the business will not understand what a point means to them. They will not understand what your team's velocity is.  At best they'll be confused.  At worst, they'll stop trusting you.

Given that a spike is time boxed (not estimated in points) and that the measure of progress is working software:

  • Spikes should be used sparingly.  You don't have to know every detail of how you'll code up a story in order to estimate it.  Unless the whole team is really confused, you should want to do real code for the story instead of spiking. 
  • Spikes should be short.  If Spikes are too long then they steal actual value from the iteration and make you start to wonder if you should decrease your velocity.  If Spikes are used sparingly and they are short, you can get back to actually coding working software.  
  • Spikes should be driven by actual User Story needs.  Spiking on architectural concerns for things that you DO NOT know you actually need in the near term, or that are not directly tied to what the business wants to accomplish could (and usually does) end up being a waste of everyone's time [See YAGNI].  Don't spike on simple stories just because you think someday you may have as many users as Facebook.  You may never, and if it looks like you might, you'll have been refactoring your code and architecture anyhow. 

In conclusion,  No.



4 responses
Great post !
How do you handle defects/bugfixes ? Do you estimate them in story points so that the business is able to prioritize them just like user stories or do you consider they do not add real value to the customer ?
Great post too, it has given me some information on how to help my team understand the principle on why we don't accrue story points on spikes. Really like the reference to the Agile Manifesto as our guiding point. Thanks very much :-)
Hi. From your article, I understand that you're making the assumption that story points (from a client's point of view) measure business value. However, the definition on this page says that story points measure the _effort_ required to implement a story: Hence, I see a spike more like a "pre"-effort needed to implement one or more user stories, and this effort should be measured, too. Because, if we don't separate this effort in a spike (but instead include it in the story) we surely estimate the story with more points. Looking forward to your reply.
Hi Ciprian... What I said here is "Story points are how we broadly estimate, and communicate size and complexity to the business." It is not a measure of business value. I consider pre-effort for a story (or set of story) as part of actually delivering the story itself. So story point estimates for a story should INCLUDE some pre-work. If research is required in order to make the estimate, that should be done as a spike but NOT counted.. because no software is delivered to the end users. Spikes should be time-boxed and the result of which is the _ability_ to provide proper estimates.