Mißverständnisse in Software-Spezifikationen.

Eine Erfahrung, die ich kürzlich gemacht habe

Ich habe online darauf gewartet, mit einem Servicemitarbeiter zu chatten. Natürlich habe ich eine Weile mit einem Bot gechattet, der in meinem Fall nicht sehr hilfreich war. Nach einer Weile wurde ich an einen echten Menschen weitergeleitet. Während ich wartete, machte ich diese Erfahrung in WhatsApp (siehe Bild). Die Wartezeit in diesen Nachrichten sollte die Zeit sein, die man noch warten muss, wie es im Text heißt. Der Entwickler hat sie anscheinend als die Zeit, die man bereits wartet, implementiert.....

Das sorgt für eine ziemlich schlechte Kundenerfahrung:

1. 1. Der Kunde erwartet eine sehr schnelle Antwort

1. 1. Der Kunde erhält jede Minute eine WhatsApp-Nachricht

Ursprung der User Stories

In meinen Product Owner-Schulungen betone ich immer wieder, dass die Aufgabe eines Product Owner nicht darin besteht, bessere Benutzergeschichten zu schreiben, sondern bessere Geschichten von Benutzern zu erzählen.

User Stories entstanden, als Kent Beck, der Begründer des eXtreme Programming (XP), das Feedback eines Benutzers erhielt, der sich so sehr über eine neue Funktionalität freute, dass die Idee aufkam, die Reaktion des Benutzers im Voraus zu definieren. Welche Reaktion erhoffen Sie sich vom Benutzer, wenn er die neue Funktion nutzen kann?

Um es einfacher zu machen, hat Ron Jeffries eine Vorlage dafür erstellt. Wenn Sie mit Agile oder Scrum arbeiten, haben Sie sie wahrscheinlich schon gesehen.

Als
Ich möchte
So dass Wert

Sie beschreiben WHO, WAS Und WARUM (Bitte beachten Sie; nicht WIE).

Missbräuchliche Verwendung von User Stories

Der Fehler, der häufig gemacht wird, besteht darin, dass diese Vorlage als neuer Weg zur Erfassung von Anforderungsspezifikationen angesehen wird. Indem man versucht, Anforderungen in der Vorlage zu erfassen, die überhaupt keinen Bezug zum Benutzer haben. Zum Beispiel:

Als Developer möchte ich eine Datenbank, damit ich meine Daten speichern kann.
Als Product Owner benötige ich einen Bericht, damit ich ihn dem CEO vorlegen kann.

Ganze Dokumente und Textblöcke werden auch an Elemente in Jira, TFS usw. angehängt.

Dafür sind User Stories nicht gedacht, sie sind die Grundlage für das Sammeln von Social Requirements, also für bessere Gespräche zwischen Entwicklern und Nutzern über die Nutzer und die Funktionalität. Alternativ zu den Nutzern kann man dafür auch Repräsentanten oder auch Stakeholder genannt verwenden, aber diese müssen die Nutzer wirklich verstehen und vertreten können.

Als Trainer des ersten XP-Teams führte Ron Jeffries die 3 K's ein: Card, Conversation und Confirmation.

• • Karte: Eine Karteikarte mit dem Titel und ein oder zwei Sätzen zur Erklärung.

• • Konversation: Diskussion mit dem gesamten Team darüber, was gewünscht wird

• • Konfirmation: Aufzeichnen, wie man feststellt, ob es den Anforderungen entspricht

User Stories müssen nicht perfekt definiert sein, bevor das Gespräch mit dem Team stattfindet. Während des #BacklogRefinements kann die Definition der User Story angepasst und die Akzeptanzkriterien können umgeschrieben oder hinzugefügt werden.

Wie wir helfen können

Wenn Sie daran interessiert sind, bessere Gespräche zu führen, werfen Sie einen Blick auf unsere User Story Mapping-Workshop

Wir werden dies auch in unserem Zertifiziertes Scrum Product Owner siehe unseren Zeitplan unten.