Scrum Guide

Het doel van de Scrum Guide

We hebben Scrum in het begin van de jaren 1990 ontwikkeld. We hebben de eerste versie van de Scrum Guide in 2010 geschreven om mensen over de hele wereld te helpen Scrum te begrijpen. Sindsdien hebben we de Guide doorontwikkeld met kleine, functionele updates.
We staan er samen achter.

De Scrum Guide bevat de definitie van Scrum. Elk element van Scrum dient een specifiek doel dat essentieel is voor de totale waarde en de resultaten die met Scrum worden behaald. Het veranderen van de kern of de basisideeën van Scrum, het weglaten van elementen of het niet volgen van de regels van Scrum, verhult problemen, beperkt de voordelen en maakt Scrum in het slechtste geval zelfs nutteloos.

We volgen het toenemende gebruik van Scrum in een steeds complexer wordende wereld. We zien met bescheidenheid hoe Scrum in talloze domeinen van complex werk wordt ingezet, ver voorbij softwareontwikkeling – waar Scrum zijn wortels heeft. Naarmate het gebruik van Scrum zich verder verspreidt, wordt dit werk gedaan door developers, onderzoekers, analisten, wetenschappers en andere specialisten. We gebruiken het woord "Developers" in Scrum niet om iemand uit te sluiten, maar om het eenvoudig te houden. Iedereen die profijt heeft van het gebruik van Scrum, mag zich aangesproken voelen.

Bij het gebruik van Scrum kunnen patronen, processen en inzichten worden toegepast en ontwikkeld die passen bij het Scrum-raamwerk, zoals beschreven in dit document. Een beschrijving daarvan gaat verder dan het doel van de Scrum Guide, omdat ze contextafhankelijk zijn en sterk kunnen verschillen afhankelijk van hoe Scrum wordt ingezet. Dergelijke tactieken voor toepassing binnen het Scrum-raamwerk variëren sterk en worden elders beschreven.

Ken Schwaber & Jeff Sutherland, november 2020

Scrum-definitie

Scrum is een lichtgewicht raamwerk dat mensen, teams en organisaties helpt om waarde te creëren door middel van adaptieve oplossingen voor complexe problemen.

Kort gezegd vereist Scrum dat een Scrum Master een omgeving bevordert waarin

• een Product Owner het werk voor een complex probleem ordent in een Product Backlog;
• het Scrum Team uit een selectie van dit werk binnen een Sprint een waardevol Increment oplevert;
• het Scrum Team en de stakeholders de resultaten inspecteren en aanpassen voor de volgende Sprint;
• deze stappen worden herhaald.

Scrum is eenvoudig. Probeer het uit zoals het is en ontdek of de filosofie, theorie en structuur ervan helpen om doelen te bereiken en waarde te creëren. Het Scrum-raamwerk is bewust onvolledig en definieert alleen de onderdelen die nodig zijn om de Scrum-theorie toe te passen. Scrum bouwt voort op de collectieve intelligentie van de mensen die het gebruiken. In plaats van mensen gedetailleerde instructies te geven, sturen de regels van Scrum hun relaties en interacties.

Binnen het raamwerk kunnen verschillende processen, technieken en methoden worden ingezet. Scrum omhult bestaande werkwijzen of maakt ze overbodig. Scrum maakt de relatieve effectiviteit van het huidige management, de omgeving en de werktechnieken zichtbaar, zodat verbeteringen kunnen worden doorgevoerd.

Scrum Theorie

Scrum is gebaseerd op empirie en Lean Thinking. Empirie betekent dat kennis voortkomt uit ervaring en dat beslissingen worden genomen op basis van observaties. Lean Thinking vermindert verspilling en focust op wat echt belangrijk is.

Scrum maakt gebruik van een iteratieve, incrementele aanpak om de voorspelbaarheid te optimaliseren en risico's te beheersen. Scrum vertrouwt op groepen mensen die samen over alle vaardigheden en expertise beschikken om het werk gedaan te krijgen, en die zulke vaardigheden waar nodig delen of verwerven.

Scrum combineert vier formele Events voor inspectie en adaptatie binnen een overkoepelend Event, de Sprint. Deze Events werken omdat ze de empirische Scrum-pijlers Transparantie, Inspectie en Adaptatie implementeren.

Transparantie

