Scrum een beschrijving
V 2012.12.13 © 2012 Scrum Alliance, Inc. Vertaald naar het Nederlands door Jef Cumps, Kris Philippaerts, Hubert Smits -‐ februari 2013 Noot van de vertalers: De originele, Engelse terminologie rond Scrum werd grotendeels behouden of minstens vermeld in func;e van het begrip en de leesbaarheid van deze tekst.
Scrum principes Waarden uit het Agile Manifest Scrum is het best gekende Agile framework. Scrum inspireerde ook veel van het denkwerk achter de waarden en principes uit het Agile Manifest, die een gemeenschappelijke basis vormen voor alle Agile frameworks en methodes. Meer informaIe hierover vind je in het Agile Manifest. De waarden uit het Agile Manifest zijn rechtstreeks toepasbaar op Scrum:
• Mensen en interac?e boven processen en hulpmiddelen. Zoals alle Agile frameworks is Scrum
gebaseerd op vertrouwen in teams, de individuen in de teams en de manier waarop ze met elkaar interageren. Teams zoeken zelf wat er moet gebeuren en voeren dat uit. Teams idenIficeren wat hen tegenhoudt en nemen de verantwoordelijkheid om alle problemen op te lossen die binnen hun invloedssfeer liggen. Teams werken samen met andere parIjen binnen de organisaIe om de problemen waarover ze geen controle hebben op te lossen. Dit is essenIeel. Proberen om Scrum toe te passen zonder deze primaire focus op de verantwoorlijkheid van teams leidt doorgaans tot problemen.
• Werkende soDware boven allesomvaFende documenta?e. Scrum eist een afgewerkte,
werkende Product Increment als belangrijkste resultaat van elke Sprint. Natuurlijk is er werk rond analyse, ontwerp en testen dat moet gedocumenteerd worden. Maar het is de werkende soSware die de organisaIe toelaat het project te leiden en succesvol op te leveren. Dit is essenIeel. Scrum teams moeten elke Sprint een werkende Product Increment opleveren.
• Samenwerking met de klant boven contractonderhandelingen. De Product Owner is het
belangrijkste contact van het Scrum Team met de eindgebruikers en met de delen van de organisaIe die het product nodig hebben. De Product Owner is een lid van het team dat met de rest van het team samenwerkt om te bepalen wat er moet worden gebouwd. Binnen deze samenwerking kiest de Product Owner de meest waardevolle zaken om als volgende uit te voeren. Zo garandeert hij dat het product op elk moment de hoogst mogelijke waarde heeS. Dit is essenIeel. De Product Owner moet een rijke samenwerking met het team opbouwen.
• Ingaan op verandering boven het volgen van een plan. Alles binnen Scrum is zo ontworpen dat
iedereen op elk moment de nodige informaIe bezit om de juiste beslissingen over het project te nemen. Echte, werkende Product Increments tonen de voortgang van het project aan. De Product Bakcklog met alle nodige werk erin is zichtbaar voor iedereen. De voortgang is zichtbaar voor iedereen, zowel binnen als over de Sprints. Problemen en zorgen worden openlijk besproken en onmiddellijk aangepakt. Dit is essenIeel. Scrum werkt goed voor teams die openlijk inspecteren wat er gebeurt en hun acIes aanpassen aan de realiteit (inspect & adapt). Scrum werkt niet voor degenen die dat niet doen.
2
Waarden van Scrum Al het werk dat binnen Scrum uitgevoerd wordt, vereist een aantal waarden die als basis dienen voor de voortgang en principes van het team. Het toepassen van het Scrum framework en het voortdurend verbeteren, steunen op deze waarden en zullen ze in de prakIjk brengen. Deze waarden zijn focus, moed, openheid, toewijding (commitment) en respect.
• Focus. We werken goed samen en leveren excellent werk op omdat we ons op elk moment
bewust op een klein aantal dingen concentreren. We leveren de meer waardevolle zaken zo vroeg mogelijk op.
• Moed. Doordat we niet alleen zijn, voelen we ons ondersteund en hebben we toegang tot meer hulpbronnen. Dit geeS ons de moed om grotere uitdagingen aan te gaan.
• Openheid. Door samen te werken, leren we te tonen hoe het gaat en wat ons tegenhoudt. We leren dat het goed is om onze zorgen te uiten, zodat ze aangepakt kunnen worden.
• Toewijding. Doordat we onze toekomst meer in eigen handen hebben, worden we meer toegewijd aan succes.
• Respect. Door samen te werken en zowel successen als mislukkingen te delen, respecteren we elkaar meer en meer en helpen we elkaar om respect te verdienen.
Als een organisaIe Scrum haar werk laat doen, zal die organisaIe de voordelen van Scrum ontdekken. En zal ze beginnen begrijpen waarom deze waarden zowel nodig zijn voor Scrum als versterkt worden door Scrum.
Scrum Framework Scrum is een kader of raamwerk (framework) om een product te bouwen. Scrum start wanneer een aantal belanghebbenden een bepaald product nodig hebben. Scrum is een teamgericht proces. Het Scrum Team bevat drie rollen: de Product Owner, de ScrumMaster en de leden van het Ontwikkelteam (Development Team). De Product Owner heeS de verantwoordelijkheid om te beslissen welk werk er moet gebeuren. De ScrumMaster helpt als dienend leider het team en de organisaIe om Scrum op de best mogelijke manier te implementeren. Het Ontwikkelteam bouwt het product op incrementele wijze in een reeks korte Ijdsperiodes die Sprints genoemd worden. Een Sprint is een periode met een vaste lengte tussen één en vier weken waarbij kortere lengtes de voorkeur krijgen. Het Ontwikkelteam zal in elke Sprint een Product Increment bouwen en opleveren. Elke Product Increment is een herkenbaar, zichtbaar verbeterd en werkend deel van het product dat voldoet aan de overeengekomen acceptaIecriteria en aan de overeengekomen lijst van kwaliteitseisen die de DefiniIon of Done genoemd wordt. Scrum bevat drie essenIële artefacten: de Product Backlog, de Sprint Backlog en de Product Increment. De Product Backlog is de lijst van ideeën voor het product, geordend in de volgorde waarin we het verwachten te bouwen. De Sprint Backlog is het gedetailleerde plan voor de 3
ontwikkelingen binnen de aankomende Sprint. De Product Increment is het resultaat van de Sprint. Het is een geïntegreerde versie van het product die van dermate hoge kwaliteit is dat de Product Owner ze in producIe zou kunnen brengen als hij dat zou willen. Bovenop deze artefacten vereist Scrum transparanIe binnen het team en met de belanghebbenden. Hiervoor maakt het Scrum Team voor iedereen zijn plannen en voortgang zichtbaar. Scrum bevat vijf acIviteiten of bijeenkomsten. Deze zijn: Product Backlog verfijning (Product Backlog Refinement), Sprint Planning, Daily Scrum, Sprint Review en Sprint RetrospecIve. We beschrijven hieronder al deze rollen, artefacten, acIviteiten en de werking van de Scrum cyclus.
Rol: Product Owner De Product Owner is de enige persoon met de verantwoordelijkheid om te bepalen wat het meest waardevolle product is binnen een bepaalde termijn of budget. Dit gebeurt door de instroom van werk naar het team te beheren en items voor de Product Backlog te selecteren en te verfijnen. De Product Owner onderhoudt de Product Backlog en zorgt dat iedereen de inhoud en prioriteiten ervan kent. De Product Owner moet één persoon zijn, maar kan geholpen worden door anderen. Natuurlijk is de Product Owner niet verantwoordelijk voor alles. Het hele Scrum Team is verantwoordelijk om zo producIef mogelijk te zijn, hun technieken en hulpmiddelen te verbeteren, de juiste vragen te stellen, de Product Owner te ondersteunen, enzovoort. Het Ontwikkelteam heeS de verantwoordelijkheid om te bepalen hoeveel werk in een Sprint opgenomen wordt en om elke Sprint een bruikbare Product Increment te creëren. En toch heeS de Product Owner in Scrum een unieke posiIe. Hij is typisch de persoon die het dichtst bij de klant staat binnen het project. De Product Owner is door de organisaIe belast met de opdracht om een bepaald product opgeleverd te krijgen. Hij is ook typisch degene van wie verwacht wordt dat hij alle belanghebbenden maximaal tevreden stelt. De Product Owner doet dit door de Product Backlog te beheren en ervoor te zorgen dat die Product Backlog en de voortgang die erin gemaakt wordt voortdurend zichtbaar is. Door te beslissen wat het Ontwikkelteam als volgende opneemt en wat het uitstelt, neemt de Product Owner de beslissingen over scope en planning die tot het best mogelijke product leiden.
Rol: Lid van het Ontwikkelteam Het Ontwikkelteam is samengesteld uit de vakmensen die samen de Product Increment opleveren. Ze zelforganiseren zich om het werk te volbrengen. Leden van het Ontwikkelteam worden verwacht om volIjds beschikbaar te zijn voor het project. Scrum vereist dat het Ontwikkelteam een mulIfuncIonele groep mensen is die samen alle nodige kennis en vaardigheden hebben om elke Product Increment op te leveren.
4
De leden van het Ontwikkelteam hebben de verantwoordelijkheid om zichzelf zo te organiseren dat ze het doel van de Sprint bereiken. En dat ze elke Sprint een Product Increment opleveren volgens het plan van de Sprint. De Product Owner maakt een geordende lijst van wat er moet gebeuren (de Product Backlog). Het Ontwikkelteam voorspelt hoeveel het in één Sprint kan afwerken en beslist hoe het dat zal doen.
Rol: ScrumMaster De ScrumMaster is een dienend leider die de rest van het Scrum Team helpt om hun proces te volgen. De ScrumMaster moet een goed begrip hebben van het Scrum framework en de subIliteiten ervan kunnen aanleren aan anderen. De ScrumMaster werkt samen met de Product Owner om hem het creëren en onderhouden van de Product Backlog te leren begrijpen. De ScrumMaster werkt samen met het Ontwikkelteam om de technieken en hulpmiddelen die nodig zijn om klaar te geraken tegen het einde van de Sprint te vinden en te implementeren. Hij werkt samen met het hele Scrum Team om de DefiniIon of Done te laten evolueren. Een andere verantwoordelijkheid van de ScrumMaster is om ervoor te zorgen dat hindernissen die het team tegenhouden of vertragen, verwijderd worden. Deze hindernissen kunnen buiten de controle van het team liggen, zoals een gebrek aan steun van een ander team, of binnen het team zoals een Product Owner die niet weet hoe hij een Product Backlog goed moet voorbereiden. De ScrumMaster ondersteunt de zelforganisaIe van het team. Problemen zouden door het team zelf moeten worden verwijderd waar mogelijk. De ScrumMaster handelt als coach voor de leden van het Scrum Team en helpt hen het Scrum proces te implementeren. Hij helpt hen om samen te werken en het Scrum framework te leren en hij beschermt hen van zowel interne als externe afleidingen. De ScrumMaster kan bijeenkomsten faciliteren en helpt om het Scrum Team producIef en op schema te houden, en hun mogelijkheden te vergroten. De ScrumMaster moet ervoor zorgen dat Scrum begrepen en geïmplementeerd wordt binnen het team en daarbuiten. Hij helpt mensen buiten het team om het proces te begrijpen en te leren welke interacIes met het team construcIef zijn en welke niet. Hij helpt ook iedereen om het Scrum Team producIever en waardevoller te maken.
Artefact: Product Backlog De Product Backlog is een essenIeel onderdeel van Scrum. Het is een geordende lijst van ideeën voor het product, in de volgorde waarin we ze verwachten uit te voeren. Het is de enige bron van waaruit alle verwachIngen geformuleerd worden. Dit betekent dat al het werk dat het Ontwikkelteam uitvoert van de Product Backlog komt. Elk idee voor een funcIonaliteit, het oplossen van een fout, een verwachIng rond documentaIe -‐ elk stukje werk dat het team doet -‐ ontstaat uit een item uit de Product Backlog. Elk item op de Product Backlog heeS minstens een beschrijving en een inschabng. 5
De Product Backlog kan starten als een lange of korte lijst. Die zou vaag of eerder gedetailleerd kunnen zijn. Typisch start een Product Backlog als een korte, vage lijst en wordt hij gaandeweg langer en meer concreet. Product Backlog items die binnenkort geïmplementeerd worden, worden verfijnd als deel van de Product Backlog verfijning. Ze worden verduidelijkt, beter gespecifieerd en in kleinere brokken opgedeeld. De Product Owner heeS de eindverantwoordelijkheid voor het produceren en onderhouden van de Product Backlog, hoewel hij hierin hulp kan en zou moeten krijgen. Product Backlog items kunnen aangebracht worden door de Product Owner, teamleden of andere belanghebbenden.
Ac?viteit: Product Backlog verfijning Product Backlog verfijning is een acIviteit die voortdurend loopt Ijdens een Scrum project. Dit komt omdat Product Backlog items iniIeel meestal groot en algemeen van natuur zijn en omdat ideeën komen en gaan en prioriteiten veranderen. Product Backlog verfijning omvat minimaal, maar is niet beperkt tot:
• De Product Backlog geordend houden. • Items die niet langer belangrijk zijn verwijderen of lager ordenen. • Items die ontstaan of belangrijker worden toevoegen of hoger ordenen. • Items in kleinere items opsplitsen. • Items samenvoegen tot grotere items. • Items inschacen. Een belangrijk voordeel van de Product Backlog verfijning is de voorbereiding voor de komende Sprints. Daarom geeS men Ijdens het verfijnen speciale aandacht aan de items die als eersten geïmplementeerd zullen worden. Hierbij zijn veel zaken waar rekening mee gehouden moet worden, onder andere:
• Elk item dat in een Sprint terechtkomt, zou ideaal gezien een verhoging van de productwaarde voor de klant moeten voorstellen.
• Het Ontwikkelteam moet in staat zijn om elk item in één enkele Sprint te bouwen. • Iedereen moet een duidelijk begrip van de verwachIngen rond een item hebben. Adankelijk van de natuur van het product zijn andere vaardigheden en informaIe nodig Ijdens Product Backlog verfijning. Het is in elk geval het beste om Product Backlog verfijning te beschouwen als een acIviteit voor alle teamleden en niet alleen voor de Product Owner.
6
Ac?viteit: Sprint Planning Elke Sprint begint met een bijeenkomst die Sprint Planning heet. In deze bijeenkomst werkt het Scrum Team samen om het werk voor de aankomende Sprint te selecteren en te begrijpen. Het hele team woont de Sprint Planning bij. Vertrekkend van de geordende Product Backlog, bespreken de Product Owner en het Ontwikkelteam elk item om tot een gedeeld begrip van dat item te komen. En om te weten wat nodig is om het volgens de DefiniIon of Done af te werken. Alle Scrum bijeenkomsten zijn beperkt in de Ijd. De aanbevolen Ijd voor de Sprint Planning is twee uur of minder per week die de Sprint duurt. Omdat de bijeenkomst in Ijd beperkt is, hangt het succes af van de kwaliteit van de Product Backlog. Daarom is Product Backlog verfijning een heel belangrijke acIviteit in Scrum. De Sprint Planning bijeenkomst bestaat uit twee delen: 1. Bepalen welke items uit de Product Backlog opgenomen worden in de Sprint. 2. Bepalen hoe dit werk volbracht zal worden. Deel 1: Welk werk wordt opgenomen? In het eerste deel van de Sprint Planning presenteert de Product Owner de geordende Product Backlog aan het Ontwikkelteam. Het hele Scrum Team werkt samen om dat werk te begrijpen. Het is enkel en alleen aan het Ontwikkelteam om het aantal items te bepalen dat in de Sprint zal opgenomen worden. Om te beslissen hoeveel items op te nemen, baseert het Ontwikkelteam zich op de huidige status van de Product Increment, het funcIoneren van het team, de huidige capaciteit van het team en de geordende Product Backlog. Alleen het Ontwikkelteam beslist hoeveel werk het in de Sprint opneemt. Noch de Product Owner, noch eender welke andere parIj kan het Ontwikkelteam meer werk opleggen. Vaak, maar niet alIjd, krijgt de Sprint een doel toegekend (Sprint Goal). Dit is een heel goede manier om als team te concentreren op de essenIe van wat gedaan moet worden. En minder op kleine details die mogelijk minder belangrijk zijn voor wat echt moet bereikt worden. Deel 2: Hoe wordt het werk uitgevoerd? In het tweede deel van de Sprint Planning werkt het Ontwikkelteam samen om te beslissen hoe het de volgende Product Increment zal opleveren in overeenstemming met de DefiniIon of Done. Ze doen net voldoende analyse en planning om vertrouwen te hebben de haalbaarheid van het werk Ijdens de Sprint. Werk dat in de eerste dagen van de Sprint zou moeten gebeuren, wordt opgesplitst in kleine brokken van één dag werk of minder. Werk dat later in de Sprint zou kunnen gebeuren, kan in grotere delen behouden worden om later op te splitsen. Het is de verantwoordelijkheid van het Ontwikkelteam om te beslissen hoe het werk moet gebeuren. Net zoals het de verantwoordelijkheid van de Product Owner is om te beslissen wat er moet gebeuren.
7
De Product Owner mag bij dit deel van de bijeenkomst aanwezig blijven om vragen te beantwoorden en misverstanden op te lossen. Hij moet in elk geval onmiddellijk beschikbaar blijven. Resultaat van Sprint Planning Op het einde van de Sprint Planning komt het Scrum team tot een gedeeld begrip van de hoeveelheid en de complexiteit van het werk dat Ijdens de Sprint zal volbracht worden. En ze verwachten dat doel ook effecIef te bereiken, afgezien van niet-‐raIonele veranderingen in de omgevingsfactoren. Het Ontwikkelteam voorspelt de hoeveelheid werk die het zal opleveren en de teamleden nemen naar elkaar toe het engagement om dat samen te volbrengen. Het Ontwikkelteam zal in de Sprint Planning:
• De items uit de Product Backlog met de Product Owner overwegen en bespreken. • Zorgen dat er voldoende gedeeld begrip rond deze items is. • Een aantal items selecteren waarvan het team voorspelt ze te kunnen te volbrengen in de Sprint.
• Een voldoende gedetailleerd plan opstellen om te verzekeren dat de geselecteerde items afgewerkt raken.
De resulterende lijst met al het werk dat moet gedaan worden, is de Sprint Backlog.
Artefact: Sprint Backlog De Sprint Backlog is de lijst van verfijnde items uit de Product Backlog die gekozen werden om in de huidige Sprint te ontwikkelen, samen met het plan van het team om dit werk te volbrengen. De Sprint Backlog geeS de voorspelling van het team weer over wat er in de Sprint kan afgewerkt worden. Als de Sprint Backlog klaar is, kan de Sprint beginnen. Het team ontwikkelt de Product Increment die door de Sprint Backlog gedefinieerd wordt.
Ontwikkeling Tijdens de Sprint zal het Ontwikkelteam zelfsturend werken om de Product Increment te bouwen volgens de Sprint Backlog, zoals die Ijdens de Sprint Planning werd opgesteld. Zelf-‐organisaIe betekent dat het team de Product Increment bouwt volgens alle standaarden van de organisaIe en volgens de DefiniIon of Done. En dat het Ontwikkelteam beslist hoe het dat het beste doet.
8
Artefact: Product Increment Het belangrijkste artefact binnen Scrum is de Product Increment. Elke Sprint resulteert in een Product Increment en deze moet van een voldoende hoge kwaliteit zijn om aan gebruikers te overhandigd kunnen worden. De Product Increment moet voldoen aan de huidige DefiniIon of Done van het team en elke component ervan moet aanvaardbaar zijn voor de Product Owner.
Andere voortgangsindicatoren Scrum vraagt transparanIe binnen en buiten het team. Hoewel de Product Increment de belangrijkste manier is om deze transparanIe te creëren, zal het Scrum Team de nodige andere artefacten ontwikkelen om de status van het project zichtbaar te maken. Enkele gebruikelijke addiIonele artefacten zijn burn-‐down grafieken en taakborden.
Afspraak: Defini?on of Done Wanneer de Product Increment wordt opgeleverd, moet hij klaar zijn volgens een gedeelde overeenkomst wat ‘klaar’ betekent. Deze definiIe is de DefiniIon of Done. Ze is verschillend voor elk Scrum Team en zal preciezer en uitgebreider worden naargelang een team meer matuur wordt. De DefiniIon of Done moet alIjd het idee bevacen dat de Product Increment van voldoende hoge kwaliteit is om klaar voor oplevering te zijn: de Product Owner moet kunnen beslissen om de Product Increment meteen in producIe te nemen na een Sprint. De Product Increment bevat alle funcIonaliteiten van alle eerdere Product Increments en is volledig getest zodat alle afgewerkte Product Backlog items goed blijven samenwerken.
Ac?viteit: Daily Scrum Het Ontwikkelteam is zelforganiserend. Het gebruikt de Daily Scrum om te verzekeren dat het op goede weg is om het doel van de Sprint te verwezenlijken. Deze bijeenkomst vindt elke dag plaats op dezelfde Ijd en plaats. Elk lid van het Ontwikkelteam geeS de volgende 3 dingen mee aan de deelnemers van de Daily Scrum:
• Wat heb ik bereikt sinds onze vorige Daily Scrum? • Wat plan ik te bereiken tussen nu en onze volgende Daily Scrum? • Wat vertraagt of voorkomt mijn voortgang? Er kunnen korte vragen gesteld en beantwoord worden, maar er gebeurt geen diepgaande discussie over deze onderwerpen. Veel teams komen vlak na de Daily Scrum samen om enkel met de directe betrokkenen te werken rond de vragen of problemen die in de Daily Scrum naar boven kwamen. De Daily Scrum is geen rapportering naar management, de Product Owner of de ScrumMaster. Het is een moment van communicaIe voor en door het Ontwikkelteam om ervoor te zorgen dat de 9
leden ervan allemaal op dezelfde golflengte zicen. Alleen de leden van het Scrum Team, inclusief de ScrumMaster en Product Owner, praten Ijdens deze bijeenkomst. Andere geïnteresseerden mogen komen meeluisteren. Gebaseerd op wat er naar boven komt in de Daily Scrum, herorganiseert het Ontwikkelteam eventueel het werk om het doel van de Sprint te bereiken. De Daily Scrum is een sleutelelement van Scrum dat leidt tot transparanIe, vertrouwen en hogere producIviteit. Het zorgt voor het snel herkennen van problemen en verhoogt de zelforganisaIe en zelfstandigheid van het team. Alle bijeenkomsten in Scrum zijn beperkt in Ijd. De duur van een Daily Scrum is niet langer dan vijSien minuten.
Ac?viteit: Sprint Review Op het einde van de Sprint evalueren het Scrum Team en de belanghebbenden de uitkomst van de Sprint. Alle bijeenkomsten in Scrum zijn beperkt in Ijd. De aangewezen duur van een Sprint Review is één uur per week die de Sprint duurde. Tijdens de Sprint Review is de Product Increment die Ijdens de Sprint werd afgewerkt het centrale punt van discussie. Aangezien de belanghebbenden ‘belang’ hebben bij deze resultaten, is het doorgaans slim en handig voor hen om deze bijeenkomst bij te wonen. De Sprint Review is een informele bijeenkomst om te kijken waar we staan en hoe we verder zouden kunnen gaan met het product. Iedereen heeS daarbij inspraak. Natuurlijk maakt de Product Owner de uiteindelijke beslissingen over de toekomst en past de Product Backlog daaraan aan. Teams zullen hun eigen manier ontwikkelen om de Sprint Review te doen. Typisch wordt een demonstraIe van de Product Increment georganiseerd. Vaak bespreekt de groep wat er gebeurde Ijdens de Sprint en welke ideeën tot stand kwamen rond het product. Ze bespreken de toestand van de Product Backlog en praten over mogelijke einddatums en wat er klaar zou kunnen zijn tegen die momenten. De Sprint Review geeS alle aanwezigen een overzicht van de huidige Product Increment. Daarom is het gebruikelijk om Ijdens de Sprint Review de Product Backlog aan te passen.
Ac?viteit: Sprint Retrospec?ve Op het einde van de Sprint komt het Scrum Team samen voor de Sprint RetrospecIve. Het doel hiervan is om te beoordelen hoe het Ijdens de voorbije Sprint ging op vlak van resultaat, proces, relaIes, technieken en hulpmiddelen. Het team bepaalt wat goed ging en wat minder goed ging en definieert mogelijke verbeteringen. Ze bouwen een plan om deze verbeteringen in de toekomst uit te voeren. Alle Scrum bijeenkomsten zijn beperkt in Ijd. De aangewezen duur van een Sprint RetrospecIve is één uur per week die de Sprint duurde. Binnen de grenzen van het Scrum framework blijvend, verbetert het Scrum Team het proces.
10
Terug naar start Vanaf hier herhaalt de Scrum cyclus zich voor elke Sprint. Om samen te vacen, werken de leden van het Scrum Team (de Product Owner, het Ontwikkelteam en de ScrumMaster) samen om een reeks Product Increments te creëren Ijdens korte, in de Ijd beperkte intervallen die Sprints heten. Elke Product Increment beantwoordt aan de acceptaIecriteria van de Product Owner en de gedeelde DefiniIon of Done van het Scrum Team. Het Scrum Team werkt vanuit de Product Backlog. Elke Sprint start met de Sprint Planning om een plan voor de Sprint, de Sprint Backlog, te produceren. Het team zelforganiseert om de ontwikkelingen uit te voeren en gebruikt de Daily Scrum bijeenkomsten om af te stemmen en te zorgen dat ze de best mogelijke Product Increment opleveren. Het team voert de Product Backlog verfijning uit om voorbereid te zijn op de volgende Sprint Planning. Het beëindigt de Sprint met de Sprint Review en Sprint RetrospecIve om het product en het proces te evalueren en verbeteren.
-‐-‐ Scrum Alliance Core Scrum v2012.12.13
11
