In Scrum Teams wird häufig Kollaboration und gemeinsames Lernen fokussiert. Viele Product Owner nehmen ihre Rolle dabei so wahr, dass sie User Stories eigenständig schreiben sowie vorbereiten und dem Team z.B. im Refinement oder Sprint Planning vorstellen. Andere Product Owner stellen dagegen insbesondere Fragen ans Team basierend auf einem Titel für ein neues Product Backlog Item (z.B. User Story). Was sind Eure Erfahrungen einer das gemeinsame Lernen unterstützenden Zusammenarbeit, die Zugleich eine hohe Effizienz mit sich führt?
2 Antworten
Hallo Christoph, es gab schon mal eine Frage die ich sehr ähnlich finde:
Wer schreibt eigentlich die User Stories?
Ich weiß nicht ob das deine Frage beantwortet oder ob deine Frage in eine andere Richtung geht.
Ich bin mir nicht sicher, ob die Frage nach der Verantwortlichkeit für das Schreiben von User Stories die richtige Frage ist. Deshalb hole ich zum besseren Verständnis etwas weiter aus:
Zunächst ist einmal klar, dass die Verantwortlichkeit für das Backlog (z.B. als eine sortierte Liste von User Stories) beim Product Owner liegt.
Wenn es um User Stories geht, assoziiere ich damit zuallererst ein Werkzeug, das nützlich dabei ist, ein gemeinsames Problemverständnis zw. Product Owner und Umsetzungsteam zu erreichen. Nicht umsonst heißt es über User Stories: 'Sie sind ein Versprechen auf eine noch zu führende Diskussion'. Diese wichtige Aussage macht für mich den Unterschied. Während im traditionellen Wasserfall Anforderungsdokumente geschrieben werden und dann weitergereicht werden an ein Team, dass diese Anforderungen umsetzen soll, soll mit der Anwendung von User Stories insbesondere die gemeinsame Diskussion über diese Anforderungen unterstützt werden. So betrachtet, ist es letztlich nicht entscheidend, WER die User Story schreibt, sondern DASS die Diskussion stattfindet. Jeder kennt das 'Stille Post' Spiel aus der Kindheit, indem man sich in einer Reihe aufstellt, der Erste dem Zweiten einen Sachverhalt ins Ohr flüstert, der Zweite diesen Sachverhalt weitergibt an den Nächsten und der Letzte in der Reihe dann laut ausspricht, was von der ursprünglichen Botschaft bei ihm noch angekommen ist. Nicht selten wurde dabei viel gelacht, welch Blödsinn übrig geblieben ist. In der Arbeitswelt ist dieser Sachverhalt zu beobachten, wenn versucht wird, alleine über Dokumente zu kommunizieren. Leider ist es hier ernst und falsch verstandene Sachverhalte verursachen gefährliche Kosten einer Fehlentwicklung am ursprünglichen Ziel vorbei. Das ändert sich auch nicht, indem man die Anforderung nun User Story nennt und gleichzeitig das altgewohnte Verhalten beibehält, indem versucht wird in der User Story genau zu beschreiben, was gemeint ist und davon ausgegangen wird, dass ein Team den Inhalt richtig interpretiert. Richtiges Verständnis ohne gemeinsame Diskussion ist eher die Ausnahme als die Regel. Als Reaktion auf dieses Problem erlebe ich, dass nach noch genauerer Beschreibung gerufen wird. Leider hilft das nicht, weil das eigentliche Problem, nämlich dass zu wenig miteinander geredet wird. Und ich ergänze, dass auch zu wenig visualisiert wird, um Gedankenmodelle und unterschiedliche Interpretationen sichtbar zu machen.
Indem Sinne, um die gestellte Frage zu beantworten: Wer sollte verantwortlich für das Schreiben von User Stories sein? Ich würde fast sagen Niemand! Die Frage verleitet zu sehr, dass das Schreiben im Vordergrund stehe und das geht an der Intention von User Stories grundlegend vorbei. Deshalb würde ich eher fragen: Wer ist verantwortlich dafür, dass User Stories diskutiert werden? Und das dürfen alle sein. Wenn es festgelegt sein soll auf ein dedizierte Rolle, dann würde ich sie dem Product Owner zuschreiben. Er muss dafür sorgen, dass das Team das zu lösende Problem richtig verstanden hat.
Als abschließenden Tipp möchte ich noch hinzufügen: Weniger ist mehr! Deshalb ist es hilfreich, um einen werthaltige Diskussion anzustoßen, dass lediglich die Story selbst mit dem bekannten Template "Als [Rolle] möchte ich [Funktionalität], um [Problem zu lösen]" textuell festgehalten wird. Im Refinement werden dann gemeinsam Akzeptanzkritierien entwickelt, mittels derer festgestellt werden kann, dass das Problem gelöst ist. Diese Akzeptanzkritierien werden dann im Anhang der User Story dokumentiert. Das Wichtigste ist also die Reihenfolge, was durch das CCC-Prinzip ausgedrückt wird: Zuerst die User Story (Card), dann die Diskussion (Conversation), dann die gemeinsamen Erkenntnisse, z.B. in Form von Akzeptanzkriterien (Confirmation).
Einen Nachteil von User Stories möchte ich nicht verschweigen. Indem im Template ein Wunsch für eine Funktionalität ausgedrückt wird, verleitet dies sehr schnell den User Story Autor bereits in das Lösungsdenken abzuschweifen. Das ist insbesondere dann tragisch, wenn dadurch das Team bereits vor-ge-biased, also vorbeeinflusst wird, was getan werden soll und lenkt vom eigentlichen Problemverständnis ab, welches unbedingt an erster Stelle stehen sollte. Würde das Team nur das Problem hören, entstehen möglicherweise ganz andere Lösungsideen, die besser, kostengünstiger und zielführender sein können. Durch die Vorbeeinflussung werden diese Ideen unbewusst unterdrückt und dieses wertvolle Potential ist dann leider verloren.
Je nach Situation und Reifegrad des Scrum-Teams bin ich daher statt der Beschreibung von User Stories übergegangen zum sogenannten Problem-Statement, welches z.B. diesem Format folgen kann: "The problem of [statement of problem] affects [users and/or stakeholders] the impact of which is [statement of issues, costs, or other impacts] a successful solution would be [important benefits that would successfully solve the problem]." Damit habe ich sehr gute Erfahrungen gemacht, dass die oben genannte wichtige Diskussion ganz von allein passiert.
Zunächst ist einmal klar, dass die Verantwortlichkeit für das Backlog (z.B. als eine sortierte Liste von User Stories) beim Product Owner liegt.
Wenn es um User Stories geht, assoziiere ich damit zuallererst ein Werkzeug, das nützlich dabei ist, ein gemeinsames Problemverständnis zw. Product Owner und Umsetzungsteam zu erreichen. Nicht umsonst heißt es über User Stories: 'Sie sind ein Versprechen auf eine noch zu führende Diskussion'. Diese wichtige Aussage macht für mich den Unterschied. Während im traditionellen Wasserfall Anforderungsdokumente geschrieben werden und dann weitergereicht werden an ein Team, dass diese Anforderungen umsetzen soll, soll mit der Anwendung von User Stories insbesondere die gemeinsame Diskussion über diese Anforderungen unterstützt werden. So betrachtet, ist es letztlich nicht entscheidend, WER die User Story schreibt, sondern DASS die Diskussion stattfindet. Jeder kennt das 'Stille Post' Spiel aus der Kindheit, indem man sich in einer Reihe aufstellt, der Erste dem Zweiten einen Sachverhalt ins Ohr flüstert, der Zweite diesen Sachverhalt weitergibt an den Nächsten und der Letzte in der Reihe dann laut ausspricht, was von der ursprünglichen Botschaft bei ihm noch angekommen ist. Nicht selten wurde dabei viel gelacht, welch Blödsinn übrig geblieben ist. In der Arbeitswelt ist dieser Sachverhalt zu beobachten, wenn versucht wird, alleine über Dokumente zu kommunizieren. Leider ist es hier ernst und falsch verstandene Sachverhalte verursachen gefährliche Kosten einer Fehlentwicklung am ursprünglichen Ziel vorbei. Das ändert sich auch nicht, indem man die Anforderung nun User Story nennt und gleichzeitig das altgewohnte Verhalten beibehält, indem versucht wird in der User Story genau zu beschreiben, was gemeint ist und davon ausgegangen wird, dass ein Team den Inhalt richtig interpretiert. Richtiges Verständnis ohne gemeinsame Diskussion ist eher die Ausnahme als die Regel. Als Reaktion auf dieses Problem erlebe ich, dass nach noch genauerer Beschreibung gerufen wird. Leider hilft das nicht, weil das eigentliche Problem, nämlich dass zu wenig miteinander geredet wird. Und ich ergänze, dass auch zu wenig visualisiert wird, um Gedankenmodelle und unterschiedliche Interpretationen sichtbar zu machen.
Indem Sinne, um die gestellte Frage zu beantworten: Wer sollte verantwortlich für das Schreiben von User Stories sein? Ich würde fast sagen Niemand! Die Frage verleitet zu sehr, dass das Schreiben im Vordergrund stehe und das geht an der Intention von User Stories grundlegend vorbei. Deshalb würde ich eher fragen: Wer ist verantwortlich dafür, dass User Stories diskutiert werden? Und das dürfen alle sein. Wenn es festgelegt sein soll auf ein dedizierte Rolle, dann würde ich sie dem Product Owner zuschreiben. Er muss dafür sorgen, dass das Team das zu lösende Problem richtig verstanden hat.
Als abschließenden Tipp möchte ich noch hinzufügen: Weniger ist mehr! Deshalb ist es hilfreich, um einen werthaltige Diskussion anzustoßen, dass lediglich die Story selbst mit dem bekannten Template "Als [Rolle] möchte ich [Funktionalität], um [Problem zu lösen]" textuell festgehalten wird. Im Refinement werden dann gemeinsam Akzeptanzkritierien entwickelt, mittels derer festgestellt werden kann, dass das Problem gelöst ist. Diese Akzeptanzkritierien werden dann im Anhang der User Story dokumentiert. Das Wichtigste ist also die Reihenfolge, was durch das CCC-Prinzip ausgedrückt wird: Zuerst die User Story (Card), dann die Diskussion (Conversation), dann die gemeinsamen Erkenntnisse, z.B. in Form von Akzeptanzkriterien (Confirmation).
Einen Nachteil von User Stories möchte ich nicht verschweigen. Indem im Template ein Wunsch für eine Funktionalität ausgedrückt wird, verleitet dies sehr schnell den User Story Autor bereits in das Lösungsdenken abzuschweifen. Das ist insbesondere dann tragisch, wenn dadurch das Team bereits vor-ge-biased, also vorbeeinflusst wird, was getan werden soll und lenkt vom eigentlichen Problemverständnis ab, welches unbedingt an erster Stelle stehen sollte. Würde das Team nur das Problem hören, entstehen möglicherweise ganz andere Lösungsideen, die besser, kostengünstiger und zielführender sein können. Durch die Vorbeeinflussung werden diese Ideen unbewusst unterdrückt und dieses wertvolle Potential ist dann leider verloren.
Je nach Situation und Reifegrad des Scrum-Teams bin ich daher statt der Beschreibung von User Stories übergegangen zum sogenannten Problem-Statement, welches z.B. diesem Format folgen kann: "The problem of [statement of problem] affects [users and/or stakeholders] the impact of which is [statement of issues, costs, or other impacts] a successful solution would be [important benefits that would successfully solve the problem]." Damit habe ich sehr gute Erfahrungen gemacht, dass die oben genannte wichtige Diskussion ganz von allein passiert.