Het zich ontwikkelende proces en het werk dat daaruit voortkomt, moeten zichtbaar zijn voor zowel degenen die het werk uitvoeren als degenen die het werk ontvangen. Bij Scrum worden belangrijke beslissingen gebaseerd op de waargenomen staat van de drie formele artefacten. Artefacten die weinig transparant zijn, kunnen leiden tot beslissingen die de waarde verminderen en het risico vergroten.

Transparantie maakt inspectie mogelijk. Inspectie zonder transparantie is misleidend en verspillend.

Inspectie

De Scrum-artefacten en de voortgang richting de afgesproken doelen moeten regelmatig en zorgvuldig worden geïnspecteerd om potentieel ongewenste afwijkingen of problemen aan het licht te brengen. Om hierbij te helpen biedt Scrum een vast ritme in de vorm van vijf events.

Inspectie maakt aanpassing mogelijk. Inspectie zonder aanpassing wordt als zinloos beschouwd. Scrum events zijn erop gericht om verandering teweeg te brengen.

Aanpassing

Als bepaalde aspecten van een proces buiten acceptabele grenzen vallen of als het resulterende product niet acceptabel is, moeten het toegepaste proces of de geproduceerde resultaten worden aangepast. De aanpassing moet zo snel mogelijk plaatsvinden om verdere afwijkingen te minimaliseren.

Aanpassing wordt moeilijker wanneer de betrokken personen niet bevoegd (empowered) zijn of zichzelf niet kunnen managen. Van een Scrum Team wordt verwacht dat het zich aanpast op het moment dat het door inspectie iets nieuws leert.

Scrum-waarden

Het succesvol toepassen van Scrum hangt ervan af dat mensen steeds beter in staat zijn om vijf waarden te leven:

• Commitment
• Focus
• Openheid
• Respect
• Moed

Het Scrum Team committeert zich om zijn doelen te bereiken en elkaar te ondersteunen. De primaire focus ligt op het werk van de Sprint, om de best mogelijke voortgang richting die doelen te realiseren. Het Scrum Team en zijn stakeholders zijn open over het werk en de uitdagingen. De leden van het Scrum Team respecteren elkaar als bekwame, onafhankelijke personen en worden als zodanig ook gerespecteerd door de mensen met wie ze samenwerken. De leden van het Scrum Team hebben de moed om het juiste te doen: aan moeilijke problemen te werken.

Deze waarden geven het Scrum Team richting als het gaat om het werk, de handelingen en het gedrag. De beslissingen die genomen worden, de stappen die ondernomen worden en de manier waarop Scrum wordt toegepast, zouden deze waarden moeten versterken en niet verkleinen of ondermijnen. De leden van het Scrum Team leren en verkennen de waarden terwijl ze werken met de events en artefacten van Scrum. Wanneer deze waarden worden belichaamd door het Scrum Team en de mensen met wie het samenwerkt, komen de empirische Scrum-pijlers transparantie, inspectie en adaptatie tot leven en bouwen ze vertrouwen op.

Scrum Team

Het centrale onderdeel van Scrum is een klein team van mensen, een Scrum Team. Het Scrum Team bestaat uit een Scrum Master, een Product Owner en Developers. Binnen een Scrum Team zijn er geen subteams of hiërarchieën. Het is een hechte eenheid van professionals die zich op één doel richten: het Product Doel.

Scrum Teams zijn cross-functioneel, wat betekent dat de teamleden over alle vaardigheden beschikken die nodig zijn om in elke Sprint waarde te creëren. Daarnaast zijn ze zelforganiserend, wat betekent dat ze intern beslissen wie wat doet, wanneer en hoe.

Het Scrum Team is klein genoeg om wendbaar te blijven en groot genoeg om binnen een Sprint betekenisvol werk af te ronden, doorgaans 10 personen of minder. Over het algemeen hebben we vastgesteld dat kleinere teams beter communiceren en productiever zijn. Als Scrum Teams te groot worden, moeten ze overwegen om zich te reorganiseren in meerdere samenhangende Scrum Teams die zich allemaal op hetzelfde product richten. Daarom delen ze het Product Doel, de Product Backlog en de Product Owner.

