Brontekst bekijken van Multi-team release burndown chart

{{tag|multi-team}}
{{tag|release}}
{{tag|burndown}}

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