Multi-team release burndown chart
2012-06-11 Martien's vraag resulteert in berichtenstroom
Martien
Sta me toe een vraag toe te voegen aan de plotse vragenstroom van vanmiddag (Ik heb geen verstand van Clojure, Scala of Hadoop. Graphviz weer wel een beetje.)
Hoe doe je een release burndown chart van meerdere teams?
5 teams, 1 product, 3 primaire clusters persona's. Mix van agile praktijken, prille ervaring (sinds begin 2012). Onvergelijkbare velocities. 2-3 releases per jaar. Willen uiteindelijk naar seizoenslag (1 release per seizoen). Release worden nu nog geschat door Product Management met BA en Architecten (dus niet door bouwploegen).
Ik denk richting: ontwikkelepisodes van 1 seizoen (12+1 weken), seizoenplanningssessie met iedereen, epics en storymaps maken. Epics relatief schatten door resp. bouwploegen per personacluster. Scenario's schrijven en daaruit de koppen van de stories destilleren. Die per team laten speedschatten en toetsen of de som daarvan consistent is met de epicschattingen. Dat vervolgens burndownen.
Maar ja, da's alleen maar mijn kronkel. Er zijn vast lichtere, eenvoudiger manieren. Ik houd me van harte aanbevolen.
Sent from Tegel, Martien's iPad…
Oh ja, De Agile voorbeelden op het net gaan veelal uit van één team :-(
Jarl
Schatting door een samen te stellen centraal 'team', uit vertegenwoordigers uit elk team, of uit relevante experts. Bij X werden de eerste schattingen gemaakt door de architecten, bij Y door een groepje experts, bij Z door 3 senior lead developers. Business moet aanwezig zijn om uit te leggen wat ze willen.
Elke story wordt uiteindelijk altijd door het team dat er daadwerkelijk mee aan de slag gaat geschat. Pas op het moment dat ze de bovenkant van de backlog naderen en Ready zijn (op de schatting na dan). Hiervan kan je leren of de originele schattingen een juist beeld geven van de hoeveelheid werk op de totale backlog. Eventueel bijstellen.
Seizoensplanningsessie waarin ook de seizoens-PBL wordt samengesteld klinkt goed. Ik vraag me af of het het waard is om dit met alle teamleden te doen, of dat het met een afvaardiging goed genoeg is.
Eens, voorwaarde is wel ervaring.
Er zit echter ook waarde in het proces van een vroegtijdige eerste schatting. Je kan dan gelijk herkennen of er sprake is van langer durende complexiteit: nieuwe techniek, nieuwe infra, bepaalde kennis, afhankelijkheid/bijdragen van derden, benodigd business of technisch beleid. Dit mis je als je zo'n schatting/plannings/seizoensmeeting geheel zou overslaan.
Maurits
De meest eenvoudige variant die ik ken is: niet schatten. Dat lukt alleen als je een ervaring PO hebt (bij een project lang geleden bij X had ik er zo een) die in staat is om de epics op te knippen in user stories van ongeveer dezelfde grootte. Als je er daar maar voldoende veel van hebt gaat de wet van de grote aantallen tellen, en zijn variaties in je benodigde inspanning nauwelijks meer relevant. Velocity meet je dan aan de hand van het aantal user stories dat een team in een sprint kan afronden.
Pieter
Misschien een open deur maar ik zit te denken aan dat de teams 'round robin' van de geordende lijst met stories pakken: dan heb je de meeste kans dat de belangrijkste dingen af zullen zijn en heeft ieder team een mix van belangrijkste en minder belangrijkste (alles is belangrijk natuurlijk :-) ).
Verder denk ik aan 1 release burn down chart, maw een release burn down per product ipv per team. Je wilt immers de PO inzicht verschaffen zodat het hem helpt met prioriteren.
Waar ik nu geen directe oplossing voor weet, is hoe je in de 'overall' backlog omgaat met het feit dat story points per team gaan. Hoe maak je een forecast voor het product zodat dat de PO inzicht geeft voor het prioriteren.
Eens met Maurits.
Bij X had ik vorig jaar een team waarbij ze de stories zodanig opknipten dat alleen nog maar 2, 3, 5 en 8 als story points voorkwamen. Is wel niet zo precies als wat Maurits beschrijft, maar als de variatie acceptabel is, kun je ook hier kiezen niet meer te schatten.
Het is wel zo dat ik dit meestal pas zie bij ervaren teams die onbewust de stories is even grote brokken splitsen. Waarom? Gewoon omdat ze ervaren dat die grootte brokjes lekker werkt.
Theo
Om de velocities van de teams vergelijkbaar te krijgen zou je een aantal referentie stories of epics door alle teams kunnen laten inschatten. Daaruit kun je dan een omrekenfactor concluderen om velocities te vergelijken, of je zou de Story Points van de teams kunnen herijken zodat ze allemaal min of meer dezelfde maat/referentie gebruiken. Heb ik al eens gedaan bij Rabobank; werkt redelijk. Regelmatig kruisschatten is nodig om de teams 'geijkt' te houden.
Een iets grovere methode is om alleen naar aantallen User Stories te kijken en daar een Burndown van te maken. Je maakt dan de impliciete aanname dat de zwaarte van de User Stories bij wat grotere aantallen uitmiddelt.
Luuk
Minor remark: Round robin lijkt me op papier wel een mooi idee maar in de praktijk is het wel lekker als je als team een epic in kunt duiken. Shared code ownership across teams is natuurlijk heel mooi maar die andere vorm van "ownership" is ook wel heel lekker rewarding