Scrum in de praktijk – begin/einde van een sprint

English: Ken Schwaber

English: Jeff Sutherland, co-inventor of SCRUM...

Image via Wikipedia

Ken Schwaber en Jeff Sutherland geven het regelmatig aan: de regels van Scrum zijn eenvoudig, maar het goed toepassen van Scrum is nog een hele klus.

In deze blog wil ik wat van mijn ervaringen delen zodat we samen leren om Scrum goed toe te passen. Ik hoor dus graag jullie reacties.

Bij een van mijn klanten heb ik een Scrum training

gegeven en het team begeleid met de start van Sprint 1. Helaas kon ik niet bij het einde van de eerste sprint en de start van de tweede sprint aanwezig zijn. Ik heb ze als hint de volgende agenda meegegeven.

9:00 – DEMO

De Product Owner is hier leidend.

De developers moeten alles inchecken en builden. Daarna kan de PO één voor één de User Stories van het ScrumBoard nemen en de tests uitvoeren die op de achterkant staan. Doe dat zoveel mogelijk op een schone omgeving (de A in de OTAP-straat).

Houd goed bij wat er fout gaat, bijvoorbeeld op Task post-its, en vergeet niet complimenten te geven voor wat goed is.

Kleine foutjes, zaken die in 10 minuten zijn op te lossen, worden bij voorkeur vandaag nog ergens opgelost. Grotere punten schuiven door naar Sprint 2. Ze worden daar dan losse taken, kosten dus alleen maar uren, maar leveren geen Story Points op. Ze gaan dus ten koste van de Velocity. Uitzondering is wanneer een Story helemaal faalt. Dan moet die hele Story door naar Sprint 2, en telt dan wel mee. Deze Story telt dan echter niet meer mee voor de behaalde Velocity van Sprint 1.

Mijn inschatting is dat jullie 1 a 2 uur nodig zullen hebben voor de demo.

11:00 – RETROSPECTIVE

De Scrum Master is hier leidend.

Vraag alle leden van het Scrum team om feedback op de eerste sprint. Bijvoorbeeld in de vorm van:

  • wat ging goed en moeten we de volgende sprint net zo doen?
  • wat ging niet goed en moeten we mee stoppen?
  • welke nieuwe dingen zouden we de volgende sprint kunnen starten?

Let erop dat dit kort en concreet blijft. Wat eruit komt moet tijdens de volgende sprint toegepast moeten worden. Vermoedelijk niet veel meer dan 3 puntjes is genoeg.

Ik doe dit zelf graag met post-its (zal jullie niet verbazen). Ik stel dan aan het begin van de sessie bovenstaande vragen, geef iedereen even de tijd om voor zichzelf een paar post-its te schrijven, plak ze dan op een sheet (3 kolommen voor de 3 vragen) en start dan de bespreking.

Het team kiest welke dingen we meenemen in de volgende sprint. Hang die punten dan ook goed zichtbaar op, bijvoorbeeld op een hoekje van de burndown chart.

Normaal gesproken duurt dit niet langer dan 30 minuten. Ik zet daar zelf ook graag een eindtijd op / timebox. Maar voor de eerste keer kan je wel iets meer tijd nemen.

12:00 – LUNCH

13:00 – SPRINT PLANNING 1 van SPRINT 2

De PO is hier leidend.

De PO beschrijft de User Stories die hij graag in de volgende sprint gebouwd ziet. Die worden besproken met het team, op functioneel niveau, nog niet echt op technisch niveau, hoe ze gebouwd worden. Als ze allemaal functioneel duidelijk zijn is deze fase klaar.

14:30 – SPRINT PLANNING 2 van SPRINT 2

Het team is hier leidend.

Het team bedenkt een technische oplossing voor iedere Story, maakt daar Taken voor aan. De Stories kunnen eventueel opnieuw gepokerd worden (als ze al gepokerd waren en we het niet meer met die inschatting eens zijn). Eventuele nieuwe Stories worden ook gepokerd. Taken worden weer ingeschat in uren.

Het team doet een inschatting van de Velocity voor de volgende Sprint. Basis hiervoor is de Velocity van Sprint 1 (dat wat echt gehaald is) en verdere informatie (onder andere het feit dat we nu een sprint van 3 weken doen en de vakantie van één van de teamleden).

Op basis van Velocity en Story Points bepaalt de PO welke Stories in deze Sprint komen en in welke volgorde.

ScrumBoard weer vullen, en Sprint 2 kan starten.

16:00 – CLEANUP SPRINT 1

Oplosssen van de kleine foutjes die in de Demo gevonden zijn.

Taart? Champagne?

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in Agile, Scrum. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s