Scrum. F. Vonk versie

Transcriptie

1 2017 Scrum F. Vonk versie

2 inhoudsopgave 1. inleiding ontstaan van Scrum het project Sprint Scrumbord Sprintplanning Daily Scrum Meeting Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding NietCommercieel GelijkDelen 3.0 Unported licentie De afbeelding op het voorblad is verkregen via INFOwrs. Copyright 2010 INFOwrs Serviços em informatica

3 1. inleiding In deze module gaan we in op één van de vele Agile Software Development methodes (zie Wikipedia) genaamd Scrum (zie Wikipedia) en het ontstaan van dit soort methodes. Scrum wordt al een redelijke tijd gebruikt binnen de software ontwikkeling en wordt daar steeds populairder. Ook binnen andere disciplines Scrum steeds vaker toegepast binnen bedrijven. Er is veel geschreven over Agile Software Development en Scrum. Hier gaan we een zeer minimale uitvoering van Scrum beschrijven die ons helpt bij het omgaan met projecten zoals die uitgevoerd gaan worden bij het vak informatica. De sleutel tot een succesvolle afronding van een project zijn goed en duidelijk beschreven eisen. Iedereen moet weten wat er gemaakt gaat worden en het daarover eens zijn. Anders kan een team geen goed product afleveren. 1 Om tot goede eisen te komen zijn mensen en interacties van groot belang. Een klant weet verrassend genoeg vaak niet wat hij/zij precies wil en moet geholpen worden om dit helder te krijgen. Dit moet duidelijk zijn vóór het project op grote schaal van start gaat zodat er zo min mogelijk onnodig werk gedaan wordt

4 2 Daarnaast is het belangrijk om een klant snelle feedback te geven zodat hij/zij vroegtijdig de eisen kan bijstellen en het project kan bijsturen als de eisen niet accuraat genoeg waren. Alles draait om flexibiliteit en wendbaarheid, vandaar de naam Scrum, een spelsituatie uit de sport Rugby. Scrum zorgt ervoor dat deze belangrijke voorwaarden voor succes op een effectieve en efficiënte wijze worden geïmplementeerd en kunnen worden uitgevoerd. Zoals gezegd gaan we niet het volledige Scrum proces beschrijven en uitvoeren. We gaan het toespitsen op de projecten die we doen bij het vak informatica. De volgende belangrijke aspecten gaan een rol spelen tijdens onze praktische opdrachten: Sprint Scrum Board rollen Daily Scrum Meeting decompositie & deelproducten planning & tracking Deze aspecten gaan we in de volgende hoofdstukken behandelen. In deze module kom je opgaves tegen die je moet maken om de lesstof te verwerken. De antwoorden kunnen in de les besproken worden. opgave Opgaves in blauw moet je maken. Let op, links in dit document hebben een rode kleur. Veel plezier en succes

5 2. ontstaan van Scrum In de begintijd van software ontwikkeling werden projecten opgezet met behulp van de zogenaamde Waterval methode. Een schematische overzicht ervan zie je in Figuur 1. Je ziet hier de fasen staan die een typisch software ontwikkelproject doorloopt. Een fase is een tijdsduur waarin met elkaar verband houdende activiteiten worden uitgevoerd. Figuur 1: Schematisch overzicht van het Waterval model. 3 De 1 e fase bestaat typisch uit het uitzoeken en beschrijven van de eisen. Een goed opgezet project begint tijdens deze fase ook al met het uitzoeken en beschrijven hoe deze eisen getest kunnen en moeten worden. De 2 e fase is typisch het maken van de bouwtekeningen van het eindproduct. Dit noemen we bij software ontwikkeling architectuur en ontwerp. De 3 e fase is het echt maken van het eindproduct, dus het schrijven van de code voor het eindproduct. In de fase wordt elk stuk code ook al getest door de software ontwikkelaar die dat stuk code maakt. Een stuk code noemen we vaak een unit, module of component. Het testen ervan heet dan ook unit, module of component testen. Hierbij wordt iedere unit individueel getest, dus zonder andere units eraan gekoppeld. In de 4 e fase worden units samen getest tot uiteindelijk het eindproduct als geheel getest kan worden. We spreken hier van integratie en systeem testen. Integratie wil zeggen dat meerdere units aan elkaar koppelen om een deelproduct te maken. Een software product wordt ook wel software systeem genoemd, vandaar de naam systeem testen. 3 Remie Woudt; Organisatie en Systeemontwikkeling

