Variaties op het scrum board: “defect scrum board”

Er wordt op dit moment steeds meer projecten op agile wijze uitgevoerd. Maar ook in traditionele projecten kun je aan de hand van agile principes en practices je voordeel halen. Een van de goede principes van agile is transparantie. In dit artikel leg ik uit wat de klant aan het scrumboard heeft aangepast en hoe dat hielp bij het bevindingen management: het defect scrum board.

We kennen het Scrum board met de bekende kolommen: Story, To do, in progress, to verify en done. De projecten van tegenwoordig die nog niet 100% volgens scrum werken, maar wel scrumlike willen zijn, pakken de tools eruit die voor hen bruikbaar zijn.

Zo heb ik bij een grote klant gezien dat dit scrum board wordt gebruikt als toevoeging voor bevindingen management. Naast het bevindingen administratie systeem is onderstaande scrum board in het leven geroepen.

Kolom 1 Submitted: aanmelden van bevinding
Kolom 2 In analysis: bevinding in analyse
Kolom 3 Prio/ severity: categorie bevinding tov test en business
Kolom 4 Solved: bevinding is opgelost
Kolom 5 Ready for retest: oplossing van bevinding is geïnstalleerd
Kolom 6 Update documentation: documentatie aanpassen
Kolom 7 Done: Done is pas done nadat de documentatie is aangepast

Dit scrum board laat de verschillende statussen van de bevinding zien. Tevens zien we welke test priority (van hoog naar laag) en business severity (van hoog naar laag) de bevinding heeft. De bevindingen worden logischerwijs vanaf linksboven naar rechtsbeneden in de tabel weggewerkt.

Vaak is er een afspraak dat aan het einde van een iteratie(of release) niet meer dan X aantal bevindingen open mogen staan. Een board kan het team helpen om daar gedurende de iteratie/ release op te sturen. Als de (work in progress) queue met openstaande majors bijvoorbeeld gemaximeerd wordt tot een lengte van 4 meldingen, dan zal een developer getriggerd worden om niet zomaar nieuwe stories op te pakken, als die bevindingen queue bijna vol zit. Omgekeerd zou een tester wellicht kunnen gaan helpen met het analyseren/ oplossen van bevindingen, als het maximum aantal reeds is bereikt.

Voordeel:
1)  Inzicht aantal bevindingen
2)  Inzicht welke status de bevindingen hebben
3)  Betrokkenheid en samenwerken in het team wordt gestimuleerd door delen van deze informatie
4)  Men kan op tijd bijsturen en taken prioriteren

Nadeel:
1)  Extra administratie, defect scrum board dient in sync te zijn met de bevindingen administratie systeem.

Heb je vergelijkbare voorbeelden? Deel het met ons!

Dit bericht werd geplaatst in Agile like, Agile Testen, Implementatie van agile en getagged met , , , , , , , , , , , , , . Maak dit favoriet permalink.

2 reacties op Variaties op het scrum board: “defect scrum board”

  1. Ben Linders zegt:

    Ik heb bij diverse organisaties soortgelijke scrum boards gezien. Op een Kanban achtige manier toegepast om incident management te doen. De stand-up wordt gebruikt om met de product owner prioriteiten te stellen. Sommige teams gebruiken de retrospective om te kijken wat ze kunnen doen om de Kanban limiet te verhogen cq de doorlooptijd te verkorten, en daarmee hun performance te verbeteren. Hele praktische toepassing van Scrum/Kanban!

  2. Willem Sham zegt:

    Met deze toepassing in een waterval omgeving, ben ik vooral erg te spreken over de transparantie binnen het team, waarbij het team verantwoordelijk is voor het eindresultaat i.p.v. de tester die de eigenaar is van de bevindingen.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s