Om een team voorspelbaar te krijgen zijn goede inschattingen vereist. Hoe beter de inschatting des te nauwkeuriger de voorspelbaarheid van het team wordt. Er zijn een aantal factoren waarom een team niet in staat is om een goede inschatting te maken. Het team kan een gebrek aan kennis hebben, het team heeft bepaalde technische kennis niet of de user story is te groot. Ook deze blog draagt weer bij aan het ezelsbruggetje dat ik in een eerdere post heb geïnitieerd. Dit maal kijken we naar de inschatbaarheid (Estimable) van user stories.

Gebrek aan kennis

Het is goed mogelijk dat een team een gebrek heeft aan domeinkennis. Dit  probleem ontstaat heel duidelijk aan het begin van een project waar een team nieuw is samengesteld en waar de opdrachtgever net is toegetreden tot het portfolio. Het team heeft tijd nodig om het domein van de opdrachtgever te begrijpen. Daarentegen wordt er wel verwacht dat de meest waardevolle user stories al in een vroeg stadium worden opgeleverd. In een eerdere blog heb ik omschreven dat het begin van een dergelijk traject gericht is op het opdoen van de nodige kennis. De pokersessie in een agile omgeving is bedoeld om de details van de user story te bespreken. Het is echter niet nodig om alle details te behandelen omdat het team waarschijnlijk nieuwe inzichten krijgt tijdens de realisatie. Het gehele team moet wel duidelijkheid hebben over de kaders van de user story om deze in te kunnen schatten.

Inzetten van een spike

Het is ook mogelijk dat de leden van het team de nodige (technische) kennis niet in huis hebben om een story in te kunnen schatten. Er kan in dit geval gekozen worden om een spike te realiseren. Een spike is een verkenning of een experiment met als doel om te leren van een onbekend terrein. De spike is altijd aan tijd gebonden in de vorm van een timebox om deze in te kunnen schatten. De spike levert geen werkelijke waarde op maar is nodig om verder te kunnen met een story die niet is in te schatten. Het resultaat van een spike is informatie om de werkelijke story die waarde oplevert in te kunnen schatten.

Een spike is een verkenning of een experiment met als doel om te leren van een onbekend terrein.

Een spike kan technisch of functioneel zijn. Functionele spikes onderzoeken een vorm van interactie met de doelgroep van een user story. Vormen van functionele spikes zijn oa. paper prototyping, wireframing en klikdemo’s. Deze vorm van spikes kunnen ingezet worden om te leren van de eindgebruiker voordat er een voorstel vanuit een UX ontwerper direct wordt gebouwd als een eindproduct. Door het gebruik van een prototype richt het product zich op de eindgebruiker waardoor er een verbeterde kwaliteit ontstaat.
Technische spikes kunnen bijvoorbeeld de doorslag zijn om een onderdeel zelf te bouwen of in te kopen maar kunnen ook vertrouwen brengen binnen een team zodat betere inschattingen gemaakt kunnen worden.

Net als andere user stories zijn spikes inschatbaar, demonstreerbaar en te accepteren. Een spike heeft dus net als user stories acceptatiecriteria zodat deze kan worden afgerond.

Epics en user stories

In sommige gevallen is de user story te groot om in te schatten. Een te grote user story kan gesplitst worden in kleinere onderdelen. Hierbij is het belangrijk dat er eerst gewerkt wordt aan de basis flow van de user story en dat alle additionele manieren, extenties en uitzonderingen in kaart worden gebracht. Deze methode heet use case 2.0 en wordt in een eerdere blog behandeld. Het is echter altijd goed om de relatie tussen de te grote user story en de gesplitste stories te handhaven. Zo is er altijd inzicht in de voortgang van de gehele epic. Vele backlog management tools hebben een optie om epics te documenteren.

In de volgende blog ga ik in op de omvang van een user story en manieren om deze te splitten of te combineren. Dit is de S uit het INVEST ezelsbruggetje.