In een vorige blog heb ik uitgelegd dat onder meer de bezetting in sprintdagen het aantal story point bepalen. Hierdoor hebben we inzicht in hoeveel story points we in de volgende sprint aankunnen. Dát zijn interessante statistieken die mijn scrumteam goed kan gebruiken zodat ze optimaal kunnen presteren. Als Scrum Master faciliteer ik hen hier graag in.
Eigen prestaties en groei monitoren met statistieken
Verkoopcijfers en klanttevredenheid zijn de KPI’s waarop we sturen en die we communiceren. Maar we schrijven geen uren om ons te verantwoorden en automatische rapportages van onze backlog draaien we niet uit. Dashboards waarmee het management ons in de gaten kan houden, daar doen we ook niet aan. Geen cijfers ter controle dus, maar wel interessante statistieken om onze eigen prestaties en groei te monitoren!
Aantal story points verbrand
Dit is voor de Product Owner een belangrijke graadmeter. Immers: hoe meer story points er worden verbrand, hoe meer er door het scrumteam wordt opgeleverd. Dit klopt niet 100% omdat bij scrum poker naar meer wordt gekeken dan alleen de hoeveelheid werk. Heel zwart-wit: een Product Owner heeft wel liever dat er 120 punten worden verbrand, dan 80 story points. Een stijgende lijn in aantal verbrande story points kán aantonen dat het scrumteam steeds meer werk verzet. Alleen is de bezetting van een scrumteam niet bij iedere sprint gelijk. Puur en alleen naar aantal verbrande story points kijken is daardoor geen goede graadmeter om een scrumteam te beoordelen.
Percentage story points verbrand
Als Scrum Master vind ik het percentage verbrande story points daarom belangrijker en relevanter. Het percentage zegt namelijk iets over hoe goed het scrumteam het eigen werk kan inschatten. Liever 50 punten opnemen en daarvan 99% verbranden, dan 100 punten opnemen en daarvan slechts 73% halen. Hoe volwassener en stabieler een team is, des te hoger ligt het percentage. Een hoger percentage over een langere termijn, draagt bij aan de voorspelbaarheid van een scrumteam. Dit maakt de sprintplanning ook een stuk eenvoudiger.
Product Owner versus Scrum Master
Overigens ligt hier een gevaar of in ieder geval een belangrijk verschil in belangen. De Product Owner kan aandringen op zoveel mogelijk story points opnemen in de sprint. In mijn rol als Scrum Master heb ik liever dat het team opneemt wat het denkt aan te kunnen. Een volwassen scrumteam weet zelf als geen ander wat het aankan.
Alle user stories op onze backlog koppelen we aan een thema: onderhoud, optimalisatie, vermarkting, vernieuwing en “Klantblijheid”.
Thema’s voor alle user stories
Alle user stories op onze backlog koppelen we aan een thema. We werken met de thema’s onderhoud, optimalisatie, vermarkting en vernieuwing. Alle scrumteams op onze afdeling werken volgens deze thema’s. De term “Klantblijheid” komt uit mijn koker en hebben we als vijfde thema toegevoegd. Bij iedere sprint moet er een goede verdeling tussen de thema’s zijn. Een sprint met 60% optimalisatie is onhandig en we worden bijvoorbeeld geacht ongeveer 20% aan onderhoud besteden. En we willen iedere sprint minimaal één user story met “Klantblijheid”. Daarom houd ik bij hoeveel we aan de verschillende thema’s besteden. Bij iedere sprintplanning kijken we of de verdeling klopt. Ook deze cijfers helpen het scrumteam bij een betere (planning van de) sprint.