Using Spikes in SCRUM

I am writing about spike in this article because I feel it gets abused during sprints and SCRUM. I will try to address why we need a spike, when to use it and when not to use it. First, what is a spike? A spike is really a prototype, code to try something new – prove a concept. Sometimes spikes are used to de-risk technologies. As developers we may be asked to do work we have never done before and prototyping that work is usually the first approach we think of. But let me start by saying why spikes are not friends of SCRUM, the reason is that on their own they offer no business value to the product owner. They do however offer a lot of value to the developer – but at the end, user stories are about business value and not knowledge to the developer. So maybe the approach is to try to get both and have a win-win situation. Try not to do a spike! Considering we are dealing with something new, something we have not done before, before jumping into prototyping the work see if you can get some value by cutting the complexity into smaller stories. For example, say we need to communicate “Sales” to another service, however we never communicated to this service before – we don’t know exactly the security or protocol to use. So no matter what you need to try to communicate to this service and figure it out. Why not just do it as part of the real story and estimate the complexity of the communication as part of the story itself. As trade off the story should have a very simple UI to do this and focus more on the communication. A later story can focus more on the UI aspect and make it more user friendly, but in order to just focus on the communication part, keep the UI functional but minimal – still if everything works there is real value here. But – what if it doesn’t work… Well, if it doesn’t work you still gained the knowledge, the same knowledge you would have gained when doing a prototype. Except this time you can estimate better, know more and adjust. It is not the end of the world not finishing a story – it is the end of the world not finishing a story and learning nothing from the experience. So I decided to come up with tips for Spikes and how to handle them:

• Every time you think you need a spike see if you can do it without a spike by breaking stories down offer some value and still gain knowledge If your team wants to do spikes every sprint there is a problem. It is not normal. It means they are afraid to commit and they are afraid to fail.
• Get around the spike by using Mocks – although this is a little bit cheating you can still mock parts of the software that are either “not ready”, or “we don’t know yet” and still get value and feedback. For previous example of sending sales to a service, we can mock the receiving service by accepting sales without worrying about protocol, security and so on. We interface this part of the code out and the story is more about “exporting” sales. Who is consuming the exported data can be done in separate story when we know more.
• If you are going to do a prototype then:
  • The prototype should time boxed (normally should be only 1 sprint)
  • Try not to have more than one spike per sprint, focus on sprint giving business value over technical knowledge.
  • The prototype should have a goal (what are we trying to learn)
  • The prototype must provide knowledge – even if you fail that’s knowledge that can be used to estimate better.
  • Doing a prototype should be team decision and the team should be open to explore alternatives.
  • The product owner should gain visibility into the prototype, so if the prototype yields that something is complicated, the product owner can offer alternatives to simplify the work.
  • A spike can also be used as an experiment – trying out a feature but not sure we want to keep it. The feature might be done in a branch and only used for feedback purposes.
  • Spikes should be estimated and entered in the backlog as technical stories
  • If a story is estimated high because – “we just don’t know how to do this…” – don’t bother putting a large estimation; instead leave the story as not estimated. Do the spike and then go back and re-estimate (or adjust the large estimation after you learned the results of the spike).
  • When possible defer commitment, if the complexity can wait, let it wait a bit. The longer you wait the more knowledge you gain. That complexity might turn simpler over time because you have learned things along the way and got feedback.
  • Time your spike – sometimes during the holidays it might be quite, the whole team is not present, take the opportunity to do a spike if you needed one.
  • Keep the code; even if it is a prototype code it correctly. However the definition of done may not apply fully to a spike – so in that case mention in in the acceptance what is the definition of done for this spike.

I have seen the two extremes, a team that never does spikes and have crazy estimations, and a team that makes 2 stories out of each story, one story for the spike and one story for the real story. Overall, try to remember that we all about offering value, where spikes does not. However, spike offer knowledge to help us estimate and de-risk, this knowledge eventually turns into value. So you should use spikes in SCRUM, but don’t overdo it.