SCRUM. voor Dummies. boeksamenvatting (aangevuld met andere bronnen)

SCRUM voor Dummies

boeksamenvatting (aangevuld met andere bronnen)

Deze samenvatting is “as is”. Er mogen geen enkele rechten aan ontleend worden en is niet bedoeld of geschikt als lesmateriaal. Het is een privé samenvatting zonder enige pretentie geschikt te zijn voor enig ander doel dan mijn persoonlijke studie. Alle rechten ©2016, R.Brinkman – www.rudybrinkman.nl

Wat is Scrum Scrum is een manier om in teams heel effectief werk te verrichten. Scrum is een Agile methodiek. Scrum benadrukt dat nieuwe inzichten altijd optreden zodra je aan de slag bent en je als team wendbaar wilt zijn om de beste inzichten in je voordeel te kunnen gebruiken. Scrum heeft maar een paar regels, twee lijsten, drie rollen en vier bijeenkomsten. Het is bewust 'klein' gehouden. Daarmee is het breed toepasbaar, eenvoudig te onthouden, en.. zorgt er voor dat je zelf altijd goed moet blijven nadenken! Het schrijft zo weinig voor dat je zelf moet kiezen hoe je scrum toepast in een specifieke situatie. Wat scrum niet is? – Het is niet het antwoord op al je problemen; – het schrijft niet voor wat je in iedere situatie moet doen; – het is géén methode die je stap voor stap voorschrijft wat te doen of waaraan te voldoen. Wat het wel is? – scrum is een lichtgewicht Agile methodiek; – het ultieme proces om alle mogelijkheden en onmogelijkheden zichtbaar te maken; – het haalt het beste uit teams; – transparant, zichtbaar → van werkvoorraad tot afspraken, van resultaat tot samenwerking, van planning tot voortgang. – Het dwingt teams éérst te doen wat het belangrijkste is en dat gebaseerd op concrete zichtbare doelen; – het zorgt er voor dat je het lang vol kunt houden, door een vast ritme en een duidelijke nadruk op kwaliteit. Scrum werkt met iteraties → korte periodes (sprints) die tot een resultaat leiden. Dit resultaat is een potentieel “verscheepbaar product”. Dat product is dus gedocumenteerd, getest, geïntegreerd enz!

Samenvatting – Scrum voor Dummies – 2/16

Agile manifesto Scum is een “Agile” methodiek. Het Agile Manifesto stelt: •

mensen en hun interactie zijn belangrijker dan processen en tools;

•

werkende software is belangrijker dan uitgebreide documentatie;

•

samenwerking met de gebruikers is belangrijker dan contractonderhandelingen;

•

tegemoetkomen aan voortschrijdend inzicht is belangrijker dan werken volgens het vooraf bepaalde plan.

Vijf Scrum principes Scrum kent de onderstaande belangrijke, vijf, principes: •

Toewijding: de leden moeten zich er vol voor inzetten; het is geen deeltijdklus.

•

Focus: men moet zich focussen op wat er in de sprints gedaan moet worden – focus op het belangrijkste en beperk daar de focus op.

•

Openheid: men moet elkaar goed op de hoogte houden van de voortgang en mogelijke problemen. (transparantie)

•

Respect: men moet mensen met een andere achtergrond en expertise respecteren.

•

Lef: men moet lef hebben om zaken te benoemen, vragen te stellen en met nieuwe oplossingen te komen.