Het Scrum Team is verantwoordelijk (responsible) voor alle productgerelateerde activiteiten: samenwerking met stakeholders, verificatie, onderhoud, beheer, experimenten, onderzoek en ontwikkeling, en alles wat verder nodig kan zijn. Het team is door de organisatie zo opgezet en gefaciliteerd dat het zijn eigen werk aanstuurt. Het werken in Sprints met een duurzaam tempo verbetert de focus en continuïteit van het Scrum Team.

Het volledige Scrum Team is aanspreekbaar (accountable) voor het creëren van een waardevol, bruikbaar Increment in elke Sprint. Scrum definieert drie specifieke verantwoordelijkheden binnen het Scrum Team: Developers, Product Owner en Scrum Master.

Developers

Developers zijn de mensen in het Scrum Team die zich inzetten om elk aspect van een bruikbaar Increment te creëren in elke Sprint.

De specifieke vaardigheden die Developers nodig hebben, zijn vaak breed en variëren afhankelijk van de werkcontext. Developers zijn echter altijd aanspreekbaar voor het volgende:

• een plan voor de Sprint opstellen, de Sprint Backlog;
• kwaliteit waarborgen door het naleven van een Definition of Done;
• dagelijks hun plan aanpassen om het Sprint Doel te bereiken; en
• elkaar als experts aanspreken op verantwoordelijkheid.

Product Owner

De Product Owner is aanspreekbaar voor het maximaliseren van de waarde van het product dat voortkomt uit het werk van het Scrum Team. Hoe dit wordt gedaan, kan sterk variëren per organisatie, Scrum Team en individu.

De Product Owner is ook aanspreekbaar voor effectief Product Backlog-management, wat het volgende omvat:

• het Product Doel ontwikkelen en expliciet communiceren;
• Product Backlog-items opstellen en helder communiceren;
• de volgorde van Product Backlog-items bepalen; en
• ervoor zorgen dat de Product Backlog transparant, zichtbaar en begrepen is.

De Product Owner kan bovengenoemde werkzaamheden zelf uitvoeren of de uitvoeringsverantwoordelijkheid aan anderen delegeren. Ongeacht blijft de Product Owner aanspreekbaar.

Om succesvol te zijn, moet de hele organisatie de beslissingen van de Product Owner respecteren. Deze beslissingen zijn zichtbaar in de inhoud en volgorde van de Product Backlog en via het inspecteerbare Increment tijdens de Sprint Review.

De Product Owner is één persoon, geen comité. De Product Owner kan de behoeften van veel stakeholders vertegenwoordigen in de Product Backlog. Wie de Product Backlog wil wijzigen, kan dat doen door de Product Owner te overtuigen.

Scrum Master

De Scrum Master is aanspreekbaar voor het invoeren van Scrum zoals gedefinieerd in de Scrum Guide. Dit doet hij/zij door iedereen te helpen de Scrum-theorie en -praktijk te begrijpen, zowel binnen het Scrum Team als in de organisatie.

De Scrum Master is aanspreekbaar voor de effectiviteit van het Scrum Team. Dit doet hij/zij door het Scrum Team in staat te stellen zijn werkwijzen binnen het Scrum-framework te verbeteren.

Scrum Masters zijn echte leiders die het Scrum Team en de gehele organisatie dienen.

De Scrum Master dient het Scrum Team op verschillende manieren, onder andere door:

• teamleden te coachen in zelfmanagement en cross-functionele samenwerking;
• het Scrum Team te ondersteunen bij het focussen op het creëren van hoogwaardige Increments die voldoen aan de Definition of Done;
• het wegnemen van belemmeringen (impediments) voor de voortgang van het Scrum Team; en
• ervoor te zorgen dat alle Scrum Events plaatsvinden, positief en productief zijn en binnen de timebox blijven.

De Scrum Master dient de Product Owner op verschillende manieren, onder andere door:

• te helpen bij het vinden van technieken voor een effectieve definitie van het Product Doel en Product Backlog-management;
• het Scrum Team te helpen begrijpen waarom heldere en nauwkeurige Product Backlog-items nodig zijn;
• te helpen bij het opzetten van empirische productplanning in een complexe omgeving; en
• de samenwerking met stakeholders te faciliteren waar gewenst of nodig.

De Scrum Master dient de organisatie op verschillende manieren, onder andere door:

