Wie schreibt man effektive User Storys mit INVEST-Prinzipien?

INVEST-Prinzip zum Erstellen von User Stories

Neben einem standardisierten Format und vollständigen Elementen sollte eine gute User Story auch den INVEST – Prinzipien folgen: 1. Ich bin abhängig; 2. verhandelbar ; 3. Wertvoll ; 4. Schätzbar ; 5. Kleines Einkaufszentrum; 6. Testbar .

1. Unabhängig – Es ist wichtig, eine User Story so unabhängig wie möglich von den anderen User Storys zu machen. Das Aufrechterhalten der Unabhängigkeit zwischen User Storys erleichtert nicht nur die Priorisierung und Ausrichtung, erleichtert die Release- und Iterationsplanung, erleichtert das unabhängige Verstehen, Nachverfolgen, Implementieren, Testen und häufige Liefern, sondern macht auch den Umfang der User-Story-Größenschätzung und damit die Schätzungsverzerrung klarer kleiner.

2. Verhandelbar – Der Inhalt einer User Story ist verhandelbar; Eine User Story ist kein Vertrag. Eine User Story ist nur eine kurze Beschreibung der User Story ohne viele Details; spezifische Details werden während der Kommunikationsphase hergestellt. Eine User Story mit zu vielen Details schränkt den Benutzer, die Ideen des Teams und die Kommunikation tatsächlich ein.

3. Wertvoll – Jede Geschichte muss für den Kunden wertvoll sein (ob es sich um einen Benutzer, einen Käufer oder eine interne Unternehmensrolle handelt). Benutzergeschichten sind für den Endbenutzer wertvoll, daher sollten sie aus der Perspektive des Benutzers geschrieben werden und eher eine FUNKTION als eine AUFGABE beschreiben.

Diese Funktion erleichtert den Entwicklungs- und Testmitgliedern des Teams den Wechsel vom traditionellen, auf Richtlinien basierenden Arbeitsstil zu einem selbstgesteuerten, wertorientierten Arbeitsstil, sodass jeder im Team den Wert seiner täglichen Arbeit kennt.

4. Schätzbar (kann bewertet werden) – Ein sehr wichtiger Teil des Planungstreffens ist die Schätzung von Story Points. Es ist eigentlich eine grobe Schätzung der zu entwickelnden User Story, damit das Team die Komplexität (Arbeitslast) dieser User Story kennen kann.

Der Fokus liegt darauf, ob die User Story gemäß den Rezeptionsbedingungen dieser User Story und den vom Team definierten DoD (Abschlusskriterien) in der aktuellen Iteration abgeschlossen werden kann, und wenn sie nicht abgeschlossen werden kann, wird der Grund und die PO angegeben entscheidet, ob die User Story aufgeteilt oder neu gestaltet wird.

Probleme, die es Entwicklern erschweren, die Geschichte einzuschätzen, entstehen durch: mangelnde Kenntnis der Domäne (in diesem Fall ist mehr Kommunikation erforderlich) oder die Geschichte ist zu groß (in diesem Fall muss sie in kleinere Stücke geschnitten werden).

5. Klein – Eine gute Geschichte sollte in Bezug auf die Arbeitsbelastung so kurz wie möglich sein, vorzugsweise nicht mehr als 10 ideale Personen/Tag, um zumindest sicherzustellen, dass sie in einer Iteration abgeschlossen wird. Je größer die User Story, desto größer das Risiko bei Terminplanung, Workload-Schätzung etc.

6. Testable (testable) – Eine User Story sollte testbar sein, um zu bestätigen, dass sie abgeschlossen werden kann. Wenn eine User Story nicht testbar ist, können Sie nicht wissen, wann sie abgeschlossen sein wird. Ein Beispiel für eine nicht testbare User Story: Die Software soll einfach zu bedienen sein.

Drei Leitlinien

Eine User Story ist grundsätzlich eine gute User Story, wenn die INVEST-Prinzipien befolgt werden. Dann konzentrieren wir uns auf drei Richtlinien, die dabei helfen sollen, die Prinzipien bei der Erstellung von User Stories besser einzuhalten.

Die drei Richtlinien lauten: ein Benutzer, vollständiger Wert und keine Abhängigkeit.

1. Ein Benutzertyp – Schließen Sie nur einen Benutzertyp ein, da mehrere Benutzer oft Nuancen haben. Es ist normalerweise ein typischer Benutzer, oft mit einem gemeinsamen Bedürfnis.

