[Agile Guide] – Agile User Stories and Estimating Spikes

“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.” – John Haro

John recently wrote a quick and dirty guide to dealing with Spikes when it comes to using them to elicit more detail for user stories. We liked how he described them:

  • Spikes should be used sparingly.
  • Spikes should be short.
  • Spikes should be driven by actual User Story needs.

So, per John, why shouldn’t we estimate Spikes when it comes to taking up development time?

  1. Completing a spike does not directly create working software so it does not directly deliver value to the customer.
  2. Given that a spike is not about delivering  actual customer value (completing a User Story) then it should not be estimated in Story Points.
  3. Story points are how we broadly estimate, and communicate size and complexity to the business.

If you estimate Spikes with story points and the customer or business sees that you’ve done X-number of points in an iteration with nothing to show for it… well that just goes against one of the principles of the Agile Manifesto: Working software as the primary measure for success.

Thanks a lot John for this great write up!

[HT: John Haro]

5 Replies to “[Agile Guide] – Agile User Stories and Estimating Spikes”

  1. I’ve read about spikes, but never seen them in use. Is it something that is done during release planning and What is a typical time box for spikes?

    1. It can be done during release planning in terms of planning a segment of time to research/analyze/look into a certain technology or issue that the team needs time to understand. Spike range in size. It can be a day it can be a whole sprint!

Leave a Reply