Omgaan met bugs in SCRUM

Hoe gaan we om met bugs in Scrum? Hoe bepalen we de omvang? Zetten we ze in een afzonderlijke backlog? Of wijzen we ze toe aan een apart SCRUM team? 
 
Scrum behoort tot de “lichtgewicht” ontwikkelprocessen. Daarvoor hebben we eenvoudige methoden nodig en liever geen extra administratie, tracking of management. Afzonderlijke teams voor bugs hebben waarschijnlijk niet dezelfde feeling met de software als het scrum team dat de software bouwde. Bovendien is het niet eenvoudig om professionals te vinden die gemotiveerd zijn voor een carrière in het oplossen van bugs. Het is goedkoper en efficiënter om bugs af te handelen in de bestaande product backlog.

Grootte van bugs niet bepalend voor niet opgeleverde broncode

Het is het beste om de bug direct weer aan de huidige of volgende sprint toe te voegen, zonder de bug te dimensioneren. De context zit nog vers in het hoofd van het team waardoor de oploskosten laag zijn. Hoewel deze aanpak de gemiddelde snelheid verlaagt, zal de kwaliteit van de productie door bugloze user stories toenemen. 
 
Hoe zit het met bugs die worden aangetroffen in opgeleverde software of in software die het huidige team niet heeft gemaakt?

• Moeten we ze gewoon toevoegen aan de sprint backlog en ons niet bekommeren om de omvang van de bug?
• Gaan we de bug als een user story behandelen en uren schatten?
• Moeten we user stories op maat maken en die geheel uitpunten?
• Of moeten we Scrum helemaal niet gebruiken en de bugs gewoon met Kanban oplossen?

Als een team Scrum gebruikt en aan user stories werkt, voegt men meestal geen ander team toe alleen maar om bugs te herstellen in Kanban. Zelfs niet als ze er geld mee kunnen besparen:

• Het is niet efficiënt als iemand anders dan de user story developer de bugs oplost.
• Het is niet eenvoudig om een ontwikkelaar te vinden die enthousiast is over het oplossen van bugs (motivatieprobleem).
• Kanban is meer geschikt voor een omgeving waar de workflow soepel loop en het team deskundig is met betrekking tot de software. Anders wordt er te veel geëxperimenteerd en gediscussieerd.

Story-points van de gevonden bugs

Bugs zijn in veel opzichten vergelijkbaar met een user story. Aangezien de huidige functionaliteit niet goed is kunnen we een bug ook beschouwen als een story om de juiste functionaliteit te implementeren.

Story-point achtergronden

Om story-points te bepalen, gebruiken we een combinatie van risico, complexiteit en inspanning en komen met een getal.

Softwarekarakteristiek-kostprijsberekening (story-pointing) is vergelijkbaar met de kosten bepaling van een functie. Onbekende code kan een risico op bugs betekenen, zeer complexe algoritmen zijn ingewikkeld en als er te veel items aangepast moeten worden is dat een grote inspanning.  

	Story / subonderdeel	Bug
Risico	Kwetsbare code, onbetrouwbare afhankelijkheden, of nieuwe bibliotheken die worden gebruikt, enz.	Kan voortkomen uit code waar niemand bekend mee is. Kan voortvloeien uit slecht geschreven bestaande code, enz.  In het algemeen is er meer risico op een bug als de code eerder voor een andere context was bedoeld.
complexiteit	Een bron van complexiteit kunnen algoritmen of complexe datastructuren zijn. Het synchroniseren van meerdere systeemkoppelingen is eveneens een bron voor bugs.	Complexe bugs ontstaan als ​complexe code gewijzigd moet worden of als er te veel koppelingen geraakt worden. Er zijn veel IT structuren waarin het wijzigen van code een complexe zaak is.
Inspanning	Afhankelijk van het aantal stappen dat nodig is. Het aantal modules en welke bedrijfsprocessen dat wordt geraakt. Er kunnen extra controles, beoordelingen en nalevingsvereisten zijn.	Vergelijkbaar met een user story.

Story-points toewijzen aan bugs

De grootte van een bug vergelijkbaar met een user story. Gebruik daarom dezelfde richtlijn ( Risk + Complexity + Effort ) om story-points toe te wijzen.

• Als een bug niet onmiddellijk kan worden geschat, voeg dan een spike toe. Het is misschien een goed idee om altijd een spike toe te voegen voordat je de bug op maat maakt.
• De product owner moet zoals gewoonlijk de backlog van het product prioriteren.

Een andere mening is dat bugs niet zo groot mogen zijn als stories, want bugs geven meer onzekerheid. Hoewel dat tot op zekere hoogte waar kan zijn, kan de onzekerheid eenvoudig worden weggenomen:

• Het hebben van een piek verzacht een deel van de onzekerheid.
• Als je de Fibonacci-schaal gebruikt – 1, 2, 3, 5, 8, 13, 21 voor de user stories, waarbij 21 de grootste maat is – maak dan een afspraak om de bug-maat te beperken tot 8 of 13 in een sprint.

Het oplossen van een bug kan meestal het doorlopen van de programmacode, her-testen, analyseren, het wijzigen van de code, en unittesten omvatten.

• Na de initiële spike, als de bug wordt geschat op groter dan 13, dan kan deze worden opgesplitst in een Root Cause + Fix story.
• Root Cause is de onderzoeksfase. Het kan acceptatiecriteria hebben en het kan worden gedemonstreerd.

Hoe vertellen we de opdrachtgever hoe lang het duurt?

Gebruik zoals gewoonlijk de snelheid.

• Aantal sprints = Story-points in backlog / snelheid
• Als de opdrachtgever alleen geïnteresseerd is in nieuwe functies (stories), kunnen we de release nog steeds voorspellen door het percentage nieuwe stories in de backlog te gebruiken.

Er van uitgaande dat bugs 30 procent van de story-points in de backlog vormen en algemene snelheid = 20, dan: Het aantal sprints = totaal aantal story-points voor nieuwe functies / (70 procent van 20).

Discussieer mee op LinkedIn.