Wer schreibt eigentlich die User Stories?

Question

Immer wieder taucht diese Diskussion in den Scrum Teams auf. Im Scrum Guide werden die User Stories gar nicht direkt erwähnt, in der Praxis sind sie aber ein viel gelebtes Tool im Zusammenhang mit Scrum und Agilität. Eine konkrete Verantwortlichkeit kann auf Basis des Scrum Guides, allerdings schon einmal nicht zugewiesen werden.

Nun oft wird es dann doch irgendwie dem Product Owner zugewiesen, da dieser im engen Kontakt mit Kunden und Stakeholdern steht. Außerdem ist er für die Priorisierung und Verständlichkeit im Productbacklog verantwortlich. Gemeinsam mit dem Team können dann die user Stories noch im Refinement spezifiziert werden.

Andererseits kann das Team auch als ganzes verstanden werden, dass die Verantwortungen teilt und keine Aufgaben einer Person zuteilt, die im Scrum Guide nicht explizit beschrieben wurden. Hier werden dann oftmals ja User Stories direkt gemeinsam erstellt. Zum einen auf Basis des Wissens des PO´s durch Kunden und Steakholder, zum anderen durch das technische Know-How der Entwickler.

Ich denke so kommt es, dass diese Aufgabe immer wieder zwischen Entwicklern und PO hin- und hergworfen wird, da es einfach eine eher unklare Aufgabe zu sein scheint.

Wie seht ihr das? Wer sollte aus eurer Scht die User Stories schreiben und was sind hier eure Erfahrungen?

Answer 1

Laut Scrum Guide, ist der PO "... für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich." Die Inhalte des Product Backlogs sind die Anforderungen (User Stories) die umgesetzt werden sollen. Damit ist die Verantwortung schon mal klar.

Wer jetzt die Stories schreiben soll steht da nicht drin. Der Product Owner kümmert sich darum, dass es diese schöne Liste gibt, dass die Einträge gut sind und sie die richtige Reihenfolge haben. Wenn es wirtschaftlich ist, dass er die Aufgabe an jemand delegiert oder gemeinsam mit Teammitgliedern macht, dann kann er es machen. Verantwortlich für das Ergebnis ist aber nur der Product Owner.

Und jetzt zu meinen Erfahrungen. Aus meiner Sicht kennt ein guter Product Owner alle seine User Stories. Jede einzelne. Er kennt sie, weil er sie geschrieben hat. Er hat sie vielleicht mit Unterstützung von Teammitgliedern ausformuliert, verbessert oder geschnitten, er hat sie aber geschrieben. Die User Stories bilden die Schnittstelle zwischen Anforderer und Entwickler. Der Product Owner muss sicherstellen, dass sein Team das tut was der Kunde braucht. Das schafft er nur durch gute, verständliche User Stories ("conversation starters") und durch die Erklärungen und das Feedback was er früh und oft gibt ("conversations").

Ein PO muss verstehen was der Kunde will und die Information ans Team transportieren. Warum sollte es effizienter sein, dass jemand außer ihm die Stories formuliert? Wie würde er es schaffen, dass keine Informationen verloren gehen?

Ja, tatsächlich höre ich ab und zu, dass Entwicklungsteams seine eigene Stories schreiben, weil der PO "keine Zeit hat". Das ist für mich eine schwere Dysfunktion: wenn der PO sich keine Zeit nimmt um Stories zu schreiben, dann nimmt er sich bestimmt auch keine um sie in Detail zu erklären. Wie soll das Team das tun was der Kunde braucht?

Answer 2

User Stories ist ja nur eine Art, wie man Backlog Items formulieren kann. Insofern sind sie im Scrum Guide definiert. Wie schon von Giancarlo geschrieben wurde, liegt die Verantwortung dass sie geschrieben werden und dass sie richtig priorisiert werden beim Product Owner.

Leider sehr oft sehe ich folgendes Modell im Einsatz:

Stakeholder entscheiden, was mit welcher Priorität (teilweise auch bis wann) umgesetzt werden muss und teilen das nur dem PO (vormals Teamlead) mit. Dieser ist also das Bottleneck bzw. Stille-Post-Prinzip zu den Stakeholdern. Der PO sieht sich in der Funktion des Fachkonzeptionisten und schreibt alle Anforderungen auf (meistens die konkreten Lösungsschritte und nicht das ursächliche Problem). Damit wird die grundlegende Idee der User Story, das konkrete Problem des Anwenders zu verstehen, um dies als Diskussionsgrundlage für potentielle Lösungsmöglichkeiten zu nutzen, bereits verletzt. Das Team wird lediglich als Menge von untergebenen Entwicklern gesehen, welche wie im Wasserfall 1:1 die fertig definierten Lösungen umsetzen sollen.

Meiner Meinung nach kann man das so machen, aber mit agiler Softwareentwicklung oder den Ideen hinter Scrum hat das nichts zu tun.

Oder man macht es, wie Scrum es vorsieht:

Der Product Owner ist der oberste Entscheider über die Produktentwicklung. Er kümmert sich um das Stakeholdermanagement - spielt aber nicht das Stille-Post-Prinzip sondern stellt Kontakte her, sorgt dafür, dass er immer auf dem aktuellen Stand ist bzgl. der Priorität und dem Mehrwert für die verschiedenen Stakeholder, um auf deren Basis selber die Priorisierung zu entscheiden.

Er sorgt anschließend dafür, dass er selber oder jemand aus dem Team die Probleme der Kunden z.B. in Form einer User Story aufschreibt. Anschließend kommt das Team zusammen, dass auch Spezialisten im Bereich Konzeption und Spezialisten im Bereich Umsetzung enthält (sowie Test etc.). Hier entsteht eine kreative Diskussion über verschiedene Möglichkeiten der Lösung des Problems. Bei konkreten Unsicherheiten über die Situation des Kunden wird der direkte Kontakt gesucht, um das Problem genau zu verstehen. Möglicherweise werden dabei aus einer User Story mehrere mit verschiedenen Lösungsoptionen. Dabei halten die Teammitglieder fest, welche Rahmenbedingungen sie sehen (z.B. Lastanforderungen, Design-Leitplanken und Skizzierung der Lösung) und schätzen die User Story(s). In Zusammenarbeit mit dem PO werden dann Kosten und Nutzen (kurz- wie langfristig) der verschiedenen Lösungen diskutiert und die letztendliche Entscheidung liegt beim PO, ob, wie und in welcher Priorisierung die Lösung angegangen wird.

Scrum sieht sich als Framework für die Entwicklung komplexer Produkte und orientiert sich an den 12 Prinzipien für agile Softwareentwicklung. Dabei spielt direkte Kommunikation eine Rolle (nicht PO als man-in-the-middle bzw. Stille-Post-Prinzip). Für komplexe Produktentwicklung nutzt Scrum ein cross-funktionales, um qualitativ hochwertige und alle Perspektiven (UX, Architektur, Design, Testbarkeit, ...) berücksichtigende Lösungen zu entwickeln und gemeinsam umzusetzen. Scrum vertraut darauf ein Team zu haben, was in der Zusammenarbeit bessere Lösungen entwickeln kann, als es jeder einzelne alleine könnte. Aus diesem Grund ist der PO weder der Fachkonzeptionist noch ein Bottleneck in der Zusammenarbeit mit den Stakeholdern.

Natürlich kenne ich diverse Interpretationen und Adaptionen von Scrum, in denen der PO kein Entscheidungsrecht über das Produkt Backlog hat, seine Daseinsbestätigung in der Vermittlung zwischen Entscheidern und Team sieht und dort die Lücke füllt und den Fachkonzeptionisten für das Team darstellt, der sich alleine um die Erstellung der Backlog Items / User Stories kümmert. Dies fördert allerdings weder ein selbstorganisiertes, verantwortliches Arbeiten bzw. Mitdenken im Team, noch die Kreativität für Lösungsfindungen im Team und beruht auf der Annahme, dass es entweder der einzelne PO besser weiß und kann als das Team zusammen oder dass PO und Team zusammen allesamt nichts zu sagen und nur das umzusetzen haben, was der Stakeholder nicht wünscht sondern befiehlt.

Comments

danke für die fundierten Beiträge. Die helfen mir grade massiv weiter.