• de organisatie te leiden, te trainen en te coachen bij de invoering van Scrum;
• Scrum-implementaties binnen de organisatie te plannen en aan te bevelen;
• medewerkers en stakeholders te ondersteunen bij het begrijpen en toepassen van een empirische aanpak voor complex werk; en
• barrières tussen stakeholders en Scrum Teams weg te nemen.

Scrum Events

De Sprint is een container voor alle andere events. Elk event in Scrum is een formele gelegenheid om Scrum-artefacten te inspecteren en aan te passen. Deze events zijn specifiek ontworpen om de vereiste transparantie mogelijk te maken. Als een event niet volgens de richtlijnen wordt uitgevoerd, mis je de kans om te inspecteren en aan te passen. Events worden in Scrum gebruikt om regelmaat te creëren en de noodzaak van meetings die niet in Scrum zijn gedefinieerd, te minimaliseren. Idealiter worden alle events op dezelfde tijd en op dezelfde plek gehouden om de complexiteit te verminderen.

De Sprint

Sprints zijn de hartslag van Scrum, waar ideeën worden omgezet in waarde.

Het zijn events met een vaste lengte van een maand of minder, om consistentie te creëren. Een nieuwe Sprint begint direct na afloop van de vorige Sprint.

Al het werk dat nodig is om het Productdoel te bereiken, inclusief Sprint Planning, Daily Scrums, Sprint Review en Sprint Retrospective, vindt plaats binnen de Sprints.

Tijdens de Sprint

• worden er geen wijzigingen aangebracht die het Sprintdoel in gevaar zouden brengen;
• neemt de kwaliteit niet af;
• wordt de Product Backlog indien nodig verfijnd; en
• kan de scope (inhoud en omvang) verduidelijkt en opnieuw overeengekomen worden met de Product Owner zodra er meer inzichten zijn.

Sprints maken voorspelbaarheid mogelijk door minstens elke kalendermaand een inspectie en aanpassing van de voortgang richting het Productdoel te garanderen. Als de horizon van een Sprint te lang is, kan het Sprintdoel achterhaald raken, kan de complexiteit toenemen en kan het risico groter worden. Kortere Sprints kunnen worden ingezet om meer leercycli te genereren en het risico van kosten en inspanning te beperken tot een kleiner tijdsbestek. Elke Sprint kan worden beschouwd als een kort project.

Er bestaan verschillende benaderingen om de voortgang te voorspellen, zoals Burn-Down-Charts, Burn-Up-Charts of Cumulative-Flow-diagrammen. Hoewel deze nuttig zijn gebleken, vervangen ze niet het belang van empirie. In complexe omgevingen is onbekend wat er zal gebeuren. Alleen wat al heeft plaatsgevonden, kan worden gebruikt voor vooruitziende besluitvorming.

Een Sprint kan worden afgebroken als het Sprintdoel obsoleet wordt. Alleen de Product Owner heeft de bevoegdheid om de Sprint af te breken.

Sprint Planning

De Sprint Planning initieert de Sprint door het werk dat tijdens de Sprint uitgevoerd moet worden uiteen te zetten. Het resulterende plan wordt opgesteld door de gezamenlijke inspanning van het hele Scrum Team.

De Product Owner zorgt ervoor dat de deelnemers voorbereid zijn om de belangrijkste Product Backlog-items te bespreken en hoe deze bijdragen aan het Productdoel. Het Scrum Team kan ook andere personen uitnodigen om deel te nemen aan de Sprint Planning voor advies.

De Sprint Planning behandelt de volgende onderwerpen:

Onderwerp één: Waarom is deze Sprint waardevol?

De Product Owner stelt voor hoe het product in de huidige Sprint zijn waarde en nut kan vergroten. Het hele Scrum Team werkt vervolgens samen om een Sprintdoel te definiëren dat verduidelijkt waarom de Sprint waardevol is voor de stakeholders. Het Sprintdoel moet vóór het einde van de Sprint Planning zijn afgerond.

Onderwerp twee: Wat kan in deze Sprint worden afgerond (Done)?

In overleg met de Product Owner selecteren de Developers items uit de Product Backlog die in de huidige Sprint worden opgenomen. Het Scrum Team kan deze items tijdens dit proces verfijnen, wat het begrip en het vertrouwen vergroot.

Bepalen hoeveel er binnen een Sprint kan worden afgerond, kan een uitdaging zijn. Hoe meer de Developers echter weten over hun eerdere prestaties, hun toekomstige capaciteit en hun Definition of Done, des te zekerder ze zullen zijn in hun Sprint-voorspellingen.