6 De laatste fase is het onderhoud van het eindproduct. Tijdens het gebruik vindt de klant nog fouten of wil extra functionaliteit aan het product toe laten voegen. Dit gebeurt in de onderhoudsfase. Deze fase duurt vaak lang, soms wel 10 jaar, en wordt daarom anders en apart gepland en uitgevoerd. Typisch werkt een ander team aan het eindproduct gedurende deze fase. Zo'n team doet vaak het onderhoud voor meerdere verschillende software producten. Projectmanagement start natuurlijk al voor de Requirements fase en speelt tijdens iedere fase een belangrijke rol. Onder project management verstaan we het opdelen, organiseren en plannen van al het werk en de administratie die daarbij hoort. Hierbij spelen zaken zoals budgetten, bemanning, materiaal en faciliteiten ook een rol. Voor onze informatica projecten zijn deze echter niet van belang. Software projecten duurden vaak 1 of 2 jaar met als resultaat dat het eindproduct pas na lange tijd beschikbaar was voor de klant. Maar al te vaak voldeed het eindproduct dan niet goed aan de wensen van de klant, omdat: De klant niet precies wist wat hij/zij wilde aan het begin van het project. Er niet gemaakt was wat de klant had aangegeven. Wat de klant gezegd had anders geïnterpreteerd was door de software ontwikkelaars. Door tijd de situatie van de klant veranderd was. Bovendien werd er 1 keer een grote planning voor het project gemaakt met als gevolg dat deze bijna nooit klopte en projecten uitliepen. Projecten die twee of meer keer zo lang duurden als gepland waren geen uitzondering. De reden hiervoor was dat er gedurende het project weinig geleerd werd over planning. Dat was pas mogelijk aan het einde als alle fasen doorlopen waren. Zoals je ziet was de Waterval methode geen succes voor software projecten. Toch is de essentie ervan niet verkeerd en gaan we die straks weer terugzien. Alleen de opzet is niet optimaal. Agile software methodes hebben hier een oplossing voor gevonden. Zoals gezegd gaan we zo kijken naar een methode die Scrum heet. Eerst gaan we nog kort laten zien wat we onder een project verstaan

7 3. het project Een project is een organisatievorm waarin een team gezamenlijk een eindproduct gaat realiseren in een beperkte tijd en met beperkte middelen. Dit ziet is schematisch afgebeeld in Figuur 2. Figuur 2: De 3 hoofdaspecten van een project. 4 De 3 hoofdaspecten leveren een continu spanningsveld op. Moet er iets aan het eindproduct veranderen, dan heeft dat direct invloed op de tijd en/of de middelen. Hetzelfde geldt natuurlijk voor de tijd en de middelen. Laten we eens naar een voorbeeld kijken. Stel voor het eindproduct moet halverwege extra functionaliteit gemaakt worden. Mogelijk moet het project dan langer duren en dat kost uiteraard ook meer geld. Maar het kan ook zijn dat het project niet langer mag duren. In dat geval zouden er meer mensen aan het project toegevoegd kunnen worden en ook dat brengt weer kosten met zich mee. Mogelijk kun je niet meer mensen vinden om je project mee te bemannen, in dat geval kun je kijken of mensen kunnen overwerken en ook dat leidt tot meer kosten. Een aspect dat vaak over het hoofd wordt gezien is kwaliteit. Deze is feitelijk onderdeel van het eindproduct, maar wordt vaak "vergeten" of genegeerd. Met alle gevolgen van dien. 4 Remie Woudt; Organisatie en Systeemontwikkeling

8 Wat je vaak ziet gebeuren is dat wanneer men in tijdnood komt de kwaliteit ondergeschikt wordt gemaakt. Dingen worden dan afgeraffeld en erger nog, er wordt minder getest. Het gevolg daarvan is dat de klant een slecht product krijgt en dat het onderhoudsteam veel werk moet verzetten. Dit leidt niet tot een grote klanttevredenheid. Toch gebeurt het nog vaak. Kwaliteitsbewaking is daarom een belangrijk onderdeel van een project en moet serieus genomen worden