De Rollen Scrum kent drie rollen: 1. product owner → verantwoordelijk voor het 'wat' en vertegenwoordigt alle belanghebbenden, de stakeholders. De product owner bepaalt of iets werkelijk voldoet aan de eisen en of het dus in productie mag (Definition of Done). De product owner bepaald wat er gemaakt wordt en sorteert (prioriteert) daarom de product backlog. Wie? Degene nemen die er het mééste belang bij heeft dat het product ook daadwerkelijk live gaat in productie! Hij, of zij, is namelijk de eigenaar van de 'business case' en daarmee gemotiveerd om het product te maken c.q. in productie te krijgen! Taken: ◦ De Product owner neemt eigenaarschap van het product, is veranwoordelijk voor de succesvolle realisatie: op tijd, binnen budget en met tevreden klanten; ◦ er is maar één product owner! De product owner neemt de beslissingen over het product. ◦ Full time job, … ! ◦ de voornaamste taak van de product owner is het backlog management: constant (her)prioriteren van de items op de product backlog zodanig dat de producten met de meeste waarde voor de stakeholers, de business, bovenaan staan. Dit zijn de producten met de hoogste waarde en relatief laagste kosten. Backlog Grooming of product refinement behelst dus het prioriteren van de backlog. ◦ De product backlog is een communicatie-middel! Hiermee communiceert de product owner dus met de 'buitenwereld' en het team.. ◦ stakeholder management ▪ inventariseren stakeholders – wie hebben er belang bij het product? ▪ Meetings met stakeholders. Er zijn twee meetings waar stakeholders zijn uitgenodigd als deelnemers: Sprint planning en Sprint Review. En bij de daily scrum zijn ze natuurlijk welkom om te luisteren. ◦ Werken met het development team.... ◦ release management → het is de uitdaging voor de product owner om een zo minimaal mogelijke set van eisen en wensen te selecteren waarmee op een verantwoorde manier live gegaan kan worden. Dit zijn de Minimal Viable Products of Minimal Marketable Features. ◦ Motiveren team → visie statement! Herhalen, onder de aandacht brengen. ◦ Releasen! 2. het team → het werk wordt gedaan door het team, ook wel Development Team genoemd. Het team werkt samen aan het behalen van de door de product owner gestelde doelen. Het team bepaalt zelf hoe ze dit doen. Ook het schatten wordt door het team gedaan. De ideale team-omvang is minimaal 3 tot maximaal ca. 9 mensen. Rol & taak van het team ◦ Het team voert al het werk uit om van een wens van de product owner te komen tot een werkend product. Analyse, ontwerp, architectuur, implementaties, testen, installatie en documentatie. Samenvatting – Scrum voor Dummies – 4/16

◦ Het team werkt in iteraties. Dit betekent constant feedback genereren en daarop handelen; ◦ het team doet de belangrijkste zaken eerst → bovenste items product backlog naar de sprint backlog en die uitvoeren; ◦ schattingen geven → aan de taken worden punten toegekend die worden geschat. Dit is een taak van het team. Zij schatten alle items op de product backlog, en regelmatig vindt er een refinement plaats. De schatting wordt daardoor steeds beter, mede door onder andere de ervaring die opgedaan wordt, voortschrijdend inzicht, etc. Hiervoor kan onder andere gebruik worden gemaakt van plannig poker e.d. → zie “De Meetings” ◦ het team maakt de sprint backlog → taken aan de muur hangen, voortgang bijhouden in de sprint burndown chart. en dan... ◦ het werk doen! 3. De scrummaster → zorgt er voor dat scrum goed wordt toegepast. Dat de spelregels in acht worden genomen, en zorgt dat alles soepel draait – de olie in de machine. Belemmeringen die het team tegenkomt of ervaart worden door de scrummaster uit de weg geruimd. Communicatie naar het management, door scrum uit te leggen en de consequenties van het gebruik er van. Proactief naar buiten toe, faciliterend voor het team en de product owner. Taken: ◦ zorgt er voor dat scrum goed wordt toegepast, het naleven van de spelregels van scrum en er (zodoende) voor zorgen dat het proces optimaal verloopt; ◦ wegnemen van belemmeringen (“impedements”) uit de omgeving. Impedements zijn zaken die het team er van weerhouden om beter of sneller te gaan. Het wegnemen er van is dus een belangrijke taak voor de scrum master. Immers: daardoor kan het team beter haar werk doen. Je bent echter géén projectsecretaris. Wat het team zélf kan doen, moeten ze zelf doen! Het gaat dus om échte belemmeringen, voornamelijk vanuit de organisatie – bijvoorbeeld gerelateerd aan de nieuwe manier van werken. ◦ zorgen dat zo veel mogelijk mensen en partijen aansluiten zodat de gang naar productie steeds makkelijker wordt. Vier verantwoordelijkheden, samengevat: ▪ steun voor scrum organiseren; ▪ bewaken van de spelregels; ▪ wegnemen belemmeringen; ▪ bewerkstelligen veranderingen in de organisatie. ◦ Shu Ha Ri → de drie stadia van meesterschap (Japans). ▪ Shu → spelregels onder de knie krijgen; ▪ Ha → alle regels volg je inmiddels en binnen regels ontwikkel je eigen strategie en tactiek; ▪ Ri → Meesterschap is bereikt, tactiek en strategie zijn zo sterk ontwikkeld dat je de regels ter discussie stelt en loslaat. ◦ Voel je niet verantwoordelijk voor bijvoorbeeld het motiveren van het team, dat zijn taken van de product owner; Samenvatting – Scrum voor Dummies – 5/16

◦ neem geen taken van het team over, dit verbloemd mogelijk problemen terwijl Scrum juist bedoeld is om die zichtbaar te maken (transparantie!) ◦ Communiceer de spelregels van scrum → zie de spiekbrief in boek; Scrum Team Het scrum team is het gehele team, dus alle rollen. In het spraakgebruik wordt het development team echter (ook) het team genoemd... als het Scrum Team wordt bedoelt, dan wordt het zo genoemd: Scrum Team. Bedoelt men het development team, dan worden de vaak aangeduidt met 'het team'.