Onderwerp drie: Hoe wordt het geselecteerde werk uitgevoerd?

Voor elk geselecteerd Product Backlog-item plannen de Developers het benodigde werk om een Increment te creëren dat voldoet aan de Definition of Done. Dit gebeurt vaak door Product Backlog-items op te splitsen in kleinere werkeenheden van een dag of minder. Hoe dit gebeurt, is volledig aan de Developers. Niemand anders vertelt hen hoe ze Product Backlog-items moeten omzetten in Increments van waarde.

Het Sprintdoel, de voor de Sprint geselecteerde Product Backlog-items en het plan voor de oplevering ervan worden samen het Sprint Backlog genoemd.

De Sprint Planning is beperkt tot maximaal acht uur voor een Sprint van een maand. Bij kortere Sprints is het event doorgaans korter.

Daily Scrum

Het doel van de Daily Scrum (ook wel Daily Stand-up genoemd) is om de voortgang richting het Sprintdoel te inspecteren en het Sprint Backlog indien nodig aan te passen om het aankomende geplande werk bij te sturen.

De Daily Scrum is een event van 15 minuten voor de Developers van het Scrum Team. Om de complexiteit te verminderen, wordt het elke werkdag van de Sprint op dezelfde tijd en op dezelfde plek gehouden. Als de Product Owner of de Scrum Master actief aan items van het Sprint Backlog werkt, neemt hij of zij deel als Developer.

De Developers mogen zelf de structuur en technieken kiezen, zolang hun Daily Scrum gericht is op de voortgang richting het Sprintdoel en een uitvoerbaar plan oplevert voor de volgende werkdag. Dit zorgt voor focus en bevordert zelfmanagement.

Daily Scrums verbeteren de communicatie, identificeren obstakels, bevorderen snelle besluitvorming en elimineren consequent de noodzaak voor andere meetings.

De Daily Scrum is niet de enige gelegenheid waarbij de Developers hun plan mogen aanpassen. Ze komen vaak gedurende de dag samen voor meer gedetailleerde discussies over het aanpassen of herplannen van het resterende werk van de Sprint.

Sprint Review

Het doel van de Sprint Review is om het resultaat van de Sprint te inspecteren en toekomstige aanpassingen vast te stellen. Het Scrum Team presenteert de resultaten van zijn werk aan de belangrijkste stakeholders, en de voortgang richting het Productdoel wordt besproken.

Tijdens het event bekijken het Scrum Team en de stakeholders wat er in de Sprint is bereikt en wat er in hun omgeving is veranderd. Op basis van deze informatie werken de deelnemers samen aan wat er vervolgens moet gebeuren. Ook kan de Product Backlog worden aangepast om nieuwe mogelijkheden te benutten. De Sprint Review is een werksessie en het Scrum Team moet vermijden om het te beperken tot een presentatie.

De Sprint Review is het voorlaatste event van de Sprint en is voor een Sprint van een maand beperkt tot maximaal vier uur. Bij kortere Sprints is het event doorgaans korter.

Sprint Retrospective

Het doel van de Sprint Retrospective is om manieren te plannen om de kwaliteit en effectiviteit te verbeteren.

Het Scrum Team evalueert hoe de laatste Sprint is verlopen wat betreft individuen, interacties, processen, tools en de Definition of Done. De geëvalueerde elementen variëren vaak afhankelijk van het werkdomein. Aannames die het team op het verkeerde spoor hebben gezet, worden geïdentificeerd en de oorsprong ervan wordt onderzocht. Het Scrum Team bespreekt wat er goed ging tijdens de Sprint, welke problemen er zijn opgetreden en hoe deze problemen wel (of niet) zijn opgelost.

Het Scrum Team identificeert de meest nuttige veranderingen om zijn effectiviteit te verbeteren. De meest impactvolle verbeteringen worden zo snel mogelijk opgepakt. Ze kunnen zelfs worden opgenomen in het Sprint Backlog voor de volgende Sprint.

De Sprint Retrospective sluit de Sprint af. Voor een Sprint van een maand is deze beperkt tot maximaal drie uur. Bij kortere Sprints is het event doorgaans korter.

Scrum Artefacten