2. Vollständiger Wert – Liefern Sie einen Kundenwert in seiner Gesamtheit. Eine vollständige User Story bedeutet, dass der Benutzer nach Abschluss dieser Story ein klares und sinnvolles Ziel erreichen kann.

3. Nicht-Abhängigkeit – Die drei gängigen Arten von Abhängigkeiten sind: Überlappung, Sequenz und Containment.

Generell sind überlappende Funktionspunkte zwischen Geschossen zu vermeiden; sequentielle Beziehungen sind eine Realität und können in den meisten Fällen auf irgendeine Weise gelöst werden; und Inklusionsbeziehungen sind hilfreich für komplexe Systeme, mit Auswirkungen auf die Planung von Releases und Iterationsplänen, die Aufmerksamkeit erfordern.

Überlappende Abhängigkeiten

Überlappende Abhängigkeiten sind die Form von Abhängigkeiten, die die meisten Probleme verursachen, insbesondere wenn mehrere User Storys mehrere verschiedene überlappende Teile enthalten. Es ist schwierig, eine Reihe von User Stories zu finden, die den Satz von Funktionen für dieses minimal funktionsfähige Produkt darstellen können, das die einmal benötigten Funktionen enthalten und nur enthalten sollte.

Lösung

Entfernen Sie die überlappenden Teile als separate User Storys.
Rationelle Aufteilung von User Stories und Beibehaltung der Überschneidungen in nur einer der zusammenhängendsten User Stories.
Verwenden Sie das Scrum-Entwicklungsmodell.

Sequentielle Abhängigkeiten

Sequenzabhängigkeit bedeutet, dass eine oder mehrere andere User Storys vor der Fertigstellung einer User Story abgeschlossen werden müssen. Sequenzielle Abhängigkeiten sind in der Regel harmlos, und es gibt Möglichkeiten, solche Abhängigkeiten abzumildern.

Aus einer agilen Entwicklungsperspektive entwickelt sich das gesamte System schrittweise von einem anfänglichen Minimum Viable Product zu einem robusten Produkt, wobei jeder spätere Schritt auf dem vorherigen aufbaut.

Aber aus einer anderen Perspektive erschweren unnötige sequentielle Abhängigkeiten das Ranking und die Priorisierung, was sich wiederum auf die Entwicklung von Release- und Iterationsplänen auswirkt und die Abschätzung des Umfangs von User Stories erschwert.

Lösung

Machen Sie User Storys innerhalb einer Iteration so frei wie möglich von intrinsischen Abhängigkeiten.
Nur unidirektionale Abhängigkeiten zwischen Iterationen beibehalten, mit nur unidirektionalen zeitlichen Abhängigkeiten von Storys in späteren Iterationen zu Storys in früheren Iterationen (Vorwärtsabhängigkeiten).
Kernabhängigkeiten als separate Storys herauslösen und abhängige und nicht abhängige Anforderungen nicht in einer Story vermischen.

Einbeziehung von Abhängigkeiten

Enthaltene Abhängigkeiten beziehen sich auf die Verwendung von hierarchischem Management beim Organisieren von User Storys, wie z. B. das übliche zweistufige Feature-Story-Management, bei dem ein Feature mehrere User Stories enthält und somit eine enthaltene Abhängigkeit des Features von seinen untergeordneten Storys darstellt.

Lösung

Die User-Story-Ebene wird für die Iterationsplanung verwendet, wodurch eine grobkörnige Iterationsplanung mit der Feature-Ebene vermieden wird, die für die Release-Planung verwendet werden kann.

Das Feature-Level kann auch aufgeteilt werden, bis es auf dem Niveau eines vermarktbaren Mindestfeatures ist, und die darin enthaltenen User Stories können separat in die neu aufgeteilten Features gruppiert werden.

Gemäß dem Minimum Viable Product-Konzept wird eine Funktion in mehreren Iterationen mehrerer User Stories implementiert, von denen jede zu einem potenziellen Ergebnis führen oder internes oder externes Feedback liefern kann.

Verweise

• Effektive User Stories – 3Cs und INVEST Guide
• Theme vs. Epic vs. User Story vs. Task
• User-Story-Karte
• Was ist User Story Mapping?
• Schreiben Sie SMARTe Ziele und INVESTIEREN Sie für User Stories