Vorige keer heb ik uiteengezet waarin de scrummethode van de traditionele (waterval)methode verschilt. In een volgend blog zal ik wat meer vertellen over Sprint 0, 'de voorbereidingssprint', waarin een aantal basale eigenschappen van het project vastgesteld worden. In Sprint 0 worden tevens de meeste stories bepaald - kort gezegd: de onderdeeltjes die ontwikkeld moeten worden.  Na deze Sprint 0 begint het bouwen, steeds in sprints van twee weken. In deze blog leg ik uit hoe de werkelijke sprint bij Occhio verloopt. 

Elke sprint heeft eenzelfde ritme: 

  • Een meeting aan het begin van de sprint: de zogenaamde Sprint Planning 
  • De ontwikkelaars en Product Owner gaan aan de slag: bouwen, ontwerpen, content vullen, testen. 
  • De meeting aan het einde van de sprint: de Sprint Demo. 

Sprint Planning 

Op de eerste dag van de sprint (meestal maandag of dinsdag) komen alle ontwikkelaars, de Scrum Master, Product Owner en Stakeholders samen. Niet alle Stakeholders zijn nodig bij dit overleg: alleen diegenen die een nuttige inbreng in deze sprint denken (of willen) te hebben. Aangezien aan het einde van sprint 0 al bepaald is wat er ongeveer in deze sprint gaat gebeuren (Sprint Goal en globale prioritering stories), kan de Product Owner het beste bepalen welke stakeholders er wel of niet bij aanwezig moeten zijn. Hierbij is het belangrijk dat de mensen die bij de meeting zijn mandaat en kennis genoeg hebben: er moet namelijk tijdens de meeting beslist kunnen worden, want de volgende ochtend staan de ontwikkelaars al klaar om direct aan de slag te gaan. 

Scrum tijdens de meeting besluiten | Occhio Sneek

De Sprint Planning ziet er globaal zo uit: 

  1. Sprint Goal herhalen/bepalen (wat gaan we deze sprint globaal doen? bijvoorbeeld "Beheermodules ontwikkelen") 
  2. Stories selecteren (welke gaan en willen we doen?) 
  3. Stories prioriteren (welke van deze geselecteerde doen we eerst?) 
  4. Stories uitwerken, detailleren en taken aanmaken 
  5. Stories inschatten (hoeveel tijd kost een story) 
  6. Stories prioriteren (indien er een ander inzicht is ontstaan n.a.v. schatting) 

