Scrum is een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Het eindproduct hoeft dus niet per definitie ontwikkelde software te zijn. Alhoewel Scrum het breedst wordt toegepast binnen de software ontwikkeling, kan het ook binnen andere vakgebieden zijn toegevoegde waarde hebben.
Aangezien ik Scrum alleen toepas binnen de software ontwikkeling, wordt dit als uitgangspunt genomen in onderstaande beschrijvingen.
Een vertaling naar andere vakgebieden is vaak eenvoudig te maken.
Scrum is ontstaan vanuit het gedachtegoed achter het Agile Manifesto.
Dit manifest, dat is opgesteld door een aantal guru's op het gebied van software ontwikkeling, concludeert het volgende:
- Mensen en hun onderlinge interactie boven processen en hulpmiddelen
- Werkende software boven allesomvattende documentatie
- Samenwerking met de klant boven contractonderhandelingen
- Inspelen op verandering boven het volgen van een plan
Hiermee zegt het manifest dat aan hetgeen vetgedrukt is, meer waarde wordt gehecht dan aan hetgeen erachter genoemd wordt.
Dit houdt niet in dat er geen documentatie opgeleverd hoeft te worden, maar de kwaliteit van de software prevalleert boven de documentatie.
Ook de twaalf principes achter het Agile Manifesto zijn de moeite van het lezen (bestuderen) waard!
Terug naar Scrum. Het Scrum raamwerk bestaat uit Scrum Teams die vanuit bepaalde rollen structurele gebeurtenissen doorlopen en daarmee bepaalde producten ontwikkelen en beheren. Deze rollen, gebeurtenissen en producten worden hieronder verder beschreven.
Scrum kent de volgende uitgangspunten:
- Scrum werkt op basis van Sprints; waarin vanuit een iteratief proces wordt gewerkt.
- Transparantie en eenduidige afspraken zijn belangrijk, zodat iedereen weet waar hij/zij aan toe is. Dus geen verrassingen!
- Er wordt vanuit de verschillende gebeurtenissen continu gecontroleerd of de ontwikkelingen nog het goede pad volgen. Ook hier geen verrassingen!
- Er wordt zoveel mogelijk gebruik gemaakt van opgedane ervaring en feedback. Gebruik voortschrijdend inzicht!
Aanpassingen van het oorspronkelijke idee zijn welkom en worden meteen verwerkt. Geen verrassingen achteraf!
- Elke Sprint wordt er een potentieel opleverbare toevoeging gedaan aan het te ontwikkelen eindproduct.
Tot zover Scrum in een notendop. Hieronder een verdere uitwerking van de verschillende Scrum onderdelen.
Gebeurtenissen
Scrum kent de volgende gebeurtenissen welke iteratief worden doorlopen:
- Een Sprint is een periode van twee weken tot maximaal een maand, waarin aan de toevoeging op het eindproduct wordt gewerkt. De overige gebeurtenissen vinden eens of meerdere malen plaats binnen elke Sprint. Gedurende de Sprint worden er geen wijzigingen gedaan aan aan het Sprint Doel. Wel kunnen de Sprint Backlog Items tijdens een Sprint alsnog worden bijgesteld om het doel van de Sprint alsnog te halen. Door de Sprint kort te houden wordt het risico op desinvesteringen verkleind; aan het eind van elke Sprint kunnen Stakeholders zien wat er is opgeleverd. Als dit niet naar wens is kan direct worden bijgestuurd.
- De Sprint Planning wordt uitgevoerd aan het begin van elke Sprint en duurt voor een Sprint van een maand maximaal acht uur. Bij de Sprint Planning is het gehele Scrum Team aanwezig. De bijeenkomst wordt opgedeeld in twee delen, waarin de volgende vragen worden beantwoord:
- Wat kan er in de komende Sprint worden uitgevoerd? Eerst wordt het Sprint Doel gedefinieerd. Vervolgens wordt vanaf de bovenkant van de Product Backlog (van de items met de meeste toegevoegde waarde) een aantal items geselecteerd welke in de komende Sprint uitgevoerd worden om dit doel te bereiken. De Product Owner voegt de items toe aan de Sprint Backlog en licht ze functioneel toe, zodat helder is wat er in detail moet gebeuren. Het Development Team bepaald het aantal items dat het verwacht uit te kunnen voeren in de betreffende Sprint.
- Hoe kan dit werk worden uitgevoerd? In dit deel van de Sprint Planning wordt een plan gemaakt voor het uitvoeren van de geselecteerde Sprint Backlog Items. Voor alle items wordt een inschatting gemaakt van de benodigde capaciteit. Hiervoor worden de (eerste) items opgedeeld in taken, welke vaak technisch van aard zijn. Als blijkt dat er teveel items op de Sprint Backlog zijn geplaatst, worden de overige items teruggeplaatst naar de Product Backlog.
- De Daily Scrum wordt elke dag op hetzelfde tijdstip en op dezelfde locatie gehouden en duurt maximaal 15 minuten.
Alleen het Development Team doet mee aan deze korte bijeenkomst, anderen mogen natuurlijk wel aanwezig zijn.
Tijdens de Daily Scrum verteld elk lid van het Development Team:
- Wat hij de afgelopen 24 uur heeft gedaan om het Sprint Doel te bereiken
- Wat hij de komende 24 uur gaat doen om het Sprint Doel te bereiken
- Of hij problemen (impediments) ziet die het bereiken van het Sprint Doel in de weg staan.
De afgeronde Sprint Backlog Items worden bijgehouden, zodat de resterende hoeveelheid werk op elk moment inzichtelijk is.
Vastgestelde problemen kunnen direct ná de Daily Scrum worden opgelost door (leden van) het Development Team of door de Scrum Master.
- De Sprint Review wordt uitgevoerd aan het einde van een Sprint en duurt voor een Sprint van een maand maximaal vier uur.
Tijdens de Sprint Review demonstreert het Development Team de toevoeging op het eindproduct die tijdens de Sprint is ontwikkeld. Bij deze demonstratie kunnen naast de leden van het Scrum Team ook Stakeholders uitgenodigd worden. Op basis van de ontvangen feedback kan ter plekke de Product Backlog worden bijgewerkt. Tot slot kan in de Sprint Review besproken worden wat in een volgende Sprint gedaan kan worden en kan de totaalplanning over de Sprints heen besproken worden.
- De Sprint retrospective wordt direct na de Sprint Review gehouden en duurt voor een Sprint van een maand maximaal drie uur. Het doel van de Sprint Retrospctive is om te kijken wat goed ging en wat beter kan tijdens de afgelopen Sprint. Dus om een plan te maken voor verbeteringen voor de volgende Sprint. Om deze reden doet het gehele Scrum Team hieraan mee, maar zijn er geen Stakeholders aanwezig. De Sprint Retrospective is het moment om bijvoorbeeld de "Definition of Done" aan te scherpen, maar ook andere (procedurele) verbeteringen kunnen hier vorm krijgen. Het is niet de bedoeling om hier verbeteringen voor het eindproduct te bespreken, hiervoor is de Sprint Review een geschikter moment.
Deze gebeurtenissen zijn belangrijk om te voorkomen dat er allerlei aanvullende / bilaterale overleggen worden georganiseerd waar vervolgens niet de gewenste personen om tafel zitten. Daarnaast zijn de gebeurtenissen bedoeld om een controle moment in te bouwen. Controle van de product voortgang, de Sprint voortgang, of alles naar wens loopt, etc. Dit om steeds te kunnen blijven verbeteren op zowel het proces als op het resultaat.
Alle gebeurtenissen zijn ge time-boxed, wat inhoudt dat ze een maximale duur hebben. Deze tijd hoort dan ook niet overschreden te worden.
Naast bovenstaande onderdelen, die gezamenlijk het Scrum raamwerk vormen, is er meer nodig voor het ontwikkelen van complexe producten. Het raamwerk moet ingevuld worden. Zo zegt het Scrum raamwerk bijvoorbeeld niets over hoe de Product Backlog eruit moet zien en over de wijze waarop deze beheerd moet worden.
Er bestaan inmiddels veel Best Practices voor het toepassen van Scrum. Hieronder een aantal voorbeelden:
- Het proces rondom de Backlog Refinement is niet beschreven. Er is alleen beschreven dat de Product Backlog een lijst moet zijn met Items welke de betreffende functionaliteit beschrijft, de waarde ervan weergeeft en de verwachte capaciteit die nodig is voor de realisatie ervan. De lijst moet worden gesorteerd op waarde, met de hoogste waarde bovenaan. Hoe alle Items op de lijst worden beschreven, ligt niet vast binnen het Scrum raamwerk.
Voor het beschrijven van Product Backlog Items worden vaak User Stories gebruikt, maar het is ook mogelijk om hier Use Cases voor te gebruiken. Belangrijk is dat de omgeving waarin de Product Backlog wordt beheerd, de gewenste beschrijving volledig ondersteund. Niets werkt vervelender dan de manier van beschrijven te moeten aanpassen aan de omgeving waarin ze worden opgeslagen. Onder meer Jira en Team Foundation Server (TFS) hebben Scrum templates waarmee de Product Backlog beheerd kan worden. Neem voldoende tijd voor de keuze van een dergelijk systeem.
- Voor het beschrijven van Product Backlog Items kunnen zoals gezegd User Stories worden gebruikt. User stories bestaan uit een beschrijvende zin en worden aangevuld met acceptatie criteria. Een User Story is opgebouwd als:
Als [rol], wil ik [gewenste functionaliteit], zodat [doel]. Bijvoorbeeld: Als geregistreerde bezoeker, wil ik kunnen inloggen, zodat ik afgeschermde gegevens kan benaderen.
Hieruit blijkt dat deze functionaliteit alleen beschikbaar hoeft te zijn voor geregistreerde bezoekers, dat er blijkbaar een authenticatie mogelijkheid moet komen, met als doel het ontsluiten van bepaalde afgeschermde gegevens.
Er zijn alleen nog een aantal zaken niet duidelijk. Deze worden vastgelegd in de acceptatie criteria. Bijvoorbeeld:
- De credentials moeten versleuteld worden verzonden
- Registreren van bezoekers staat beschreven in User Story "Registreer bezoeker"
- Het ontsluiten van de betreffende gegevens staat beschreven in User Story "Ontsluit gegevens"
- ...
Na het lezen van de User Story ontstaan er vaak veel vragen. Dit is goed. Deze vragen kunnen beantwoord worden tijdens een Backlog Refinement sessie en vervolgens als acceptatie criterium worden toegevoegd. Daarmee ontstaat een volledige beschrijving van de gewenste functionaliteit. Als het niet mogelijk lijkt om de gewenste functionaliteit in een User Story te beschrijven, is de kans groot dat de granulariteit van het Item te laag is; er is te weinig detail aanwezig, dus het is nog te groot. Opdelen van het Item in meerdere Items kan in dit geval een oplossing zijn.
- Een andere manier van vastleggen van requirements is het beschrijven in Use Cases, eventueel verder gemodelleerd met UML. Een Use Case bestaat uit een aantal delen:
- Titel
- Doel / Rationale
- Actor
- Pre condities
- Standaard scenario / stappenplan
- Alternatieve scenario (herstel- of faal scenarios)
- Post condities
Hieruit blijkt onmiddellijk dat er direct veel meer detail wordt beschreven. Daarnaast kan de Use Case nog worden ondersteund met bijvoorbeeld een Use Case diagram, een Activity diagram, een Sequence diagram, een Klassendiagram, etc.
Het grote verschil is dat voor Use Cases alles helder moet zijn voordat ze geschreven kunnen worden. User Stories daarentegen kunnen organisch groeien. Er kan eenvoudig een acceptatie criterium worden toegevoegd. Om deze reden ben ik van mening dat User Stories meer Agile zijn dan Use Cases, maar het gebruik van Use Cases is absoluut mogelijk, ook binnen Scrum.
- Het Scrum raamwerk zegt dat het Development Team verantwoordelijk is voor het aantal Backlog Items dat ze voor een bepaalde Sprint selecteren. Wat niet beschreven is, is de manier waarop dit gebeurt.
Een mogelijke (en naar mijn idee goede) manier hiervoor is het zogenaamde Planning Poker. Hiervoor hebben alle leden van het Development Team een aantal kaarten met daarop de nummers uit de Fibonacci reeks. Dit is een reeks cijfers beginnend met 0, 1 en vervolgens telkens de som van de twee voorgaande cijfers. Dus: 0, 1, (1,) 2, 3, 5, 8, 13, etc. Bij Scrum poker kaarten wordt de reeks meestal aangevuld met de waarden 20, 40 en 100.
De nummers staan voor de inspanning (in eenheden, niet per se in uren) die nodig is om het Item te realiseren. Ieder Development Team lid bedenkt hoeveel inspanning nodig is en pakt de eerst hogere kaart. Als iedereen een kaart heeft getrokken, worden de kaarten gezamenlijk open neergelegd. Alleen de leden met afwijkende (naar boven of beneden) lichten toe waarom ze deze keuze hebben gemaakt. Op deze manier kan snel tot een pragmatische inschatting worden gekomen.
- In de Daily Scrum wordt ook de voortgang van de uitgevoerde Items bijgehouden. Dit wordt vaak gedaan op een Scrum Board. Een Scrum Board kan digitaal zijn; zelf vind ik een fysiek bord prettiger. Het Scrum board bestaat uit minimaal vier kolommen, waarin op Post-its de Items en taken worden bijgehouden:
- De Sprint Backlog Items
- De "To Do" taken die hier per Item uit voortkomen
- De "In Progress" taken waar momenteel aan gewerkt wordt
- De "Done" taken die uitgevoerd zijn.
Op basis van dit overzicht kan snel worden gezien welke Items inmiddels zijn afgerond. Ook staat het Sprint Doel ergens op het Scrum Board vermeld, om iedereen hieraan te herinneren.
- Om de planning nog beter inzichtelijk te maken, kan een Burn Down Chart worden bijgehouden. De Burn Down Chart is een grafiek waarbij op de verticale Y-as de totale inspanning (eenheden) voor de huidige Sprint staat, en op de horizontale X-as staat het aantal dagen in de Sprint. Op dag 1 wordt er een punt gezet bij de totale inspanning die is gepland voor de Sprint, en bij de laatste dag wordt er een punt gezet op de horizontale as (resterende inspanning = 0). Tussen deze twee punten wordt een lijn getrokken, welke de ideale Burn Down lijn weergeeft.
Elke dag wordt nu tijdens de Daily Scrum een punt gezet bij de totale inspanning nodig voor de resterende (nog niet afgeronde) Items. Hiermee wordt de gerealiseerde Burn Down getoond. Als deze lijn boven de ideaal lijn zit is er achterstand, als hij eronder komt is er voorsprong.