Gute User Stories brauchen Zeit und Aufmerksamkeit

Nicht jede User Story bringt eine Verbesserung für das Produkt - Vermeiden Sie Fehler

Wie erkennt man eine schlechte User Story?

Heute will jedes Team auf die agile Methodik der Agilen Programmierung umsteigen, d.h. den Anwender in den Mittelpunkt der Prozessplanung bei der Produktentwicklung stellen. Sie bauen schließlich ein Produkt für die Endbenutzer, richtig?

User Stories sind eines der grundlegenden Werkzeuge, die Teams helfen, sich bei der Definition eines Produkts und seiner Funktionalität an den Benutzer zu erinnern. Es wird viel darüber gesprochen, wie man sie richtig schreibt.

Wenn wir User Stories schreiben, haben wir oft den Eindruck, dass wir sie aus der Perspektive des Benutzers schreiben. Letztlich sind sie aber immer durch unsere Sichtweise und unser Fachwissen verzerrt. Oft sind diese Fehler miteinander verbunden und enden nie nur bei einer falschen Einschätzung. Deshalb möchte ich hier einige der häufigsten und häufigsten Fehler besprechen, die Teams beim Schreiben von User Stories machen.

User Stories, die zu breit, allgemein sind

Wenn User Stories zu allgemein gehalten sind, kann es leicht passieren, dass wichtige Informationen über die erwartete Aktivität und den Bedarf übersehen werden. Wenn es viele "und" oder "oder" in User Stories gibt, ist das ein Hinweis darauf, dass sie zu breit sind und Sie sollten in Betracht ziehen, sie neu zu schreiben.

User Stories, die zu gut sind

Wenn User Stories zu gut geschrieben sind, fangen wir an, darüber zu reden, wie wir sie umsetzen wollen. Das entfernt den Benutzerfokus und führt zu schlechter Kommunikation im Team.

User Stories, die nicht verhandelbar sind

User Stories sollten nicht eine spezifische und genaue Beschreibung der Funktion sein. Manchmal ist die User Story so charakteristisch geschrieben, dass das Team Schwierigkeiten hat, sie korrekt umzusetzen, weil es eine einfachere Alternative gibt. In solchen Fällen sollte das Team bereit sein, Kompromisse bei der Herangehensweise einzugehen, vorausgesetzt, es schadet nicht dem zu erzielenden Nutzen für den Benutzer.

Wiederholung der User Story in den Abnahmekriterien

Mit Akzeptanzkriterien können Sie die Bedingungen beschreiben, die erfüllt sein müssen, damit eine Story als abgeschlossen markiert wird. Dies dient der Rückmeldung, der Unterstützung bei der Planung des Teams und der Verfolgung ihrer Arbeit. Dadurch wird die User Story reichhaltiger, präziser und testbarer.

Einen undefinierten Benutzer haben

Die Erwähnung der Persönlichkeit des Benutzers in jeder User Story mag frivol erscheinen, aber auf der anderen Seite kann es einen großen Wert in Bezug auf die Ergebnisse bringen. Dies ist besonders wichtig, wenn Ihr Produkt mehr als einen Benutzer hat. Natürlich wird es Features geben, die auf verschiedene Charaktere zugeschnitten sind. Wenn Sie möchten, dass Ihr Team die Ergebnisse, die Sie von ihm erwarten, besser umsetzen kann, muss es wissen, wer die Endbenutzer sind und welche Vorteile sie durch die Einführung der jeweiligen Funktion erhalten.

Schlechter Kontext

Nach einiger Zeit sieht fast jede User Story gleich aus, z.B. als Content Manager möchte ich einen Texteditor haben, um den Inhalt bearbeiten zu können. All dies sagt dem Team, dass Sie wollen, dass sie eine Textverarbeitung bauen und nichts weiter. Wenn Sie einige User Stories für eine lange Zeit geschrieben haben, machen Sie eine Pause und kommen Sie mit einer neuen Perspektive zurück. Manchmal kann es sein, dass Sie auch nach einer Pause nicht in der Lage sind, sich etwas sinnvolleres einfallen zu lassen. Das ist ein guter Indikator dafür, dass Sie mehr mit den Benutzern sprechen sollten, um ihre Bedürfnisse besser zu verstehen. Es ist wirklich nicht nötig, das Rad neu zu erfinden.

Die Verwendung von User Stories kann zwar nützlich sein, ist aber nie so einfach, wie es klingt. Ein Fehler beim Schreiben führt oft zu einer Reihe von anderen als Nebenprodukt. Und dann finden wir uns in einem noch größeren Schlamassel wieder, als wenn wir sie gar nicht geschrieben hätten. Deshalb, wenn wir uns entscheiden, es vorzubereiten, sollten wir viel Zeit und Aufmerksamkeit darauf verwenden.

Ihr Kommentar zum Artikel

"Gute User Stories brauchen Zeit und Aufmerksamkeit"

Wir freuen uns über Ihren Kommentar und antworten so schnell es geht!

Das Angebot von "HECKER CONSULTING" richtet sich ausschließlich an Unternehmen und Behörden (iSv § 14 BGB). Verbraucher (§ 13 BGB) sind vom Vertragsschluss ausgeschlossen. Mit Absendung der Anfrage bestätigt der Anfragende, dass er nicht als Verbraucher, sondern in gewerblicher Tätigkeit handelt. § 312i Abs. 1 S. 1 Nr. 1-3 und S. 2 BGB (Pflichten im elektronischen Geschäftsverkehr) finden keine Anwendung.

Vielen Dank, Ihr Kommentar wurde empfangen!
Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Beratungs-Leistungen für Das Thema

Software Engineering

Wir erweitern ständig unser Beratungsportfolio. Über 300 Beratungsleistungen haben wir für Sie im Programm. Selbstverständlich lassen sich die einzelnen Themen kombinieren. So erhalten Sie genau die Beratung, die Sie wünschen und brauchen

Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>
Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>

Kontaktanfrage

Das Angebot von "HECKER CONSULTING" richtet sich ausschließlich an Unternehmen und Behörden (iSv § 14 BGB). Verbraucher (§ 13 BGB) sind vom Vertragsschluss ausgeschlossen. Mit Absendung der Anfrage bestätigt der Anfragende, dass er nicht als Verbraucher, sondern in gewerblicher Tätigkeit handelt. § 312i Abs. 1 S. 1 Nr. 1-3 und S. 2 BGB (Pflichten im elektronischen Geschäftsverkehr) finden keine Anwendung.

Vielen Dank, Ihre Nachricht wurde empfangen!
Beim Absenden des Formulars ist etwas schief gelaufen.
WEITERE INFORMATIONEN AUS UNSEREM BLOG ZUM THEMA

Software Engineering

Aktuelle und interessante Themen und Beiträge für Sie zusammengetragen und aufbereitet.

Mehr IT-, Online-, Digital-Neuigkeiten anzeigen >>
Nach oben