De Lijsten Scrum kent twéé lijsten: 1. product backlog → alle wensen en eisen die het product beschrijven worden hier op bijgehouden → de “product backlog items”. Vaak worden ze ook de “Stories” genoemd. Maar dat zijn niet de enige items, er kunnen ook andere zaken op staan bijv. technische eisen, normen, e.d. Waaraan voldaan moet worden. Ook problemen, bugs, etc kunnen op de product backlog voorkomen. Stories is dus niet een begrip waarmee alles afdoende wordt afgedekt. Het beheer wordt gedaan door de product owner. De lijst is altijd gesorteerd op waarde voor de business. De lijst is tevens voorzien van schattingen, door het team. De voortgang wordt bijgehouden in de Release Burndown Chart. De 'stories' zijn iets anders dan user stories. User Stories zijn korte beschrijvingen van wat een gebruiker wil en kent het format: Als een {rol gebruiker/stakeholder} Wil ik {wens} Zodat {voordeel}

Een user story is bedoeld om de wensen van de gebruikers te beschrijven zodat het team een inschatting kan geven van het benodigde werk er voor. Bij user stories horen acceptatiecriteria en daaruit kan je ook weer test-criteria afleiden. Inschatten Zodra de product backlog is vastgesteld en gesorteerd op basis van waarde voor de business moeten ze worden ingeschat – relatieve schatting van de inspanning die nodig is om het te realiseren. De héle backlog moet worden ingeschat, niet alleen de bovenste items! Korte backlog Het verdient aanbeveling de backlog zo kort mogelijk te houden door bijvoorbeeld items te clusteren, minder detaillering toe te passen etc. Zo'n 80 items is een behapbaar maximum. 2. Sprint backlog → alle items die in de sprint worden gemaakt staan op de sprint backlog en worden daar op gezet vanuit de product backlog. Dit zijn dus de bovenste items van de product backlog (de belangrijkste). Van de voortgang wordt een Sprint Burndown Chart bijgehouden. Het aantal items op de sprint backlog wordt bepaald door de velocity van het team → de snelheid. Verder wordt er rekening gehouden met de bezetting van de sprint. Kies zoveel werk als je kunt waarmaken op basis van recente resultaten! De sprint backlog is een hulpmiddel voor het team om tijdens de sprint het werk te verdelen. Samenvatting – Scrum voor Dummies – 6/16

Detaillering bij de detaillering van de items moet je niet verder detailleren dan nodig is maar voldoende om je te kunnen committeren. De items kunnen vervolgens in taken worden uitgewerkt. Bijvoorbeeld zaken als – navigatie ontwerpen; – menu aanpassen; – schermen maken; – database aanpassen; – configuratiebestanden maken (etc) Planning → bord Het scrum bord kent de kolommen: “TODO”, “DOING”, “DONE”. Extra stappen mogen, maar schrap ze zodra het team daar klaar voor is en hou het zo overzichtelijk en 'simpel' mogelijk. Bijwerken wordt door het team gedaan. Definition of Done Wanneer is het werk 'done' oftewel klaar? In Scrum betekent 'done' → het kan in productie. De definition of done wordt opgesteld door de product owner, hij bepaalt aan welke criteria moet worden voldaan voor iets in productie kan, in samenspraak met het Development Team. Dat kan dus per product verschillen. Het team kan de product owner hierin goed ondersteunen en adviseren – bijvoorbeeld over technische eisen, testen, e.d. Onderdelen van de definition of done: 1. de code is geschreven en voldoet aan de afgesproken programmeer standaarden; 2. de code is gedekt door unit testen en heeft een dekkingsgraad van minimaal 90%; 3. het werk is functioneel getest; 4. er is documentatie voor de onderdelen die dat nodig hebben – installatiehandleiding, release notes, beschrijving van de werking van de oplevering voor beheerdoeleinden; 5. geverifieerde integratietesten – integratie met externe systemen, databases ed; 6. performance is getest; 7. geïnstalleerd op acceptatie-omgeving, door Beheer, op basis van de geleverde documentatie Door deze manier van werken wordt wat de mééste waarde heeft voor de product owner (de stakeholders) als eerste gemaakt en opgeleverd. Er zijn dus twéé backlog's met beide hun eigen Burndown Chart! Burndown Charts Release Burndown – bewaking van de voortgang; – hoort bij product backlog; – is van de product owner; – opstellen op basis van de “verbrande” punten ten opzicht van het totaal in tijd. Een 'neergaande lijn' waarmee je einddatum kunt prognotiseren. Samenvatting – Scrum voor Dummies – 7/16