9 4. Sprint 5 Een heel belangrijke eigenschap van Scrum (en de meeste andere Agile Software Development methodes) is dat de methode iteratief is. Iteratief betekent dat het ontwikkelteam niet in één keer naar het eindproduct toewerkt maar dat er deelproducten worden gerealiseerd die stap voor stap bijdragen aan het eindproduct. Ieder deelproduct is het resultaat van een iteratie die we bij Scrum een Sprint noemen. De meeste mensen kennen het spel Pong. Als je dit spel wilt maken kun je simpelweg in één keer het spel maken. Voor een klein en eenvoudig spel als Pong is deze strategie niet eens heel slecht als je weet dat je voldoende tijd hebt om het af te krijgen. Toch kun je ook voor zo'n klein spel Scrum gebruiken en is dit zelfs de veiligste manier. Als je onverhoopt toch tegen problemen aanloopt heb je bij Scrum nog deelproducten die af zijn. In het andere geval heb je mogelijk een spel dat niet getest is en niet of niet goed werkt. Als je Pong met Scrum zou aanpakken, dan kunnen daar bijvoorbeeld de volgende deelproducten uitkomen: 1. Het speelveld met achtergrond, de batjes en het balletje. Het balletje botst tegen de batjes en de boven- en onderkant van het speelveld. Bij ieder nieuw spel wordt een andere achtergrond gekozen. Het balletje verdwijnt aan de linker- en rechterkant uit het veld als het niet geraakt wordt door een batje. 2. Het spel detecteert dat het balletje links of rechts uit het speelveld verdwijnt, houdt de score bij en zet een nieuw balletje in het veld. Het spel kan een winnaar bepalen en de winnaar van een spel kan zijn/haar naam invullen en komt in de high score. De high score wordt getoond na een spel. De snelheid van het balletje gaat omhoog naarmate de tijd vordert. 3. Er zit geluid in het spel en bij ieder nieuw spel is er een ander achtergrond muziekje. Geluid kan aan- en uitgezet worden. Er is een menu met keuze tussen twee moeilijkheidsgraden. De hoogste moeilijkheidsgraad betekent dat er kleinere batjes worden gebruikt. Ieder deelproduct is het resultaat van een Sprint en kun je laten zien aan de klant die er feedback op kan geven. Als je tijd tekort hebt en de derde Sprint kun je niet afmaken dan heb je nog steeds een speelbaar spel. Zelfs na de eerste Sprint heb je in principe een speelbaar spel al is dit niet de meest spannende oplossing

10 opgave 4.1 In de module over software testen en bug fixen heb je het spel Pac- Man gemaakt. Verdeel het werk dat gedaan moet worden voor Pac- Man in 3 Sprints. Sprints hebben een vaste tijdsduur waarvan niet afgeweken wordt. Tijdens iedere Sprint worden steeds de traditionele fasen van het softwareontwikkelproces, die je kent van het Waterval model, uitgevoerd: Het selecteren van de eisen voor de sprint. Het ontwerpen van de functionaliteit op basis van de eisen. Het implementeren van de ontworpen functionaliteit. Het testen van de gerealiseerde functionaliteit. Schematisch ziet dit alles er uit zoals afgebeeld in Figuur 3. voorbe reiding eisen selectie eind test & evaluatie test implem entatie detail ontwerp Figuur 3: Een schematisch overzicht van een iteratieve methode. Zoals je in het Pong voorbeeld ziet, moet je de totale hoeveelheid werk eerst opsplitsen in kleine brokjes werk (activiteiten). Dit noemen we work breakdown. We leggen het resultaat vast in de WBS (Work Breakdown Structure)

