User Story Pattern: Teile und Herrsche

In meinem zweiten Artikel zum Thema Story Pattern möchte ich auf ein Problem eingehen, das mir vor kurzem bei einem Kunden begegnet ist.

Es gibt eine große Menge von auf den ersten Blick eher klein erscheinenden Änderungen an meinem Produkt, die bis zu einem bestimmten Zeitpunkt, z.B. einem Messeauftritt, fertig gestellt sein müssen. Die Liste der Änderungen kommt zu mir als Product Owner in Form einer Excel-Tabelle oder einer Powerpoint-Präsentation. Mit der Qualität der Beschreibungen können sowohl mein Team als auch ich gut leben. Wir wissen aber alle, dass die Menge der Änderungen zu groß ist, als dass sie bis zum gesetzten Termin umgesetzt werden können.

Es ist mir schon oft passiert, dass der Product Owner in solchen Fällen eine Story erstellt mit dem Inhalt „Setzt so viele Änderungen wie möglich aus der Liste um“ und den Aufwand aus der aktuellen Velocity seines Teams anhand des Enddatums berechnet oder einfach die Timebox hinnimmt.

Ich gehe mit solchen Fällen anders um. Genau das sind Situationen, in denen ich die Aufgaben des Product Owner besonders ernst nehme. Da mich mein Team ohnehin fragen wird, womit sie beginnen sollen, muss ich mich mit den Prioritäten der einzelnen Änderungen beschäftigen. Nur habe ich, wenn ich das in eine Story packe, keine Möglichkeit den Aufwand der für die einzelnen Änderungen notwendig ist, in meiner Priorisierung zu berücksichtigen. Deshalb erstelle ich aus den einzelnen Änderungen einzelne, vermutlich sehr kleine User Stories. Da stöhnt man als Product Owner schon mal, weil das eine lästige und aufwendige Arbeit ist. Aber die Mühe lohnt sich.
Ich kann die USer Stories dann nämlich nach meinen Vorstellungen priorisieren und in der von mir erdachten Reihenfolge von meinem Team schätzen lassen. Sind Stories dabei, deren Kosten/Nutzen-Verhältnis mir nicht gefällt, sortiere ich sie aus. Und wenn die kumulierte Schätzung des Teams bei seiner aktuellen Velocity das Zeitfenster bis zum Endtermin ausfüllt, kann ich das Schätzen abbrechen. Alles weitere wird nämlich bis zum Termin ohnehin nicht fertig, also muss sich damit auch niemand weiter beschäftigen.

Nach dem ganzen Aufwand, den ich dafür getrieben habe, möchte ich als Product Owner natürlich einen Vorteil gegenüber der Nur-Eine-Story-Variante. Das Positive ist: Es gibt nicht nur einen Vorteil.

  • Weil das Team die Stories geschätzt hat, wird seine Velocity nicht verfälscht. Damit bleibt meine Planungsgrundlage für die nächsten Sprints stabil.
  • Weil ich eine Priorisierung der Stories festgelegt habe, muss das Team mich nicht nach einer Abarbeitungsreihenfolge innerhalb einer großen Story fragen. Ich kann mich also schon um die Inhalte für die nächsten Sprints kümmern.
  • Weil ich das Team nur so viel habe schätzen lassen, wie es schaffen kann, bekomme ich ein Maximum an Output. Das Team muss sich nicht mit Dingen beschäftigen, die für mich nicht relevant sind – die habe ich ja aussortiert.
  • Und ich bekomme nur die Änderungen, die ich auch als wertvoll hinsichtlich ihres Aufwand/Nutzen-Verhältnisses erachte.

Ich habe dieses Pattern unter dem Aspekt Zeitbegrenzung beschrieben, weil es im letzten Szenario, in dem es mir begegnete genau dieses Ziel verfolgte. Ich kann aber auch das Ziel einer Nutzenmaximierung oder einer Aufwandsbegrenzung damit erreichen, je nachdem was mir als Product Owner gerade wichtig ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.