Sprint Burndown – bewaking voortgang sprint; – hoort bij de sprint backlog; – is van het team; – geeft antwoord op de vraag hoeveel werk er in de sprint is gedaan ten opzichte van de planning – kan per story of per taak worden bijgehouden. Een burn down chart moet nooit op basis van uren worden bijgewerkt. Dat is immers nietszeggend want die Scrum wordt voortgang pas gemeten, en alléén gemeten, als een taak 'af' is.

De Meetings Er zijn vier meetings in Sprint en alle meetings zijn getimeboxed – van te voren wordt afgesproken hoe lang ze duren en er wordt nooit langer over gedaan. Korter mag uiteraard wel! 1. Sprint planning Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint planning meetings, die is opgedeeld in twee delen. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team. De Sprint planning meeting beantwoordt de volgende vragen, en is verdeeld in twee delen hiervoor: 1. In Sprint Planning 1 komende de volgende vragen aan de orde: Wat kan worden geleverd aan het einde van de komende Sprint? Waaróm moet dit worden opgeleverd? → stakeholders mogen aanwezig zijn hierbij. 2. Hoe wordt het benodigde werk, om dit Product Increment te leveren, uitgevoerd1) In Sprint Planning 2 wordt het werk dat vastgesteld is in planning 1 opgesplitst in kleinere delen – verantwoordelijkheid team! Dit heeft als doel het werk te verdelen. → stakeholders zijn hierbij niet aanwezig want “team aangelegenheid” (en vaak veel technische zaken) Aan het einde van de sprint planning geeft het team aan hoeveel van de items het denkt te kunnen verwezenlijken. De product owner is bij Sprintplanning 1 & 2 aanwezig. Het Team spreekt daarna haar vertrouwen uit (commitment) – Twijfel? Praat met product owner over de hoeveelheid werk! Definition of ready De lijst van zaken waaraan een item op de product backlog moet voldoen voordat deze klaar is om in een sprint te worden opgenomen → intake criteria waaraan moet worden voldaan. Deze definitie is geen vast onderdeel van scrum maar wordt in de praktijk wel veel gebruikt. Op een Definition of Ready staan zaken als: het team heeft tot in detail het item besproken, er is een schatting beschikbaar, een demo scenario aanwezig, schatting is 13 punten of minder of een kwart van de velocity (anders wordt het te groot voor een sprint en een te groot item kan er toe leiden dat het team bij een impedement 'niets zit te doen' omdat er geen andere items meer zijn om op te pakken!). Een definition of ready zou voor een goed team niet nodig moeten zijn, een uitgebreide definition of done echter wel.

1 http://www.scrum.nl/site/Scrum-Begrippen-agile-scrum#Sprint planning meeting Samenvatting – Scrum voor Dummies – 8/16

2. Daily Scrum → kort en staande gehouden werkoverleg van maximaal 15 minuten. De Daily Scrum is publiek – er mogen toehoorders aanwezig zijn, zij mogen zicht echter niet mengen in de scrum. Het is geen rapportage aan wie dan ook. De vragen die de deelnemers beantwoorden zijn: 1. Wat heb ik gedaan sinds de vorige meeting? 2. Wat ga ik doen tot de volgende meeting? 3. Welke issues heb ik en welke hulp heb ik daar bij nodig? 3. Sprint Review → aan het einde van de sprint wordt het werk van het team, het resultaat van de sprint, aan de product owner en de stakeholders getoond. Het doel hiervan is om feedback te krijgen. Deze meeting wordt vaak 'de demo' genoemd maar dat doet de meeting tekort omdat de demo het middel is, niet het doel. Het doel is feedback, vandaar ook de naam Sprint Review! De sprint review is een meeting waarin wederzijds begrip wordt gekweekt. Het is namelijk nooit zo dat je vooraf kan beschrijven wat je precies nodig hebt of hoe het moet worden gebouwd. De meeste wensen veranderen tijdens de productontwikkeling en traditioneel wordt er twee keer meer gevraagd dan nodig is. De meeste veranderingen ontstaan door gewijzigde requirements – het is dus duur om iets te maken en pas véél later te horen dat het toch anders moest (changes). Bij de review wordt aan de stakeholders gepresenteerd wat er is gemaakt in de sprint. En de vraag is nu “wat vinden ze er van?”. Daarbij wordt alleen dat getoond dat helemaal klaar is. Niet helemaal af = niet af. Geen “shippable product” en dus ook niet tonen. Het is het beste als het team de demo doet en ook zelf regelt. Zo leren ze ook de stakeholders kennen en vice versa. Verwerk de feedback van de stakeholders – niet in de verdediging schieten! Alle feedback is waardevol, niemand heeft ongelijk, er hoeft ook niet ter plekke te worden besloten dat de stakeholder gelijk heeft of welke stakeholder gelijk heeft (als ze van mening verschillen bijvoorbeeld). Het is ook heel normaal dat een stakeholder achteraf niet blij is met wat er geleverd wordt – ook al heeft hij er zelf om gevraagd want: soms is wat een stakeholder bedoelde iets anders of pakt de functionaliteit anders uit dan dat hij had gedacht. Acties bepalen Als gevolg van de review moeten er potentieel acties worden genomen. Het laatste deel van de sprint review is bedoeld om te bepalen welke acties dat zijn. Extra refinement? Bespreken in Retrospective? Kunnen we naar productie? 4. Sprint Retrospective → na de sprint review volgt de laatste meeting, de Retrospective. Hier kijkt het team terug naar de afgelopen periode, sprint, en kijkt hoe ze zichzelf kan verbeteren. Benoemen zaken die goed gaan, bespreken zaken die beter kunnen. Afspraken maken over de te ondernemen acties.


