Activiteiten en artefacten van Scrum

Hieronder worden niet alleen de belangrijkste activiteiten en artefacten van Scrum toegelicht, maar ook hoe deze met elkaar verbonden zijn.

De Product Owner heeft een bepaalde productvisie. Omdat het product zeer complex kan zijn, wordt het door middel van zogenaamde Backlog Refinement opgedeeld in kleinere features (elementen), die worden opgenomen in een prioriteitenlijst: het Product Backlog.

Een Sprint begint met de Sprint Planning, omvat het ontwikkelwerk (Sprint Execution) tijdens de Sprint en eindigt met Review en Retrospective. Het aantal items in het Product Backlog is doorgaans groter dan wat een ontwikkelteam in een korte Sprint-periode kan verwerken. Daarom moet het ontwikkelteam aan het begin een aantal items uit het Product Backlog selecteren waarvan het denkt deze af te kunnen ronden (Sprint Planning). Het doel is om aan het einde van de Sprint een potentieel opleverbaар productincrement te hebben.

Een opmerking over de activiteiten in Scrum

In 2011 heeft een wijziging in "The Scrum Guide" (Schwaber en Sutherland 2011) een debat op gang gebracht over de vraag of de juiste term om het resultaat van Sprint Planning te beschrijven "forecast" (prognose/inschatting) of "commitment" (toezegging) zou moeten zijn. Voorstanders van de term Forecast geven de voorkeur aan deze term, omdat zelfs de beste inschatting door nieuwe informatie in de loop van een Sprint kan veranderen. Er is ook de opvatting dat een Commitment van het team ertoe leidt dat de kwaliteit van het werk eronder lijdt, omdat geprobeerd wordt dit vastgestelde doel koste wat het kost te halen, of omdat het team de neiging kan hebben om te lage doelen te stellen, zodat het deze in elk geval kan bereiken.

Het staat waarschijnlijk buiten kijf dat elk ontwikkelteam een inschatting zou moeten geven van wat het denkt in een Sprint te kunnen realiseren. Toch zouden veel ontwikkelteams er baat bij kunnen hebben om uit een Forecast een Commitment af te leiden. Commitments leiden namelijk tot sterker vertrouwen tussen de Product Owner en het ontwikkelteam, net als tussen de individuele teamleden onderling. Bovendien vereenvoudigen Commitments de kortetermijnplanning en een zinvolle besluitvorming binnen een organisatie. Wanneer meerdere teams bij de productontwikkeling betrokken zijn, kunnen zij door Commitments hun planning beter op elkaar afstemmen – een team kan zich bij zijn besluitvorming oriënteren op het Commitment van een ander team. Een Commitment zou zich echter primair moeten richten op het Sprintdoel en niet zozeer op de openstaande taken. Met toenemende kennis slagen teams er vaak in het Sprintdoel op een andere manier te bereiken dan oorspronkelijk gedacht. (In het vervolg wordt meestal de term Commitment gebruikt. Waar de context dit vereist, wordt af en toe ook de term Forecast gehanteerd.)

Om te waarborgen dat het ontwikkelteam een zinvol Commitment heeft afgegeven, stellen de teamleden tijdens de Sprint Planning een tweede Backlog op, ook wel Sprint Backlog genoemd. In dit Sprint Backlog wordt aan de hand van gedetailleerde taken beschreven hoe het team van plan is de afzonderlijke items uit het Product Backlog tijdens deze Sprint te ontwerpen, te ontwikkelen, te integreren en te testen.

De volgende stap heet Sprint Execution, oftewel de uitvoering van de Sprint. Hier voert het ontwikkelteam de benodigde taken uit om de geselecteerde features te kunnen realiseren. In deze fase vinden dagelijks zogenaamde Daily Scrums plaats, waarin synchronisatie- en inspectieactiviteiten alsook adaptieve planningsactiviteiten worden uitgevoerd. Hierdoor zijn de teamleden in staat hun werkprocessen beter te managen. Aan het einde van de Sprint Execution heeft het team een potentieel opleveerbaar productincrement geproduceerd, dat al een deel vertegenwoordigt van wat de Product Owner voor ogen had.