11 Om tot een goede WBS te komen moet je eerst weten wat je allemaal moet maken om je project succesvol af te ronden. Dit zijn de zogenaamde projectresultaten; de dingen die je aan het einde van het project in moet leveren. Via de projectresultaten bepaal je, zo goed en nauwkeurig als je kunt, alle activiteiten die je moet gaan uitvoeren tijdens je project. Dit alles documenteer je in een plan van aanpak waarvoor de "plan van aanpak leidraad" bestaat. Welke projectresultaten je moet maken vindt je uiteraard in de opdrachtbeschrijving. De WBS kun je vervolgens gebruiken in je Sprintplanningen. Om met Sprints van vaste lengte te kunnen werken en toch flexibel te blijven gebruiken we een speciale planning en tracking methode waarop we later terugkomen. Bij onze projecten werken we met Sprints van 1 week. Bij het eindproject bepaal je zelf hoe lang een Sprint duurt. Elke Sprint wordt afgesloten met een korte terugblik (retrospective), zodat je leert van deze Sprint voor de volgende Sprint. Met name op het gebied van proces en planning is dit belangrijk. Je gaat dit dus elke Sprint doen en documenteren. Hiervoor bestaat de "Sprint terugblik leidraad". Zoals je in Figuur 3 ziet, moet je voorbereidingen treffen voor je iteratief kunt gaan werken. Het starten van het plan van aanpak is daar onderdeel van. Tijdens de voorbereiding doe je de volgende dingen: Bedenken wat je wilt maken, teamgenoten zoeken en Scrumomgeving opzetten. Opdrachtbeschrijving bestuderen. Zoals gezegd, een begin maken met het plan van aanpak waarbij je tenminste de PR en WBS lijsten documenteert. Optioneel kun je planning poker doen. Een productbeschrijving maken. Eisen bedenken en documenteren. Oriënteren. Dit doe je met name om inspiratie op te doen voor je ontwerp. Positieve punten uit je oriëntatie kun je meenemen in je ontwerp. Verbeterpunten uit je oriëntatie kun je vermijden of juist omzetten in iets positiefs. Starten met het maken van een eerste ontwerp op basis van de eisen. Hiervoor zijn 3 "ontwerp leidraad" documenten die per leerlijn verschillen. Eisen beschrijven wat je wilt maken, ontwerp beschrijft hoe je dat gaat doen. Uiteraard kun je nog niet alles ontwerpen, maar wel al heel veel. Als dingen vervolgens niet lukken is dat niet erg, daar leer je juist van. Zeker als je uitzoekt waarom iets niet lukt! Als je ervaring hebt met het doen van projecten, dan kun je de voorbereiding ook in Sprints doen. Meestal heb je hiervoor 2 Sprints nodig. Hier gaan we je straks mee helpen

12 5. Scrumbord Het Scrumbord is het fysieke of virtuele bord waarop de planning en voortgang per Sprint wordt bijgehouden. Het Scrumbord kan op vele manier ingedeeld worden. Een veel voorkomende manier is het gebruiken van vier kolommen zoals je hierna ziet. Figuur 4: Voorbeeld van een Scrum Board in Trello. In het To Do gedeelte staan de activiteiten van de Sprint waar nog geen enkel teamlid aan begonnen is. Je kunt hier al activiteiten aan teamleden toekennen, maar dat hoeft niet altijd. In het In Progress gedeelte staan de activiteiten waar op dit moment door teamleden aan gewerkt wordt. Deze zijn altijd afkomstig uit het To Do gedeelte. Bij iedere activiteit is nu aangegeven wie er aan de activiteit werkt. In het To Verify gedeelte staan de activiteiten die gecontroleerd moeten worden. Bij iedere activiteit wordt aangegeven wie de activiteit gaat controleren, let op dat dit iemand anders is dan degene die de activiteit heeft uitgevoerd. In het Done gedeelte staan de activiteiten die klaar zijn

13 Aan het begin van iedere Sprint, wordt het Scrumbord gevuld met de activiteiten die je tijdens die Sprint wil gaan uitvoeren. Al deze activiteiten hangen natuurlijk in de To Do kolom. Hoe je dit doet is beschreven in het volgende hoofdstuk. We gaan ons Scrumbord maken in een virtuele omgeving die Trello heet. Deze omgeving vind je op de website van Trello. Ieder teamlid heeft toegang tot het Scrumbord en is verantwoordelijk voor en actief betrokken bij het bijhouden van het bord en de voortgang. Scrumborden worden gedocumenteerd in het plan van aanpak zoals aangegeven in de "plan van aanpak leidraad". In het Scrum proces zijn er 2 rollen, te weten de Scrum Master en de teamlid. Let op: iedereen is verantwoordelijk voor het proces, maar de Scrum Master (die overigens ook gewoon een teamlid is) handelt een aantal administratieve activiteiten af, te weten: Opzetten van het Scrumteam in Trello. Aan het begin van iedere Sprint de gezamenlijk gekozen activiteiten in de To Do kolom van het Scrumbord zetten. Het beginbord van de Sprint in het plan van aanpak zetten. Bijeenroepen en voorzitten van de Daily Scrum Meetings. Monitoren (in de gaten houden) van het Scrumbord en teamleden aanspreken wanneer ze het bord niet bijhouden. Het eindbord van de Sprint in het plan van aanpak zetten. Aan het einde van het project alles volledig en correct inleveren. Zoals gezegd is iedereen verantwoordelijk voor het proces, dus: Ieder teamlid houdt zijn/haar eigen voortgang bij op het Scrumbord. Wanneer een teamlid verzuimt zijn/haar eigen activiteiten bij te houden op het Scrumbord, dan wijzen andere teamleden hem/haar hierop. Teamleden weten van elkaar waar ze mee bezig zijn en proberen zoveel mogelijk van elkaar te leren. Teamleden bekijken en reviewen (bestuderen en becommentariëren) elkaars werk om het beter te maken. Teamleden houden elkaar op de hoogte bij afwezigheid. Als de Scrum Master afwezig is moeten de teamleden hem/haar op de hoogte houden en zijn/haar taken overnemen