Een goede retrospective is essentieel voor continue verbetering. Een goede retrospective bestaat uit vier delen. 1. Setting the stage (sfeer maken) → een atmosfeer waarin de teamleden zich op hun gemak voelen, een veilige omgeving waarin vrijheid is kritiek te geven, krijgen, fouten te bespreken; 2. Gather data (data verzamelen, wat is er gebeurt?) → belangrijk om te kijken wat er allemaal gebeurd is in deze sprint – wat is er gemaakt, hoe was de samenwerking, hoe was de stemming, waren er verrassingen etc. 3. Generate insights (inzicht vergaren) → als er problemen waren deze van meerdere kanten bekijken, niet direct één oplossing kiezen. Alternatieven bekijken. Probeer ook inzicht te krijgen in wat er goed ging en waaróm dat goed gaat. Zodat je dat kunt herhalen, blijven toepassen. 4. Decide what to do (acties) → een goede retrospective leidt tot acties. Er zijn met name drie categorieën acties: 1. werkafspraken → bijv. tijd daily scrum verplaatsen, meer pair programming enz. 2. aanpassingen aan de Definition of Done → bijv. dekkingsgraad test verhogen; 3. Product Backlog items → een aanpassing in de definition of done kan leiden tot nieuwe backlog items, bijv. refactoring, nieuwe of gewijzigde technieken, meer testen etc.

De Sprint De sprint dient de volgende doelen: – het brengt focus aan → concentratie op een aantal items; – het is mogelijk commitment aan te gaan → een korte periode is overzichtelijk en goed te plannen; – periodes vergelijken met elkaar is makkelijker en het leereffect komt sneller om de hoek kijken! – Risicomanagementstrategie → iedere sprint weer moet iets werkends worden geleverd. Daardoor kom je een groot aantal risico's die bij een waterval pas veel later zichtbaar zijn nu elke sprint naar voren omdat je in elke sprint analyse, bouw, test, documentatie én oplevering doet. Na een paar sprints heb je de meeste risico's dus wel gezien. En weet je hoe je daar mee om moet gaan! De sprint heeft een vaste lengte, vanwege bovenstaande. Aan die lengte valt niet te tornen. Als je een sprint van twee week afspreekt kan die niet opeens 2,5 of 3 week worden. Maar ook niet korter. Een sprint heeft nu eenmaal een vaste lengte. Dit is ook ideaal voor planningen en afspraken. Je weet op voorhand wanneer de Sprint Planning, Review en Retrospective is bijvoorbeeld. En dus kunnen stakeholders dat in de agenda zetten. Iedere twee week een oplevering naar beheer → dan weet exploitatie en beheer wat en wanneer ze dat kunnen verwachten.

Meerdere Scrum Teams? Niet doen. Zeker niet direct in het begin!!! En als het echt niet anders kan een soort van 'celdeling' toepassen maar pas later in het traject. Scum-meetings van de teams gelijktijdig, daarna een 'Scrum of Scrums'. Bij twee teams is er nog één product owner en één product backlog, bij 3 of meer wordt dit allemaal heel lastig (meerde backlogs, meerdere product owners). Samenvatting – Scrum voor Dummies – 10/16

