Dank User Story in Richtung Kundenzufriedenheit

Wie Stefanie Schütz in ihrem letzten Blogbeitrag berichtet hat, ist User Experience ein wesentlicher Bestandteil von Produkten und Services, welcher sich sowohl auf die Kundenzufriedenheit, als auch auf die Kundentreue auswirkt. Diese Zufriedenheit ist – nebst der Funktionalität – die wichtigste Voraussetzung für erfolgreiche Software. Eine User Story hilft dabei, die Bedürfnisse der Stakeholder zu erkennen und diese erkenntnisbringend zu dokumentieren.

Konzept User Story

Die folgenden drei Teile gehören zum Konzept der User Stories:

• Card
• Communication
• Confirmation

Die «Story Card» ist die strukturierte Karte, auf der die jeweilige User Story festgehalten und weiterentwickelt wird. Dabei gilt der Grundsatz «Einmal aufgeschrieben ist nicht in Stein gemeisselt». Während der Phase «Communication» geht es darum, die User Story weiter auszuarbeiten – so lange, bis sie den INVEST-Kriterien gerecht wird. Für die INVEST-Kriterien muss sie folgende Qualitäten erfüllen:

• Independent: Sie muss unabhängig, d.h. in sich geschlossen sein.
• Negotiable: Ihre Elemente müssen bis zur Umsetzung verhandelbar sein.
• Valuable: Sie muss den Anwendern einen Mehrwert bieten.
• Estimable: Ihr Umsetzungsaufwand muss schätzbar sein.
• Small: Sie soll möglichst klein sein, um besser priorisiert und geplant werden zu können.
• Testable: Sie muss genügend Informationen bereitstellen, um geprüft werden zu können.

Den zentralen Teil der User Stories bildet das folgende Satzschema: Als «Rolle» will ich «Feature», so dass «Geschäftswert». Die User Story beschreibt keine Bedürfnisse, sondern Stakeholder-Anforderungen. Während für die Anforderung die Elemente «Rolle» und «Feature» der User Story selbsterklärend sind, beinhaltet insbesondere das Element «Geschäftswert» wesentliche Informationen über die Motivation des Stakeholders. Mit der Frage «Wieso?» kann dieser Geschäftswert vertieft und exakt benannt werden.

Mit der Satzschablone alleine ist es aber noch nicht getan. Zu einer kompletten User Story gehören auch die folgenden Bausteine:

• Titel
• Eindeutiger Identifikator
• Zuordnung der User Story zum jeweiligen Business Requirement
• Priorisierung
• Story-Points zur Einschätzung des Aufwandes
• Risikoeinschätzung
• Akzeptanzkriterien (auf der Rückseite der Story Card) zur Prüfung der Anforderung

Sobald die User Story den aufgelisteten Kriterien entspricht, kann das Lieferobjekt entwickelt werden. In der Phase «Confirmation» wird das Lieferobjekt anhand der vordefinierten Akzeptanzkriterien schliesslich geprüft.

Um Ihnen diesen Prozess zu erleichtern, stellen wir Ihnen gerne ein Muster für eine Story Card zur Verfügung:

Abbildung 1: Muster für eine Story Card

Verwendung der User Story in Ihrem Unternehmen

Eine User Story bildet die Bedürfnisse der Stakeholder an einem System in Form von Anforderungen ab. Deshalb sollte sie auf Ebene der Stakeholder erfasst werden und auf die Erfüllung eines einzelnen Business Requirement abzielen. Ein Business Requirement hat dementsprechend mehrere User Stories – eine User Story gehört aber jeweils nur zu einem Business Requirement.

Auch Sie können Ihr Projekt mit Hilfe von User Stories in die gewünschte Richtung lenken. Binden Sie alle Stakeholder mit ein und versuchen Sie, User Stories durch geeignete Schneidetechniken möglichst granular zu halten. Um diese Granularität zu erreichen, gilt der Grundsatz: «So klein wie möglich – so gross wie nötig». In meinem nächsten Blogbeitrag zum Thema «User Stories» werde ich für Sie verschiedene Schneidetechniken für User Stories beleuchten.

Folgen Sie uns auf LinkedIn, um weiterhin auf dem Laufenden zu bleiben!