Wat doe je als de oplossing voor een User Story onduidelijk is? Als je nieuwe technologie wilt gaan gebruiken maar niet weet of dit wel de ware oplossing is? Als je geen inzage in risico’s hebt waardoor je niet weet hoe je een story moet inschatten? Daarvoor gebruik we binnen Scrum een Spike. Hier ga ik je meer over vertellen in deze blog.

In deze blog zal het gaan over:

1. Wat is een Spike
2. Soorten Spikes
3. Een spijker slaan is geen klimwerk
4. Het gebruik van Spikes
5. Spikes en Agile onzekerheden

Wat is een Spike?

Eens in de zoveel tijd kom je met je Scrum team een Product Backlog item tegen die je niet verder kan refinen. Waarschijnlijk door een gebrek aan domeinkennis of kennis van de te gebruiken technologie.

Een spike is een speciaal type User Story die gebruikt wordt om de noodzakelijke kennis op te doen die nodig is om risico’s, requirements of benodigde Story Points beter in beeld te brengen. Spikes helpen je een beter beeld te scheppen bij een story en helpen je de richting (opnieuw) te bepalen. Spikes timebox je en neem je net als gewone user stories op in je Sprint Backlog.

De term Spike (Nederlands: spijker) komt voort uit een analogie met bergklimmen. Dat verklaart de naam ook: bij het klimmen kan het zijn dat je even een pauze neemt om een spijker in de bergwand te slaan. De spijker in de wand slaan is niet gelijk aan het klimmen zelf – het brengt ons niet dichter bij de bergtop – maar het zorgt er wel voor dat we veiliger naar ons doel toe kunnen klimmen.

Soorten Spikes binnen Scrum

Er wordt onderscheid gemaakt op basis van twee verschillende soorten Spikes: technische en functionele.

Technische Spike

Technische Spikes worden gebruikt om een overzicht te krijgen van omgevingsfactoren en risico’s bij het implementeren van een bepaalde technische oplossing. Denk aan de limieten van een nieuw framework bepalen, of bepalen wat nodig is om een bepaalde oplossing snel genoeg te maken. Technische Spikes kunnen ook ingezet worden als er binnen het team niet genoeg kennis aanwezig is om duidelijkheid te scheppen wat betreft de User Story, de oplossing of de weg er naartoe.

Functionele Spike

Functionele Spikes worden gebruikt om duidelijkheid te scheppen voor het opbreken van stories en om de risico’s en complexiteit in beeld te brengen. Ook worden Functionele Spikes ingezet om – de naam zegt het eigenlijk al – de functie, werking van bepaalde items van tevoren te bepalen. Dit zal vaak gebeuren door middel van het maken van prototypes/Mock ups.

Een spijker slaan is geen klimwerk

Een Spike is dus een stuk vooronderzoekwerk voor een story, dat dus ook echt beperkt is tot het stuk vooronderzoek. Denk terug aan het voorbeeld over bergklimmen: op het moment dat je de spijker in de wand slaat, ben je niet ook bezig met het klimmen naar boven. Dit zijn twee aparte handelingen. Het klimmen zelf is een aparte User Story, die aan de hand van de uitkomst van de Spike wel of niet uitgevoerd kan worden, of wellicht aangepast moet worden.

Het stuk onderzoek hoort dus wel bij de Spike. Wellicht moet je via links of via rechts naar boven klimmen, wellicht kan de klim toch niet en ga je zoeken naar een andere rots.

Het gebruik van Spikes

Aangezien Spikes geen directe klantwaarde opleveren, is het niet de bedoeling dat deze vaak gebruikt worden. Het mag ook niet zo zijn dat je Spikes gaat gebruiken (deels) als vervanging voor refinement activiteiten. Refinement moet alsnog plaatsvinden, gebruik Spikes alleen indien refinement niet genoeg is om de waarde en oplossing van de User Story duidelijk te maken, of wanneer er niet genoeg kennis aanwezig is om duidelijkheid te scheppen over een story.

Ook moet je je bedenken dat een Spike meestal één sprint voor de sprint van bijbehorende story gepland moet worden. Het inplannen van een Spike met de story waar deze bijhoort is namelijk riskant: als je erachter komt dat de story moet veranderen, of niet meer kan, zal dit problemen opleveren voor je Sprint Backlog.

Onzekerheid is ingebouwd in het Agile gedachtegoed en de frameworks die eruit voortkomen; de steeds terugkerende Sprint Review in het Scrum Framework die gebruikt wordt om telkens weer te kijken of wij ons op de juiste koers bevinden is daar één voorbeeld van. Ook bij het inschatten van stories wordt er rekening gehouden met onzekerheden, en bij het gebruik van Story Points ook. Denk aan het feit dat je bij Planning Poker niet precies 4 punten kan schatten, maar moet kiezen tussen 3 en 5. En daarna kan je geen 6 of 7 kiezen maar is 8 punten het volgende kaartje. Onzekerheid is part of the game.

Als onzekerheid al is ingebouwd in onze werkwijze hebben wij Spikes toch niet nodig? Dat klopt deels: Het merendeel van de tijd zal je geen spikes nodig hebben. Je zal al een duidelijk kader kunnen scheppen over de story en de oplossing tijdens de refinement. Spikes zijn dus echt alleen voor als het niet anders kan.