HEC Blog: Technik & Methoden
Verfasst von Frank Düsterbeck am 25. April 2018
Durch Stakeholder oder Nutzer als Präsentierende

Review mal anders

Das Scrum Review dient ja bekannt­lich zur Inspek­tion des Produk­tin­kre­ments. Häufig werden hier­bei die umge­setz­ten Product Back­log Items, wie z.B. User Stories, durch einzelne Perso­nen des Entwick­ler-Teams oder den Product Owner präsen­tiert. Teil­neh­mer eines Reviews sind dabei idea­ler­weise nicht nur das Scrum Team selbst sondern alle, die dieses Produk­tin­kre­ment inter­es­siert – die Stake­hol­der / Nutzer.

Was liegt da näher, die Stake­hol­der inten­si­ver in ein solches Review einzu­bin­den?

Mit dem Ziel, das best­mög­li­che Feed­back zu erhal­ten, ist es sinn­voll, dass dieje­ni­gen, die z.B. als Nutzer einer User Story genannt sind, versu­chen die Story selbst zu präsen­tie­ren. Hier­bei können alle Betei­lig­ten auf sehr direkte Weise erken­nen, ob sich der Nutzer schnell zurecht­fin­det, ob Hinder­nisse im Arbeits­fluss beste­hen, ob Miss­ver­ständ­nisse, Doppel­deu­tig­kei­ten oder auch Fehler z.B. in den Akzep­tanz­kri­te­rien exis­tie­ren. Der Nutzer selbst bekommt dadurch eben­falls erleb­ba­res Feed­back und kann besser beur­tei­len, ob das, was er sich gewünscht hat, auch entspre­chend umge­setzt wurde.

Ein klei­ner Tipp am Ende: noch besser ist es natür­lich, wenn die Nutzer / Stake­hol­der schon während der Entwick­lung inner­halb eines Sprints mit einbe­zo­gen werden.