Het Scrum Team sluit de Sprint af met het inspecteren en aanpassen (inspect-and-adapt) van het product en het Scrum-proces. Het product wordt tijdens de Sprint Review door het Scrum Team en de stakeholders beoordeeld. De inspectie van het Scrum-proces dat wordt gebruikt voor het creëren van een product, wordt tijdens een activiteit genaamd Retrospective door de teamleden uitgevoerd. Als gevolg hiervan kunnen aanpassingen in het Product Backlog of in het ontwikkelproces worden doorgevoerd.

Op dit punt begint de Sprint-cyclus opnieuw. Het ontwikkelteam bepaalt nu de volgende Product Backlog Items die het kan afronden. Na een passend aantal Sprints zal de visie van de Product Owner gerealiseerd zijn en kan het resultaat worden gepresenteerd.

In het vervolg wordt elk van deze activiteiten en artefacten nog in detail behandeld.

Product Backlog

Bij het werken met Scrum worden altijd eerst de meest waardevolle taken opgepakt. De Product Owner is – in samenwerking met het ontwikkelteam en de stakeholders – uiteindelijk verantwoordelijk voor de volgorde van deze werkstappen en moet deze communiceren in een prioriteitenlijst, het Product Backlog. Bij de ontwikkeling van nieuwe producten zijn de Product Backlog Items in eerste instantie features die nodig zijn om de visie van de Product Owner te realiseren. Bij de doorontwikkeling van producten kan het Product Backlog ook nieuwe features bevatten, evenals aanpassingen van bestaande features, noodzakelijke bugfixes of technische verbeteringen enzovoort.

De Product Owner werkt samen met interne en externe stakeholders om de Product Backlog Items te verzamelen en te bepalen. Vervolgens moet hij ervoor zorgen dat alle items in de juiste volgorde worden geplaatst (op basis van waarde, kosten, kennis en risico), zodat de meest waardevolle items bovenaan staan en de minder waardevolle items lager in de Product Backlog verschijnen. De Product Backlog is een voortdurend evoluerend artefact. Wanneer de omstandigheden voor een onderneming veranderen of het begrip van het Scrum Team over het product groeit (door feedback tijdens de Sprints), kunnen items door de Product Owner worden toegevoegd, verwijderd en herzien.

In principe wordt het ontwerpen, uitwerken, inschatten en prioriteren van de Product Backlog Items Backlog Grooming of Backlog Refinement genoemd.

Voordat je het prioriteren of ordenen van de items in de Product Backlog kunt afronden, moet echter eerst de omvang van de afzonderlijke items bekend zijn. De omvang bepaalt de kosten en de Product Owner moet deze kennen om de prioriteit van een item te kunnen vaststellen. Een specifieke maateenheid wordt door Scrum niet voorgeschreven. In de praktijk gebruiken veel teams relatieve maateenheden zoals Story Points of Ideal Days. Een relatieve maateenheid drukt niet de absolute omvang van een item uit, maar alleen de omvang in verhouding tot andere items.

Sprints

In Scrum bestaan er iteraties of cycli van maximaal één maand die Sprints worden genoemd. Een afgeronde Sprint moet altijd iets van tastbare waarde voor de klant of gebruiker opleveren.

Voor alle Sprints wordt een tijdskader (Timebox) met een vast start- en eindmoment bepaald, dat in principe voor alle Sprints even lang zou moeten zijn. Direct na de afronding van een voorgaande Sprint start een nieuwe Sprint. Ook al zijn er wijzigingen in de scope of het team die het doel zouden beïnvloeden en die daarom eigenlijk niet tijdens een Sprint doorgevoerd mogen worden, is dit vanwege bepaalde zakelijke behoeften soms niet te vermijden.

Sprint Planning

Het werk in een Product Backlog kan meerdere weken of maanden duren, wat veel meer is dan in een enkele, korte Sprint gedaan kan worden. Tijdens de Sprint Planning bepalen de Product Owner, het Development Team en de Scrum Master welke Product Backlog Items het belangrijkst zijn voor de volgende Sprint. Bij deze planning komen de Product Owner en het Development Team een Sprint Doel overeen, oftewel een definitie van wat er in de komende Sprint opgeleverd moet worden.

Op basis van deze richtlijn bekijkt het ontwikkelteam de Product Backlog en benoemt de meest waardevolle items die het team in de volgende Sprint daadwerkelijk kan afronden. De werksnelheid, ook wel Sustainable Pace genoemd, moet zo gekozen worden dat die zonder problemen voor langere tijd volgehouden kan worden.

