Introductie
In deze post deel ik de experimenten die we de afgelopen drie sprints hebben gedaan met ons fysieke Scrum board. De focus lag op een beter begrijpelijke visuele weergave van onze sprintvoortgang. Sprints zijn voor ons op dit moment blokken van twee weken.
Ons Scrum board zoals het nu is
De afbeelding hieronder laat het board zien dat we bijna een jaar gebruiken. Toen we Scrum serieuzer gingen nemen, merkten we dat dit board aan transparantie tekortkomt.
Op dit board hebben we al veel van de eerdere problemen opgelost. Die verbeteringen leg ik uitgebreid uit in een eerdere post: Our sprints in real life.
Om onze reis beter te begrijpen is “Achieving FLOW with Scrum” ook een must-read. Die post duikt in onze achtergrond en, belangrijker nog, beantwoordt de vraag: waarom doen we dit eigenlijk?
Dit zijn de lanes en de opzet die we op dit moment gebruiken. De laatste twee (Testing en Done) hebben we gesplitst voor meer transparantie binnen onze huidige CI/CD-opzet. Hieronder een lijst met dingen die we al getest hebben en dus op dit board zijn doorgevoerd. Deze verbeteringen blijven we meenemen bij het experimenteren met nieuwe versies van ons board.
Het sprintdoel is duidelijk zichtbaar.
We gebruiken groene kaartjes voor de items die bijdragen aan het behalen van het sprintdoel.
Taken die te lang in testing staan markeren we met een visueel uitroepteken.
In onze Done-lane gebruiken we “released” en “not yet released”, zodat DOD-items die nog niet gedeployd zijn zichtbaar blijven voor het Scrum team.
De volgorde van ons werk staat op het board in de Todo-lane van boven naar onder. Bovenaan betekent eerst, tenzij er een goede reden is om niet in die volgorde te werken :)
Andere taken uit onze sprintcommitment markeren we blauw.
Willekeurige bugfixes en mogelijke hotfixes die tijdens een sprint opduiken, markeren we rood. Die gaan onderaan het board. Ze kunnen belangrijk zijn, maar ze kwamen tijdens een sprint naar boven en staan daarom onderaan de “TODO”-lane.
Subtasks worden altijd op dit board gedefinieerd. Ze zijn er voor de developers om het werk te doen waarmee de volledige story wordt opgeleverd. Ze kunnen in Jira staan, maar het fysieke board is leidend.
We gebruiken naamkaartjes om te laten zien wie waaraan werkt.
De reden dat we zijn gaan experimenteren met andere boardopzetten, hieronder te vinden, is dat we stories steeds vaker gingen opsplitsen in subtasks. Maar als een developer een subtask afrondde, wilden we die niet direct van het board halen, om een heleboel verschillende redenen.
Een subtask weghalen zorgt voor minder transparantie en voor minder gesprekken over afgeronde subtasks.
Het geeft developers die niet op kantoor waren (vrij) inzicht in afgeronde taken als ze de volgende dag binnenkomen.
Het belangrijkste punt was het gebrek aan transparantie dat dit board nog steeds had rond subtasks!
Het voelt ook bevredigender om een afgeronde subtask naar een vaste plek op het board te verplaatsen. Neerpleuren en verder. Dat geeft een gevoel van afronding. Dat gevoel krijg je niet als je wat je net hebt afgerond direct weghaalt, schoonmaakt en uitwist.
In de eerste versie van ons board hadden we hier geen rekening mee gehouden. Soms gingen subtasks mee met de story. Op andere momenten verschoof een subtask naar de “Done”-lane. Dat is fout! Er valt niets te releasen of niet te releasen. Het is een afgeronde subtask van een branch die waarschijnlijk nog niet eens gecommit is. Deze situatie zorgde voor veel problemen op het gebied van transparantie.
Aanpassingen eerste iteratie
We zijn gaan experimenteren met het splitsen van de “Dev”-lane in een “Doing” en een “Done”. Zo konden we afgeronde subtasks in een eigen lane houden. Aanvankelijk was er wat irritatie over deze opzet. Maar het was essentieel om het uit te proberen om de effectiviteit te bepalen!
Conclusie eerste iteratie
Na twee weken met deze opzet gewerkt te hebben, is onze conclusie dat het nuttig is om een vaste plek te hebben voor “Done” subtasks. Maar die plek binnen de huidige lanes van het board is niet ideaal. Afgeronde subtasks zouden niet meer zo zichtbaar moeten zijn; nu lijkt het alsof ze nog verder naar rechts moeten.
Subtasks zelf gaan bijvoorbeeld niet naar Testing, want ze zijn onderdeel van een story die de waarde vasthoudt. Het is de story die verder beweegt naar Review, Testing en Done. Deze aanpak raden we dus niet aan.
We zijn wel overeengekomen om kaartjes weg te halen als de developers collectief vonden dat het tijd was. Maar ook die methode geeft geen transparantie, omdat er geen duidelijke regel is.
Aanpassingen tweede iteratie
Samen kwamen we met een nieuwe versie van het board. Ook deze versie staat op de afbeelding hieronder.
We zijn teruggegaan naar de lanes zoals we die aan het begin van dit experiment hadden. Todo, Dev, Review, Testing en Done. De visuele weergave van Todo hebben we weggehaald en daar staat nu het sprintdoel. We waren het er allemaal over eens dat dit een betere plek is voor het sprintdoel.
We besloten ook om werk nooit boven de items te plaatsen die het behalen van ons sprint goal vertegenwoordigen. Stel dat we beginnen aan een blauw of rood item. Dat item schuift naar “Dev”, maar blijft op dezelfde horizontale lijn staan waar het oorspronkelijk lag. Vanaf nu willen we items dus horizontaal uitgelijnd houden terwijl ze door de lanes bewegen. De enige uitzondering is de Done lane, die is verdeeld in secties voor gereleased en nog niet gereleased werk.
De “Burn Pile” is een naam die we zelf verzonnen hebben voor alle afgeronde subtasks. We wilden voorkomen dat we twee “Done” lanes kregen. Het is gewoon bevredigend om de subtasks die je net hebt afgerond op deze plek te leggen! Deze aanpak geeft niet alleen een gevoel van afronding, maar laat ook zien wat er allemaal als subtask is afgerond.
Conclusie tweede iteratie
Dit is de eerste iteratie van onze “Burn Pile”-versie. We hebben al wat andere overwegingen besproken om deze versie uit te proberen.
Misschien moeten we voor de transparantie een verwijzing naar het story toevoegen. Of bijvoorbeeld dezelfde subtasks van een story bij elkaar groeperen.
We leren van deze ervaring door het gewoon in de praktijk te brengen. Het is belangrijk om dingen niet meteen onnodig ingewikkeld te maken. Zoals je op de screenshot ziet, hebben we al wat subtasks in de Burn Pile gelegd, en we zijn het er allemaal over eens: het voelt goed om dat fysiek te doen.
Conclusie
We hebben besloten dat we voorlopig met deze versie van het bord verder gaan. De eerste iteratie werkte niet goed: te veel lanes, te veel ruimte, twee Done lanes, en subtasks die na afronding te lang zichtbaar bleven.
Vanaf nu gebruiken we dus deze versie. Ik blijf deze post updaten telkens als we verbeteringen vinden in ons werk met dit bord.
