Hoe een product owner bugs moet registreren

In een Scrum/ Agile omgeving is het belangrijk om snel te kunnen schakelen. Dus efficiënt en transparant werken zodat je meters kan maken. De velocity gaat hierdoor omhoog. Dit geldt voor iedereen in het team. Dus ook voor Product Eigenaren. In dit artikel geef ik tips voor Product Eigenaren die tijdens de sprint moeten acceptatietesten.

Mijn ervaring is dat er bij het acceptatietesten door product eigenaren vaak getest word met het beeld dat wat ze testen wel goed is. Dit testen doen ze wel even. En dan, als ze dan een issue (bug/ bevinding) hebben gevonden, staat de hele wereld op z’n kop en moet het direct worden opgelost. De wijze van het registreren van een issue is vaak ook niet om over naar huis te schrijven. Dit gebeurt soms via e-mail of als een comment in de story geplaatst.

Nu loop ik al een tijdje mee als tester en heb ik dit best vaak meegemaakt. Daarom ook de onderstaande tips.

Stick to the team.

Als eerste is het heel belangrijk om in dezelfde kamer te zitten als het developmentteam.  Dit werkt sneller, transparanter en heel efficiënt. Je krijgt veel meer mee van het bouwproces en je ziet gelijk waar het team mee bezig is en/ of tegenaan loopt. Ook kan een developer / tester makkelijker vragen stellen. Het scheelt namelijk : twee meter lopen (of even roept) of dat je naar een andere afdeling moet lopen.

Stand up!

Als Product Owner wil je graag weten wat er met jouw product gebeurt, toch? Daarom ben je onmisbaar bij de stand up! Kom erbij! Sta daar voor het product. Sta daar voor de organisatie die je als PO vertegenwoordigt! Neem je plaats in!

Heb je een issue (bug/ bevinding )? Check het even

Als je ergens tegenaan loopt of je denkt een issue te hebben gevonden loop dan even langs bij het team. Of roep er desnoods een developer / tester erbij als je bij het team in de kamer zit. Door het te toetsen wat je hebt gevonden weet je het direct.  Is het echt een issue? Dan kan je die registreren.

Registeren van een issue (bug/bevinding)

Het registreren van issue gebeurt in een daarvoor bestemde applicatie. Dit kan Excel zijn, Trello, JIRA of een andere tool. Maar ga het niet mailen! Dit komt op de hoop met mails.

Laten we er voor het gemak, voor dit artikel, vanuit gaan dat je JIRA gebruikt.

  1. Registreer het issue als subtask en koppel deze aan de story.
  2. Maak per issue een nieuwe subtask aan
  3. Zet in de titel van het ticket ‘issue’.  Dus bijvoorbeeld ‘issue – er staat een komma teveel in de tekst
  4. Laat het team weten dat je een issue hebt gevonden en geregistreerd is.

Inhoudelijk: het registreren van een issue

De kracht van het registreren van een issue is dat dit gestructureerd gebeurt zodat een ontwikkelaar het kan oppakken. De ontwikkelaar hoeft dan niemand te storen of te gaan shoppen omdat er informatie mist. Daarom het onderstaande lijstje:

  1. Beschrijf het issue. Dus wat heb je gevonden? (huidige situatie)
  2. Wat heb je gedaan zodat dit gebeurt of ontstaat? (Stappen)
  3. Wat had je verwacht? Wat had er moeten gebeuren? (Verwachting)

Het is echt belangrijk om in stappen uit te leggen wat je hebt gedaan. Doe dit zo kinderachtig mogelijk. Dat mag best. Als staan er 100 bullets met stappen: een ontwikkelaar heeft liever veel info dan te weinig.

Dan is het noodzakelijk om screenshots erbij te plaatsen. Dit maakt het voor de ontwikkelaar mogelijk om het issue snel te kunnen beoordelen en te kunnen fixen en voor de tester is het duidelijker waar er op gelet moet worden tijdens het hertesten van het gevonden issue.

Pas dit bovenstaande toe en je zal zien dat het team blij wordt! Tijdens de retro zal je hier schouderklopjes voor krijgen!

Heeft dit artikel je geholpen?
  • Ja 
  • Nee