Tien redenen om Scrum te gebruiken 1. meer waar voor je geld Het is duidelijk waar aan en waarvoor gewerkt wordt. De Time-to-Market kan drastisch worden ingekort; 2. meer controle empirisch proces (gebaseerd op waarneming) – er is vroeg informatie beschikbaar over voortgang, producten, etc; 3. tevreden gebruikers de gebruiker wordt betrokken en niet uit het oog verloren; 4. hogere kwaliteit; 5. busines case validatie bij een onzeker avontuur 'in het diepe springen'. Na een paar week weet je dan vanzelf of het gaat lukken of niet – in plaats van allerlei dure vooronderzoeken, consultants, analyses en ontwerpen... ; 6. aansluiten bij opdrachtgever directe betrokkenheid tussen opdrachtgever en nemer is beter, de opdrachtgever wordt immers betrokken bij het Scrum proces (product owner!); 7. minder bureacratie door meer transparantie en grote focus – geen CAB's e.d! 8. (op)schalen kleine organisaties Scrum is een mooie methode voor kleine startups die nog helemaal geen proces hebben om, zodra ze groeien, een vorm van procesmatig werken te gaan hanteren; 9. kennisdeling Het is met Scrum onmogelijk om niet ook maar een béétje specialist van het gebruikersdomein te worden! 10. LOL Meer plezier in het werk, meer voldoening, door meer verantwoordelijkheid en invloed op je werk, autonomie, passie, vakmanschap.


Begrippenlijst http://www.scrum.nl/site/Scrum-Begrippen-agile-scrum

Agile Overkoepelend gedachtegoed voor methodieken en frameworks voor software ontwikkeling, die voldoen aan de pricipes zoals gesteld in het Agile Manifesto: • • • •

Mensen en hun onderlinge interactie boven processen en hulpmiddelen Werkende software boven allesomvattende documentatie Samenwerking met de klant boven contractonderhandelingen Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd. Backlog Refinement Het verduidelijken, verbeteren, prioriteren en schatten van de Product Backlog. Vaak gebeurt dit in een workshop met het team en de Product Owner, waarin gezamenlijk wordt gekeken naar de details van de Product Backlog items. Corporate backlog Een geprioriteerde lijst met doelen, acties en producten die een bedrijf wil gaan leveren of uitvoeren. Cross-functional team Samenwerking tussen en over de verschillende functies heen / functie-overschrijdende samenwerking. Bijvoorbeeld wanneer software ontwikkelaars, informatie analisten, testers, ontwerpers in één team. Daily Scrum Elke dag houdt het team een korte meeting van 15 minuten die Daily Scrum of Daily Standup wordt genoemd. Het doel van deze meeting is zorgen dat iedereen zo effectief mogelijk bezig is. Om de meeting kort en effectief te houden blijft iedereen staan en beantwoord de volgende 3 vragen: • • •

Wat heb ik gedaan sinds de vorige meeting? Wat ga ik doen tot de volgende meeting? Welke issues heb ik en welke hulp heb ik daar bij nodig?

Definition of Done De Definition of Done beschrijft waar het resultaat van een Sprint aan moet voldoen. Het is een hulpmiddel voor het team om de kwaliteit van het werk constant te houden. De Definition of Done wordt door het team zelf opgesteld en beschrijft dingen als testen, unittesten, documentatie enz. Development Team Een cross-functioneel, zelfsturend team, van minimaal 3 en maximaal 9 personen. Zij zijn verantwoordelijk voor het opleveren (en hebben daarvoor de juiste personen) van een potentieel ‘verscheepbaar’ gedeelte van het product, aan het eind van de sprint. Epic Een epic heeft dezelfde vorm als een User story, alleen omvat deze een grotere scope. Happiness metric De Happiness metric kan worden gebruikt om het gevoel in een team te meten. Hoe blij/gelukkig zijn de teamleden. Tevens geven de teamleden aan wat er moet gebeuren om hun gevoel te verbeteren.


