“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?
- 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.
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]