Om een gevoel te krijgen voor wat haalbaar is, verdelen veel teams elk Product Backlog Item in verschillende tasks. Deze vormen, samen met de bijbehorende items, een tweede backlog: de Sprint Backlog.

Daarna geven de ontwikkelteams een inschatting van de benodigde inspanning per item (meestal in uren). Product Backlog Items opsplitsen in tasks is een vorm van design en just-in-time planning voor het opleveren van features. Bij een Sprint-duur van één tot vier weken moet de Sprint Planning in twee tot acht uur afgerond worden – meer tijd zou je er niet voor moeten uittrekken. Hierbij zijn er verschillende werkwijzen, waarbij een van de populairste gebaseerd is op een eenvoudige cyclus: je kiest een Product Backlog Item (indien mogelijk het volgende item in de ranglijst van de Product Owner), splitst het op in tasks en beslist of het goed in de Sprint past (met het oog op andere items die voor deze Sprint gepland zijn). Als het in de Sprint past en er nog genoeg tijd over is, wordt het proces herhaald totdat de capaciteit van het team voor verdere taken volledig benut is.

Bij een andere werkwijze bepalen de Product Owner en het team alle gewenste Product Backlog Items in één keer. Alleen het ontwikkelteam voert de opsplitsing in afzonderlijke tasks uit en bevestigt daarmee dat het alle gewenste items kan afronden.

Sprint Executie

Zodra het Scrum Team de Sprint Planning heeft afgerond en het eens is geworden over de inhoud van de volgende Sprint, gaat het ontwikkelteam aan de slag met het werk (op taak-niveau) dat nodig is om de features op te leveren. Opleveren betekent in dit geval dat al het werk is gedaan dat nodig is om kwalitatief hoogwaardige features te produceren.

Niemand schrijft het ontwikkelteam voor hoe en in welke volgorde het de werkzaamheden in de Sprint Backlog op taak-niveau moet uitvoeren. De teamleden kunnen dus zelf hun werk op taak-niveau bepalen en zich zo organiseren als zij denken dat optimaal is om het Sprint Doel te bereiken.

Daily Scrum / Daily Standup

Elke dag tijdens de Sprint, bij voorkeur op dezelfde tijd en dezelfde plek, houden de teamleden een meeting die Daily Scrum wordt genoemd. Deze meeting duurt maximaal 15 minuten. Dit Inspect-and-Adapt ritueel wordt soms ook Daily Stand-Up genoemd, omdat in de praktijk alle aanwezigen vaak blijven staan om de meeting kort te houden.

Een gangbare aanpak bij het Daily Scrum is dat de individuele teamleden elk drie vragen beantwoorden, wat voor de rest van het team enorm nuttig is.

• Wat heb ik sinds het laatste Daily Scrum bereikt?
• Waar zal ik waarschijnlijk bij het volgende Daily Scrum aan werken?
• Wat houdt me precies tegen om vooruitgang te boeken?

Door het beantwoorden van deze vragen krijgt iedereen een overzicht van wat er gebeurt, van de voortgang richting het Sprint Doel, van welke planwijzigingen er voor de volgende dag zijn en welke problemen aangepakt moeten worden. Om als team snelle en flexibele werkprocessen binnen een Sprint te kunnen garanderen, is een Daily Scrum onmisbaar.

Problemen worden tijdens het Daily Scrum niet opgelost. In plaats daarvan kunnen de teams zich na het Daily Scrum met alle geïnteresseerden in kleine groepen treffen om problemen te bespreken. Het Daily Scrum Meeting is ook geen traditioneel statusoverleg, zoals die welke door een projectmanager worden belegd om hem over de laatste stand van het project te informeren. Een Daily Scrum is eerder bedoeld om de status van de Sprint Backlog Items binnen het Development Team te communiceren. Een Daily Scrum is voornamelijk een activiteit waarbij inspectie, synchronisatie en adaptieve planning plaatsvinden, waardoor een zelforganiserend team nog beter werk kan leveren.

Definition of Done

