Onderstaande informatie kan als handvat en checklist gebruikt worden door iedereen binnen de nieuwe teams.
Het is verdeeld in de volgende onderdelen:
- Dagelijks tijdens Sprint
- Daily Standups
- Ready proces
- Deployment van app naar Productie
- Per Sprint wissel
- Retrospective
- Refinement
- Sprint Review
- Sprint Planning
Dagelijks tijdens Sprint
Daily Standups
Op tijd aankondigen, mensen verzamelen, TV-scherm met juiste scrum bord aan:
- 10:00 uur team 1
- 10:15 uur team 2
- 10:30 uur team 3
(warning) Niet laten inbellen (onrustig, slechte verbinding, kost tijd).
Scrum bord nalopen en het team wijzen op onderstaande symptonen:
- Zijn User Stories al meerdere dagen in review kolom?
- Zijn User Stories unassigned?
- Zijn de User Stories aan JIRA versions (= release version van een applicatie) gekoppeld?
Inspect&Adapt moment:
is de trend van de Burndown niet volgens verwachting? Dan is herplanning noodzakelijk door een stories waar nog niet aan gestart is uit de sprint te halen. Doe dit bij voorkeur in overleg met de Product Owner.
Ready proces
Door de BA's worden de User Stories met de hoogste prioriteit Ready gemaakt zodat deze behandeld kunnen worden in Refinement sessie. Gebruik de checklist User Story template
Deployment van app naar Productie
JIRA release overzicht bijwerken met de releasedatum
Systeemdocumentatie
Functionele informatie uit User Story opnemen in systeemdocumentatie en versioneren op overzicht Systeemdocumentatie
Per Sprint wissel
Retrospective
Repeterende meeting inplannen in Outlook, locatie regelen, uitnodigingen versturen
Bepaal het onderwerp, format. Zorg voor een beetje afwisseling in aanpak, nodig ook eens een keer de Product Owner uit.
Start met terugblik op de Improvement van de vorige sprint: zijn deze geïmplementeerd? Heeft dit al het verwachte resultaat opgeleverd?
Bepaal 1 improvement voor het team om de volgende sprint op te pakken. Maak hiervoor een User Story aan en zet die bovenaan de backlog voor de volgende sprint. Soms zijn Improvements wat groter (Epic) en kan daar meerdere sprints aan gewerkt worden. Probeer dat dan wel onder te verdelen in kleinere stories/taken die wel in 1 sprint afgerond kunnen worden.
Retrospective resultaat toevoegen aan overzicht Retrospectives
Refinement
Repeterende meeting inplannen in Outlook, locatie regelen, uitnodigingen versturen
(lightbulb) Nodig hier standaard ook de Product Owner voor uit.
Team kan ervoor kiezen om dit te verdelen in meerdere kleinere sessie van 1-1,5 uur per week of in één sessie per sprint van maximaal 2-3 uur.
Bepaal welke Stories in de sessie behandeld kunnen worden:
Dit zijn de user Stories die Ready zijn en hoogste prioriteit hebben
Deze een dag van te voren naar het team e-mailen.
Team kan vragen aan de Product Owner en Business Analist stellen ter verduidelijking van het Requirement. Team bespreekt vervolgens de oplossingsrichting/aanpak van de User Story. Als het duidelijk is wordt met Planning Poker de User Story geschat op het aantal Story Points. Refereer aan de Reference Story als de onderlingen verschillen erg groot zijn.
(warning) Team pokert alleen het Development werk. Het test werk en analyse werk valt hier buiten. Testers en BA's pokeren dus ook niet mee
Reference User Story
Het maken van een nieuwe Front end GUI waarin een backend tabel gelezen wordt en 5 waarden op het scherm worden getoond
Zonder: validaties, updates en saves
Totaal: 5 Story Points
Voer nog een ronde Planning Poker totdat er consensus is. Maximaal 2 rondjes, daarna nog middelen/onderhandelen indien nodig.
Sprint Review
Repeterende meeting inplannen in Outlook, locatie regelen, uitnodigingen versturen.
(lightbulb) Nodig hier standaard alle relevante stakeholders voor uit: Teamleden, Product Owners, Enterprise Architecten, Projectleden, etc.
Maak een sprint samenvatting in powerpoint en zet dit bij het overzicht Sprint Reviews team
Probeer de teams een Demo te geven van werkende software, dat is de kers op de pudding van een Sprint Review
Sprint Planning
Repeterende meeting inplannen in Outlook, locatie regelen, uitnodigingen versturen
(info) Deze meeting kan soms ook direct als afsluiting van de Refinement sessie worden uitgevoerd, als de tijd het toelaat.
Van te voren de capaciteits spreadsheet bijwerken met bekende vakanties van de teamleden zodat de Development capaciteit van de komende sprint bekend is.
Werk de gemiddelde Velocity bij met het resultaat van de vorige sprint. het gemiddelde van de afgelopen sprints is meestal representatief.
Capaciteit * Velocity = maximaal aantal Story Points in de nieuwe sprint