samen
werken
Wat zijn Spikes in Scrum en hoe gebruik je ze?
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. In deze blog leer je er meer over.
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 dat 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. Aan elke Spike geef je ook een timebox mee zodat je niet eindeloos onderzoek blijft doen. Daarnaast neem je Spikes net als gewone User Stories op in je Sprint Backlog.
De term Spike (Nederlands: spijker) komt voort uit een analogie met bergbeklimmen. 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.
Soorten Spikes binnen Scrum
Er wordt onderscheid gemaakt op basis van twee verschillende soorten Spikes: technische en functionele.
Technische Spikes
Technische Spikes worden gebruikt om een overzicht te krijgen van omgevingsfactoren en risico’s bij het implementeren van een bepaalde technische oplossing. Denk aan het koppelen van het ene op het andere softwarepakket. Mocht dit nog nooit eerder gedaan zijn dan kan dit veel risico’s met zich meebrengen. Kan het softwarepakket wel gekoppeld worden? Hoe kunnen we testen of alles goed werkt? Weten we welke stappen we moeten doorlopen? 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 Spikes
Functionele Spikes worden ingezet om – de naam zegt het eigenlijk al – de functie, werking van bepaalde items van tevoren te bepalen. Zo kan het zijn dat we twijfelen hoe de eindgebruiker zal reageren als we ons product of dienst aanbieden. Je kunt hiernaar onderzoek doen door bijvoorbeeld gebruik te maken van prototypes of mock-ups.
Een spijker slaan is geen klimwerk
Een Spike is dus een stuk vooronderzoek in plaats van daadwerkelijk werk opleveren, dat dus ook echt beperkt is tot het stuk vooronderzoek. Denk terug aan het voorbeeld over bergbeklimmen: 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 bij hoort is namelijk riskant: als je erachter komt dat de story moet veranderen, of niet meer kan, zal dit problemen opleveren voor je Sprint Backlog.
Spikes en Agile onzekerheden
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 de volgende mogelijkheid. 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.
Heb je vraag over Spikes, User Stories of over een heel ander onderwerp? Neem dan contact op via info@agilescrumgroup.nl of 020 2614 195 of volg een van onze trainingen.
Ook interessant:
- Wat zijn de nadelen van de Scrum methode?
- NLP metamodel: stel slimmere vragen
- De drie Scrum pillars: wat houden ze in?
