Schauen wir uns an, wie und warum wir User Stories qualitätssichern möchten. Schlechte User Stories führen zu unnötigen Besprechungen, Verschwendung und Nacharbeit. Die Verbesserung der User Story so früh wie möglich im Entwicklungslebenszyklus ist eine wirksame Möglichkeit, Verschwendung und Nacharbeit zu minimieren.
Qualitätssicherung ist ein systematischer Ansatz, um festzustellen, ob ein „Produkt“ akzeptable Kriterien erfüllt. Für die Qualitätssicherung von User Stories müssen wir zunächst definieren, was gut ist. Was ist der Unterschied zwischen guten User Stories (und einer Reihe von User Stories) und schlechter Qualität?
Für die agile Softwareentwicklung neigen wir dazu, die User Story als Kurzform für eine Softwareanforderung zu verwenden. Einige Agile-Coaches mögen bestreiten, dass User Stories tatsächlich Anforderungen sind, aber die meisten Teams tun dies tatsächlich.
Heutzutage erfolgt die Qualitätssicherung größtenteils teilweise (oder vollständig) automatisiert.
Was erwarten wir von einer guten User Story?
Minimum
- Wir empfehlen einen prägnanten, eindeutigen Titel
- Eindeutige Identifizierung des Benutzers (konsistent über eine Reihe von User Stories hinweg).
- Klare, prägnante Angaben zu den Funktionsschritten, die zur Erfüllung einer einzelnen funktionalen Benutzeranforderung erforderlich sind.
Optional, empfohlen
- Eine Aussage von Nutzen oder „damit“
- Eine Aussage des Auslöseereignis, welche Benutzerumstände dazu führen, dass diese Anforderung ins Spiel kommt.
- Eine eindeutige Referenz-ID, die sich nicht ändert, auch wenn dies bei der User Story der Fall ist.