De artefacten van Scrum vertegenwoordigen werk of waarde. Ze zijn ontworpen om de transparantie van belangrijke informatie te maximaliseren. Zo heeft iedereen die ze bekijkt dezelfde basis voor aanpassingen.

Elk artefact bevat een commitment om ervoor te zorgen dat er informatie wordt geboden die transparantie en focus verbetert, zodat voortgang meetbaar wordt:

• Voor de Product Backlog is dat het Productdoel.
• Voor de Sprint Backlog is dat het Sprintdoel.
• Voor het Increment is dat de Definition of Done.

Deze commitments dienen om empirie en de Scrum-waarden voor het Scrum Team en zijn stakeholders te versterken.

Product Backlog

De Product Backlog is een opkomende, geordende lijst van alles wat nodig is om het product te verbeteren. Het is de enige bron van werk dat door het Scrum Team wordt uitgevoerd.

Product-Backlog-items die door het Scrum Team binnen een Sprint kunnen worden afgerond (Done), worden als gereed beschouwd voor selectie tijdens een Sprint Planning-event. Deze mate van transparantie bereiken ze doorgaans door Refinement-activiteiten. Het Refinement van de Product Backlog is het proces waarbij Product-Backlog-items worden opgesplitst in kleinere, preciezere elementen en verder worden gedefinieerd. Dit is een doorlopende activiteit, waardoor extra details zoals beschrijving, volgorde en omvang worden toegevoegd. De kenmerken variëren vaak afhankelijk van de werkomgeving.

De Developers die het werk gaan uitvoeren, zijn verantwoordelijk voor het inschatten van de omvang. De Product Owner kan de Developers beïnvloeden door hen te helpen de Product-Backlog-items te begrijpen en compromissen te sluiten.

Commitment: Productdoel

Het Productdoel beschrijft een toekomstige toestand van het product, dat het Scrum Team als planningsdoel kan dienen. Het Productdoel bevindt zich in de Product Backlog. De rest van de Product Backlog ontstaat om te definiëren "wat" het Productdoel vervult.

Een product is een middel om waarde te leveren. Het heeft duidelijke grenzen, bekende stakeholders, eenduidig gedefinieerde gebruikers of klanten. Een product kan een dienst, een fysiek product of iets abstracter zijn.

Het Productdoel is het langetermijndoel voor het Scrum Team. Het Scrum Team moet een doelstelling behalen (of loslaten) voordat het de volgende oppakt.

Sprint Backlog

De Sprint Backlog bestaat uit het Sprintdoel (Waarvoor), de voor de Sprint geselecteerde Product-Backlog-items (Wat) en een uitvoerbaar plan voor de oplevering van het Increment (Hoe).

De Sprint Backlog is een plan van en voor de Developers. Het is een duidelijk zichtbaar realtime beeld van het werk dat de Developers tijdens de Sprint willen uitvoeren om het Sprintdoel te bereiken. De Sprint Backlog wordt daarom gedurende de hele Sprint bijgewerkt zodra er meer geleerd is. Het moet voldoende detail bevatten zodat ze hun voortgang in de Daily Scrum kunnen inspecteren.

Commitment: Sprintdoel

Het Sprintdoel is de enige doelstelling voor de Sprint. Hoewel het Sprintdoel een commitment van de Developers is, biedt het flexibiliteit wat betreft het exacte werk dat nodig is om het te bereiken. Het Sprintdoel creëert ook samenhang en focus en moedigt het Scrum Team zo aan om samen te werken in plaats van in afzonderlijke initiatieven.

Het Sprintdoel wordt tijdens het Sprint Planning-event opgesteld en vervolgens aan de Sprint Backlog toegevoegd. Terwijl de Developers binnen de Sprint werken, houden ze het Sprintdoel in gedachten. Als blijkt dat het werk afwijkt van hun verwachtingen, werken ze samen met de Product Owner om de scope van de Sprint Backlog binnen de Sprint te onderhandelen, zonder het Sprintdoel te beïnvloeden.

Increment

Een Increment is een concrete stap in de richting van het Productdoel. Elk Increment is additief ten opzichte van alle voorgaande Increments en grondig getest om te waarborgen dat ze allemaal samen functioneren. Om waarde te leveren, moet het Increment bruikbaar zijn.

