Het Agile Manifest is het document waarin agile software-ontwikkeling is gedefinieerd en bevat de belangrijkste principes van agile werken. In dit artikel geven we een Nederlandse vertaling van dit document.Agile, letterlijk wendbaar of behendig, is een van de populairste stromingen binnen software-ontwikkeling. Agile zelf is geen methode maar een verzamelnaam. Er zijn meerdere agile methodes (o.a. Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming). Deze zijn tussen 1980 en 1999 onafhankelijk ontwikkeld op basis van de eigen ervaring van verschillende experts. Het gemeenschappelijke kenmerk van de methodes is dat ze allemaal minder bureaucratie nastreven. In 2001 zijn zeventien uitvinders van agile methodes bij elkaar gekomen in Utah om de overeenkomsten tussen we verschillende methodes te bespreken. Uiteindelijk zijn zij tot een hele korte tekst gekomen en ook op het woord ‘agile’. Deze tekst heet het Agile Manifesto en is de enige definitie van agile. Hieronder is een Nederlandse vertaling gegeven inclusief de achterliggende principes
Wij ontdekken betere manieren om software te ontwikkelen door het in de praktijk te doen en door anderen ermee te helpen. Door dit werk waarderen we:
Mensen en hun onderlinge samenwerking 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 de zaken aan de rechterkant enige waarde hebben, vinden wij de zaken aan de linkerkant belangrijker.
Principes achter het Agile Manifest
We volgen de volgende principes:
Onze hoogste prioriteit is het tevredenstellen van de klant door het vroeg en voortdurend opleveren van waardevolle software.
We verwelkomen veranderende requirements (eisen), zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.
Lever regelmatig werkende software op. Liefst iedere paar weken, minimaal iedere paar maanden.
Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.
Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.
Werkende software is de belangrijkste maat voor voortgang.
Agile processen bevorderen constante ontwikkelsnelheid. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.
Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agile werken
Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.
De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
Het team onderzoekt op vaste tijden hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.
Oefening “Voorbeelden aub?”
Vat de vier uitgangspunten van het manifest kort samen.
Laat de studenten per uitgangspunt in 60-90 seconden een voorbeeld noteren.
Elke student leest hardop zijn of haar voorbeeld. Laat vervolgens de groep een keus maken wiens voorbeeld het beste is en noteer deze op het bord(bij besluiteloosheid mag je er voor kiezen om er twee te noteren).
Scrum is een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Deze leerlijn beschrijft de definitie van Scrum. Deze definitie bestaat uit de Scrum rollen, gebeurtenissen, artefacten en de regels die deze zaken samenbrengen. Jeff Sutherland en Ken Schwaber hebben Scrum ontwikkeld; de Scrum leerlijn is door hen geschreven en ter beschikking gesteld. Zij staan samen achter deze leerlijn.
Geschiedenis
Jeff Sutherland en Ken Schwaber hebben samen Scrum voor het eerst gepresenteerd tijdens de OOPSLA conferentie in 1995. Deze presentatie documenteerde datgene wat Jeff en Ken geleerd hadden gedurende de voorgaande jaren bij het toepassen van Scrum.
De geschiedenis van Scrum wordt nu al beschouwd als lang. Ter ere van de eerste plekken waar het werd geprobeerd en verfijnd noemen we hier Individual, Inc., Fidelity Investments, en IDX (nu GE Medical).
Ls1 Scrum Overzicht
Deze les heeft als doel dat jij:
Weet wat Scrum is
Weet wat de theorie achter Scrum is
Weet hoe een Scrum Team is samengesteld
Weet welke Scrum gebeurtenissen er zijn
Weet welke Scrum artefacten er zijn
Scrum (n): Een raamwerk waarbinnen mensen complexe, adaptieve problemen adresseren en tegelijkertijd op een productieve en creatieve wijze producten van de hoogst mogelijk waarde leveren.
Scrum is:
Lichtgewicht
Simpel om te begrijpen
Extreem moeilijk om te leren beheersen
Scrum is een procesraamwerk dat sinds de jaren 1990 gebruikt wordt om complexe productontwikkeling te managen. Scrum is geen proces of techniek voor het bouwen van producten; het is een raamwerk waar binnen je de verschillende processen en technieken kunt inzetten. Scrum maakt de effectiviteit van jouw productmanagement en ontwikkeltechnieken inzichtelijk zodat je kunt verbeteren.
Het Scrum raamwerk bestaat uit Scrum Teams en hun bijbehorende rollen, gebeurtenissen, artefacten en regels. Elk onderdeel binnen het raamwerk dient een specifiek doel en is essentieel voor het gebruik en succes van Scrum.
De regels van Scrum verbinden de gebeurtenissen, rollen en artefacten met betrekking tot de interactie tussen hen. De regels van Scrum worden beschreven door deze hele tekst heen.
Specifieke strategieën voor het gebruik van het Scrum raamwerk verschillen en worden niet in deze leerlijn behandeld.
Scrum Theorie
Scrum is gebaseerd op de theorie van empirische procesbesturing , ofwel het empirisme.
Empirisme gaat er vanuit dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Scrum gebruikt een iteratieve, incrementele aanpak om voorspelbaarheid te optimaliseren en risico’s te beheersen.
Drie pijlers vormen het fundament van elke implementatie van empirische procesbesturing: transparantie, inspectie en aanpassing.
Transparantie
Significante aspecten van het proces moeten zichtbaar zijn voor diegenen die verantwoordelijk zijn voor het resultaat. Transparantie vereist dat deze aspecten gedefinieerd zijn volgens een gezamenlijke standaard zodat waarnemers een gezamenlijk begrip hebben van wat er gezien wordt. Bijvoorbeeld:
Een gemeenschappelijke taal met betrekking tot het proces moet door alle deelnemers worden gedeeld; en,
Een gemeenschappelijke definitie van “Klaar” (“Definition of Done”) moet worden gedeeld door degenen die het werk uitvoeren en degenen die het werkende product accepteren.
Inspectie
Scrum gebruikers moeten frequent de Scrum artefacten en de voortgang ten opzichte van het doel inspecteren, om ongewenste variantie te kunnen detecteren. Hun inspecties mogen niet zo frequent zijn dat de inspecties in de weg gaan zitten van het werk. Inspecties zijn het meest nuttig wanneer ze zorgvuldig worden uitgevoerd door vaardige inspecteurs, daar waar het werk gedaan wordt.
Aanpassing
Als een inspecteur bepaalt dat één of meer aspecten van een proces buiten de acceptabele limieten vallen en dat het resulterende product onacceptabel zal zijn, zal het proces of het onderhanden werk aangepast moeten worden. Een aanpassing moet zo snel mogelijk uitgevoerd worden om verdere afwijkingen te minimaliseren.
Scrum schrijft vier formele gelegenheden voor ten behoeve van inspectie en aanpassing, zoals beschreven in het Scrum Gebeurtenissen gedeelte van deze leerlijn.
Sprint Planning
Dagelijkse Scrum
Sprint Review
Sprint Retrospective
Het Scrum Team
Het Scrum Team bestaat uit een Product Owner, het Ontwikkelteam en een Scrum Master. Scrum Teams zijn zelforganiserend en multidisciplinair. Zelforganiserende teams kiezen zelf hoe zij het beste hun werk kunnen uitvoeren, in plaats van dat dit verteld wordt door iemand van buiten het team. Multidisciplinaire teams hebben alle competenties die nodig zijn om het werk uit te voeren, zonder afhankelijk te zijn van anderen buiten het team. Het team model in Scrum is ontworpen voor optimale flexibiliteit, creativiteit en productiviteit.
Scrum teams leveren iteratief en incrementeel producten, waarbij gelegenheden voor feedback gemaximaliseerd worden. Incrementele leveringen van een “Klaar” (Done) product zorgen ervoor dat een potentieel bruikbare versie van het product altijd beschikbaar is.
De Product Owner
De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product en de werkzaamheden van het Ontwikkelteam. Hoe dit precies gedaan wordt verschilt enorm per organisatie, Scrum Team en individu.
De Product Owner is de enige persoon die verantwoordelijk is voor het managen van de Product Backlog. 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 Ontwikkelteam uitvoert;
Ervoor zorgen dat de Product Backlog zichtbaar, transparant en duidelijk is voor iedereen, en dat het laat zien waar het Scrum Team als volgende aan gaat werken; en
Ervoor zorgen dat het Ontwikkelteam de Product Backlog items begrijpt tot het niveau dat nodig is.
De Product Owner kan het bovenstaande werk zelf uitvoeren, of het door het Ontwikkelteam laten doen. In elk geval blijft de Product Owner verantwoordelijk.
De Product Owner is één persoon, geen comité. De Product Owner kan de wensen van een comité vertegenwoordigen via de Product Backlog, maar iedereen die een verandering wil in prioriteit van een Backlog Item, moet de Product Owner aanspreken.
Om te kunnen slagen als Product Owner, moet de gehele organisatie zijn of haar beslissingen respecteren. De beslissingen van de Product Owner zijn zichtbaar in de inhoud en ordening van de Product Backlog. Niemand mag het Ontwikkelteam aan een andere set van requirements laten werken het en het Ontwikkelteam is het niet toegestaan te acteren op basis van wat iemand anders zegt.
Oefening “Mind Reading”
Deze oefening is bedoeld om het belang van nauwe samenwerking met de productowner te begrijpen door vragen te stellen om de succescriteria te achterhalen. Stel de openingsvraag: “Zijn bij de start van een project de succescriteria duidelijk of onduidelijk?” Hoe worden de onduidelijkheden duidelijk? – besteed ongeveer 3-4 minuten aan discussies.
Verdeel de klas in een 5 groepen en geef een ieder een 3 A4tjes.
Sprint 1: Wijs een “vrijwillige” PO aan, zet de PO apart en fluister het ‘product’ -bijvoorbeeld *. Vraag de groepsleden om in 5 minuten iets te maken met het papier waarvan zij denken dat de PO het zou willen hebben. Breng de PO terug en laat deze rond gaan en de gemaakte producten aannemen of afwijzen. Bespreek hoe het voelt om problemen op te lossen onder deze omstandigheden en beoordeel de resultaten.
Sprint 2: Wijs een andere “vrijwillige” PO aan, zet de PO apart en fluister het ‘product’ -bijvoorbeeld *. Informeer de groepsleden ze 5 minuten hebben om uitsluitend met behulp van Ja/Nee vragen te weten moeten komen wat ze moeten doen én het product te maken. Bespreek hoe het voelt om problemen op te lossen onder deze omstandigheden en beoordeel de resultaten.
Sprint 3: Wijs een andere “vrijwillige” PO aan, zet de PO apart en geef ze afgedrukte maak-instructies van iets -bijvoorbeeld *. Informeer de groepsleden ze 5 minuten hebben om met vragen te weten moeten komen wat ze moeten doen. Geef daarnaast nog 5 minuten om het product te maken en te verfraaien. Bespreek hoe het voelt om problemen op te lossen onder deze omstandigheden en beoordeel de resultaten.
Leerpunten:
Het opmerken van de frustratie van het moeten “Gedachten lezen” ten opzichte van de mogelijkheid om vragen te stellen.
Om resultaten te maken zijn de juiste antwoorden op vragen nodig en is dus een PO nodig maar niet vanzelfsprekend.
Welke vragen stel ik als er veel onduidelijkheden zijn en hoe voorkom ik dat ik dichtklap.
*zie lesplan
Het Ontwikkelteam
Het Ontwikkelteam bestaat uit professionals die het werk doen om een potentieel uitleverbaar Increment van het “Klaar” (Done) product op te leveren aan het einde van elke Sprint. Alleen leden van het Ontwikkelteam creëren het Increment.
Ontwikkelteams zijn zodanig gestructureerd en voorzien van bevoegdheden door de organisatie dat zij hun eigen werk kunnen organiseren en beheren. De resulterende synergie optimaliseert de algehele efficiëntie en effectiviteit van het team.
Ontwikkelteams hebben de volgende karakteristieken:
Ze zijn zelfsturend. Niemand (zelfs de Scrum Master niet) vertelt het Ontwikkelteam hoe zij de Product Backlog moeten omzetten in Incrementen van potentieel uitleverbare functionaliteit;
Ontwikkelteams zijn multidisciplinair, met alle benodigde vaardigheden om als team een product Increment te kunnen maken;
Scrum erkent geen titels voor Ontwikkelteamleden anders dan Ontwikkelaar, ongeacht het werk dat door de persoon wordt uitgevoerd; er zijn geen uitzonderingen op deze regel;
Ontwikkelteams omvatten geen subteams die toegewijd zijn aan een specifiek domein zoals testen of business analyse; er zijn geen uitzonderingen op deze regel; en,
Individuele Ontwikkelteamleden kunnen specifieke vaardigheden of focusgebieden hebben, maar verantwoordelijkheid ligt bij het Ontwikkelteam als geheel.
Ontwikkelteam grootte
De optimale Ontwikkelteam grootte is klein genoeg om wendbaar te blijven en groot genoeg om significant werk te kunnen leveren binnen een Sprint. Minder dan drie Ontwikkelteamleden maakt dat interactie vermindert en resulteert in lagere productiviteitswinst. Kleinere Ontwikkelteams kunnen tegen een gebrek aan vaardigheden aanlopen tijdens de Sprint, wat resulteert in het niet kunnen opleveren van een potentieel uitleverbaar Increment. Meer dan negen leden in het team vereist teveel coördinatie. Grote Ontwikkelteams genereren teveel complexiteit om door een empirisch proces bestuurd te kunnen worden. De Product Owner en de Scrum Master worden hierin niet meegeteld tenzij zij ook werk van de Sprint Backlog uitvoeren.
Oefening “The Name Game”
Vaak denken studenten dat ze over sterke multitaskingvaardigheden beschikken, maar meestal is het inefficiënt. Dit is een snelle en eenvoudige oefening om te laten zien hoe inefficiënt multitasken eigenlijk is. Het laat zien hoe vaak ontwikkelaars tegelijkertijd aan verschillende projecten werken en dat uiteindelijk elke klant maar een deel van zijn tijd krijgt en er zelfs last van heeft omdat hun projecten langer duren.
De ontwikkelaar moet de namen van zijn klanten op een kaart noteren om ze zo snel mogelijk tevreden stellen. Zodra de tijd begint, vertellen de klanten de ontwikkelaar hun namen en kan hij slechts één letter van elke naam tegelijk schrijven. Zodra een naam is ingevoerd, wordt de kaart aan de klant gegeven die heeft vastgelegd hoe lang het duurde om het te krijgen.
In de tweede ronde moet de ontwikkelaar elke naam één voor één schrijven. En nogmaals, de klant moet de tijd noteren die het duurde om de naam te krijgen vanaf het moment dat de ontwikkelaar het begon op te schrijven. Natuurlijk zullen ze het sneller krijgen dan in de eerste ronde.
Leerpunten:
Het focussen op één taak tegelijk helpt om betere kwaliteit, snellere levering, gelukkiger klanten en minder verspilde tijd te krijgen.
De Scrum Master
De Scrum Master is ervoor verantwoordelijk dat Scrum wordt begrepen en goed wordt uitgevoerd. Scrum Masters doen dit door ervoor te zorgen dat het Scrum Team zich houdt aan de Scrum theorie, praktijk en regels.
De Scrum Master is een dienend leider voor het Scrum Team. De Scrum Master helpt diegenen buiten het Scrum Team te begrijpen welke van hun interacties met het Scrum Team behulpzaam zijn en welke niet. De Scrum Master helpt iedereen deze interacties te veranderen om zo de waarde die door het Scrum Team wordt gecreëerd te maximaliseren.
Scrum Master diensten aan de Product Owner
De Scrum Master dient de Product Owner op een aantal manieren, waaronder:
Het vinden van technieken voor een effectief Product Backlog management;
Het Scrum Team de noodzaak laten inzien om duidelijke en beknopte Product Backlog items te maken;
Inzicht verkrijgen in de product planning in een empirische omgeving;
Ervoor zorgdragen dat de Product Owner weet hoe de Product Backlog te ordenen zodat de maximale waarde verkregen kan worden;
Inzicht verkrijgen in en het beoefenen van agility; en,
Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig.
Scrum Master diensten aan het Ontwikkelteam
De Scrum Master dient het Ontwikkelteam op een aantal manieren, waaronder:
Coachen van het Ontwikkelteam op het vlak van zelforganisatie en multidisciplinair werken;
Het Ontwikkelteam helpen bij het maken van producten van hoge waarde;
Het verwijderen van belemmeringen (‘impediments’) in de voortgang van het Ontwikkelteam;
Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig; en,
Het coachen van het Ontwikkelteam in organisatorische omgevingen waarbinnen Scrum nog niet volledig is opgenomen en begrepen.
Scrum Master diensten aan de Organisatie
De Scrum Master dient de organisatie op een aantal manieren, waaronder:
Het leiden en coachen van de organisatie in haar Scrum adoptie;
Plannen van Scrum implementaties in de organisatie;
Helpen van medewerkers en belanghebbenden bij het begrijpen en doorleven van Scrum en empirische productontwikkeling;
Initiëren van veranderingen die de productiviteit van het Scrum Team verhogen; en,
Met andere Scrum Masters samenwerken om de effectiviteit van de toepassing van Scrum binnen de organisatie te verhogen.
Scrum Gebeurtenissen
Binnen Scrum worden voorgeschreven gebeurtenissen(ceremonies) gebruikt om regelmaat te creëren en om de behoefte aan overige, niet in Scrum gedefinieerde bijeenkomsten te minimaliseren. Scrum maakt gebruik van timeboxes bij gebeurtenissen, zodat elke gebeurtenis aan een maximale tijdsduur is gebonden. Als een Sprint eenmaal begonnen is, is de duur niet meer aanpasbaar en kan dus niet ingekort of verlengd worden. De andere gebeurtenissen mogen eindigen zodra het doel van de gebeurtenis is bereikt, zodat de juiste tijd wordt gespendeerd aan planning zonder waardevermindering (“waste”) van het planning proces.
Anders dan de Sprint zelf, die een container is voor alle andere gebeurtenissen, is elke gebeurtenis in Scrum een formele gelegenheid om iets te inspecteren en aan te passen. Deze gebeurtenissen zijn specifiek ontworpen om kritieke transparantie en inspectie mogelijk te maken. Het niet opnemen van één van de deze gebeurtenissen resulteert in een vermindering van transparantie en is een gemiste kans voor inspectie en aanpassing.
Scrum Artefacten
De artefacten van Scrum vertegenwoordigen werk of waarde die waardevol zijn voor het bieden van transparantie en voor mogelijkheden tot inspectie en adaptie. De artefacten die Scrum definieert zijn specifiek ontworpen voor maximale transparantie van sleutelinformatie zodat iedereen hetzelfde begrip heeft van het artefact.
Artefact Transparantie
Scrum is gebouwd op transparantie. Beslissingen die genomen worden om de waarde te optimaliseren en risico’s te beheersen, worden genomen op basis van de waargenomen toestand van de artefacten. Voor zover de transparantie compleet is, hebben deze beslissingen een goede basis. Als de artefacts niet geheel transparant zijn, kunnen deze beslissingen verkeerd zijn, neemt waarde af en neemt risico toe.
De Scrum Master werkt met de Product Owner, het Ontwikkelteam, en andere betrokken partijen om duidelijk te krijgen of de artefacten volledig transparant zijn. Er zijn practices voor het omgaan met onvolledige transparantie; de Scrum Master moet iedereen helpen om de meest toepasselijke practices te gebruiken in geval van absentie van volledige transparantie. Een Scrum Master kan onvolledige transparantie detecteren door de artefacten te inspecteren, patronen te herkennen, nauwkeurig te luisteren en verschillen te vinden tussen verwachtingen en resultaten.
Het is de taak van de Scrum Master om met het Scrum Team en de organisatie de transparantie van de artefacten de vergroten. Dit werk behelst meestal leren, overtuigen en verandering. Transparantie zal niet plotsklaps plaatsvinden; het is een traject.
Ls2 Visie op eindproduct
Bij de start van een Scrum-project moeten minimaal de producten Visie en Product Backlog aanwezig zijn voordat het scrumteam begint met de ontwikkeling van het systeem/product (Ken Schwaber). Een product backlog, zijnde een geprioriteerde werklijst, is meestal wel aanwezig. Een gezamenlijke visie op het eindproduct ontbreekt daarentegen nogal eens in scrum-projecten. Toch is een gezamenlijk visie essentieel om richting te geven aan het project en om continue gefocust te blijven op het leveren van meerwaarde voor de business. Bovendien kan een inspirerende visie zeer motiverend werken op het team.
Deze les heeft als doel dat jij:
Weet wat een Product Vision is
Begrijpt hoe een PV wordt samengesteld
Begrijpt waarom een PV wordt samengesteld
Een PV kan samenstellen
Product Vision
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geïnteresseerde Wanneer: begin van een project. Timebox: één tot twee uur Doel: uitleggen wat en waar dit product/systeem voor is Input: kennis van de markt of de business Output: Product Vision (minder dan 60 woorden) Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs & chickens Van wie: product owner Door wie: product owner
Inhoud visie
De product owner is verantwoordelijk voor het creëren en uitdragen van de visie. Hiermee geeft hij aan wat het eindproduct in essentie behelst en wat de toegevoegde waarde daarvan is. Een heldere visie geeft kort maar krachtig antwoord op de volgende vragen:
Voor wie maken we het systeem/product? Wie zijn de klanten/gebruikers?
Waarom willen zij het systeem/product kopen/gebruiken? Welke meerwaarde heeft het systeem/product voor hen?
Wat zijn de Kritieke Succes Factoren? Welke eigenschappen moet het systeem/product zondermeer hebben?
Hoe onderscheidt het systeem/product zich van de concurrenten/alternatieven? Wat zijn de Unique Selling Points?
Is zo’n systeem/product technisch en financieel haalbaar?
Kortom: De visie geeft aan wat het doel van het project is en welke systeem/producteigenschappen daarbij cruciaal zijn.
Aandachtspunten
Het is niet eenvoudig om een goede visie te creëren. Het vereist een vooruitziende blik, inlevingsvermogen en verbeeldingskracht. Daarnaast is diepgaande kennis van de markt of de business waarvoor het systeem/product bedoeld is nodig. Hieronder volgen een aantal aandachtspunten voor het ontwikkelen van een visie.
Gezamenlijke visie
Het is van belang dat alle betrokkenen zoals scrumteam, management, gebruikers en andere stakeholders, hetzelfde beeld hebben van het eindproduct. Zonder gezamenlijk visie is er geen gezamenlijk doel en dat leidt vroeg of laat tot problemen en tegengestelde belangen. Een gezamenlijke visie versterkt het teamgevoel en bevordert de samenwerking.
Kort en krachtig
Een goede visie geeft in zo weinig mogelijk woorden de essentie van het eindproduct weer. De visie moet voldoen aan de ‘elevator test’. De visie bevat geen opsomming van de belangrijke systeem/producteigenschappen maar alleen de 3 of 4 cruciale eigenschappen. Dit laat ruimte voor het vinden van creatieve oplossingen.
Feedback vragen
Een visie is geen vaststaand gegeven. De behoeften van klanten/gebruikers kunnen bijvoorbeeld wijzigen of verkeerd ingeschat zijn. Toets daarom de visie zo vroeg en zo vaak mogelijk en stel hem bij als dat nodig is. Nodig gebruikers uit op sprint review meetings en vraag om feedback. Breng zo snel mogelijk een eerste release uit om te zien hoe de klanten/gebruikers erop reageren en vraag welke functionaliteit ze graag toegevoegd zien.
Eerstvolgende release
Een visie is bij voorkeur gericht op de eervolgende release van het systeem/product. Dit is een concreet doel en geeft een tijdshorizon die goed te overzien is. Bij agile ontwikkeling wordt vaak eens per kwartaal een release uitgebracht.
Oefening “Design De Doos”
Laat de studenten in groepen van 4-6 in 120min de verpakking van hun product ontwerpen, dit is een in krimpfolie gewikkelde doos. Voornaamste taak is om de voor- en achterkant te ontwerpen. Dit betekent dat er in ieder geval aandacht moet worden besteed aan:
De productnaam
Een logo
3-4 USP’s(unique selling points)
Een gedetaileerde beschrijving van het product
Korte gebruiksaanwijzing
Ls3 Product Backlog
Deze les heeft als doel dat jij:
Weet wat een Product Backlog is
Weet welke onderdelen in een PB horen
De Product Backlog is een geordende lijst van alles dat mogelijk nodig is in het product, en is de enige bron van requirements voor wijzigingen die aan het product gemaakt moeten worden. De Product Owner is verantwoordelijk voor de Product Backlog, inclusief de inhoud, beschikbaarheid en ordening.
Een Product Backlog is nooit compleet. De eerste versies ervan bevatten alleen de initieel bekende en best begrepen requirements. De Product Backlog ontwikkelt zich naar gelang het product en de omgeving waarin het gebruikt gaat worden zich verder ontwikkelen. De Product Backlog is dynamisch: hij verandert voortdurend om duidelijk te maken wat het product nodig heeft om toepasbaar, concurrerend en bruikbaar te zijn. Zolang het product bestaat, bestaat de bijbehorende Product Backlog ook.
De Product Backlog somt alle kenmerken, functies, requirements, verbeteringen en foutherstel op die gezamenlijk de wijzigingen zijn die in toekomstige releases aan het product gemaakt moeten worden. Product Backlog items hebben als kenmerken een beschrijving, ordening, een schatting en een waarde.
Vanaf het moment dat het product gebruikt wordt en waarde oplevert, en de markt terugkoppeling levert, wordt de Product Backlog een grotere en meer uitputtende lijst. Requirements blijven altijd veranderen, en dus is de Product Backlog een levend artefact. Veranderingen in bedrijfseisen, marktomstandigheden of technologieën kunnen veranderingen in de Product Backlog tot gevolg hebben.
Meerdere Scrum Teams werken vaak samen aan hetzelfde product. Één Product Backlog wordt gebruikt om het aankomende werk op het product te beschrijven. Er wordt dan een Product Backlog attribuut gebruikt om items te groeperen.
Product Backlog verfijning (“refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog onderhoud worden items gereviewed en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog items kunnen op elk moment worden bijgewerkt door de Product Owner of naar de Product Owner’s eigen beoordeling.
Product Backlog items met een hogere rangorde zijn normaliter duidelijker en meer gedetailleerd dan die met een lagere rangorde. De schattingen zijn meer precies vanwege de hogere mate van duidelijkheid en detaillering. Hoe lager de rangorde, hoe minder details. De Product Backlog items waarmee het Ontwikkelteam de komende Sprint aan de slag gaat zijn zo ver verfijnd dat elk item “Klaar” kan zijn binnen een Sprint. De Product Backlog items die door het Ontwikkelteam “Klaar” kunnen zijn binnen een Sprint worden beschouwd als “Ready” voor selectie in een Sprint Planningsbijeenkomst. Product Backlog items verkrijgen deze mate van transparantie over het algemeen door de verfijningsactiviteiten die hierboven besc hreven staan.Het Ontwikkelteam is verantwoordelijk voor alle schattingen. De Product Owner mag het Ontwikkelteam beïnvloeden door te helpen bij het begrijpen en maken van afwegingen, maar de mensen die het werk moeten doen maken de uiteindelijke schatting.
Controleren op de voortgang tot een doel
Op elk moment in de tijd kan het totale werk, dat nog nodig is om een doel te bereiken, worden opgeteld. De Product Owner houdt de totale resterende hoeveelheid werk bij, op zijn minst voor elke Sprint Review. De Product Owner vergelijkt dit totaal met de resterende totale hoeveelheid werk uit eerdere Sprint Reviews om een inschatting te maken of het resterende werk binnen de gewenste tijd kan zijn afgerond voor het gestelde doel. Deze informatie wordt transparant gemaakt voor alle stakeholders.
Verschillende technieken voor trendanalyse: burndown, burnup en andere predictie-methoden zijn gebruikt om voortgang te voorspellen. Deze zijn nuttig gebleken. Echter, ze vervangen niet het belang van empirisme. In complexe omgevingen is niet bekend wat er in de toekomst gaat gebeuren. Alleen wat er is gebeurd mag gebruikt worden voor toekomstgerichte besluitvorming.
Ls4 Product Backlog: nieuwe en geprioriteerde eisen en wensen
Deze les heeft als doel dat jij:
Begrijpt hoe een PB wordt opgesteld
Begrijpt waarom een PB wordt opgesteld
Een voorlopige PB kan opstellen
Raw Product Backlog
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: begin van een project. Timebox: één tot twee uur Doel: alle eisen en wensen documenteren Input: alle eisen en wensen en de Product Vision Output: Raw Product Backlog Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs & chickens Van wie: product owner
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.
Ls5 Product Backlog: Vertaal eisen en wensen naar Epics en User Stories
Deze les heeft als doel dat jij:
Weet wat een User story is
Begrijpt waarom user stories worden gemaakt
Weet aan welke kenmerken een goede US voldoet
User stories kan maken
Een PB kan opstellen
Product Backlog
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: begin van een project. Timebox: één tot twee uur Doel: alle eisen en wensen vertalen naar user stories Input: Raw Product Backlog Output: Product Backlog Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs & chickens Van wie: product owner
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. Alhoewel de PO verantwoordelijk is voor het bestaan van een product backlog is het niet strikt noodzakelijk dat de PO de items oftwel userstories maakt, iedereen mag userstories maken.
Userstories zijn de doelen die worden vastgelegd. Een user story is een korte beschrijving (story) van wat een gebruiker (user) wil. Bij het maken van een user story moet jij je verplaatsen in de gedachte van een gebruiker. Een user story beschrijft vanuit de gebruiker, wat hij of zij op de applicatie kan doen. User stories worden als volgt geschreven:
Als (rol/gebruiker), wil ik (feature), zodat ik (reden waarom/achterliggende behoefte)
Het eerste deel van deze zin beschrijft de “ROL/GEBRUIKER“. De meeste applicaties kennen meerdere rollen/gebruikers(groepen). Denk bijvoorbeeld aan doelgroepen , bedrijven, directeur, beheerder, redacteur, lid, bezoeker, enz.. Voor elke rol stel je dan user stories samen.
Het tweede deel van de zin bestaat uit “WAT” de rol/gebruiker wil doen. Dit maak je zo concreet mogelijk bijvoorbeeld: Als bezoeker wil ik mij aanmelden voor de nieuwsbrief.
Het laatste deel van de zin beschrijft het “WAAROM“, hieruit valt af te leiden hoe belangrijk en hoeveel het (zakelijk) waard is.
Oefening “Rollen”
Noem minstens 5 verschillende rollen (type gebruikers) van de website van het ICTcollege.
Teams van 3 studenten.
Elk team noteert volgens het userstory format…
Oefening “Invest”
Hieronder vind je een aantal userstories van een webshop. Bespreek in het team of de stories aan INVEST voldoen en waarom. Waar nodig herschrijf de stories naar INVEST ready. Tip: kijk eerst of het geen epics zijn.
Als koper wil ik de specificaties van een product kunnen bekijken, zodat ik weet wat ik ga kopen.
Als aanstaande koper wil ik weten of de website gekeurd is, zodat ik kan kijken of de website betrouwbaar is
Als koper wil ik weten wat anderen van het product vinden, zodat ik mijn mening op dat van een ander kan baseren.
Als klant wil weten hoe ik contact kan opnemen met het bedrijf zodat ik vragen kan stellen over bepaalde producten
Als klant wil ik weten wat de inhoud van het product is, zodat ik kan kijken of ik het product willen aanschaffen.
Als nieuwe klant wil meer informatie over het bedrijf en de missie zodat ik kan beoordelen of het betrouwbaar is.
Epic
Een epic heeft dezelfde vorm als een User story, alleen omvat deze een grotere scope. Het kan meerdere stories bevatten of de epic moet nog worden opgesplitst in een meerdere kleinere user stories.
Oefening “Check please!”
Lees de volgende epic:
Als bedienend personeel wil ik makkelijk de totaalprijs van de bestelling weten zodat ik snel kan afrekenen met de gasten.
Verdeel de epic in kleine story’s en maak stap voor stap een prototype. Bewaar elke stap.
Het eindresultaat is een overzicht met alle artikelen per tafel met tafelnummer, aantal artikelen, naam artikel, totaal prijs zonder btw, totaal met btw en eventueel korting.
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.
Oefening “Olifanten Carpaccio”
De Olifanten carpaccio methode is een manier om Epics en Stories op te delen in zo klein mogelijke ‘slices’. Dit geeft de mogelijkheid om per slice de discussie aan te gaan over de noodzaak, kwaliteit en prioriteit van het werk.
Teams van 4 studenten.
Elk team legt vast op papier…
Zie de presentatie “Scrum in een notendop”…
Ls6 Definitie van “Klaar” (Definition of “Done”)
Deze les heeft als doel dat jij:
Weet wat een DoD is
Begrijpt waarom je DoD maakt
Een DoD zelf kan opstellen
Indien een Product Backlog item wordt omschreven als “Klaar”, moet iedereen begrijpen wat “Klaar” betekent. Hoewel dit significant verschilt per Scrum Team, moeten de teamleden een gezamenlijk begrip hebben wat het betekent om het werk klaar te hebben, om transparantie te kunnen garanderen. Deze “Definitie van klaar” (“Definition of Done”) voor het Scrum Team wordt gebruikt om te controleren wanneer het werk voor een product Increment klaar is. Dezelfde definitie helpt het Ontwikkelteam te bepalen hoeveel Product Backlog items zij kunnen selecteren tijdens de Sprint Planning. Het doel van elke Sprint is om Incrementen van potentieel opleverbare functionaliteit te leveren die voldoen aan de huidige Definitie van “Klaar” van het Scrum Team. Ontwikkelteams leveren elke Sprint een Increment van product functionaliteit . Dit Increment is bruikbaar, zodat een Product Owner kan besluiten dit onmiddellijk in gebruik te nemen. Als de ontwikkelorganisatie al een Definitie van “Klaar” heeft als conventie, standaard of richtlijn, zullen alle Scrum Teams deze tenminste moeten volgen. Als de ontwikkelorganisatie nog geen Definitie van “Klaar” heeft als conventie, standaard of richtlijn, zal het Ontwikkelteam van het Scrum Team zelf een Definitie van “Klaar” moeten definiëren die geschikt is voor het product. Als er meerdere Scrum Teams werken aan hetzelfde systeem of productrelease, moeten de Ontwikkelteams van alle Scrum Teams gezamenlijk de Definitie van “Klaar” definiëren.
Elk Increment is additief aan alle voorgaande Incrementen en grondig getest zodat wordt gegarandeerd dat alle Incrementen samen werken.
Naarmate Scrum Teams meer volwassen worden, is de verwachting dat hun Definitie van “Klaar” uitgebreid wordt met striktere criteria ten behoeve van een hogere kwaliteit. Elk product of systeem zou een Definitie van “Klaar” moeten hebben die als standaard geldt voor elk werk wat eraan gedaan wordt.
Ls7 DoD en DoR: Het maken van een definition of ready en done
Deze les heeft als doel dat jij:
Weet wat een DoR is
Begrijpt waarom je DoR maakt
Een DoR zelf kan opstellen
Definition of Ready
Verplichte deelnemers: het team, scrum master Vrijwillige deelnemers: geen Wanneer: voor er gestart wordt met de realisatie. Timebox: één half uur Doel: vastleggen wanneer met de realisatie kan worden begonnen Input: Product Backlog Output: Definition of Ready Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
De Definition of Ready beschrijft waar de stories/taken aan moeten voldoen om te kunnen starten. Het is een hulpmiddel voor het team om de kwaliteit van het werk constant te houden. De Definition of Ready wordt door het team zelf opgesteld en beschrijft dingen als user story is uitgewerkt, DoD is gemaakt, user story is ingeschat enz.
Definition of Done
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: voor er gestart wordt met de realisatie. Timebox: één half uur Doel: vastleggen wanneer een user story ‘klaar’ is Input: Product Backlog Output: Definition of Done Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
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.
Ls8 De Sprint
Deze les heeft als doel dat jij:
Weet wat een Sprint is
Begrijpt waarom je Sprints gebruikt
Een Sprint zelf kan opstellen
Het hart van Scrum is een Sprint, een timebox van één maand of minder waarbinnen een “Klaar”, bruikbaar en potentieel uitleverbaar product Increment wordt gecreëerd. Sprints hebben idealiter een consistente lengte gedurende de ontwikkelinspanning. Een nieuwe Sprint start direct nadat de vorige Sprint is afgesloten.
Sprints bevatten en bestaan uit een Sprint Planningsbijeenkomst, Dagelijkse Scrums, het ontwikkelwerk, de Sprint Review en de Sprint Retrospective.
Gedurende de Sprint:
Worden geen veranderingen aangebracht die het Sprint Doel in gevaar kunnen brengen;
Verminderen kwaliteitsdoelstellingen niet; en,
Mag de scope worden verduidelijkt en heronderhandeld tussen Product Owner en Ontwikkelteam naarmate meer is geleerd.
Elke Sprint mag worden beschouwd als een project met een horizon van niet meer dan één maand. Net als projecten worden Sprints gebruikt om iets te bereiken. Elke Sprint bestaat uit een definitie van wat er gemaakt moet worden, een ontwerp en een flexibel plan dat de bouw richting geeft, de werkzaamheden zelf en het resulterende product.
Sprints worden beperkt tot één kalendermaand. Wanneer een Sprinthorizon te ver weg is kan de definitie van wat gemaakt wordt veranderen, complexiteit kan verhogen en risico’s kunnen vergroot worden. Sprints geven de mogelijkheid van voorspelbaarheid door, op zijn minst elke maand, ervoor te zorgen dat via inspectie en aanpassing naar een Sprint Doel wordt gestuurd. Sprints zorgen er ook voor dat het risico wordt beperkt tot maximaal één maand aan kosten.
Afbreken van een Sprint
Een Sprint kan worden afgebroken voordat de Sprint timebox voorbij is. Alleen de Product Owner heeft de autoriteit om een Sprint af te breken, hoewel hij of zij dit kan doen onder invloed van de belanghebbenden, het Ontwikkelteam of de Scrum Master.
Een Sprint wordt typisch afgebroken als het Sprint Doel achterhaald is geworden. Dit kan gebeuren als de organisatie van richting verandert of indien de markt- of technologieomstandigheden veranderen. In zijn algemeenheid zou een Sprint moeten worden afgebroken indien deze, gegeven de omstandigheden, niet zinvol meer is. Echter, gezien de korte looptijd van een Sprint, is het afbreken zeer zelden zinvol.
Indien een Sprint wordt afgebroken, worden Product Backlog items die “Klaar” zijn geïnspecteerd. Indien een deel van het werk potentieel uitleverbaar is zal de Product Owner dit normaal gesproken accepteren. Alle incomplete Product Backlog Items worden opnieuw ingeschat en terug op de Product Backlog gezet. Het werk dat reeds gedaan is voor deze items vermindert snel in waarde en moet frequent opnieuw worden ingeschat.
Sprints afbreken kost resources, want iedereen moet hergroeperen in een nieuwe Sprint Planning om een nieuwe Sprint te starten. Het Afbreken van een Sprint is vaak traumatisch voor het Scrum Team en komt zelden voor.
Ls9 Sprint Planning
Deze les heeft als doel dat jij:
Weet wat een Sprint planning is
Begrijpt waarom je een SP doet
Weet uit welke onderdelen een SP bestaat
Een SP gebeurtenis zelf kan aanpakken
Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint Planning. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team.
De Sprint Planningsbijeenkomst is een meeting binnen een timebox van acht uur voor een Sprint van één maand. Voor kortere Sprints is de bijeenkomst normaliter korter. De Scrum Master draagt er zorg voor dat deze gebeurtenis plaats vindt en dat de deelnemers het doel begrijpen. De Scrum Master leert het Scrum Team hoe ze het binnen de timebox kunnen afronden.
Sprint Planning beantwoordt de volgende vragen:
Wat kan worden geleverd in het resulterende Increment van de komende Sprint?
Hoe wordt het benodigde werk om dit Increment te leveren behaald?
Onderwerp één: Wat kan worden gedaan in deze Sprint?
In dit deel werkt het Ontwikkelteam aan een voorspelling van de functionaliteit die in deze
Sprint ontwikkeld zal worden. De Product Owner bespreekt het doel dat bereikt zou moeten worden met de Sprint en de Product Backlog items die, als ze worden afgemaakt tijdens de Sprint, het Sprint Doel zullen vervullen. Het hele Scrum Team werkt samen om het werk van de Sprint te begrijpen.
De input voor deze bijeenkomst is de Product Backlog, het laatste product Increment, de verwachte capaciteit van het Ontwikkelteam gedurende de Sprint en de prestaties uit het verleden van het Ontwikkelteam. Het aantal items dat wordt geselecteerd van de Product Backlog is volledig aan het Ontwikkelteam. Alleen het Ontwikkelteam kan inschatten wat zij kan bereiken binnen de aankomende Sprint.
Nadat het Ontwikkelteam een prognose heeft gegeven van de Product Backlog items die zij kunnen gaan leveren, formuleert het Scrum Team een Sprint Doel. Het Sprint Doel is een doel dat binnen de sprint wordt behaald door het implementeren van de Product Backlog, en het geeft sturing aan het Team over het waarom het huidige increment gebouwd wordt.
Onderwerp twee: Hoe wordt het gekozen werk gedaan?
Na het Sprint Doel te hebben vastgesteld en het werk voor de Sprint te hebben geselecteerd, beslist het Ontwikkelteam hoe het deze functionaliteit realiseert tot een “Klaar” product Increment gedurende de Sprint. De voor de Sprint geselecteerde Product Backlog items plus het plan voor het leveren ervan wordt de Sprint Backlog genoemd.
Gebruikelijk is dat het Ontwikkelteam start met het ontwerpen van het systeem en het werk dat gedaan moet worden om de Product Backlog om te zetten in een werkend product Increment. Werk kan variëren in grootte of geschatte inspanning. Tijdens de Sprint Planningsbijeenkomst plant het Ontwikkelteam zodanig veel werk dat een voorspelling gedaan kan worden met betrekking tot wat het denkt te kunnen opleveren in de komende Sprint. Aan het einde van deze meeting heeft het team het werk voor de eerste dagen van de Sprint opgedeeld in eenheden, vaak van één dag of kleiner. Het Ontwikkelteam organiseert zichzelf om het werk in de Sprint Backlog gedaan te krijgen, zowel gedurende de Sprint Planning als gedurende de Sprint.
De Product Owner kan helpen om de geselecteerde Product Backlog items verder te verduidelijken en om afwegingen te maken. Indien het Ontwikkelteam bepaalt dat er te veel of te weinig werk is, mag het team over de Sprint Backlog items opnieuw onderhandelen met de Product Owner. Het Ontwikkelteam mag ook andere mensen uitnodigen om advies te leveren op technisch vlak of over het domein.
Aan het einde van de Sprint Planningsbijeenkomst zou het Ontwikkelteam in staat moeten zijn om aan de Product Owner en Scrum Master uit te leggen hoe zij van plan zijn, als zelf organiserend team, het Sprintdoel te behalen en het verwachte Increment te realiseren.
Ls10 Sprint Planning: Wat en hoe User stories, Taken en Bugs
Bij de start van een sprint wordt bekeken welke user stories het ontwikkelteam in die sprint gaat implementeren en welke werkzaamheden ze daarvoor moet uitvoeren. De ontwikkelaars moeten hiervoor goed begrijpen wat de user stories inhouden. Ze hebben allerlei details nodig die niet in de user story-zin zijn terug te vinden.
Deze les heeft als doel dat jij:
Weet wat een Planning Poker is
Begrijpt waarom je Planning Poker gebruikt
Een Planning Poker gebeurtenis zelf kan aanpakken
Sprint planning
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geïnteresseerde Wanneer: begin van een sprint. Timebox: één uur per week sprintduur Doel: wat en hoe vastleggen Input: Product Backlog Items (minimum twee sprints) Output: Sprint Goal en Sprint Backlog Items Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
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?
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. Grote 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.
Verschillende benaderingen:
MoSCoW prioritering methode
Monopoly Money
100-punten methode
Kano analyse
T-Shirt maten
Op waarde gebaseerde prioritering(belangrijkste)
Als je net begint met Scrum maak je gebruik van T-Shirt maten(XS, S, M, L en XL). Elke maat krijgt punten(uit de Fibonacci reeks) toegewezen:
T-Shirt maat
Points
XS
8
S
13
M
21
L
34
XL
55
XXL
89
Ls11 Sprint doel aka Increment
Deze les heeft als doel dat jij:
Weet wat een Sprint Doel is
Begrijpt waarom je een Sprint Doel maakt
Een Sprint Doel zelf kan opstellen
Sprint doel
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: begin van een sprint. Timebox: één kwartier per week sprintduur Doel: antwoord op de vraag waarom doen wij deze sprint Input: Sprint Backlog Items Output: Sprint Goal Statement(maximaal 30 woorden) Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
Het Increment is het totaal van alle Product Backlog items voltooid tijdens een Sprint en alle voorgaande Sprints. Aan het eind van een Sprint moet het nieuwe Increment “Klaar” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Klaar” gebruikt door het Scrum Team. Het moet in bruikbare conditie zijn ongeacht of de Product Owner daadwerkelijk besluit het te in gebruik te nemen.
Het Sprint Doel is een doelstelling welke gesteld wordt voor de Sprint, welke kan worden behaald door het implementeren van de Product Backlog. Het geeft richting aan het Ontwikkelteam op het “waarom” het dit increment aan het bouwen is. Het wordt gecreëerd gedurende de Sprint Planning.
Het Sprint Doel geeft het Ontwikkelteam de nodige flexibiliteit ten aanzien van de functionaliteit die geïmplementeerd wordt in de Sprint. De geselecteerde Product Backlog items leveren een samenhangende functie, wat het Sprint Doel kan zijn. Het Sprint Doel kan elke andere samenhang zijn die ervoor zorgt dat het Ontwikkelteam gaat samenwerken in plaats van aan verschillende initiatieven.
Tijdens het werken houdt het Ontwikkelteam het Sprint Doel in het oog. Functionaliteit en technologie worden geïmplementeerd om het Sprint Doel te bereiken. Indien het werk anders blijkt te zijn dan het Ontwikkelteam had verwacht, werken zij samen met de Product Owner om over de scope van de Sprint Backlog binnen deze Sprint te onderhandelen.
Ls12 Sprint 1 / Sprint Zero
Deze les heeft als doel dat jij:
Weet wat een eerste Sprint is
Begrijpt waarom je een eerste Sprint maakt
Weet wat een eerste Sprint Backlog is
Een eerste Sprint zelf kan opstellen
In de eerste sprint kiest het team een paar van de meest belangrijke/bepalende userstories om in toekomstige sprints op een gerichte manier toegevoegde waarde te kunnen leveren. Sprint 1 moet worden gebruikt om:
het basis raamwerk op te zetten
inrichtingswerkzaamheden te verrichten
timeboxed proof of concepts te ontwikkelen
het minimum aan grafisch ontwerp / styling te verrichten
het minimum aan database ontwerp te verrichten
Ls14 Sprint Backlog
Deze les heeft als doel dat jij:
Weet wat een Sprint Backlog is
Begrijpt waarom je een Sprint Backlog maakt
Weet wat een Sprint Backlog Item is
Een voorlopige SB zelf kan opstellen
De Sprint Backlog is de verzameling Product Backlog items geselecteerd voor de Sprint inclusief het plan voor opleveren van het product Increment en voor 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 Sprint Backlog is een plan met voldoende detail zodat veranderingen in de voortgang begrepen kunnen worden in de Dagelijkse Scrum. Het Ontwikkelteam past de Sprint Backlog gedurende de Sprint aan, en de Sprint Backlog ontwikkelt zich gedurende de Sprint. Deze ontwikkeling gebeurt als het Ontwikkelteam het plan afwerkt en meer leert over het werk dat nodig is om het Sprintdoel te halen.
Als er nieuw werk nodig is voegt het Ontwikkelteam dat toe aan de Sprint Backlog. Wanneer werk wordt uitgevoerd of afgerond wordt de schatting van het resterende werk bijgesteld. Als onderdelen van het plan overbodig blijken, worden ze verwijderd. Alleen het Ontwikkelteam kan haar Sprint Backlog bijwerken gedurende een Sprint. De Sprint Backlog is een zeer zichtbaar, real-time beeld van het werk dat het Ontwikkelteam van plan is te doen gedurende de Sprint, en het behoort uitsluitend toe aan het Ontwikkelteam.
Controleren Sprint voortgang
Op elk moment in de Sprint kan de totaal resterende hoeveelheid werk voor de Sprint Backlog items worden opgeteld. Het Ontwikkelteam houdt dit totaal minstens voor elke Dagelijkse Scrum bij om de waarschijnlijkheid van het halen van het Sprintdoel te projecteren. Door het bijhouden van de resterende hoeveelheid werk gedurende de Sprint kan het Ontwikkelteam haar voortgang bewaken.
Ls15 Sprint Backlog: Subset PB User stories, Taken en Bugs
Deze les heeft als doel dat jij:
Een SB zelf kan opstellen
Sprint Backlog
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: begin van een sprint. Timebox: één kwartier per week sprintduur Doel: backlog items van de sprint vastleggen Input: Sprint Backlog Items Output: Sprint Backlog Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
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.
Ls16 Scrum Board: backlog items into tasks.
Deze les heeft als doel dat jij:
Weet wat een Scrum Board is
Begrijpt waarom je Scrum Board maakt
Een Scrum Board zelf kan opzetten
Scrum Board
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: begin van een sprint. Timebox: één kwartier per week sprintduur Doel: werk afstemmen Input: Sprint Backlog Items Output: Scrum Board Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
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 4 kolommen: Sprint Backlog, To Do, Doing 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.
Ls17 Dagelijkse Scrum
Deze les heeft als doel dat jij:
Weet wat een Dagelijkse Scrum is
Begrijpt waarom je een Dagelijkse Scrum gebruikt
Een Dagelijkse Scrum zelf kan opstarten
De Dagelijkse Scrum is een 15-minuten-timeboxed gebeurtenis voor het Ontwikkelteam om activiteiten te synchroniseren en een plan te maken voor de komende 24 uur. Dit wordt gedaan door het werk sinds de laatste Dagelijkse Scrum te inspecteren en te voorspellen welk werk gedaan kan worden tot de volgende Dagelijkse Scrum.
De Dagelijkse Scrum wordt elke dag gehouden op dezelfde tijd en plaats om complexiteit te reduceren. Gedurende de bijeenkomst licht elk Ontwikkelteamlid het volgende toe:
Wat heb ik gisteren gedaan dat het Ontwikkelteam heeft geholpen het Sprint Doel te bereiken?
Wat ga ik vandaag doen om het Ontwikkelteam te helpen het Sprint Doel te bereiken?
Zie ik enig obstakel die mij of het Ontwikkelteam in de weg staat het Sprint Doel te bereiken?
Het Ontwikkelteam gebruikt de Dagelijkse Scrum om te voortgang ten opzichte van het Sprint Doel te beoordelen en om te beoordelen hoe de trend is van het gedane werk ten opzichte van de Sprint Backlog. De Dagelijkse Scrum optimaliseert de waarschijnlijkheid dat het Ontwikkelteam het Sprint Doel behaalt. Elke dag moet het Ontwikkelteam begrijpen hoe zij samen gaan werken als zelf organiserend team om het Sprint Doel te behalen en hoe het verwachte Increment te realiseren in het restant van de Sprint. Vaak houdt het Ontwikkelteam ,of teamleden een bijeenkomst direct na de Dagelijkse Scrum voor gedetailleerde discussies, of om de rest van het werk in de Sprint aan te passen of te herplannen.
De Scrum Master zorgt ervoor dat het Ontwikkelteam de bijeenkomst houdt, maar het Ontwikkelteam zelf is verantwoordelijk voor het uitvoeren van de Dagelijkse Scrum. De Scrum Master leert het Ontwikkelteam om de Dagelijkse Scrum binnen de 15-minuten-timebox te houden.
De Scrum Master dwingt de regel af dat alleen Ontwikkelteamleden participeren in de Dagelijkse Scrum.
Dagelijkse Scrums verbeteren communicatie, elimineren andere bijeenkomsten, identificeren obstakels bij de ontwikkeling zodat die verwijderd kunnen worden, belichten en bevorderen het maken van snelle beslissingen en verbeteren het kennisniveau van het Ontwikkelteam. Dit is een zeer belangrijke “inspect and adapt” (inspectie en aanpassing) bijeenkomst.
Ls18 Sprint execution: Daily Scrum:
Deze les heeft als doel dat jij:
Weet wat een Dagelijkse Scrum is
Begrijpt waarom je een Dagelijkse Scrum gebruikt
Een Dagelijkse Scrum zelf kan opstarten
Daily Scrum
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geïnteresseerde Wanneer: elke ochtend Timebox: één kwartier Doel: planning meeting Input: Scrum Board Output: Actualiseren van de Sprint Backlog en Sprint Burn-down Chart Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
Timeboxing
Een afgesproken tijdskader waarbinnen een activiteit wordt uitgevoerd. Een Daily Scrum heeft bijvoorbeeld een timebox van 15 minuten.
Daily Standup
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?
Sprint burn-down chart
Dagelijkse voortgang van een sprint, aangegeven over de lengte van de sprint. De burn down chart van de sprint hangt meestal aan de wand in de projectkamer. Op die manier is voor iedereen direct duidelijk hoeveel er nog gedaan moet worden. Doordat het dagelijks wordt bijgewerkt is direct duidelijk hoe het ervoor staat.
Release burn-down chart
Er zijn ook andere typen van “burn down charts” in gebruik, bijvoorbeeld de release burn down chart hierop staat hoeveel er nog gedaan moet worden voor de volgende release van het product (Ervan uitgaande dat een “release” in meerdere sprints gerealiseerd wordt). Ook bestaat er een alternative release burn down chart, deze doet in principe hetzelfde, maar geeft extra de wijzigingen aan door het meer/minder werk, veroorzaakt door het voortschrijdende inzicht.
Ls19 Sprint Review
Deze les heeft als doel dat jij:
Weet wat een Sprint Review is
Weet uit welke onderdelen een Sprint Review bestaat
Begrijpt waarom je een Sprint Review doet
Een Sprint Review zelf kan opstarten
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.
Dit is een vier-uur-timebox bijeenkomst voor Sprints van één maand. Over het algemeen wordt er minder tijd gepland voor kortere sprints. De Scrum Master draagt er zorg voor dat de gebeurtenis plaatsvindt en dat de aanwezigen het doel begrijpen. De Scrum Master leert iedereen om het binnen de timebox te houden.
De Sprint Review omvat de volgende elementen:
De aanwezigen zijn het Scrum Team en belangrijke belanghebbenden die worden uitgenodigd door de Product Owner.
De Product Owner identificeert welke Product Backlog items “Klaar” zijn en wat er niet “Klaar” is;
Het Ontwikkelteam bespreekt wat er goed ging gedurende de Sprint, welke problemen ze zijn tegengekomen en hoe deze problemen werden opgelost;
Het Ontwikkelteam demonstreert het werk dat “Klaar” is en beantwoordt vragen met betrekking tot het Increment;
De Product Owner bespreekt de Product Backlog zoals deze nu is. Hij of zij projecteert waarschijnlijke data van completering op basis van de voortgang tot nu toe (als nodig);
De gehele groep werkt samen aan wat er vervolgens gemaakt gaat worden, zodat de Sprint Review waardevolle input levert voor de komende Sprint Planningsbijeenkomst;
Een beoordeling van de markt of potentieel gebruik van het product kan beïnvloeden wat het meest waardevolle is om vervolgens te maken; en,
Een overzicht van de tijdlijn, budget, potentiele mogelijkheden, en markt voor de volgende verwachte ingebruikname van het product.
Het resultaat van de Sprint Review is een herziene Product Backlog welke de waarschijnlijke Product Backlog items voor de volgende Sprint definieert. De Product Backlog kan ook over het geheel worden aangepast om nieuwe kansen te kunnen omarmen.
Ls20 Sprint Review: Customer Review
Deze les heeft als doel dat jij:
Weet wat een Customer Review is
Begrijpt waarom je een Customer Review doet
Een Customer Review zelf kan opstarten
Sprint Review
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geïnteresseerde Wanneer: aan het einde van een sprint Timebox: één uur per week sprintduur Doel: demonstreren van sprintresultaat Input: (Shippable) Increment Output: terugkoppeling verzamelen Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
(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.
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.
Ls21 Sprint Retrospective
Deze les heeft als doel dat jij:
Weet wat een Sprint Retrospective is
Begrijpt waarom je een Sprint Retrospective doet
Een Sprint Retrospective zelf kan opstarten
De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.
De Sprint Retrospective vindt plaats na de Sprint Review en vóór de volgende Sprint Planning. Dit is een drie-uur-timebox bijeenkomst voor Sprints van één maand. Over het algemeen wordt minder tijd gepland voor kortere sprints. De Scrum Master draagt er zorg voor dat de gebeurtenis plaatsvindt en dat de aanwezigen het doel begrijpen. De Scrum Master leert iedereen om het binnen de timebox te houden. De Scrum Master neemt deel als een gelijkwaardig teamlid aan de bijeenkomst vanuit zijn verantwoordelijkheid voor het Scrum proces.
Het doel van de Sprint Retrospective is om:
Te inspecteren hoe de laatste Sprint is gegaan met betrekking tot mensen, relaties, processen en tools;
Dingen die goed gingen en potentiële verbeteringen te identificeren en te ordenen; en,
Een plan te creëren om verbeteringen op de manier waarop het Scrum Team zijn werk doet te implementeren.
De Scrum Master moedigt het Scrum Team aan om, binnen het Scrum proces raamwerk, hun ontwikkelproces en practices te verbeteren, om het team effectiever en plezieriger te maken voor de volgende Sprint. Gedurende elke Sprint Retrospective plant het Scrum Team manieren om de kwaliteit van het product te verhogen door zo nodig de definitie van “Klaar” aan te passen.
Tegen het einde van de Sprint Retrospective zou het Scrum Team verbeteringen moeten hebben benoemd die geïmplementeerd zullen worden in de volgende Sprint. Het implementeren van deze verbeteringen in de volgende Sprint is de aanpassing naar aanleiding van de inspectie van het Scrum Team zelf. Alhoewel verbeteringen altijd geïmplementeerd mogen worden, biedt de Sprint Retrospective een formeel moment gericht op inspectie en aanpassing.
Ls22 Sprint Review: Team Retrospective:
Deze les heeft als doel dat jij:
Weet wat een Team Retrospective is
Begrijpt waarom je een Team Retrospective doet
Een Team Retrospective zelf kan opstarten
Sprint Retrospective
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geïnteresseerde Wanneer: aan het einde van een sprint Timebox: één uur per week sprintduur Doel: terugkijken op sprint wat heeft goed en minder goed gewerkt Input: Scrum board Output: twee verbeterpunten Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: het team
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’.
Ls23 Product 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.
Deze les heeft als doel dat jij:
Weet wat een Product Backlog Refinement gebeurtenis is
Begrijpt waarom je een Product Backlog Refinement gebeurtenis verricht
Een Product Backlog Refinement gebeurtenis zelf kan opstarten
Product Backlog
Verplichte deelnemers: het team, scrum master, product owner Vrijwillige deelnemers: geen Wanneer: wekelijks Timebox: één half uur per week sprintduur Doel: Product Backog items ‘Ready’(DoR) maken Input: Product Backlog Items Output: Product Backlog Items Beoordeling: projectbegeleider vervolgens product owner Voor wie:pigs Van wie: product owner
Story Time
In this meeting you will be discussing and improving the stories in your product backlog, which contains all the stories for future sprints. Note that these are not the stories in the current sprint–those stories are now in the sprint backlog. We recommend one hour per week, every week, regardless of the length of your sprint. In this meeting, the team works with the product owner on:
Acceptance Criteria
Each user story in the product backlog should include a list of acceptance criteria. These are pass/fail testable conditions that help us know when then the story is implemented as intended. Some people like to think of them as acceptance examples: the examples that the team will demonstrate to show that the story is done.
Story Sizing (Estimation)
During story time, the team will assign a size (estimate, if you prefer that term) to stories that haven’t yet been sized. This is the team’s guess at how much work will be required to get the story completely done.
Story Splitting
Stories at the top of the product backlog need to be small. Small stories are easier for everyone to understand, and easier for the team to complete in a short period of time. Stories further down in the product backlog can be larger and less well defined. This implies that we need to break the big stories into smaller stories as they make their way up the list. While the product owner may do much of this work on their own, story time is their chance to get help from the whole team.
