The Spike character sounded much like the Kraken from one of the Pirates of Caribbean movies, who all of a sudden appeared to tell us, “you got to deal with me first”, interrupting the sprint journey.

Well, that was my first face-off with spike and the time I started exploring the spice that the spike adds to the overall flavour of agile delivery.

XP thing invented by Guru’s

XP guru Ward Cunningham would ask Kent Beck (another Guru known for his TDD advocacy) – “what is the simplest thing we can programme that will convince us we are on the right track?” He was referring to a very simple programme to explore potential solutions. Kent named it a “spike’. They first presented an example of it in OOPLA 97 conference.

Spice Factor: Why it is named “spike”? – spike was seen as a vertical probe from top to bottom for the smallest unit of work to get the crux of the problem and then develop solutions around it – much like adding a field in the database and then in UI to see if it is passing thru first and then add more fields. So, spike is “end-to-end, but very thin”, like driving a spike all the way through a log, as the Guru’s indicated in their official blog.

Definition and adoption by bodies of knowledge

Scrum.org and Scrum Alliance don’t have any official version of spike in their guide or curriculum. PMI-ACP doesn’t have any agile BOK altogether unlike PMBOK.

Agile business consortium (DSDM 2014 onwards) doesn’t have any mention of it either. Jeff De Luca’s original FDD work also doesn’t refer spike or similar anywhere.

However, scaled agile defines it as a ‘type of exploration enabler story in SAFe, used for activities such as research, design, investigation, exploration, and prototyping’.

Spice Factor:  Spike has underlying acceptance by all BOK’s – irrespective of formal acknowledgement or not; it is referred by all BOK’s in some and other forms: –

i.) PMI-ACP prescribes spike in the exam content outline.

ii.) Scrum alliance has publications by some authors on its website highlighting the wider use of spike.

iii.) Scrum.org ask questions on spike in its certification exams as it is apparent from the open assessments.

iv.) DSDM 2008 version had referred to it as an architectural spike for prototyping.

Lifeline of spike – timeboxing it!

From minutes to hours, to full sprint duration or beyond – how long should spike run? There are different opinions: Mike Cohn at MountainGoatSoftware suggests that spike should be time-boxed based on product owner’s willingness to invest into it or team’s decision to yield results from it.

Todd A Jacobs at CodeGnome advocates for the maximum duration of the spike up to the full sprint. Andrew Fuqua at leading agile terms spike a potential risk in the backlog so it should be quickly resolved preferably within 1- 3 days.

Spice Factor: The official blog C2 wiki mentions a quote by Kent Beck – Spikes are good when you are knowledge-limited, not time-limited. So there is no prescribed timeboxing – rather is strictly a prerogative of PO & teams.

Real world usage and interpretation

The situation I mentioned in the beginning – the spike added by the onshore team – was to develop a reference data algorithm as the normal SQL was not responding well. After some research team could find a piece of code which with some customisation did the trick! a technical spike.

The other spike we had was to simulate the integration of existing SSO with the newly developed portal and observe how it responds to the simplest user access. it later helped us to complete the actual integration with minimal issues – a functional spike.

There are references of infrastructural spikes available which are raised to ensure smooth CI & CD experience.

Spike is largely seen as a serious exercise to help stories in discovering the unknowns, mitigating the risks of failures, proving the feasibility of the solution and arriving on the estimations. Not every story could have an overhead of spike so spike is cautiously raised.

Spice Factor: Spike solution may not be directly implemented in stories ‘as is’ and some spikes even may not yield desired results so are thrown away at the end.

Counted in velocity or not?

For our spike, we didn’t estimate the story points and still delivered the committed stories but then the team had to stretch to compensate for the spike; we wished it could have been counted even if the velocity is inflated at times. We thought so for two reasons:

1. Considerable efforts were put in the spike and we certainly wanted to highlight it.
2. Had we not stretched for spike and would have compromised on stories, it would have negatively skewed the velocity. Stretching is not always possible and more spikes would mean badly skewed velocity.

We were advised not to estimate spikes based on the following assumptions :

1. Spikes are no direct value but rather are potential solutions for stories and are meant to be thrown away as the actual deliverables are stories.
2. Spikes generates a sense of urgency being identified as risk items so better have these quickly resolved than estimating and counting in velocity.

Estimate or not depends primarily on the prescribed agile delivery model and then on team’s willingness to set-it-up having known the pros & cons.

Spice Factor:  While the stories do have functionality up for demo and are counted towards velocity, the demo of spike limits mostly to indicate whether its results are accepted or not, irrespective of it being counted in velocity or not!

So. what appeared to be initially an uninvited blocker in the progress of the sprint, was discovered to be an interesting and valuable enabler for agile delivery.

So next time you see set of problematic stories, spike these through for a solution and then keep SPIKING !!!

Written by Ajeet Singh, Project Manager at Cognizant Technology Solutions