Binnen een Sprint kan meer dan één Increment worden opgeleverd. De som daarvan wordt tijdens de Sprint Review gepresenteerd, waarmee empirie wordt ondersteund. Een Increment kan echter ook al vóór het einde van de Sprint aan de stakeholders worden geleverd. De Sprint Review mag nooit als een barrière voor het leveren van waarde worden beschouwd.

Werk kan niet als onderdeel van een Increment worden beschouwd zolang het niet voldoet aan de Definition of Done.

Commitment: Definition of Done

De Definition of Done is een formele beschrijving van de toestand van het Increment wanneer het voldoet aan de voor het product vereiste kwaliteitsmaatregelen.

Op het moment dat een Product-Backlog-item aan de Definition of Done voldoet, wordt een Increment geboren.

De Definition of Done creëert transparantie door iedereen een gedeeld begrip te geven over welk werk als onderdeel van het Increment is afgerond. Als een Product-Backlog-item niet aan de Definition of Done voldoet, kan het niet worden gereleased noch tijdens de Sprint Review worden gepresenteerd. In plaats daarvan gaat het terug naar de Product Backlog voor toekomstige overweging.

Als de Definition of Done voor een Increment onderdeel is van de standaarden van de organisatie, moeten alle Scrum Teams deze als minimum volgen. Als het geen organisatiestandaard is, moet het Scrum Team een voor het product geschikte Definition of Done opstellen.

De Developers moeten zich aan de Definition of Done houden. Als meerdere Scrum Teams aan één product samenwerken, moeten ze een gezamenlijke Definition of Done definiëren en zich er allemaal aan houden.

Slotopmerking

Scrum is gratis en wordt in deze guide aangeboden. Het Scrum-raamwerk, zoals het hier beschreven wordt, is onveranderlijk. Het is weliswaar mogelijk om slechts delen van Scrum te implementeren, maar het resultaat is dan geen Scrum. Scrum bestaat alleen in zijn geheel en functioneert goed als container voor andere technieken, methodieken en praktijken.

Dankwoord

Personen
Van de duizenden personen die aan Scrum hebben bijgedragen, willen we degenen uitlichten die in het begin van bijzonder belang waren: Jeff Sutherland werkte samen met Jeff McKenna en John Scumniotales, en Ken Schwaber werkte samen met Mike Smith en Chris Martin ‐ en ze werkten allemaal samen. Vele anderen hebben in de jaren daarna een bijdrage geleverd. Zonder hun hulp zou Scrum niet zo verfijnd zijn als het vandaag de dag is.

Scrum‐Guide‐Historie
Ken Schwaber en Jeff Sutherland hebben Scrum voor het eerst samen gepresenteerd op de OOPSLA-conferentie in 1995. Deze presentatie documenteerde in de kern de inzichten die Ken en Jeff in de voorgaande jaren bij de toepassing van Scrum hadden opgedaan, en vormde de eerste formele publicatie van de definitie van Scrum.

De Scrum Guide documenteert Scrum zoals het door Jeff Sutherland en Ken Schwaber gedurende meer dan 30 jaar is doorontwikkeld, gegroeid en onderhouden. Andere bronnen bieden patronen, processen en inzichten die het Scrum-raamwerk aanvullen. Deze kunnen leiden tot verhoging van de productiviteit, de waarde, de creativiteit en de tevredenheid over de resultaten.

De volledige geschiedenis van Scrum wordt elders beschreven. Om de eerste plekken te eren waar het is beproefd en zich heeft bewezen, erkennen we Individual Inc., Newspage, Fidelity Investments en IDX (nu GE Medical) als zodanig.

© 2020 Ken Schwaber and Jeff Sutherland

This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Wijzigingen ten opzichte van de 2017-versie werden door Sohrab Salimi, de CEO van Scrum Academy, samengevat.

Bij deze versie (3.2) gaat het om een volledig nieuwe vertaling ter gelegenheid van de publicatie van de Scrum Guide 2020. Stand: 03-12-2020

Vertaling

Deze guide is vertaald vanuit de Engelse originele versie, beschikbaar gesteld door Ken Schwaber en Jeff Sutherland. Hieraan hebben bijgedragen:
2020: Silke von der Bruck, Sabine Canditt, Jan Gretschuskin, Eva Gysling, Martin Hoppacher, Björn Jensen, Ralph Jocham, Dominik Maximini, Wolf Dieter Moggert, Peter Schmidt, Boris Steiner