flowchart TD
A[Requirements]
B[Design]
C[Implementation]
D[Integration]
E[Testing]
F[Deployment]
A --> B
B --> C
C --> D
D --> E
E --> F
%% Staircase / waterfall layout
A ~~~ B
B ~~~ C
C ~~~ D
D ~~~ E
E ~~~ F
Les 4: Scrum en Agile
Inleiding
In de vorige lessenreeks leerden we over versiebeheer met Git en hoe we GitHub gebruiken om code te delen en samen te werken met andere ontwikkelaars.
In de volgende lessen bouwen we hier op verder. We bekijken hoe we werk als team kunnen organiseren om grotere projecten tot een goed einde te brengen.
Bij een softwareproject moet je nadenken over wat je precies wilt bouwen, welke taken daarvoor nodig zijn, in welke volgorde je die het best uitvoert en hoe je de voortgang opvolgt. Werk je samen met meerdere ontwikkelaars, dan komt daar ook afstemming bij: wie neemt welke taak op, hoe stemmen jullie wijzigingen op elkaar af en hoe zorgen jullie ervoor dat iedereen naar hetzelfde doel toewerkt?
Met andere woorden: een softwareproject vraagt om projectmanagement. Om zulke projecten gestructureerd en succesvol aan te pakken, zijn doorheen de jaren verschillende methodologieën ontwikkeld. Die helpen teams om werk te plannen, samen te werken, risico’s te beheersen en stap voor stap tot een goed eindresultaat te komen.
Een Stukje Geschiedenis
De Oorsprong: Code-and-Fix
In de beginjaren van softwareontwikkeling waren er natuurlijk nog geen grote projecten zoals we die nu kennen. Er werd doorgaans op een ongestructureerde manier te werk gegaan. Men begon gewoon te programmeren, keek wat eruit kwam, en loste problemen onderweg op.
“Software” was vaak ook maar een klein onderdeel van projecten.
Bij kleine programma’s kon dat nog werken. Eén programmeur of een klein team kon snel iets bouwen, testen, aanpassen en opnieuw proberen.
Waterfall
In de jaren 70 groeit het domein van softwareontwikkeling enorm. Met programmeertalen als Pascal, Smalltalk en C en technologieën als EPROM, floppy disks, cassettes en de eerste Intel processoren.
Om softwareprojecten te managen tasten bedrijven naar methodologieën die ze al kennen: een rigide, gefaseerde en document-centrische aanpak.
Eerst analyseer je het probleem, daarna ontwerp je de oplossing, vervolgens implementeer je de software, daarna test je ze, en tenslotte lever je ze op en onderhoud je ze.
Elke fase start pas als de vorige fase volledig is afgerond - vaak gepaard met formele go/no-go vergaderingen.
Elke fase “stroomt” naar de volgende - vandaar de naam waterfall.
Dat had duidelijke voordelen. Het model bracht structuur, maakte planning eenvoudiger en gaf managers houvast. Voor organisaties die gewoon waren om te werken met contracten, deadlines en uitgebreide specificaties, was dit een erg aantrekkelijk model.
Toch had het waterfallmodel ook belangrijke nadelen, zeker bij software:
- klanten weten in het begin vaak nog niet exact wat ze nodig hebben;
- wijzigingen tijdens het project zijn moeilijk en duur;
- werkende software komt pas laat beschikbaar;
- fouten in analyse of ontwerp worden soms pas ontdekt tijdens het testen;
- feedback van gebruikers komt vaak te laat.
Software bouwen bleek in de praktijk minder voorspelbaar dan bijvoorbeeld een brug of een gebouw. Waar het waterfallmodel uitgaat van stabiliteit en voorspelbaarheid, is softwareontwikkeling vaak juist onzeker en veranderlijk.
Het Spiral Model
Om beter om te gaan met onzekerheid ontstonden later alternatieven, waaronder het spiral model. In plaats van softwareontwikkeling als één rechte lijn te zien, stelt het spiral model het project voor als een reeks rondes of cycli.
In elke cyclus doorloopt men opnieuw een aantal stappen, zoals:
- doelen bepalen;
- risico’s analyseren;
- een oplossing ontwerpen of prototypen;
- evalueren en plannen voor de volgende ronde.
Het grote verschil met waterfall is dat het spiral model expliciet erkent dat je niet alles vanaf het begin zeker weet. Daarom wordt er meer aandacht besteed aan risicoanalyse, experimenten en tussentijdse evaluatie.
Dat was een belangrijke stap vooruit. Het model liet toe om eerder bij te sturen en minder blind vast te houden aan een initiële planning.
Extreme Programming (XP): een voorloper van Scrum en Agile
Een belangrijke evolutie was Extreme Programming, vaak afgekort als XP. XP ontstond in de jaren 90 en legde sterk de nadruk op korte feedbacklussen, nauwe samenwerking en technische kwaliteit.
XP stelde een aantal praktijken centraal, zoals:
- kleine, frequente releases
- veel klantbetrokkenheid
- pair programming
- test-driven development (TDD)
- refactoring
- continuous integration
Waar waterfall vooral focuste op voorspelbaarheid via planning en documentatie, focuste XP op aanpasbaarheid via snelle feedback en goede technische discipline.
XP heeft sterk bijgedragen aan het denken dat later onder de noemer Agile bekend werd. Veel ideeën die vandaag vanzelfsprekend lijken in moderne softwareontwikkeling — kleine iteraties, testen automatiseren, vaak integreren, continu verbeteren — werden in XP expliciet uitgewerkt.
Scrum - Inleiding
Toenemende kritiek op zware processen
In de jaren 80 en 90 was vooral de waterfall methode populair en groeide de kritiek op zware, document-gedreven ontwikkelmethodes. Veel teams ervaarden dat ze enorm veel tijd investeerden in plannen, rapporteren en documenteren, terwijl de echte software pas laat zichtbaar werd.
Projecten leden vaak onder dezelfde problemen:
- de klant veranderde van idee tijdens het traject;
- de markt veranderde sneller dan het project kon volgen;
- documentatie was soms verouderd nog voor de software klaar was;
- het team bouwde soms correct wat gevraagd was, maar niet wat echt nodig was.
Met andere woorden: een strikt plan bood geen garantie op succes. Steeds meer ontwikkelaars en teams gingen op zoek naar lichtere, flexibelere manieren van werken.
Wat is Scrum
Een van de nieuwe manieren van werken die hieruit is ontstaan is Scrum.
Scrum is in de eerste plaats een framework om (onder andere) softwareproducten te ontwikkelen. Scrum definieert hiervoor een aantal waarden, principes en praktijken.
De kern van Scrum zijn:
- De Product Backlog, een lange lijst met alle functionaliteit die ontwikkeld moet worden
- Incrementele ontwikkeling, waarbij elk increment functioneel is en potentieel gebruiksklaar
- Ontwikkeling in korte Iteraties van vaste tijdsduur
- Cross-functionele ontwikkelingsteams
De eerste “officiële” versie van Scrum is een paper die in 1995 is gepubliceerd en besproken op OOPSLA (een conferentie over object-georiënteerde talen en praktijken): SCRUM Development Process, Ken Schwaber (1995).
Aan Scrum zijn volledige opleidingen en certificaties gewijd en honderden boeken geschreven. Maar vanaf de officiële scrum.org website krijg je (gratis) toegang tot originele Scrum Guide die bovendien ook in verschillende talen beschikbaar is. Ook een Nederlandstalige versie.
We bekijken eerst kort de belangrijkste concepten.
Scrum Praktijken
Scrum omvat een aantal vaste rollen, activiteiten en artefacten.
Scrum Rollen
Binnen een Scrum Team onderscheiden we volgende rollen:
Product Owner: of PO, is het gezicht van het product en vertegenwoordigt de klant of eindgebruikers. De inhoud en volgorde van items in de Product Backlog wordt door de PO bepaald.
Scrum Master: of SM, is een expert in Scrum en is verantwoordelijk voor de effectiviteit van het Scrum Team. Begeleidt de verschillende Scrum activiteiten en treed op als coach voor de rest van het team.
Development Team: is cross-functioneel (bvb. architect, frontend, backend, tester) met een grote van doorgaans 5 tot 9 personen.
Scrum Activiteiten
Bij Scrum noemen we een korte ontwikkelingscyclus (denk aan het Spiral model) een Sprint. Sprints hebben in principe een vaste looptijd van 1 tot 4 weken. Er wordt ook some gesproken over een Iteratie i.p.v. een Sprint.
Elke sprint bestaat uit de volgende activiteiten of gebeurtenissen:
Sprint Planning: het volledig Scrum team spreekt de inhoud van de komende sprint af
Daily Scrum: of Standup, is korte (15m) dagelijkse synchronisatie-meeting
Sprint Review: het Scrum team presenteert de resultaten aan de belanghebbenden (stakeholders); samen worden eventuele aanpassingen aan de product backlog gemaakt
Sprint Retrospective: het Scrum team inspecteert de afgelopen Sprint en identificeert mogelijke verbeteringen om de effectiviteit te verhogen
Zowel de Sprint Review als Retrospective zijn zogenaamde inspect-and-adapt activiteiten - een centrale pijler binnen Scrum waar we zeker nog op terug komen.
Scrum Artefacten
De artefacten vertegenwoordigen werk of waarde en zorgen voor transparantie van belangrijke informatie voor alle betrokkenen.
Product Backlog: een levende, in prioriteit geordende lijst van items die nodig zijn om het product te maken of verbeteren - die items noemen we Product Backlog Items of PBIs.
Sprint Backlog: de subset van items uit de Product Backlog die geselecteerd zijn om tijdens de huidige Sprint af te werken.
Increment: het resultaat van de Sprint en een concrete stap in richting van het uiteindelijke product doel.
Agile
Agile en Scrum worden vaak in één adem genoemd, maar ze betekenen niet hetzelfde.
Agile is de bredere filosofie of denkwijze over softwareontwikkeling:
- werk in kleine stappen
- lever regelmatig werkende software op
- verzamel snel feedback en stuur bij wanneer de noden veranderen
Die manier van denken kreeg begin jaren 2000 een duidelijke vorm in het Agile Manifesto (2001), waarin een groep softwareontwikkelaars reageerde tegen zware, starre en sterk document-gedreven ontwikkelmethodes zoals het klassieke Waterfall.
Scrum is daarentegen geen algemene filosofie, maar een concreet framework om dat Agile denken in de praktijk te organiseren. Scrum bestond als aanpak eigenlijk al vóór het Agile Manifesto en werd later één van de bekendste manieren om Agile toe te passen.
Waar Agile dus vooral zegt waarom je iteratief, flexibel en klantgericht werkt, beschrijft Scrum meer hoe je dat kunt aanpakken in een team: met vaste rollen, korte sprints, een backlog, daily stand-ups, reviews en retrospectives.
Agile = Wendbaar
bijvoeglijk naamwoord
als iets makkelijk aangepast of van richting veranderd kan worden
Draaibaar. Makkelijk te zwenken. Makkelijk draaibaar. Versatiel. Soepel.
Het Agile Manifesto
Het Agile Manifesto staat nog steeds in zijn originele vorm online (net als heel wat vertalingen, inclusief in het Nederlands) en is eigenlijk erg kort. De volledige tekst luidt als volgt:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Je merkt ongetwijfeld de sterke overeenkomst met Scrum concepten.
Vooral de laatste zin is ook erg belangrijk en wordt soms, al dan niet bewust, vergeten!
Scrum is dus een Agile framework. Daarnaast bestaan er nog tal van andere methodes die de Agile principes volgen, bijvoorbeeld SAFe, Kanban of Lean Software Development.
Binnen deze cursus houden we ons echter aan Scrum.
Oefeningen: Boekenlijst
Opdracht
Een klant wil een eenvoudige applicatie laten bouwen waarmee gebruikers hun persoonlijke boekenlijst kunnen bijhouden.
De eerste versie wordt een webapplicatie. Later wil de klant eventueel ook een mobiele versie laten maken.
De klant heeft nog geen volledig uitgewerkte specificatie. Er zijn alleen enkele eerste wensen. Jullie team moet deze wensen omzetten naar een Product Backlog met duidelijke Product Backlog Items.
Initiële requirements:
- De applicatie moet gebruikers helpen om boeken bij te houden die ze willen lezen, aan het lezen zijn of al gelezen hebben.
- Een gebruiker moet boeken kunnen toevoegen aan zijn of haar lijst.
- Van een boek wil de gebruiker minstens de titel en auteur kunnen bewaren.
- Een gebruiker moet kunnen aanduiden of een boek nog te lezen, bezig of gelezen is.
- Een gebruiker moet zijn of haar boekenlijst kunnen bekijken en beheren.
Later wil de klant misschien extra functies zoals zoeken, filteren, favorieten, beoordelingen of een mobiele app.
Scrum Software
Er bestaan uiteraard heel wat software en platformen die een Scrum en andere Agile frameworks ondersteunen, bijvoorbeeld Miro, Teamwork en zeker in grotere bedrijven erg populair, Jira.
GitHub biedt echter al een aantal jaar Projects aan als (gratis) feature. Hiermee kan je ook perfect Scrum implementeren. Bovendien gebruiken we GitHub toch al als source code management systeem!
In een klein en lokaal team kan je zelfs prima op papier werken, zoals te zien is in deze clip uit de HBO reeks Silicon Valley: Silicon Valley S01E05 scrum scene (YouTube) (let op: expliciet taalgebruik).
GitHub Issues
Je kent waarschijnlijk al de “gewone” GitHub Issues. Deze worden door vrijwel alle open-source projecten gebruikt om problemen te melden, op te volgen en te bespreken. Meestal kan iedereen issues bekijken en een nieuw issue aanmaken.
Dit zijn bijvoorbeeld issues in de Python repository:
Deze issues zijn dus altijd gelinkt aan één (en slechts één) GitHub repo. Issues kunnen worden georganiseerd met labels en gelinkt worden aan andere issues en pull requests.
Op zich zouden we issues kunnen gebruiken om product backlog items voor te stellen. Met labels kunnen we de items organiseren. Toch zijn er een aantal beperkingen waardoor deze aanpak minder aantrekkelijk wordt, bijvoorbeeld:
- Issues zijn verbonden aan een bepaalde repo maar onze PBIs zijn vaak verspreid over meerdere repos.
- Bij een nieuw product of component zijn er misschien zelfs nog geen repos!
- De PBIs worden vermengd met andere issues.
- We missen een aantal belangrijke velden om een PBI complete te maken zoals een status en inschatting (estimation). Deze komen later nog aan bod.
GitHub Projects
GitHub zelf definieert een Project als volgt:
A project is an adaptable collection of items that you can view as a table, a kanban board, or a roadmap and that stays up-to-date with GitHub data. Your projects can track issues, pull requests, and ideas that you note down.
In het kader van Scrum kunnen we één GitHub Project zien als één Product Backlog. Projecten kunnen wel gelinkt worden met een (of meer) repository maar dit is geen één-op-één mapping. In de plaats zijn Projects verbonden aan een GitHub Organization (of aan je persoonlijk GitHub account). Bijgevolg is een Project ook niet automatisch zichtbaar voor iedereen - zelfs voor leden van een repo.
Een Project bevat Items (onze Scrum PBIs). Items worden eerst als draft aangemaakt en bevatten dan al een aantal belangrijke velden:
Title, uiteraard. Voor een PBI willen we een korte maar duidelijke titelDescription, zal de PBI in detail beschrijvenStatusSize/EstimateIteration, komt overeen met een Scrum Sprint
Praktijk
We maken als oefening samen een GitHub Project voor onze Boekenlijst applicatie en voeren alle PBIs in. Om te starten hebben we enkel de titels van de PBIs. Later zullen we deze verder uitwerken.
Scrum Principes
Waarom de naam ‘Scrum’?
Scrum is geen acroniem maar een term die we lenen van de sport Rugby.
De traditionele watervalmethode kunnen we vergelijken met een estafette-race, waarbij iedereen zijn eigen deel afzonderlijk zo snel mogelijk afwerkt. De volgende renner start pas als de vorige klaar is een de stok doorgeeft.
Daartegenover wordt bij rugby als volledig team vooruitgang gemaakt de de bal continu heen en weer te passen. De Dcrum is bij rugby een manier het spel terug op te starten.
Bij plan-gedreven methodes als waterfall probeert men all mogelijke functionaliteiten en scenarios op voorhand vast te leggen. Evenals de beste manier om deze te implementeren. Het idee zijnde dat op die manier de uitvoering vlekkeloos en binnen de verwachte termijn zal verlopen.
Deze aanpak is niet inherent slecht en leent zich goed bij domeinen waar problemen exact gedefinieerd zijn, voorspelbaar, en niet of weinig zullen veranderen.
Het probleem is dat die bij softwareontwikkelingsprojecten doorgaans net niet het geval is.
Scrum en Agile principes gaan juist uit van constante verandering en onvoorspelbaarheid. In dit hoofdstuk bekijken we een aantal belangrijke principes.
Variabiliteit en Onzekerheid
- Elke softwareproject is verschillend. In tegenstelling tot bvb. productieprocessen maken we bij software nooit 2x precies hetzelfde product.
- Door iteratief te werken verminderen we de impact van foute keuzes en aannames.
- Door incrementeel te werken maken we ruimte voor veranderingen
- De kern van Scrum draait rond inspectie, aanpassing (adaptation) en transparantie. Hier wordt soms naar verwezen met de term Empirische procescontrole.
- Scrum past dit toe niet alleen op wat we maken, maar ook op hoe we het maken!
Voorspellen en Aanpassen
- Opties openhouden. Beslissingen nemen of het “beste” moment, ofwel het last responsible moment (LRM) principe.
Last responsible moment
Bron: Essential Scrum - Aanvaarden dat niet alle initiële requirements en plannen juist zullen zijn.
- Een verkennende en adaptieve aanpak. Verkennen, bvb. via prototypes, kost vandaag een grootorde minder dan vroeger.
Historical cost of exploration
Bron: Essential Scrum - Door minder op voorhand volledig te proberen vastleggen verlaagt de kost van verandering in een later stadium.
- Er is uiteindelijk een balans tussen zaken op voorhand vast te leggen t.o.v. op het laatst mogelijke moment.
Aannames Bevestigen
- Vaak moeten we initieel aannames maken.
- Belangrijke aannames proberen we zo vroeg mogelijk te bevestigen.
- En zo nodig aanpassen.
- De cyclus van inspecteren -> aanpassen -> bevestigen komt op verschillende niveaus terug.
- Bvb. daily scrum, sprint review, …
- Bij Scrum is snelle en constant feedback dus cruciaal.
Work-in-Progress (WIP)
- De procesindustrie kent het concept van Batch Size: het aantal eenheden die tegelijk geproduceerd worden.
- Waterfall = 1 batch van 100%
- Scrum = kleinere, variable batch size, genoeg voor 1-4 weken (sprint size)
- In een fabriek is WIP onmiddellijk zichtbaar - bij softwareproductie is dit veel moeilijker. Scrum maakt WIP zichtbaar.
- Scrum focust op inactief werk, niet op inactieve werkers. 100% bezetting van werkers heeft geen nut als het werk zelf moet wachten.
Utilization vs. Queue Size
Bron: Essential Scrum
Vooruitgang Meten
- Scrum meet vooruitgang door te kijken naar functionele incrementen van het producten - niet naar het bereiken van arbitraire milestones (bvb. “code complete” in waterfall).
- Bij scrum proberen we zo vroeg mogelijk, en bij elke iteratie, waarde toe te voegen.
Prestaties
- Bij scrum proberen we zo snel mogelijk resultaten te krijgen om zo: feedback te krijgen, aannames te bevestigen, waarde toe te voegen.
- Snel is niet hetzelfde als gehaast. Scrum mikt op een continu aanhoudbaar werkritme.
- Kwaliteit en performantie van het product is een onderdeel van elke iteratie en elk increment. Niet iets wat achteraf bekeken wordt.
Requirements en User Stories
Requirements
Bij plan-gedreven methodes zoals waterfall is het op voorhand volledig vastleggen van gedetailleerde requirements een belangrijke step. Veranderingen later in het ontwikkelingsproces gaan vaak gepaard met een formeel change control process.
Bij Scrum worden requirements:
- Doorheen de volledige productontwikkeling continue onderhandeld d.m.v. conversatie.
- Net op tijd (just-in-time) vastgelegd, met de (op dat moment) nodige niveau van details.
- Gezien als onmogelijk om volledig op voorhand vast te leggen - hoeveel tijd en energie er ook wordt ingestoken.
Die requirements worden dus voorgesteld door de Product Backlog Items of PBIs. Initieel zullen deze nog vaag en high-level zijn.
De product backlog wordt continu geordend zodat de belangrijkste items bovenaan staan. De hoogste items moeten dan als eerste verder uitgewerkt worden. Dat kan twee vormen aannemen: grote items kunnen opgesplitst worden in kleine items, en, items kunnen aangevuld worden met extra details.
Dit process van verfijnen gebeurt in de eerste plaats door conversatie tussen de product owner, het ontwikkelingsteam en de stakeholders (eindklant, business analisten, management, …).
User Stories
Een volledig uitgewerkt PBI noemen we een User Story: een manier om gewenste business-waarde uit te drukken, zodanig dat die begrepen kan worden door zowel technische als niet-technische medewerkers.
Om User Stories te definiëren wordt vaak verwezen naar de zogenaamde “3 C’s”(Ron Jeffries, 2001):
- Card: Een story moet passen op een index kaart. De tekst op de voorkant volgt een vast formaat:
As a <user role> I want to <goal> so that <benefit>.Ofwel wie wat wil bereiken, en waarom. - Conversation: Stories worden opgemaakt en later verfijnd d.m.v. conversatie tussen de betrokken partijen.
- Confirmation: De voorwaarden waar aan moet worden voldaan, ook wel de acceptance criteria, komen op de achterkant van de kaart.
Epics
De oorspronkelijk grotere PBIs die later verfijnd worden tot User Stories noemen we Epics. M.a.w. een Epic is een groot stuk werk of een grote functionaliteit dat te omvangrijk is om in één keer uit te voeren.
Epics blijven na het opsplitsen bestaan en vormen een handige manier om verschillende user stories te groeperen en organiseren.
Voorbeeld:
- Epic: Gebruikersbeheer
- Mogelijke user stories:
- gebruiker kan een account aanmaken
- gebruiker kan inloggen
- gebruiker kan zijn wachtwoord wijzigen
INVEST
INVEST (Bill Wake, 2003) is een ezelsbruggetje om te helpen bij het uitwerken van goede user stories.
- Independent: beperk afhankelijkheden tussen stories zodat ze eenvoudiger zijn om te plannen en implementeren
- Negotiable: details zijn onderhandelbaar; focus ligt bij de waarom, niet de hoe
- Valuable: er is toegevoegde waarde voor de klant en/of eindgebruiker*
- Eestimatable: is het moeilijk voor het team om een story in te schatten dan is dit een teken dat deze te groot is (-> opsplitsen), ofwel dat het team onvoldoende kennis heeft (-> verkennend werk inplannen)
- Small: we willen stories die klein genoeg zijn om verschillende stories in eenzelfde sprint te kunnen plannen
- Testable: als een story niet testbaar lijkt wijst dit vaak om onduidelijk of onvoldoende acceptance criteria
* Wat met werk dat geen rechtstreeks toegevoegde waarde heeft?
Een eerste teken is vaak als je stories begint te schrijven die beginnen met As a developer I want to …. Dit kan bijvoorbeeld gaan over het uitbreiden van testen, herwerken (refactor) van stukken code, enz.
Vaak is dit een gevolg van onduidelijke acceptance criteria in andere stories, of een onvolledige definition of done.
Definition of Done
De Definition of Done is een formele checklist die beschrijft aan welke voorwaarden moet worden voldaan voordat een PBI als afgewerkt kan worden beschouwd. Op dat moment ontstaat ook een nieuw increment van het product.
De Definition of Done zorgt voor transparantie, doordat iedereen een gedeeld begrip heeft van wat “klaar” (done) precies betekent.
Als een PBI op het einde van een sprint niet voldoet aan de DoD dan wordt deze niet meegeteld en teruggeplaatst in de product backlog.
De Definition of Done is dus, in tegenstelling tot de Acceptance Criteria, hetzelfde voor alle PBIs.
De DoD kan wel evolueren, in gemeenschappelijk overleg tussen het Scrum team and the stakeholders.
Voorbeeld Definition of Done
- de functionaliteit voldoet aan alle acceptance criteria;
- de code is geschreven en lokaal getest;
- alle automatische tests slagen;
- de code is gereviewd via een pull request;
- de wijziging is gemerged naar de afgesproken branch;
- er zijn geen bekende blokkerende bugs meer;
- eventuele documentatie of README-informatie is aangepast;
- de Product Owner heeft het resultaat bekeken en goedgekeurd.
Opdracht
We werken de product backlog items uit de vorige opdracht uit tot volwaardige user stories.
I.p.v. index kaarten gebruiken we GitHub Projects.
De Product Backlog
In dit deel bekijken we deze beide concepten in iets meer detail.
De Product Backlog
We definieerden eerder de Product Backlog als een levende, in prioriteit geordende lijst van items die nodig zijn om het product te maken of verbeteren.
DEEP (Pichler & Cohn, 2010) is een ezelsbruggetje om te onthouden aan welke eigenschappen een goede Product Backlog moet voldoen:
- Ddetailed appropriately: De belangrijkste/dringendste PBIs hebben zo veel mogelijk detail nodig - maar PBIs waar we (misschien) pas over twee maanden aan kunnen beginnen hebben dat niet!
- Emergent: De Product Backlog wordt continu geupdate - bvb. met nieuwe items, opgesplitste items, aanpassingen.
- Estimated: Alle items in de Product Backlog moeten een inschatting (estimation) hebben.
- Prioritized: De volgorde in de Product Backlog moet altijd de juiste prioriteit aangeven.
PBI Estimation
Story Points
Bij waterfall proberen we op voorhand precies uit te rekening hoelang elk stuk werk zal duren om zo tot een exacte project planning te komen.
Bij Scrum gaan we nog steeds elk PBI inschatten, maar i.p.v. de exacte uitvoeringstijd gebruiken we een relatieve complexiteit, uitgedrukt door een getalwaarde. De zogenaamde story points. Deze getalwaarde ligt meestal tussen 1 en 100.
Met relatief bedoelen we relatief t.o.v. andere PBIs. Zo kunnen we een item zien als ongeveer even complex, een beetje complexer, dubbel zo complex, enz.
Voor de mogelijke waarden wordt vaak een vaste en exponentieel-groeiende reeks gekozen. Dit weerspiegelt namelijk het feit dat hoe groter en complexer een PBI, hoe minder exact de inschatting kan zijn. Vaak wordt gekozen een iets aangepaste reeks van Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100 of voor matchten van twee: 1, 2, 4, 8, 16, 32.
Deze keuze ligt bij het team en verschillende teams kunnen verschillende waarden gebruiken.
Ideaal voor de Product Owner is als alle items in the product backlog zo een inschatting hebben. Maar we hebben gezien dat niet alle PBIs in evenveel detail uitgewerkt zijn. Dat betekent dat de inschatting voor minder uitgewerkte PBIs minder exact (en vaak ook een stuk hoger) zal zijn. Ook op inschattingen kunnen we in Scrum itereren - als een PBI verder wordt uitgewerkt kan de inschatting herzien worden. Voor hele grote PBIs waarvan we weten dat ze later opgedeeld zullen worden, kunnen zogenaamde t-shirt sizes gebruikt worden: bvb. S, M, L, XL.
Planning Poker
Planning Poker is een manier waarop het team tot een gezamenlijke inschatting kan komen. De in te schatten PBIs worden één voor één doorgenomen en zo nodig verduidelijkt. Elk teamlid (PO en SM doen in principe niet mee maar zijn wel aanwezig) kiest dan tegelijk een waarde uit de afgesproken reeks.
Alle stemmen worden vergeleken en zo nodig besproken. Een veelgebruikte regel is dat stemmen mogen verschillen maar de hoogste en laagste stem moeten naast elkaar liggen in de reeks. Bvb 3,5,5,5 is ok, maar 3,5,8,5 niet. Dit is een signaal dat niet iedereen hetzelfde begrip heeft van de PBI en deze mogelijks verder verduidelijkt of uitgewerkt moet worden.
Bij veel software oplossingen, bvb Jira, is planning poker een geïntegreerd functie.
Opmerking
PBI Estimation lijkt misschien een grote tijdsinvestering voor het hele team en vooral nuttig voor de PO.
Maar de echte toegevoegde waarde voor het team zijn de gesprekken die onvermijdelijke tijdens deze meetings naar boven komen. Door een inschatting te moeten maken wordt je verplicht elk item in detail te begrijpen en over verschillende aspecten na te denken (testing, integratie met andere componenten, …).
Opdracht
Als opdracht proberen we de PBIs van onze boeken-app in te schatten.
We kunnen gebruiken maken van tools als https://planning-poker-agile.web.app of https://planningpokeronline.com.
Velocity
De Velocity (snelheid) van een Sprint is de som van alle Story Points die tijdens de Sprint werden afgewerkt.
Op die manier verkrijgt de Product Owner na een aantal sprint een gemiddelde Velocity. Hiermee kan hij beginnen inschatten hoeveel Sprints er zullen nodig zijn om een bepaald aantal PBIs uit de Product Backlog af te werken.
Hoe meer sprints worden afgewerkt, hoe beter deze inschatting zal evolueren.
Soorten PBIs
Het hebben het al uitgebreid gehad over User Stories en deze vormen normaal gezien de grote meerderheid van de PBIs.
Toch kunnen er nog andere soorten werk opduiken die we wel als PBIs willen vastleggen maar geen echte User Stories zijn.
- Defect of Bugfix
- Technical Improvement, bvb. een verplichte database versie upgrade
- Knowledge Acquisition, bvb. een prototype of proof-of-concept maken - worden ook wel Spike genoemd
Product Backlog Grooming
Backlog Grooming (letterlijk: verzorging) is de combinatie van drie belangrijke activiteiten:
- Het aanmaken en verfijnen (uitwerken) van PBIs
- PBI Estimation
- Het prioritiseren van PBIs
Backlog Grooming staat onder leiding van de Product Owner maar wordt, afhankelijk van de activiteit, ondersteunt door de product stakeholders en rest van het Scrum team. Het is normaal dat het team ongeveer 10% van een Sprint spendeert aan backlog grooming activiteiten.
Sprints
Herhaling
Elke sprint bestaat uit de volgende activiteiten of gebeurtenissen:
Sprint Planning: het volledig Scrum team spreekt de inhoud van de komende sprint af
Sprint Execution: de eigenlijke sprint, met de dagelijkse Daily Scrum of Standup
Sprint Review: het Scrum team presenteert de resultaten aan de belanghebbenden (stakeholders); samen worden eventuele aanpassingen aan de product backlog gemaakt
Sprint Retrospective: het Scrum team inspecteert de afgelopen Sprint en identificeert mogelijke veranderingen om de effectiviteit te verhogen
Sprint Planning
Tijdens de sprint planning worden twee belangrijke vragen beantwoord:
- Wat gaan we doen?
- Hoe gaan we dit doen?
]
Inputs:
- Product Backlog: de stories bovenaan moeten klaar zijn voor de sprint
- Team velocity: storypoints van de vorige sprints
- Constraints: technische of andere beperkingen; bvb. een specifiek testsysteem zal niet beschikbaar zijn
- Team capabilities: de technische kennis binnen het team, afwezigheden en beschikbaarheden
- Initial sprint goal: wat de PO graag zou verwezenlijken in deze sprint
Sprint Execution
Elke Sprint kan je eigenlijk zien als een mini-project waarvan het team gezamenlijk en in detail de inhoud heeft vastgelegd tijdens de Sprint Planning.
De eigenlijke uitvoering van de Sprint komt meestal uit op 80%-90% van de volledige Sprint looptijd (bvb 8 dagen bij sprints van 2 weken).
De output van de Sprint Planning vormt de input van de Sprint Execution: de Sprint Goal en Sprint Backlog.
Tijdens de sprint heeft het team altijd de Sprint Goal en geselecteerde PBIs voor ogen en organiseert zelfstandig het werk in overeenstemming daarmee. M.a.w. er wordt in de eerste plaats samengewerkt om de vooropgestelde doelen te bereiken, i.p.v. taken uit te delen waarbij elk teamlid op zijn eigen taak focust.
Het afwerken van PBIs en daarbij horende taken in volgorde heeft altijd de hoogste prioriteit. Dit kan bijvoorbeeld inhouden dat het belangrijker is de code van een teamlid te reviewen zodat het gemergd kan worden, dan aan de volgende taak te werken.
De Daily Scrum of Standup is een dagelijkse samenkomen van het team. Dit is een synchronisatie meeting voor het team zelf, en geen status meeting. Er wordt in de eerste plaats vooruit gekeken: wat moeten we vandaag doen en zijn er blokkerende elementen die vooruitgang belemmeren. De bedoeling is om deze meeting onder de 15 minuten te houden.
Sprint Review
De Sprint Review is een inspect-and-adapt moment aan het einde van elke sprint waarin het Scrum-team en stakeholders het opgeleverde productincrement bekijken en bespreken. Waar de Sprint Retrospective focust op het proces, richt de Sprint Review zich op het product zelf en de toekomstige richting ervan.
De Sprint Review biedt transparantie over de huidige staat van het product, inclusief problemen of afwijkingen. Het doel is feedback verzamelen, leren en tijdig bijsturen. Dankzij de korte sprintcycli kan het team snel reageren op veranderende inzichten of marktomstandigheden.
Deelnemers zijn het volledige Scrum-team (product owner, ScrumMaster en development team) en relevante stakeholders zoals management, gebruikers, business owners, support, marketing of klanten.
Tijdens de Sprint Review geeft het team eerst een samenvatting van het sprintdoel en de behaalde resultaten. Daarna volgt, indien van toepassing, een demonstratie van het werkende productincrement.
Sprint Retrospective
De Sprint Retrospective is een vast Scrum-moment aan het einde van elke sprint waarin het Scrum-team het eigen werkproces onderzoekt en verbetert. Waar de Sprint Review focust op het product, richt de Retrospective zich op samenwerking, processen, communicatie, tools en werkwijzen. Het doel is continu leren en verbeteren.
Het volledige Scrum-team neemt deel: development team, ScrumMaster en product owner. Openheid en psychologische veiligheid zijn cruciaal zodat problemen eerlijk besproken kunnen worden zonder schuldtoewijzing.
Tijdens de Retrospective identificeert het team inzichten: wat goed werkte, wat niet werkte en wat verbeterd kan worden. Deze inzichten worden gegroepeerd en geprioriteerd, vaak via dot voting. Belangrijk is dat het team concrete acties bepaalt die in de volgende sprint uitgevoerd worden, zoals technische verbeteringen of procesaanpassingen.
