Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

User-Stories schreiben – Wer darf das eigentlich?!

Meta Userstories - was PO und Teammitglied sich wünschen. Scrum als Produkt, das vom Scrum Master entwickelt wird.

Meta Userstories – was PO und Teammitglied sich wünschen. Scrum als Produkt, das vom Scrum Master entwickelt wird.

Die Frage danach, wer die User-Stories schreiben darf, läuft faktisch auf die Frage hinaus, wer für sie und ihre Qualität verantwortlich ist. Und vermutlich denkt sich der ein oder die andere jetzt, dass das banale Fragen sind. Dass das Thema abschließend behandelt ist. Dass es dazu nicht mehr viel zu sagen gibt. Letztendlich: dass die Beschäftigung mit der Frage Zeitverschwendung ist. Ist es aber nicht.

User-Stories schreiben? Das macht der Product Owner!

So lautet wohl die vorherrschende Meinung. In der Fachliteratur und in verschiedenen Blogs wird immer die Wichtigkeit des PO hervorgehoben, wenn es um das Verfassen von User-Stories geht. Und das zunächst einmal mit Recht.

Vergegenwärtigen wir uns kurz die Situation: Der Product Owner repräsentiert die Fachlichkeit. Und damit sämtliche Aspekte, die mit der Produktentwicklung zu tun haben. Er oder sie kennt den Markt und stellt einen Plan auf was benötigt wird, sprich: welche Features umgesetzt werden sollen, welche Anforderungen und Erwartungen die User an das Produkt richten. Diese Informationen gewinnen die PO indem sie etwa den Markt bzw. die Konkurrenz beobachten. Oder sie machen Umfragen, Usertests, werten bestehende Reports und KPIs aus etc.

Damit ist die Frage beantwortet? Nein. Ist sie noch nicht.

Wie eingangs erwähnt, läuft die Frage, wer Stories schreiben darf, auf die Frage hinaus: Wer ist für den Inhalt und damit die Qualität der Stories verantwortlich?

Eine User-Story: a promise for a conversation

Sich nun auf den Punkt zurückzuziehen dass ein PO dafür verantwortlich ist, dass der Inhalt einer Story „ordentlich“ ist, wird dem agilen Prinzip nicht gerecht. Denn eine User-Story ist „a promise for a conversation.“ Man verspricht nicht sich selbst, sondern einander, dass man sich über das betreffende Thema unterhalten wird. An der Stelle kommt also noch eine zweite Seite, neben dem PO, ins Spiel.

Und diese zweite Seite ist das Umsetzungsteam.

Für agile Methoden ist der Dialog wesentlich. Hier soll er sich zwischen PO und Team abspielen. Ein PO soll das Problem beschreiben, das Umsetzungsteam entwickelt die Lösung. Ein PO kann nicht immer wissen, ob die Problembeschreibung ausreichend ist. Ob etwa alle Informationen enthalten sind, die das Team zur Entwicklung einer Lösung braucht. Das Team muss diese Fragen aufwerfen und sie mit dem PO diskutieren.

Daraufhin ergeben sich neue Punkte, die so noch nicht in der User-Story enthalten sind. Und mitunter fallen andere weg. Das ist der ganz normale Verlauf einer Konversation. Der Inhalt entwickelt sich qualitativ weiter. Und man gewinnt mit der Zeit ein genaueres Verständnis vom Gesprächsgegenstand. Und vor Allem: ein gemeinsames Verständnis.

Und plötzlich ist das, was anfangs aufgeschrieben wurde, veraltet.

Man muss also nicht nur User-Stories schreiben. Man muss sie fortschreiben!

Die Konversation dokumentieren und in die User-Stories schreiben

Dann hängen wir die neuen Informationen einfach als Kommentar ans JIRA Issue dran? Nein! Bitte nicht, denn so ist nichts gewonnen, das führt zu anderen Problemen. Ja was dann? Nun …

Team und PO kommen zur Konversation über eine eine Story zusammen. Beispielsweise in einem Refinement Meeting. Was läge da näher als das Issue zu öffnen und die Beschreibung selbst zu aktualisieren? Ob das jetzt der PO öffnet oder ein Teammitglied oder der Scrum Master (oder Agile Coach, wie es inzwischen heißt …) ist nebensächlich.

Eventuell bietet sich der Scrum Master sogar dafür an. Denn so haben PO und Team die Hände frei und können sich über das Thema verständigen. Der Scrum Master moderiert und kann mit zielgerichteten Fragen steuern:

  • Was schreiben wir jetzt hier rein?
  • Wie müsste die Formulierung lauten, damit sie richtig ist?
  • Ist es das worum es geht?
  • Was haben wir, wenn die Story umgesetzt ist?

