Story-Splitting – Verfeinerung auf eine optimale Granularität
Eine scheinbar kleine Geschichte kann sich als viel größer erweisen als erwartet. Nur durch Verfeinerung oder Aufteilung der Geschichte können Sie dies herausfinden. Die Aufteilung der Story kann früh oder kurz vor dem vorangegangenen Sprint erfolgen. Wir empfehlen, dies so früh wie möglich zu tun, um späte Überraschungen zu vermeiden.
Wir betrachten „Story Splitting“ und „Story Refinement“ als sehr ähnliche Aktivitäten. Es geht darum, die Granularität der geschriebenen User Story zu optimieren.
Was sind User Stories?
Für die Teams, die gemeinsam arbeiten können, kann die User Story lediglich eine Erinnerung an ein Gespräch sein. In den meisten Fällen verlassen wir uns auf die User Story als schriftliche Funktionsanforderung. Um bei der Bereitstellung effektiv zu sein klare Kommunikation User Stories müssen sorgfältig geschrieben werden, um Missverständnisse zu minimieren. Aber zuerst müssen wir verstehen, wie User Stories in den größeren Kontext (Hierarchie) der Kommunikation darüber passen, was getan werden muss, um den Benutzern einen Mehrwert zu bieten:
Der Kontext von User Stories
Eine komplette User Story
Nachdem wir diesen Kontext geschaffen haben, können wir nun sehen, wo User Stories passen. Der Kontext innerhalb der Hierarchie hilft zu verstehen, was in einer User Story benötigt wird, damit sie gut geformt und von guter Qualität ist. Eine vollständige User Story muss:
- Geben Sie einen Benutzer an oder Persona muss angegeben werden.
- Beschreiben Sie die hohe Funktionalität als Teil einer einzelnen diskreten Funktionsaktion durch den Benutzer auszuführen.
- enthalten alle Funktionsschritte erforderlich, um die Benutzeranforderungen zu erfüllen.
Wann ist Story Splitting sinnvoll?
Idealerweise so früh wie möglich im Software-Lebenszyklus. Es ist nicht so mühsam, wie viele behaupten würden, und selten eine verschwenderische Tätigkeit. Schauen Sie sich unseren Blogartikel an Empfohlene User Story-Qualitätsattribute
Techniken zur Aufteilung von Geschichten
Überlegen Sie zunächst, wer der Benutzer ist und welche Datentypen er verarbeiten muss, um eine bestimmte Anforderung zu erfüllen, die das System am Ende in einem stabilen Zustand zurücklässt.
Benutzerorientiert
Beschreibt diese Geschichte die Funktionalität einer Persona oder einer Gruppe von Personas?
Messbar (klare Funktionsschritte)
Um messbar oder skalierbar zu sein, müssen wir die Funktionalität in Bezug auf die verarbeiteten Datengruppen kennen. z.B
Als registrierter Benutzer kann ich meine aktualisieren Profil.
Für messbare Ergebnisse empfehlen wir den COSMIC-Standard zur funktionalen Größenbestimmung, der die Identifizierung interessierender Objekte erfordert.
Vollständig
Haben wir alle für diese Geschichte benötigten Datengruppen erwähnt? Wenn wir Daten von anderer Stelle nachschlagen müssen, müssen diese ebenfalls einbezogen werden. Viele User Stories erfordern verschiedene Datensuchen, bevor ein Objekttyp erstellt oder aktualisiert wird.
Geschäftsregeln
Geschäftsregeln sind in der Regel Einschränkungen, die auf Kontext oder referenzierten Daten basieren. Stellen Sie sicher, dass Sie alle referenzierten Datentypen in Ihre funktionale User Story einbeziehen. Gelegentlich erzwingen Geschäftsregeln die Aufteilung einer Story in zwei ähnliche Storys. Manchmal kann der Kontext dargestellt werden, indem der Benutzername mit einem bestimmten Status kombiniert wird, z. B. angemeldet_user_with_cart_items
Prägnant
Manchmal spezifizieren wir eine User Story zu sehr mit allen Akzeptanzkriterien, bevor wir die Grundlagen richtig verstanden haben. Vermeiden Sie es, dies zu früh zu tun.