In Scrum worden de resultaten van Sprints aangeduid als potentieel leverbare productincrementen. Dat betekent dat alles wat het Scrum Team wilde bereiken, volgens de afgesproken Definition of Done (definitie van wat als afgerond beschouwd kan worden), ook daadwerkelijk afgerond is. Deze definitie specificeert in welke mate het resultaat van het werk van goede kwaliteit en potentieel leverbaar is. Bij softwareontwikkeling, bijvoorbeeld, zou de Definition of Done als absoluut minimum de volledige ontwikkeling van een productfunctionaliteit moeten voorschrijven, die ontworpen, ontwikkeld, geïntegreerd, getest en gedocumenteerd wordt.

Door een ambitieuze Definition of Done kan een organisatie bij elke Sprint beslissen of ze wat er ontwikkeld is, wil leveren aan interne of externe klanten.

Even ter verduidelijking: "potentieel leverbaar betekent niet dat iets ook daadwerkelijk geleverd moet worden. Dit is namelijk een zakelijke beslissing, die voortdurend wordt beïnvloed door factoren zoals "Hebben we voldoende features of genoeg bijgedragen aan de klanttevredenheid?" of "Kunnen onze klanten nog een verandering aan, als we twee weken geleden al iets geleverd hebben?".

"Potentieel leverbaar" moet eerder gezien worden als de mate waarin er in de Sprint daadwerkelijk iets opgeleverd is. Dat betekent dat er geen belangrijke werkzaamheden (zoals belangrijke tests of integratie enzovoort) onafgerond zijn die eerst afgerond moeten worden voordat het resultaat van de Sprint geleverd zou kunnen worden. De Definition of Done ligt niet vast in steen en zou net als al het andere regelmatig geïnspecteerd en aangepast moeten worden. In de praktijk passen veel teams hun Definition of Done in de loop der tijd aan.

Sprint Review

Aan het einde van elke Sprint zijn er twee verdere Inspect-and-Adapt activiteiten. Eén daarvan wordt de Sprint Review genoemd.

Het doel van deze activiteit is het inspecteren en aanpassen van het gewenste product. Een essentieel onderdeel hiervan is de afstemming tussen het Scrum Team, stakeholders, sponsors, klanten en geïnteresseerde leden van andere teams. De nadruk ligt op het beoordelen van de zojuist opgeleverde features in relatie tot de totale ontwikkelinspanning. Iedereen die aanwezig is, krijgt een helder beeld van wat er momenteel gebeurt en heeft de mogelijkheid om de verdere ontwikkeling te beïnvloeden, zodat de beste oplossing voor de organisatie mogelijk wordt.

Een succesvol Review resulteert in een informatiestroom in beide richtingen. De personen die geen deel uitmaken van het Scrum Team kunnen zich informeren over de status van het product en de volgende stappen beïnvloeden. Tegelijkertijd hebben de leden van het Scrum Team de mogelijkheid om een beter begrip te ontwikkelen van de bedrijfseconomische en marketinggerelateerde aspecten, doordat ze voortdurend feedback ontvangen of de productontwikkeling op koers ligt zodat klanten en gebruikers enthousiast zullen zijn over het product. De Sprint Review is dus een geplande gelegenheid om een product te inspecteren en aan te passen. Personen buiten het Scrum Team kunnen tijdens een Sprint feature reviews uitvoeren en feedback geven, wat het Scrum Team op zijn beurt helpt om het Sprint Doel te bereiken.

Sprint Retrospective

De tweede Inspect-and-Adapt activiteit aan het einde van een Sprint is de Sprint Retrospective. Deze wordt regelmatig uitgevoerd na de Sprint Review en vóór de volgende Sprint Planning. Terwijl een Sprint Review wordt gebruikt om het product te bekijken en aan te passen, is de Sprint Retrospective een gelegenheid om het proces te bekijken en aan te passen. Tijdens een Sprint Retrospective komen het Development Team, de Scrum Master en de Product Owner samen om te bespreken wat in de praktijk met Scrum wel en niet werkt. De nadruk ligt op continue procesverbetering, waardoor een goed Scrum Team een geweldig Scrum Team kan worden. Aan het einde van een Sprint Retrospective zou het Scrum Team een zinvolle set verbeteracties moeten hebben geïdentificeerd, die het vervolgens in de volgende Sprint uitvoert.

Wanneer de Sprint Retrospective is afgelopen, begint het hele proces weer opnieuw – met een nieuwe Sprint Planning, waarin wordt bepaald wat het meest waardevolle werk is waar het team zich op moet richten.