Vooral in stap 4 zijn alle hens aan dek nodig: hier wordt bepaald hoe de story er echt uit ziet.  De story luidt bijvoorbeeld als volgt: "Als bezoeker wil ik direct weten hoeveel hypotheek ik kan krijgen, zodat ik een idee krijg hoeveel ik kan lenen". De ontwerper schetst een voorstel, de Product Owner en Stakeholder(s) (bijv. specialistische collega's van de opdrachtgever) denken na over welke velden het formulier zal moeten krijgen, de ontwikkelaars checken of het technisch allemaal mogelijk is en uit welke taken de user story bestaat. Samen bedenken ze wat de beste interactieoplossing is. 

Planning poker helpt vlot en grof inschatten 

In stap 5 wordt ingeschat hoeveel tijd de ontwikkelaars denken nodig te hebben. Om een snelle, effectieve maar grove schatting te maken, wordt er met Planning Poker gewerkt. Ieder heeft een set kaarten met daarop de getallen 0, 1, 2, 3, 5, 8, 13, 20 en 40.

De getallen van de planning poker kaarten zijn gebaseerd op de reeks van Fibonacci. Meer weten over planning poker?

Per story wordt door iedereen ingeschat hoeveel uren ze individueel denken dat dit kost om te ontwikkelen: iedereen gooit op aangeven van de scrum master één kaart op. Ook de product owner schat mee, zo zie je snel of er een verschil van inzicht is over de grootte van de taak. Uiteindelijk bepalen de ontwikkelaars samen hoe hoog de schatting wordt. Aardig aan deze methode is dat je gedwongen wordt om grof te schatten en op het moment dat je allemaal hetzelfde kaartje opgooit is er geen onnodige discussie over de inhoud en inschatting van de story. Als de product owner een schatting erg hoog vindt, kan hij dit direct aangeven en kan er gekeken worden of de story vereenvoudigd kan worden.

Aan het einde van de sprint planning is bekend: 

  • welke story als eerste, tweede, derde, vierde etc gebouwd gaat worden 
  • welke stories de ontwikkelaars denken af te krijgen 
  • welke 2 a 3 user stories waarschijnlijk niet af komen (tenzij het meevalt). De zogenaamde "PO's corner of hope" 
  • uit welke taken een story bestaat 

Met deze informatie wordt het zogenaamde Scrumboard bij Occhio opgetuigd. Hierop is precies te zien wat er in deze sprint allemaal gebeurt. 

Bouwen, ontwerpen, content vullen, testen 

Direct na de Sprint Planning beginnen de ontwikkelaars met de bouw. Soms moet de ontwerper nog wat schermen detailleren, maar vaak is dit vlot gedaan. Vragen zullen de ontwikkelaars bij de Product Owner neerleggen en rond woensdag/donderdag is de Product Owner bij Occhio op kantoor. De ontwikkelaars kunnen dan efficiënt overleggen en wellicht al een demo en uitleg geven van de eerste stories. De Product Owner kan dan gelijk de content van die stories invoeren en de stories testen. Eventuele bevindingen kan de Product Owner dan direct met ontwikkelaars doornemen. Omdat de ontwikkelaars de stories nu vers in hun hoofd en vingers hebben, kunnen aanpassingen efficiënt gedaan worden: dit scheelt een hoop tijd ten opzichte van een aanpassing die pas veel later gevraagd wordt. Kortom: er blijft meer tijd over om user stories te ontwikkelen. 

de product owner heeft een erg actieve rol 

Afhankelijk van de stories kan het wenselijk zijn dat de product owner in de week erop (de tweede week van de sprint) nog een keer langskomt voor overleg, content invoeren en testen. Fijn is dat een story ook echt volledig afgerond wordt. In de traditionele projectmanagementmethode moet achteraf alles in één keer uitgelegd, getest en gevuld worden - niet echt ideaal aangezien je een hoop moest onthouden in plaats van goed getraind werd. 

De Product Owner heeft dus een erg actieve rol: twee keer per week moet hij aanwezig zijn: reken op 5 uur voor de Sprint Planning + nabespreking, 2 x 4 uur voor overleg, content invoeren en testen en 2 uur voor de Sprint Demo. Soms kan hij een ander sturen als vervanger, maar deze moet dan wel mandaat genoeg hebben om te kunnen beslissen. 

Tot slot: de Sprint Demo 

Aan het einde van de sprint, meestal op donderdag of vrijdag van de tweede sprintweek, is de Sprint Demo. Tijdens deze meeting tonen de ontwikkelaars, scrum master en product owner aan de stakeholders welke user stories ontwikkeld zijn. De scrum master of een ontwikkelaar neemt alle stories door. Deze stories zijn dan al eerder getest door de product owner. 

Eventuele kleine verbeteringen en bugs worden hier nog opgemerkt en verwerkt in een story voor de volgende sprint. Tevens is er ruimte voor reflectie: hoe is afgelopen sprint gegaan? Dit onderdeel heet in scrum-termen de Retrospective. Ook wordt er doorgenomen welke stories niet ontwikkeld zijn: bij de volgende Sprint Planning wordt bepaald of deze dan ontwikkeld worden. 

In een enkel geval worden Sprint Demo en de Sprint planning van de volgende sprint in één meeting gedaan: vaak op maandag of dinsdag. Voordeel is dat je dan maar één keer samen hoeft te komen. Nadeel is dat de meeting erg lang gaat duren, waardoor aan het einde van de Sprint Planning de concentratie wat weg is. 

In de serie over scrum verschenen: 

Deel dit artikel via
X

Welkom! Deze website maakt gebruik van cookies

Geef hier aan welke cookies we mogen plaatsen. De noodzakelijke en statistiek-cookies verzamelen geen persoonsgegevens en helpen ons de site te verbeteren.

Noodzakelijke cookies helpen een website bruikbaarder te maken, door basisfuncties als paginanavigatie en toegang tot beveiligde gedeelten van de website mogelijk te maken. Zonder deze cookies kan de website niet naar behoren werken.

NaamAanbiederDoelVervaldatum
admin_authOcchio.nlWij gebruiken deze cookie om te onthouden of een Occhio.nl gebruiker is ingelogd in ons systeem.5 jaar
October_sessionOcchio.nlDeze cookie wordt gebruikt door ons content management systeem en wordt geplaatst bij bezoek aan willekeurig welke pagina van onze website. Sessie
NaamAanbiederDoelVervaldatum
_gat_gtag_UA_63158_1Google-analytics.comGebruikt door Google Analytics om verzoeksnelheid te vertragen1 minuut
_gaGoogle-analytics.comRegistreert een uniek ID die wordt gebruikt om statistische gegevens te genereren over hoe de bezoeker de website gebruikt.1 jaar
_gidGoogle-analytics.comRegistreert een uniek ID die wordt gebruikt om statistische gegevens te genereren over hoe de bezoeker de website gebruikt.24 uur

Occhio.nl maakt geen gebruik van marketing cookies.

Cookies

Een cookie is een klein tekstbestand dat tijdens uw bezoek aan een website wordt geplaatst. In dit tekstbestand wordt informatie opgeslagen. Deze informatie kan bij een later bezoek weer worden herkend door deze website.

Bekijk hier onze privacy verklaring