Mißverständnisse in Software-Spezifikationen.

In Software-Spezifikationsdokumenten kommt es häufig zu Missverständnissen. Die Lösung, die wir normalerweise wählen, besteht darin, detailliertere Spezifikationen zu erstellen. Das führt aber leider nicht zu besseren Ergebnissen
Sie können diesen Beitrag auch lesen in

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. Der Kunde erwartet eine sehr schnelle Antwort

    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.

 

Teilen:

Zugehöriger Blogbeitrag

10 Vorteile der Verwendung von Sprint Goals

Wir von Better Change glauben an die Kraft der Teamzusammenarbeit, um in Unternehmen Werte zu schaffen. Ein wichtiger und oft übersehener Aspekt dabei ist die Verwendung von Sprint Goals. Dabei handelt es sich um klare, prägnante Ziele, die für jedes Sprint festgelegt werden und den Scrum-Teams Richtung und Fokus geben.

Scaling Challenges: Die Sichtweise eines CIO

Viele CIOs starten ehrgeizige Skalierungsinitiativen mit dem Ziel, agility freizusetzen und die Markteinführung zu beschleunigen. Der Weg dorthin kann jedoch mit unerwarteten Hürden gespickt sein. Dieser Artikel befasst sich mit häufigen Hindernissen und bietet Anleitungen...

Elevate Your SAFe® By Breaking Down Barriers

Auswirkungen von Hierarchiegrenzen auf die Einführung von SAFe® Scaled Agile Framework Bei der Verfolgung der organisatorischen agility soll die Scaled Agile Framework (SAFe®) vor allem einen Fahrplan für die...

Verwandte Ausbildung

Verwandte Ressourcen

Wie man ein Retrospective betreibt

Die Durchführung einer effektiven Retrospektive ist entscheidend für die kontinuierliche Verbesserung in Agile-Teams. Wenn Sie jemals das Gefühl hatten, dass die Retrospektiven Ihres Teams nicht zielführend sind oder keine verwertbaren Erkenntnisse liefern, sind Sie...

Ein kreisförmiges Flussdiagramm mit verschiedenen Phasen, die den Scrum-Prozess darstellen

Der Scrum-Prozess erklärt

Entdecken Sie die Feinheiten des Scrum-Prozesses und erfahren Sie, wie dieses agile-Framework das Projektmanagement revolutionieren kann.

Ein Teleskop, das auf ein entferntes

Was ist eine Produktvision?

Entdecken Sie die Kraft einer Produktvision und wie sie die Zukunft eines Unternehmens prägt.

Mehr Beiträge

Lass uns reden über
Wie wir helfen können!

Gefallen Ihnen unsere Artikel? Noch besser ist es, wenn Sie persönlich mit uns sprechen können! Nehmen Sie Kontakt mit uns auf, damit wir einen Termin vereinbaren können!