Retrospektive und DoR / Panda Story – Episode #02

Retrospektive und DoR – Panda Story – Episode #02

Am Nachmittag des Tages ist die Team Restrospektive. Howard hat sich vorbereitet, um diese Chance zu nutzen, den letzten Sprint zu reflektieren. Er hat sich im Besonderen Gedanken darüber gemacht, wie das Refinement ablaufen sollte. Er ist sich nun sicher, dass der  Weg, komplett auf Effizienz zu gehen, nicht der Richtige war. Aber ganz die Zügel aus der Hand geben, möchte er nicht. Er glaubt, eine Definition auf Ready (DoR) könnte helfen, eine Balance herzustellen. Der Product Owner wird das erste Mal bei der Retrospektive dabei sein. Das Development Team hatte es bis dato nicht zugelassen, dass er dabei ist und ihn hat es nicht gestört. Howard hat ihn explizit eingeladen, um dem gesamten Scrum Team die Möglichkeit zu geben, sich zu verbessern.

Jeder aus dem Team trägt im Laufe der Retrospektive seine Punkte vor. Der Product Owner merkt an, dass er enttäuscht ist, dass im Sprint nicht an die alternative Routenberechnung gedacht wurde. Das Development Team ist enttäuscht, dass das Commitment vom Sprint nicht erfüllt werden konnte. Noch bevor es zu einer Analyse oder Erörterung im Scrum Team kommen kann, schlägt Howard vor, vielmehr besteht er darauf, eine Definition of Ready zu entwickeln. Er hat auch bereits einen ersten Entwurf dabei, der wie folgt aussieht:

Definition of Ready

  1. PBI (Product Backlog Item) sind vornehmlich als User Story inkl. Akzeptanzkriterien verfasst
  2. PBI sind geschätzt
  3. PBI besitzen einen Value

Howard hat das Thema der letzten Tage, des letzten Sprints zusammen mit Britta reflektiert, daher erklärt er den ersten Punkt nochmals. Er hält es für sinnvoll, dass immer dann User Stories als PBI Format verwendet werden, wenn ein direkter Kundennutzen auch adressiert wird. Er weiß, dass es ein Fehler war, zu fordern, dass alle Akzeptanzkriterien vom Product Owner kommen müssen. Im Zuge dessen stellt er  gleich die drei Cs vor, von denen er glaubt, dass diese ein guter Weg sind, User Stories zusammen mit dem Team zu entwickeln.

Die Drei Cs stehen für

  • CARD
  • CONVERSATION
  • CONFIRMATION

Besonders auf das zweite C geht Howard expliziter ein, er erinnert sich an Britta und ihren Kommentar bzgl. dem Agilen Manifest. Er wünscht sich, dass über jedes PBI bzw. über jedes User Story mindestens einmal gesprochen wird. Somit ein Versprechen für Kommunikation. Auch ermöglicht diese Kommunikation nun viel besser, dass der Product Owner zusammen mit dem Development Team die Akzeptanzkriterien (das dritte C) für die  User Stories im Refinement entwickelt, nachdem diese die Funktion der User Story erörtert haben. Hierfür hat Howard noch die Story Card mitgebracht, das erste C von den drei C. Er schlägt vor, diese Karte zu benutzen, inkl. einem Template für User Stories.

Als <Persona / User> möchte ich <Funktion> damit <Nutzen>

Howard erklärt, der Product Owner ist der Experte für den Nutzen, das Team für die Funktion. Im Refinement gibt das Development Team somit Input bzgl. der Funktion, denn oft findet sich eine bessere oder andere Funktion, welche den Nutzen besser erfüllt. Howard ist mit dem Ergebnis der Retrospektive soweit zufrieden, das Team hat eine DoR und das User Story Problem ist auch aus der Welt geschafft. In der Cafeteria berichtet er Britta von der Retrospektive und der DoR. Er hofft, dass Britta es genauso sieht und vielmehr, dass der Produkt Owner verstanden hat, dass PBIs, welche nicht der DoR entsprechen, nicht in den Sprint genommen werden.

Britta ist erfreut über die Fortschritte von Howard und seiner ersten Retrospektive mit dem Team. Britta ermuntert Howard erneut, das Agile Manifest zu reflektieren, bezogen auf die DoR und seiner Forderung gegenüber dem Product Owner.

find the english version here / Zur Englischen Version