14 6. Sprintplanning 6 Plannen is een onzekere activiteit. Je probeert immers in te schatten 7 hoeveel tijd je nodig denkt te hebben om een activiteit af te ronden. Ervaring helpt om beter te leren schatten maar zelfs met ervaring zijn er altijd onvoorziene omstandigheden. Daarom is plannen alleen niet voldoende en moet je ook aan tracking doen. Dat wil zeggen dat je regelmatig kijkt of je planning wel klopt. Als dat niet het geval is moet je de planning bijstellen. Bij Scrum krijg je iedere Sprint feedback over de planning en die kun je bij de planning van de volgende Sprint dus gebruiken. Ben in het begin niet bang om verkeerd te schatten! Je kunt je planning snel genoeg bijstellen. 8 Om je Sprints optimaal en toch flexibel te plannen is de MoSCoW methode uitermate geschikt. De medeklinkers in de naam van de methode zijn de categorieën waarin je eisen van de klant kunt opdelen. Eisen in de categorie Must (M) zijn eisen die je in een sprint af moet hebben. Eisen in Should (S) wil je heel graag af hebben. Feitelijk zou je een Sprint zo moeten plannen dat je alle M en S eisen ook daadwerkelijk af hebt aan het einde van de sprint. Zoals gezegd is dat lastig omdat plannen een onzekere activiteit is. Het is daarom niet erg als je een aantal S eisen niet af hebt. Maar wat als je tijd over hebt? Dat is de reden dat je de categorie Could (C) hebt. Dit zijn de eisen die je doet als je tijd over hebt in een Sprint. De laatste categorie, Won't (W) gaan we niet gebruiken. Deze wordt wel gebruikt door volledig geautomatiseerde Scrum tools maar voor ons heeft het weinig zin om voor iedere Sprint aan te geven wat we toch niet gaan doen. Het is echter wel belangrijk om dus zoveel C eisen in je Sprint op te nemen dat je van tevoren eigenlijk al weet dat je die nooit allemaal af gaat krijgen! 6 massachusetts-reverse-mortgage.com/wp-content/uploads/2011/05/puzzled-150x150.jpg 7 schatting: onnauwkeurige berekening van de waarde of grootte van iets (encyclo.nl) 8 upload.wikimedia.org/wikipedia/commons/4/40/sant_vasily_cathedral_in_moscow.jpg

15 Om de categorie van een eis of activiteit goed te herkennen op het Scrum Board, spreken we de volgende kleurcodering af: M eisen hebben de kleur groen. S eisen hebben de kleur geel. C eisen hebben de kleur oranje. Mocht je toch met W eisen willen werken dan hebben die de kleur rood. Nu volgt een overzicht van activiteiten die je per Sprint moet doen om je proces goed te laten verlopen: Activiteiten kiezen die in de Sprint uitgevoerd gaan worden en ze in het Scrumbord zetten. Activiteiten zijn dus niet alleen ontwikkelactiviteiten, maar ook ontwerp, test en documentatie activiteiten. Het Scrumbord bijhouden. Daily Scrum Meetings houden en documenteren. Dit wordt uitgelegd in het volgende hoofdstuk. Het ingeplande werk uitvoeren. Individueel uitgevoerd werk samenvoegen. Testen bedenken en documenteren voor wat je gemaakt hebt, deze uitvoeren en een testrapportage maken. Je documentatie bijhouden. Bij een deelproduct hoort documentatie die correct en volledig is. Het deelproduct archiveren, zodat je erop terug kunt vallen als dat nodig is. Ieder teamlid doet en documenteert zijn/haar eigen Scrum terugblik. Tijdens de laatste Sprint doe je nog een aantal extra dingen: Bugs die gevonden zijn tijdens het testen worden gedocumenteerd maar niet meer opgelost. Ieder teamlid doet en documenteert zijn/haar eigen evaluatie van het project. Alle projectresultaten volledig en correct inleveren. Begin met hard werken! In het begin kom je namelijk de meeste onzekerheden en risico's tegen en pas als je die hebt weggenomen wordt je project voorspelbaarder. Op deze manier werken voorkomt stress! opgave 6.1 Je gaat straks van start met de eerste Sprint van je project. Daarvoor moet je echter eerst bedenken wat je wilt gaan maken en met wie. Daarnaast moet je teamgenoten zoeken. Kies ook alvast een Scrum Master

