Scrum guide 2020: Commitments

Op 18 november is de vernieuwde Scrum Guide gelanceerd. In deze Scrum Guide 2020 is een aantal wijzigingen gedaan om Scrum toegankelijker te maken voor een groter publiek en nog minder dwingend te zijn als het om de invulling gaat. In dit blog richt ik me specifiek op 'Commitments', een nieuw begrip dat bedoeld is om te helpen de focus te houden binnen het artefact. Voor een overzicht van de veranderingen kun je terecht op de site van de Scrum Guide.

Kort maar krachtig

Door alle wijzigingen in de nieuwe editie van de Scrum Guide vooral een stuk korter geworden. Het document is teruggebracht van 19 naar 13 pagina’s. Dit komt onder andere door het schrappen van alle verwijzingen naar het softwareontwikkelproces. De bedoeling hiervan is om duidelijker te maken dat Scrum ook toepasbaar is voor andere processen, bijvoorbeeld binnen marketing of HR. Daarnaast zijn alle acties rondom het voortijdig stoppen van een sprint uit de Scrum Guide verwijderd.

De meest in het oog springende aanvullingen zijn de toevoeging van de “waarom” vraag aan de sprint planning: wat is nu zo waardevol aan wat we deze sprint gaan opleveren? En daarnaast de introductie van 'Commitments' met in het bijzonder de product goal.

Commitments

In de vorige editie van de Scrum guide waren drie groepen gedefinieerd: Rollen, artefacten en evenementen. Daarnaast waren er nog twee termen die niet ergens bij hoorden: Definition of Done en Sprint goal. Zij zijn erg belangrijk maar waar horen ze nu eigenlijk bij?

Dat probleem heeft de Scrum guide nu opgelost met het in het leven roepen van commitments. Een commitment is gekoppeld aan een artefact en helpt met de focus houden binnen het artefact.

Product goal

Door de product backlog een product goal te geven, maakt het de keuze voor de product owner makkelijker welke PBI hoger of lager op de product backlog moet komen. Het is ook makkelijker om de volgorde van PBI’s met de stakeholders te bespreken; als de PBI binnen de Product goal valt, dan komt het hoger op de product backlog te staan.

Het voordeel voor de developers (Let op: er is geen development team meer, iedereen is onderdeel van één team: het Scrum team) is, dat iedereen binnen het team weet waar we de komende aantal sprints aan gewerkt gaat worden. De grote lijn voor de developers is duidelijker en de horizon stopt niet met het einde van de sprint.

Een product goal moet meetbaar zijn en het moet voor iedereen duidelijk zijn wanneer het doel behaald is. Een voorbeeld kan zijn: We willen 10.000 nieuwe gebruikers. Hoe je daar toe komt hoeft niet in de product goal komen te staan.

Door de product goal is er ook een makkelijkere manier om de sprint backlog samen te stellen

Sprint goal

De sprint goal werd al gebruikt in Scrum, maar zoals eerder besproken, de plaats was niet per se duidelijk. Nu is het een commitment van de sprint backlog geworden en is het makkelijker in te vullen.

Als de product goal goed geformuleerd is, staat de product backlog in de juiste volgorde. Daarmee is het makkelijk om de sprint backlog te vullen met die items en de sprint goal te formuleren.

De sprint goal zal vaak afgeleid zijn van de product goal. Daarmee heb je de eerste check al binnen: zijn de twee doelen in lijn? Daarnaast kun je controleren of de PBI’s in de sprint backlog daadwerkelijk met de sprint goal te maken en hebben en met de product goal. Focussen we als team op één doel of doen we van alles wat?

Increment en definition of done

Een increment is een stapje in de richting van de product goal. Elke PBI die af is (“Done”) zorgt voor een nieuw increment. Werk is pas een onderdeel van het increment als het voldoet aan de definition of done.

Een aantal zinnen uit de Scrum guide om de grenzen van de definition of done aan te geven:

• De definition of done geeft transparantie over wat er gedaan moet worden om werk klaar te hebben.
• Een PBI mag niet gereleased worden of zelfs getoond worden in de sprint review als het niet voldoet aan de definition of done.
• De definition of done wordt opgesteld door de organisatie of door het team, als de organisatie er geen opgesteld heeft.

Valkuilen voor commitments

Natuurlijk zijn er in een open manier van communiceren valkuilen, hieronder voor elke commitment een voorbeeld:

Valkuil van de Product goal

We mogen maar één zin gebruiken voor de product goal, maar wel willen wel dat we meerdere zaken kunnen doen. We maken dus een hele lange zin met veel komma’s er in om alles af te dekken.
Breek zo’n product goal af in kleine stukjes en zorg dat je na elk behaalde kleine product goal een nieuwe definieert of oppakt. Dus niet: we willen 10000 nieuwe gebruikers en een betere gebruikerservaring en een nieuwe manier van factureren. Kies er één uit en ga voor dat doel. Misschien komen die andere doelen ineens heel dichtbij of zijn zelfs niet meer nodig.

Valkuilen bij een Sprint goal

We weten niet zo goed wat onze sprint goal is, dus we noemen hem nu maar “Alles wat in de sprint staat” of “Kleine dingetjes, die we af moeten maken”. Probeer niet de sprint te vullen met de sprint goal [M5] maar zorg dat de verschillende PBI’s met elkaar te maken hebben en probeer ook een sprint goal meetbaar te maken als doel en niet als een setje taken die je af moet vinken. Een voorbeeld van een goed sprint goal kan zijn: Gebruikers kunnen hun profiel aanpassen.

Valkuilen bij een Definition of done

Bij een korte definition of done is de kans aanwezig, dat de kwaliteit niet hoog is. We hebben namelijk niet voldoende afgetikt om de PBI af te ronden. Aan de andere kant, als je definition of done bestaat uit teveel stappen of onderdelen, is de kans groot dat je niet alles af krijgt. Probeer dus een definition of done te vinden die precies voldoende doet om te zorgen, dat jouw werk door de klant gebruikt kan worden. Ik probeer zelf altijd te beginnen met een definition of done die aangeeft dat je iets maakt, de kwaliteit controleert en dat het gebruikt kan worden. De 4 standaard taken, die daar voor mij bij horen zijn: bouw, test, code review en documentatie.

Conclusie

In de nieuwe Scrum guide wordt meer dan ooit de nadruk gelegd op het opleveren van waarde aan de klant. Hoewel de Scrum guide een stuk korter is geworden, zijn juist de artifacts en hun commitments uitgebreid om meer handvatten te geven aan het waarde opleveren.

Wat viel jou op in de nieuwe Scrum guide of waar heb je moeite mee? Neem contact op met ons om samen te bepalen wat we voor je kunnen doen.

Alex Roos - DevOps consultant