Zusammengesetzte User Stories

Anwendergeschichten Anwendergeschichten müssen den Geschäftswert darstellen. Aus diesem Grund verwenden wir die bekannte einzeilige Beschreibung 'als ein <Schauspieler> Ich möchte eine <Aktion>, damit ich eine <Ziel>'. Es ist sowohl einfach als auch leistungsstark, da es dem Team einen konkreten kundenbezogenen Kontext für die Identifizierung der relevanten Aufgaben zur Erreichung des gewünschten Ziels bietet. Die vom Team in den Sprint gezogenen Stories haben eine Größenbeschränkung. Sie sollten zumindest klein genug sein, um in einen Sprint zu passen. Diese Größenbeschränkung kann in manchen Fällen dazu führen, dass die Story in kleinere Storys unterteilt werden muss. Hierfür gibt es einige nützliche Muster wie Workflow-Schritte, Geschäftsregeln oder Datenvariationen usw. Komplexe Systeme Beim Umgang mit großen und komplexen Systemen, die aus vielen interagierenden Komponenten bestehen, kann der Prozess der Aufschlüsselung Probleme bereiten, selbst wenn man den Standardrichtlinien folgt. Vor allem dann, wenn das Aufschlüsseln einer Geschichte zu Geschichten führt, die sich auf Komponenten tief im System beziehen, ohne direkte Verbindung zum Endbenutzer oder dem Geschäftsziel. Diese Storys sind in der Regel von Natur aus technisch und weit von der Geschäftsperspektive entfernt.

Nehmen wir an, das Team stößt auf eine Story wie 'Als Benutzer möchte ich etwas wirklich Komplexes, das nicht in eine Story passt, damit ich A tun kann'. Die Geschichte erfordert die Interaktion mehrerer Komponenten, also zerlegt das Team sie in kleinere Geschichten wie 'Als Benutzer möchte ich, dass Komponente X die Operation Y ausführt, damit ich A tun kann'. Es sollte ein Benutzer- und ein Geschäftsziel geben, aber die Aktion hat keinen direkten Bezug zu einem dieser beiden Ziele. Sie bietet keinen sinnvollen Kontext für diese spezielle Geschichte und fühlt sich einfach nicht richtig an. Aus Zeitgründen und ohne offensichtliche Lösung durch bekannte Muster wird das Team wahrscheinlich eine Geschichte wie diese definieren: 'Implementiere Operation Y in Komponente X', was im Grunde eine zusammengesetzte Aufgabenbeschreibung ist und keinerlei Kontext bietet. Komponenten als Akteure Unter Umgehung der Regeln ist es möglich, das Prinzip der Definition von Benutzergeschichten anzuwenden und in diesen Fällen einen sinnvollen Kontext zu schaffen. Der Trick besteht darin, in das System hineinzuzoomen und die Substories auf einer anderen Ebene zu definieren, indem man eine zusammengesetzte Beziehung verwendet und die Komponenten selbst zu Akteuren mit eigenen Zielen macht: 'Als Komponente Z möchte ich Operation Y auf Komponente X aufrufen, damit ich B tun kann' und 'Als Komponente X möchte ich Operation Y implementieren, damit ich C tun kann'. Es gibt keinen direkten Kunden- oder Geschäftswert in dieser Substory, aber da sie durch eine Komposition verknüpft ist, lässt sie sich recht einfach auf den Geschäftswert zurückführen. Jedes der Teilziele trägt zu dem in der Composite Story genannten Ziel bei. Ziel A wird erreicht, wenn sowohl Ziel B als auch Ziel C erreicht werden (A = B + C). Verknüpfen der Stories Es gibt mehrere Möglichkeiten, die Stories mit ihrer zusammengesetzten Story zu verknüpfen. Sie können Stories nummerieren wie 1, 1a, 1b, ... oder die Haftnotizen mit den Sub-User-Stories auf dem Scrum Board einrücken, um die Beziehung zu visualisieren. Um die Beziehung deutlicher zu machen, können Sie auch die Beschreibung der Story wie folgt erweitern: Als ein <Schauspieler> Ich möchte <Aktion>, so kann ich erreichen <Ziel> und tragen bei zu <Komposit-Ziel>.

Zusammenfassung Der Schwerpunkt dieses Ansatzes liegt auf dem Versuch, bei der Aufteilung von (technischen) Benutzergeschichten für komplexe Systeme mit vielen interagierenden Komponenten einen sinnvollen Kontext zu erhalten. Indem Sie die Komponenten als Akteure mit eigenen Zielen betrachten, können Sie aussagekräftige User Stories mit relevanten Kontexten erstellen. Die Verwendung einer zusammengesetzten Struktur schafft logische Beziehungen zwischen den Geschichten in der Komposition und verbindet sie mit dem Geschäftswert. Auf diese Weise kann das Team eine konsistente Art und Weise beibehalten, die Funktionalität mithilfe von User Stories auszudrücken. Haftungsausschluss Diese Methode sollte nur angewandt werden, wenn eine Aufteilung der User Stories nach den Standardmustern nicht möglich ist. Sie bietet zum Beispiel keine Antwort auf die Regel, dass jede Story dem Endbenutzer einen Wert liefern sollte. Es ist wahrscheinlich, dass mehr als ein Sprint erforderlich ist, um eine zusammengesetzte Story zu liefern. Außerdem sollten Sie sich die Frage stellen, warum das System so komplex ist und ob es sich vermeiden lässt. Aber für Teams, die mit dieser Komplexität und der Herausforderung konfrontiert sind, die Stories heute aufzuteilen, kann diese Methode das kleinere Übel sein.