De 3 Scrum commitments uitgelegd

Ken je het verhaal van de kip en het varken? Het gaat als volgt: Een varken en een kip lopen over straat. De kip zegt: “He, varken, wij zouden samen een restaurant moeten openen!” “Hmm, misschien wel,” antwoordt het varken, “hoe zouden we het dan noemen?” De kip heeft wel een idee: “Wat dacht je van ‘ham-n-eggs’?” Het varken denkt even na en zegt dan: “Nou, nee bedankt. Ik zou er volledig in opgaan en jij bent maar voor een deel betrokken.”

Wat betekent commitment in Scrum?

In een Agile project heb je zowel varkens als kippen nodig: mensen die volledig toegewijd zijn (zoals het varken) en mensen die er voor een deel bij betrokken zijn (zoals de kippen). De leden van een Scrum Team kun je zien als de varkens, zij committen zich volledig op het werk binnen het team. Stakeholders, waaronder klanten, gebruikers en management, kun je zien als kippen. Zij zijn wel bij het project betrokken, leggen her en der een ei, maar hebben daarnaast ook hun “eigen” werk.

Commitment is een van de vijf waarden in het Scrum Framework. Door je toe te wijden aan de doelen die je als Scrum Team stelt, breng je focus aan in je werk en kun je controleren of je voortgang boekt. Scrum commitments zie je daarom op meerdere niveaus terugkomen.

1. De Product Goal, als commitment op de Product Backlog
2. De Sprint Goal, als commitment op de Sprint Backlog
3. De Definition of Done, als commitment op het Increment

De Product Goal

Waarom werk je als Scrum Team eigenlijk samen? De Product Goal beschrijft je lange termijn doel, de stip op de horizon, die je als team samen wil bereiken. De Product Goal biedt daarmee richting voor de invulling van de Product Backlog en is daarom de eerste Scrum commitment.

Al het werk dat nodig is om het doel te bereiken hoort op de backlog en werk dat niet direct of indirect bijdraagt aan het behalen van ons doel, hoort ook niet op je Product Backlog. Op deze manier creëert commitment op de Product Goal niet alleen focus voor het team, maar ook motivatie: je wil samen een doel bereiken en daar ga je 100% voor.

De Sprint Goal

Vaak weet je aan het begin van een project nog niet precies wat je allemaal moet doen om de Product Goal te bereiken. Gelukkig is dat ook niet nodig. Met een Sprint kijk je namelijk maximaal 1 maand vooruit. In een paar weken tijd maak je vervolgens een stap om dichter bij de stip op de horizon te komen. Wat is waardevol om de komende paar weken te bereiken? Dat is je Sprint Goal.

Een Sprint Goal is leidend voor de scope van één Sprint. Een Product Owner (PO) heeft vaak al een beeld van de stappen die nodig zijn om de Product Goal te bereiken, bijvoorbeeld aan de hand van een roadmap. Het korte termijn doel van de PO is daarmee het startpunt van een Sprint Planning. Vanuit daar kunnen de PO en Developers bespreken welke Product Backlog Items (PBI’s) nodig zijn om het doel voor de komende paar weken te behalen.

Nadat je samen besproken hebt welke PBI’s ook daadwerkelijk haalbaar lijken voor deze Sprint, kun je het doel waar nodig nog wat aanscherpen. Vervolgens geeft het team commitment op de Sprint Goal en wordt het doel gedurende de Sprint niet meer gewijzigd. Als blijkt dat er toch andere werkzaamheden nodig zijn om het doel te bereiken, of dat niet alles wat haalbaar leek daadwerkelijk afgerond kan worden, biedt de Sprint Goal een leidraad voor de keuzes die de Developers en PO samen maken met betrekking tot de inhoud van de Sprint Backlog.

Omdat de Sprint Goal het commitment is voor een Sprint Backlog, is het ook de enige reden om een Sprint af te breken. Alleen wanneer het doel écht niet meer relevant is, heb je een reden om de Sprint af te breken. Zolang het doel wel relevant is, kun je opnieuw in gesprek gaan over de scope van de Sprint, zonder een nieuwe Sprint te moeten starten.

De Definition of Done

De derde en tevens laatste Scrum commitment is de Definition of Done. Elk Product Backlog Item dat het team realiseert, creëert een Increment. Een concreet stukje werk dat bijdraagt aan het behalen van de Product Goal en Sprint Goal. Om er voor te zorgen dat alles wat je doet, zowel vroeg als laat in het project, goed bij elkaar past en van minimaal dezelfde kwaliteit is, heeft elk Scrum Team een Definition of Done (D.o.D.).

De Definition of Done geldt voor al het werk dat het Scrum Team uitvoert en kan daardoor vrij algemeen zijn. Denk bijvoorbeeld aan criteria als “alle zichtbare onderdelen moeten voldoen aan de huisstijl” en “een ander teamlid heeft feedback gegeven op het werk”. En als je met meerdere teams aan hetzelfde product werkt, heb je dezelfde D.o.D. als minimum. Elk team kan daar nog eigen criteria aan toevoegen, maar uiteindelijk moet alles bij elkaar passen en heb je dus een aantal richtlijnen nodig waar al het werk van alle teams aan voldoet. Een Product Backlog Item kan pas naar de ‘Done’ kolom van een Sprint Backlog wanneer het voldoet aan alle eisen die aan dat PBI werden gesteld én aan de criteria uit de D.o.D.

De Definition of Done kan later in het project veranderen. Als je bijvoorbeeld merkt dat het werk vaak niet voldoet aan de privacyregels, kun je een check op die regels toevoegen aan de D.o.D. En criteria die inmiddels routinewerk zijn geworden, kun je er wellicht weer uit halen. Vergelijk het met autorijden: wanneer je net leert rijden ben je meer met het bedienen van de machine bezig en minder met het verkeer om je heen. Op een gegeven moment bedien je de auto vanuit routine en heb je meer aandacht voor de rest van het verkeer, waardoor je daar ook kritischer en efficiënter mee om kunt gaan. Het algemene doel, veilig deelnemen aan het verkeer, verandert niet. Maar sommige aspecten die daarvoor nodig zijn, zijn inmiddels vanzelfsprekend geworden, waardoor je ze niet meer expliciet hoeft te benoemen. Dat is ook het gewenste effect van een Definition of Done.

Ook interessant:

• Hoe ‘nee’ zeggen tegen stakeholders als Product Owner?
• Wie kan er allemaal de Product Backlog vullen met items?
• Teaminterventies, hoe pak ik dat aan? (+werkvorm)

Wil je eens doorpraten met een van onze ervaren coaches of trainers over hoe je slimmer samenwerkt met Scrum binnen jouw organisatie? Bekijk onze trainingen, coaching, of transformatie mogelijkheden. Neem contact op via 020 2614 195 of info@agilescrumgroup.nl en we plannen vrijblijvend wat in.

Over de auteur: Dennis Dielissen

Dennis is Agile Coach en trainer. Hij heeft een passie voor producten en diensten waar mensen écht op zitten te wachten. Vanuit zijn expertise in innovatie management en praktijkervaring als Product Owner, helpt hij teams om op een Agile manier succesvolle oplossingen te ontwikkelen. Dit doet hij voornamelijk door focus aan te brengen in de werkzaamheden en rollen, waardoor kwaliteiten beter tot hun recht komen.