16 Ieder teamlid maakt een Trello account aan, doe dit via je schoolmailadres. De Scrum Master maakt een team aan in Trello en nodigt alle teamleden uit. De teamnaam begint met de aanduiding van je informatica cluster, bijvoorbeeld H4in1, H5in1, V4in2. De Scrum Master maakt binnen de teamomgeving het Scrumboard voor de eerste Sprint aan. Terwijl de Scrum Master bezig is, eventueel met hulp van een ander teamlid, maken de overige teamleden alvast een opzet (voorblad en inhoudsopgave) voor het verslag. Vervolgens ga je gezamenlijk het Scrumbord voor de eerste Sprint inrichtingen. Zet de volgende activiteiten in de To Do kolom. Voor de activiteit is de MoSCoW categorie aangegeven tussen haakjes. Er wordt hieronder uitgegaan van 4 teamleden. (M) Initiële scrumbord in verslag zetten. (M) Opdrachtbeschrijving bestuderen en PR lijst maken. (Individueel, dus staat 4x op het bord.) (M) Individueel PR lijst detailleren. (4x) (M) Individuele PR lijsten in verslag zetten (naam erbij!). (M) PR lijsten samenvoegen tot 1 PR lijst. (M) Uiteindelijke PR lijst in verslag zetten. (M) Individueel WBS maken. (4x) (M) Individuele WBS lijsten in verslag zetten (naam erbij!). (M) WBS lijsten samenvoegen tot 1 lijst. (M) Uiteindelijke WBS in verslag zetten. (M) Uiteindelijke scrumbord in verslag zetten. (M) Daily Scrum Meeting houden en notuleren (2x) (M) Scrum terugblik. (4x) (S) Productbeschrijving maken. (S) Verslag netjes maken. (S) Indeling voor verslag bedenken en kopjes aanmaken. (C) Inschatten hoe lang iedere activiteit in uiteindelijke WBS duurt. (4x) (C) Planning poker spelen. (C) Uiteindelijke schattingen in verslag zetten

17 7. Daily Scrum Meeting 9 Deze meeting wordt ook wel de Stand-Up Meeting genoemd. De reden is dat bij deze bijeenkomst iedereen staat in plaats van zit. Uit onderzoek is gebleken dat vergaderingen die staand worden gehouden doorgaans minder lang duren en even effectief zijn, zie onder andere APA PsycNET. Aan het begin van de eerste les van de week (Sprint) wordt de Sprintplanning gedaan. Aan het begin van de andere 2 lessen van de week (Sprint) houd je een Daily Scrum Meeting. Deze wordt bijeengeroepen en voorgezeten door de Scrum Master. De meeting duurt maximaal 5 minuten, maar liefst korter. Zorg dat je tijdens deze meeting je Scrum Board open hebt staan. In deze meeting geeft ieder teamlid het volgende aan: lig ik op planning, wat heb ik sinds vorige keer (inclusief huiswerk!) afgekregen, wat ga ik deze les doen en heb ik problemen die mijn voortgang hinderen. Om toerbeurt maakt iemand notulen van de meeting en deze neem je op in je Plan van Aanpak, zie "plan van aanplak leidraad". De notulist mag zitten! In de meeting besproken procesproblemen worden gedocumenteerd in het Plan van Aanpak, productproblemen worden gedocumenteerd in het Ontwerp Document. Tijdens de meeting wordt besloten wie wat documenteert. opgave 7.1 Voer de eerste Sprint uit. Zorg dat je je voortgang netjes bijhoudt op het bord gedurende de Sprint