(Shippable) Increment Het product dat het Scrum team aan het einde van een sprint oplevert. Het product voldoet aan de afgesproken Definition of Done. Het moet in bruikbare conditie zijn. Ongeacht of de Product Owner daadwerkelijk besluit het product op de markt te brengen. Pair programming Twee software ontwikkelaars samen achter een computer zitten en aan code werken. Planning poker Planning poker is een format om een relatieve schatting te maken van de ' implementation effort' van een Product backlog item. Het gaat hierbij vooral om de conversatie. Iedereen geeft door middel van kaarten aan hoeveel werk een Backlog Item inhoudt. Verschillen in die inschatting worden besproken waarna het kaarten zich herhaalt totdat er consensus wordt bereikt. De discussie die deze manier van inschatten oplevert zorgt ervoor dat iedereen betrokken is. Portfolio backlog High-level backlog op portfolio niveau (die gebruikt wordt in het Scaled Agile Framework) Het is een geprioriteerde lijst van epics of features die voor de toekomst op de planning staan. Product backlog De Product backlog is een lijst met het resterende werk voor het product. Alle Product backlog items zijn voorzien van een waarde, bijvoorbeeld waarde voor de business. De items worden door het team van een relatieve inschatting voor de hoeveelheid werk voorzien. Op basis van de verwachtte waarde en de vereiste inspanning kan de Return On Investment (ROI) berekend worden. De Product Backlog kan op basis van de ROI worden geprioriteerd, maar bijvoorbeeld ook op afhankelijkheden met andere Product backlog items. Items die hoger geprioriteerd zijn, zijn over het algemeen duidelijker gespecificeerd, zodat de items opgenomen kunnen worden in een volgende sprint. Product backlog items Alles wat er op een product backlog staat is een product backlog item. Product Backlog items hebben als kenmerken een beschrijving, ordening, een schatting en een waarde. Product backlog management Goed Product Backlog management omvat o.a.: • Helder omschrijven van Product Backlog items • Ordenen van Product Backlog items, om doelen en missie op de beste manier te behalen • Optimaliseren van de waarde van het werk dat het Development team uitvoert • Ervoor zorgen dat de Product backlog zichtbaar, transparant en duidelijk is voor iedereen, en dat het laat zien waar het Scrum Team aan gaat werken. • Ervoor zorgen dat het Development team de Product backlog items begrijpt tot het niveau dat benodigd is. Product Owner De Product Owner is verantwoordelijk voor het bijhouden van de Product Backlog, door het vertegenwoordigen van de belangen van alle stakeholders. Tevens is de Product Owner verantwoordelijk voor het maximaliseren van de waarde van hetgeen het development team oplevert. De Product Owner is één persoon, geen comité. Project Start Architecture document Een Project Start Architecture is bedoeld om vooraf te borgen dat nieuwe ontwikkelingen en veranderingen welke in een project gerealiseerd gaan worden passen binnen bestaande en/of toekomstige organisatie- of domeinarchitectuur. Reference architecture Een template oplossing voor een architectuur binnen een domein. De referentie architectuur kan gebruikt worden om een gezamenlijk uitgangspunt te hebben om over software implementaties te discussiëren en kan Samenvatting – Scrum voor Dummies – 13/16

dienen als uitgangspunt om de uiteindelijke architectuur vorm te geven. Release burn-down chart Een grafiek die aangeeft hoeveel van de release nog gerealiseerd moet worden. De grafiek loopt af, naar een vooraf besproken doel. Release burn-up chart Een grafiek die aangeeft hoeveel van een release al is gerealiseerd. Elke sprint komt er weer een nieuw increment bij, waardoor de release burn-up groeit en dichterbij het einddoel komt. Requirements Alle eisen en wensen die een klant stelt aan de software. Dit kunnen onder andere functionele eisen, performance eisen, beheer eisen of klantwensen zijn. Roadmap Een roadmap is een prestatie- en doelgericht plan. In de roadmap wordt niet op de details ingegaan. Rollen Er zijn 3 rollen binnnen Scrum; de Product Owner, die de belangen van de klant vertegenwoordigt; de Scrum Master die het proces ondersteunt en het team, die in een korte tijd werkende software kan opleveren. Scrum Een framework/kader waarbinnen mensen complexe en bewerkelijke problemen kunnen aanpakken, terwijl ze productiever en creatiever producten kunnen leveren van de hoogst mogelijke waarde. Scrum Master De Scrum Master is een diendende leider die verantwoordelijk is voor het Scrum proces. Hij zorgt ervoor dat Scrum op de juiste manier wordt ingezet om zodoende maximale waarde door het development team te laten creëren. Servant leader De servant leader is een leider die, in tegenstelling tot een traditionele leider of manager, de verantwoordelijkheid deelt met zijn medewerkers, de behoefte van anderen voorop stelt en mensen helpt zich te ontwikkelen en het beste uit zichzelf te halen. Sprint Een time-box van een maand of minder, waarin een werkend software increment wordt opgeleverd, dat voldoet aan de definitie van "Done". Elke sprint is dezelfde lengte gedurende de gehele ontwikkeltijd en volgen elkaar direct op. Sprint Backlog De Sprint Backlog is de verzameling Product Backlog items die geselecteerd zijn voor de Sprint, inclusief het plan voor opleveren van het Product Increment en voor de realisatie van het Sprint Doel. De Sprint Backlog is een voorspelling door het Ontwikkelteam over de functionaliteit die aanwezig zal zijn in het volgende Increment en het werk dat nodig is om die functionaliteit te leveren in een “Klaar” Increment. De Sprint Backlog maakt al het werk zichtbaar dat het Ontwikkelteam heeft geïdentificeerd als noodzakelijk voor behalen van het Sprint Doel. De Scrum methode is iteratief. Elke iteratie wordt een ‘Sprint’ genoemd. Een Sprint duurt 2 tot maximaal 4 weken. Binnen deze tijd pakt het team een vooraf geselecteerde hoeveelheid werk op wat helemaal afgemaakt wordt. Het resultaat van elke Sprint is een stukje werkende software. Daardoor is het product snel bruikbaar en krijgt het team snel feedback op het product en het proces. Sprint burn-down chart Dagelijkse voortgang van een sprint, aangegeven over de lengte van de sprint. Samenvatting – Scrum voor Dummies – 14/16