Das nur so als Idee. An dieser Personalie – also an der Frage wer das notiert – sollte es nicht scheitern. Wenn es das tut, hat man ganz andere Probleme.

Denn long story short: Alle Seiten sind in einem Dialog dafür verantwortlich, dass das Gespräch gelingt. Und alle Seiten sollten darauf bestehen, dass der Inhalt einer Story in einem Refinement Meeting aktualisiert wird. Dass neue Informationen an der richtigen Stelle eingefügt und obsolete entfernt werden. Ein Team, dass sich über die Qualität von Issues beschwert, beschwert sich potenziell also auch über sich selbst. Ups.

Ein Scrum Master oder Agile Coach trägt aufgrund seiner Rolle nochmal eine besondere Verantwortung. Er soll alle Beteiligten daran erinnern, die Konversation einfordern und die Beteiligten aktivieren. Und ggf. selbst mit gutem Beispiel vorangehen.

User-Stories schreiben. Und zusammenfassen. Und splitten. Und was man sonst noch so tun kann …

User-Stories sind also nicht in Stein gemeißelt. Und neben dem Umschreiben gibt es noch andere Dinge, die ein Team mit einer User-Story tun kann.

Was tun, wenn zwei Stories ein und denselben Code betreffen? Zusammenführen!

Was tun wenn eine User-Story mehrere verschiedene Aspekte behandelt, die nichts miteinander zu tun haben? Splitten!

Beides sind Fälle, die ein PO nicht unbedingt absehen kann. Ein PO kennt die Codebase sehr wahrscheinlich nicht. (Braucht sie auch nicht zu kennen, dafür sind Entwickler da.) D.h. auch, dass wir trotz INVEST Kriterien nicht immer erwarten können, dass der Zuschnitt der Story passt. Nur PO und Team können gemeinsam sicher stellen, dass das der Fall ist. Und bei diesem Beispiel sollte die Initiative auch vom Team ausgehen.

Der PO legt die Story vielleicht an, aber das Team hat nicht nur das Recht, sondern auch die Aufgabe die Story so umzuformen, dass das vom PO beabsichtigte Ziel der Story am besten erreicht werden kann.

Das gilt für den Gegenstand der Story: Im Gespräch sollten verschiedene mögliche Lösungsansätze diskutiert werden um den einfachsten herauszufinden.

Aber auch für deren Form: Also ob man daraus zwei Stories macht oder zwei Issues zusammenführt oder die Beschreibung der Story verständlicher formuliert.

Und dann gibt es da noch Issues, von denen ein PO nichts wissen kann, bzw. die ihm nicht zugänglich sind. Dinge die technischer Natur sind oder im technischen Bereich ihren Ursprung haben. Hier ist ein PO auf das Team angewiesen. Und das Team kann den PO am besten unterstützen, wenn es das Issue dazu anlegt und die Problemkonstellation beschreibt. Und zwar in einer Sprache, die für den Laien verständlich ist. (Es kann dann zwar sein, dass man das Problem in besagtem Abschnitt nicht abschließen beschreiben kann, aber die Tragweite sollte verständlich werden. Detaillierte Informationen für das Umsetzungsteam kann man ja trotzdem anfügen.)

Fazit

Der Dialog liegt im Wesen des agilen Prinzips. Zu seinem Gelingen tragen alle Seiten bei und alle sind gemeinsam dafür verantwortlich. Ein Beharren auf „das muss aber von XY gemacht werden“ oder „das ist nicht mein Issue, ich schreibe da nichts rein“ ist nicht agil. Ebenso wenig ein „ich schreib das jetzt einfach rein, mir doch egal.“

Vielmehr muss eine Anforderung im Dialog mit dem PO / dem Anforderer konkretisiert werden. Jeder bringt etwas mit, das die anderen ohne ihn nicht haben. Etwas, das aber zum Erfolg benötigt wird.

Beim agilen Vorgehen geht es darum eine Funktionalität, einen Mehrwert für den User zu realisieren. Und dadurch das Produkt auf dem Markt nach vorne zu bringen. Dabei ist es am Ende egal, wer welchen Part in der Anforderungsbeschreibung dokumentiert hat.

Es gibt gute Gründe – bspw. fachlicher Natur – die einen PO hier im Lead sehen. Aber sie entbinden nicht den Rest des Scrum Teams, also das Umsetzungsteam und den Scrum Master, von der Verantwortung.

Im agilen Manifest heißt es ja auch: „Individuals and interactions over processes and tools – (Customer) collaboration over contract negotiation“

Verwandte Artikel

Schönen Mittwoch!