Agile INVEST – 6 große Richtlinien für Benutzerstories

Agil verwendet Benutzerstories, um die Probleme auszudrücken, die ein Produkt oder ein System lösen sollte. Die Agile-INVEST-Richtlinie ist eine Reihe von Empfehlungen, die von Bill Wake zusammengestellt wurde, um das Testen und Erstellen von hochwertigen Benutzerstories (oder allgemeiner: Produkt-Backlog-Elementen) zu unterstützen, die eine effektiveagile Projektmanagement.

Laut derAgile INVESTRichtlinie sind hochwertige Benutzerstories leicht zu:

• Verstehen
• Implementieren
• Testen
• Dem Kunden vorführen
• Unabhängig sein

Aber lassen Sie uns analysieren, was der Akronym INVEST eigentlich bedeutet.

Agile INVEST – Unabhängig

Das bedeutet, dass die Geschichte als Produkt-Backlog-Element (PBI) mit eigener Priorität existieren kann, unabhängig geschätzt werden kann und von keiner anderen Geschichte abhängt.

Die zugewiesene Priorität einer Benutzerstory sollte der einzige Faktor sein, der bestimmt, wann das Team sie umsetzt. Wenn ihre Priorität niedriger ist, steht die Geschichte weiter unten im Backlog und wird später umgesetzt; wenn sie höher ist, verschiebt das Team sie nach oben im Backlog, um eine schnellere Lieferung zu ermöglichen. Wenn Benutzerstories voneinander abhängen, bestimmt die Abhängigkeit – nicht die Priorität –, wann das Team sie umsetzt.

Agile INVEST – Verhandelbar

Eine gute Benutzerstory fasst die Essenz des Kundenbedürfnisses zusammen. Falls Fragen auftreten, bespricht das Team diese mit dem Kunden, um den richtigen Wert der Geschichte zu ermitteln. Das Entwicklungsteam kann mit dem Product Owner und den Stakeholdern verhandeln. Auf diese Weise entsteht durch die Zusammenarbeit zwischen dem Projektteam (Lieferant und Kunde) ein herausragendes Produkt oder eine herausragende Dienstleistung.

Hat ein agiles Team nichts zu fragen, weil alles in der agilen Benutzerstory dokumentiert ist? Dann hat ein Business Analyst die Anforderungen verfasst.

Es werden einige verbindliche Punkte geben (häufig nicht-funktionale), wie zum Beispiel:

• Sicherheitsrichtlinien im Zusammenhang mit Benutzerkonten
• Leistungsanforderungen, wie die Anzahl an gleichzeitigen Benutzern, die das System verarbeiten muss

Das ist in Ordnung – solange die Details der Funktionalität selbst offen bleiben und Gespräche fördern.

Agile INVEST – Wertvoll

Bezogen auf agile Prinzipien bedeutet „wertvoll“, dass wir das angeforderte Feature oder die Funktionalität während des Sprint-Review-Treffens dem Kunden vorführen können.

Beim Aufteilen von Benutzerstories müssen Teams vertikal (auch repräsentiert durch das „V“) statt horizontal aufteilen. Dadurch wird eine vollständige Funktionalität am Ende des Sprints geliefert und der potenziell lieferbare Produkt-Teil wird erhöht.

Teams können es interessanter finden, technische PBIs umzusetzen, aber sie liefern nicht immer direkten Wert für den Kunden – was einem deragilen Prinzipien: den Kunden durch frühe und kontinuierliche Lieferung wertvoller Software zu befriedigen.

Agile INVEST – Schätzbare

Eine gute User Story muss schätzbar sein. In agilen Projekten ist die Schätzung relativ – im Vergleich zu anderen User Stories im Backlog. Beliebte Methoden sind die Fibonacci-Folge, T-Shirt-Größen (S, M, L usw.), und mehr.

Die Diskussion zur Schätzung hilft dem gesamten Team, sich auf die Bedingungen für die Fertigstellung der Story zu einigen. Manchmal ist eine Story nicht schätzbar, was normal ist, wenn die Story zu groß ist oder mehrere Funktionen in einem einzigen Punkt enthält. In solchen Fällen sollte die Story in mehrere kleinere Stories aufgeteilt werden. In anderen Situationen gibt es zu viele Unbekannte, die eine Forschung erfordern.

Agile INVEST – Klein

Stories sollten zwischen einigen Stunden und maximal einer vollständigen Sprintlänge dauern. Andernfalls treten verschiedene Probleme auf – wie z. B. die Geschwindigkeit (wie das Team sich für die Lieferpunkte verantwortlich fühlt), Schwierigkeiten bei der genauen Schätzung und mehr.

Agile INVEST – Testbar

Im vorliegenden Kontext bezieht sich „testbar“ auf die während der Analyse definierten Akzeptanzkriterien.

Wir können eine User Story nicht als „Erledigt“ betrachten, es sei denn, sie erfüllt die Akzeptanzkriterien. Die einzige Möglichkeit, dies zu überprüfen, ist durch Testen und Verifizieren.

Akzeptanzkriterien sind keine Testfälle. Sie beantworten die Frage: „Wie weiß ich, wann ich diese User Story abgeschlossen habe?“

Testfälle beschreiben die Schritte, die zum Testen der Funktionalität erforderlich sind.

Der Kunde kann Ihnen sagen, wie die Testumgebung aussieht und unter welchen Testbedingungen das Team eine User Story als ERLEDIGT.