A task particularly aimed at collecting information or answering a query instead of delivering shippable outcome. Sometimes user story that is generated and cannot be properly estimated until a development team executes some actual works geared towards resolving design problems or technical questions. The solution is to actually make a “spike” wherein some work have the purpose of providing a solution or answer. The word “spike” comes from Extreme Programming or XP wherein this means “A Spike Solution is an ultimately simple program for exploring potential solutions”.

Spike in Agile Software Development

In the agile software development, architecture actually evolves in order to address the needs of Product Backlog Item or PBI’s forecasted on the given Sprint. This is lean. Unlike a skyscraper or a bridge, establishing business software does not really require defining the entire architecture upfront. Remember that spikes are invention of XP and are considered as special types of stories that are used in driving out risks and uncertainties on project facets or user story. It might be necessary to spike on the perfect persistence option however, implementation of spike must be wrapped to a PBI.

Spikes by definition got maximum time box sprint size. That tends to be your upper bound. At the sprint’s end, spike is either done or not really done same as other stories. Spike is the technical investigation to produce answers with regards to certain criteria on PBI prioritized on upcoming sprints. This is an excellent way of mitigating risks earlier and promoting fluid iterations later on projects. This also allows team to ensure feedback and develop clearer understanding on upcoming complexity of PBI.

Why Doing It?

Spikes are done for the following reasons:

  • The group might not know about another area, and spikes might be utilized for fundamental research to acclimate the group with another domain or technology.
  • The story might be too huge to be estimated accurately, and the group may utilize a spike to analyze suggested conduct, so they can part the story into respectable pieces.
  • The story might contain essential technical risk, and the group may need to do some examination or prototyping to pick up trust in a mechanical approach that will permit them to commit the client story to some future timebox.
  • The story might contain noteworthy functional risk, in that while the purpose of the story might be comprehended, it’s not clear how the framework needs to communicate with the client to accomplish the implied benefit.

Just like other common stories, spike is actually put on backlog, sized and estimable to fit perfectly in iteration. The spike results vary depending on the type of the story as this generally produce information instead of working code. Spike can be used and can result to decision, proof of concept, prototype and other partial solution which tends to help in driving final results.  In an instance, spike must be developing just the sufficient information to be able to identify and size stories concealed beneath the spike.

— Slimane Zouggari