Sprint planning meeting Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint planning meeting. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team. De Sprint planning meeting beantwoordt de volgende vragen: • •

Wat kan worden geleverd aan het einde van de komende Sprint? Hoe wordt het benodigde werk, om dit Product Increment te leveren, uitgevoerd?

Sprint Retrospective De Sprint wordt afgesloten met de Sprint Retrospective. Tijdens deze meeting kijkt het team terug op het werkproces, de samenwerking, gebeurtenissen en de kwaliteit van de afgelopen Sprint. Dit heeft als doel om beter te worden. Alles wat niet goed ging moet worden aangepakt, zodat in volgende Sprints niet dezelfde fouten gemaakt kunnen worden. Punten die uit de Retrospective komen, zijn bij voorkeur ‘actionable’. Sprint Review Een Sprint Review wordt gehouden aan het einde van de Sprint om het Increment te inspecteren en indien nodig de Product Backlog aan te passen. Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen wat er bereikt is gedurende de Sprint. Op basis hiervan en op basis van veranderingen in de Product Backlog, werken de aanwezigen samen aan de volgende stappen die genomen kunnen worden om waarde te optimaliseren. Dit is een informele bijeenkomst, geen status meeting, en de presentatie van het Increment heeft als doel feedback te verzamelen en samenwerking te bevorderen. Scrum Board Het Task Board, of Scrum Board, is een bord waar alle Sprint Backlog Items hangen. De taken op het bord zijn verdeeld over 3 kolommen: To Do, In Progress en Done. De belangrijkste taken hangen bovenaan het bord. De Sprint Backlog is daarmee ook gesorteerd op prioriteit. Samen met de Sprint burn-down chart geeft dit bord in één oogopslag inzicht in de huidige status. Het Scrum Board is voor het team de centrale plaats om het resterende werk en de aanpak af te stemmen. Team Het team is multidisciplinair en zelfsturend. Dat betekent dat het team zelfstandig in staat is alle taken van ontwerp, realisatie, testen tot en met de oplevering te verzorgen. Het team bestaat uit 5 tot en met 9 deelnemers. Het team is verantwoordelijk voor zowel het inplannen als het uitvoeren van het werk tijdens een Sprint. Het bijzondere van Scrum is dat het team zelf verantwoordelijk is voor het werkproces. Door elke Sprint af te sluiten met een evaluatie wordt continue gewerkt aan verbeteringen aan dit proces. Team Velocity De Velocity is de hoeveelheid werk die het team in één Sprint kan wegwerken. Tijdens elke Sprint wordt de hoeveelheid werk bijgehouden. Op basis van deze Velocity kan het team inschatten hoeveel werk het per Sprint aankan. Test Driven Development Een toepassing in Software ontwikkeling, waarin begonnen wordt met het schrijven van een test, die initieel faalt. Daarna wordt de software geschreven om de test te laten slagen. De falende test laten slagen is dus het uitgangspunt om de software te schrijven. Timebox Een afgesproken tijdskader waarbinnen een activiteit wordt uitgevoerd. Een Daily Scrum heeft bijvoorbeeld een timebox van 15 minuten. User Stories Een Product Backlog Item dat beschrijft ‘wat’ en ‘waarom’ de klant deze functionaliteit wil hebben. Het ‘hoe’ staat niet in de Story, omdat dit aan het team wordt overgelaten in de Sprint Planning meeting. User stories worden als volgt geschreven: Als (gebruiker), wil ik (feature), zodat ik (reden waarom/achterliggende Samenvatting – Scrum voor Dummies – 15/16

behoefte) Value Management Techniek om voortgang te meten aan de hand van geleverde waarde. Velocity De Velocity is de hoeveelheid werk die het team bewezen heeft af te kunnen maken in één sprint. Tijdens elke Sprint wordt de hoeveelheid opgeleverd werk bijgehouden. De velocity is een hulpmiddel voor tijdens de Sprint planning meeting.


SCRUM. voor Dummies. boeksamenvatting (aangevuld met andere bronnen)

Recommend Documents