Was ist eine Benutzergeschichte? Definition
User Stories sind eine agile Praxis, die hauptsächlich in Scrum verwendet wird, um die Bedürfnisse der Benutzer zu „erfassen“, indem sie in einer allgemeinen, nicht detaillierten Weise Merkmale, Funktionen und Anforderungen an das zu erstellende Produkt ausdrücken.
Sie sind ein Element des Product Backlogs, das in Scrum eine „Liste“ aller Dinge darstellt, die im Projekt umgesetzt werden müssen.
Sie sind ein scheinbar einfaches Element, das aber sehr effektiv ist, da es Ihnen ermöglicht, sich auf die Bedürfnisse und Anforderungen der Benutzer (und/oder Kunden) und den zu realisierenden Wert zu konzentrieren.
Benutzergeschichten werden oft auf Pappe oder Post-it-Zettel geschrieben, sie werden an der Wand oder auf Tischen befestigt, um die Planung und Diskussion zu erleichtern. Auf diese Weise gelingt es ihnen, den Schwerpunkt vom Schreiben von Features auf die Diskussion über Features zu verlagern und die Bedeutung der Aussage des Agilen Manifests „funktionierende Software statt erschöpfender Dokumentation“ zu demonstrieren.
Wozu dienen User Stories?
User Stories sind eine hervorragende Möglichkeit, das Produkt/die Dienstleistung klar zu definieren. Eine Reihe von gut geschriebenen und nach Prioritäten geordneten User Stories kann dem Team helfen, die Produktfunktionalität auszudrücken und weiterzugeben, ohne dabei ins technische Detail zu gehen.
Eine User Story ermöglicht es, die Bedeutung und Auswirkung einer Funktionalität auf das Unternehmen zu verstehen und hilft auch dem Kunden, den Nutzen der Funktionalität und ihre Priorität zu verstehen.
Wenn sie gut geschrieben sind, bieten User Stories eine solide Grundlage für die Kommunikation und Zusammenarbeit und rücken den Benutzer in den Mittelpunkt des Interesses. Die Verwendung von User Stories erleichtert die Diskussion über das Produkt, sowohl innerhalb des Entwicklungsteams als auch mit externen Stakeholdern.
Woraus besteht die User Story?
Jede User Story beschreibt auf einfache, für den Kunden und die Entwickler gleichermaßen verständliche Weise, was zu tun ist, für wen und warum. Die Sichtweise ist die der Person, die die neue Funktionalität anfordert, die Menge an Informationen ist die, die unabdingbar ist, damit das Entwicklungsteam eine grobe Schätzung des Arbeitsaufwands für die Realisierung vornehmen kann.
Es gibt verschiedene Arten, eine User Story zu schreiben, aber in der Regel enthält sie einen Namen, eine kurze Beschreibung und die Angabe der Akzeptanzkriterien und Bedingungen, damit die Story als abgeschlossen gilt.
Eine Vorlage kann sein:
Als <Nutzertyp> möchte ich <ein Ziel> haben, damit <ein Grund>.
Hier sind zwei Beispiele:
- Als Kunde möchte ich meine Hotelbuchung stornieren, um eine Rückerstattung zu erhalten.
- Als Online-Kunde möchte ich mich einloggen können, um einen sicheren Zugang zu meinem Konto zu erhalten.
Die User Story macht einen Dialog mit dem Kunden und/oder Benutzer erforderlich, denn durch den Dialog können wir alle verschiedenen Aspekte der Geschichte verstehen, wir können ein gutes Verständnis für den Bereich haben und wissen, warum wir diese spezifische Funktionalität entwickeln müssen.
Grundlegende Merkmale von User Stories
User Stories sollten immer 6 Merkmale aufweisen, die durch das von Bill Wake* verwendete Akronym INVEST dargestellt werden:
Independent: sie müssen voneinander unabhängig sein
Negotiable: Sie müssen „verhandelbar“ sein und offen für Beiträge von allen
Valuable: Sie müssen dem Kunden einen zusätzlichen Nutzen bringen.
Estimable: Sie müssen abschätzbar sein, nicht genau, aber genug, um eine grobe Planung für die Umsetzung zu ermöglichen
Small: Sie müssen klein sein, so dass die Funktionalität in maximal ein paar Wochen Arbeit realisiert werden kann. Sie müssen klein sein, weil die Schätzungen dann präziser sind. Wenn die Geschichte zu komplex ist, teile ich sie in mehrere Geschichten auf.
Testable: Sie müssen testbar sein und Informationen darüber enthalten, wie sie getestet werden können.
Im Folgenden finden Sie ein Beispiel dafür, wie eine Benutzergeschichte in einfachere Benutzergeschichten unterteilt werden kann.
Wer schreibt Benutzergeschichten?
Benutzergeschichten können von jedem geschrieben werden, der über die nötigen Fähigkeiten verfügt, sie zu schreiben. Am häufigsten werden sie vom Product Owner geschrieben (Link zu einem späteren Beitrag). Sie können aber auch vom gesamten Team in Zusammenarbeit verfasst werden.
Acceptance criteria
Zusammen mit den User Stories ist es wichtig, Akzeptanzkriterien aufzustellen, d. h. Kriterien, anhand derer beurteilt werden muss, ob eine Story korrekt und vollständig umgesetzt wurde. Es handelt sich also um die Bedingungen, die das Softwareprodukt erfüllen muss, um vom Benutzer und/oder Kunden akzeptiert zu werden. Akzeptanzkriterien sind grundlegend, um zu verstehen, wann das Ziel der User Story erreicht ist.
Format
Die Benutzergeschichte wird oft auf A6-Papier geschrieben. Das kleine Format zwingt einen dazu, nicht zu viele Informationen zu verwenden. Die Karte ist nützlich, weil sie einfach zu benutzen ist und es ermöglicht, die Karten an der Wand oder auf dem Tisch zu gruppieren, um die Konsistenz, die Vollständigkeit und die Verbindungen zwischen verschiedenen Geschichten zu beurteilen. Auch wenn Sie elektronische Geschichten haben, kann es nützlich sein, Karten zu verwenden.
Ein weiterer wichtiger Faktor ist die Sichtbarkeit: Die Geschichten müssen für das gesamte Team sichtbar sein. Schließlich stellen sie die Einheit der Arbeit dar, die das Team in einem Sprint anstrebt.
Was sind die wichtigsten Merkmale eines agilen Sprints? Lesen Sie den Blogbeitrag die 5 Merkmale eines erfolgreichen agilen Sprints!
*INVEST in Good Stories, and SMART Tasks
Copyright © 2019 Agile Business Consortium all rights reserved
