In einem flexiblen Prozess sollte der Endnutzer immer an erster Stelle stehen. Unternehmen setzen User Stories ein, um genau das zu erreichen. Scrum Product Backlog Einträge werden z.B. häufig in Form von User Stories geschrieben. In diesem Artikel erfährst du alles, was du über Scrum User Stories wissen müssen und wie man sie schreibt.
Was ist ein Scrum Master?
Ein Scrum Master führt ein Team durch den Projektverlauf führt. Agiles Projektmanagement ist dabei ein häufiges Mittel. Um ein erfolgreiches Ergebnis zu gewährleisten, fördert er das Engagement und die Kommunikation aller Teammitglieder und Führungskräfte.
Was macht ein Scrum Master?
Scrum ist eine agile Entwicklungsmethodik, die zur Erstellung großer Projekte, meist Software, verwendet wird. Sprints, kurze Entwicklungszyklen, die in der agilen Projektmanagementtechnik verwendet werden, führen zu einer kontinuierlichen Verbesserung von Produkten oder Dienstleistungen. Es gibt zahlreiche agile Frameworks, und Scrum ist eine beliebte Wahl für Projekte, die sich schnell entwickeln (sollen). Die Kompetenz und die Skills des Scrum Masters bestimmt die Ergebnisse des Prozesses, die von dem hohen Maß an Zusammenarbeit und den Anforderungen an effektive Prozesse abhängen.
Scrum-Master-Positionen sind weltweit in einer Vielzahl von Branchen und für ein breites Spektrum von Organisationen verfügbar – nicht nur in der IT.
Auf der Suche nach top Scrum Mastern?
Hier bist du richtig.
Was ist eine User Story?
- Eine „User Story“ wird oft als die Erfahrung eines Benutzers mit einem Produkt beschrieben.
- User Stories machen die Interaktion zwischen Nutzern und Entwicklern sichtbar, die für die Erstellung eines Produkts erforderlich ist.
- Es ist eine von vielen Methoden zur Beschreibung eines Product Backlog Items. Es erleichtert die Kommunikation zwischen dem Team und dem Kunden.
Wir haben bereits über die Definition von Scrum User Stories gesprochen. Grundsätzlich werden sie vom Product Owner erstellt, um das geplante Produkt oder die Software aus der Sicht des Nutzers zu beschreiben. Die Grundfrage lautet: „Wie soll die Software aus Sicht des Benutzers aussehen?“ Obwohl User Stories keine offizielle „Technik“ in Scrum sind, wird diese Methode gerne verwendet, um ein klareres Bild des angestrebten Ziels zu erhalten.
Außerdem werden verschiedene Ebenen unterschieden: Epic, Story und Task. Die schauen wir uns jetzt mal genauer an.
Epic
Dieser erste Schritt ist zu abstrakt, um in einem Sprint (siehe unten) erreicht zu werden. Der Product Owner erstellt daher in dieser Phase mehrere kleine User Stories.
(User) Story
Die Story wird verwendet, um die Anforderungen für die Realisierung des Projekts einzuschätzen. Eine Story enthält die Anforderungen in verschiedenen kleinen Textbausteinen.
Task
Die Story kann wiederum in einzelne „Aufgaben“ unterteilt werden. Jede Aufgabe sollte innerhalb eines bestimmten Zeitraums abgeschlossen werden. Wenn alle Aufgaben einer Story abgeschlossen sind, ist auch das Projekt bereit zur Abgabe.
Sprints vs. Epic in Scrum
Ein Epic ist mit User Stories verwandt. Ursprünglich aus dem Extreme Programming-Bereich, gibt es zwei verschiedene Definitionen von Epic. Oft handelt es sich um eine sehr umfangreiche User Story, die in kleinere User Stories aufgeteilt werden muss, um einen lieferbaren Mehrwert darzustellen. In anderen Fällen kann es sich um eine Gruppierung von zusammenhängenden User Stories handeln.
Der Sprint ist ein Konzept von Scrum. Es handelt sich um einen Zeitrahmen, der Sprint Planning, Sprint Review, Sprint Retrospective und Daily Scrum Events umfasst, sowie den Aufwand für die Verfeinerung des Backlogs und die Implementierung der Arbeit. Eine Timebox hat einen festen Start- und einen Endpunkt. Meistens wird ein Zeitraum von nicht mehr als einem Monat festgelegt, in dem das Team ein funktionierendes Produkt produzieren sollte, das zur Übergabe oder Freigabe geeignet ist.
Was ist der Unterschied zwischen User Stories und Use Cases?
Leicht zu verwechseln, aber User Stories und Use Cases sind zwei Paar Stiefel.
Sowohl Use Cases als auch User Stories unterstützen Teams bei der Planung und Ermittlung der für die Ausführung der Arbeit erforderlichen Ressourcen. User Stories sind aber „nur“ einfache, knappe Berichte, die aus der Sicht des Kunden geschrieben werden. Sie stehen am Anfang eines umfangreicheren Verfahrens, das die Interaktionen oder das Verhalten eines Kunden bei der Verwendung Ihres Produkts beschreibt. Use Cases bieten viel mehr Kontext. Dabei braucht man deutlich mehr Input, um den Teams dabei zu helfen, zu verstehen, wie ein Benutzer oder Kunde mit einem System interagiert.
Warum sind User Stories wichtig?
- Stories haben den Nutzer im Blick
Eine Auflistung von Stories sorgt dafür, dass sich das Team auf die Suche nach Lösungen auf die tatsächlichen Benutzer fokussiert – ähnlich wie bei einer To-Do Liste. - Stories fördern die Zusammenarbeit
Sobald das Endziel feststeht, kann sich das Team voll und ganz darauf konzentrieren. Man zieht an dem berühmten einen Strang. - Kreative Lösungen werden durch Stories beflügelt
Das Team wird im besten Fall durch die Stories ermutigt, kritisch nachzudenken und kreativ über die besten Wege zur Erreichung des Ziels nachzudenken. - Stories bringen Schwung in die Sache
Stories lockern den oftmals sehr langen Prozess einer Produktentwicklung und sind durch die Kundenorientierung gut greifbar.
Wie viele der Entwicklungsansätze, die heute zum Standard in der Softwareentwicklung gehören, wurden User Stories zuerst in der Extreme Programming (XP) Community entwickelt. Ein XP-Team konzentriert sich auf die Bereitstellung eines letzten Produktinkrements, genau wie ein Scrum-Team. Das neue Produktinkrement steigert den Wert für den Benutzer, und an diesem Punkt hat das Team den höchsten Grad an „Fertigstellung“ erreicht. Daher muss sich das Team bei der Entwicklung der entsprechenden Funktionen darauf konzentrieren, wie der Benutzer mit dem Produkt interagieren wird.
Eine User Story konzentriert sich nicht auf die Implementierung oder Realisierung des gesamten Projekts. Ob für die Umsetzung eine Datenbank, ein Microservice oder eine GUI-Komponente benötigt wird, ist für den Anwender nicht wirklich von Bedeutung. Er bewertet den Erfolg eines Produkts danach, was es für ihn leisten kann.
Wie man User Stories in Scrum schreibt
Agile User Stories bestehen in der Regel aus wenigen Sätzen mit folgendem Format:
Als [Akteur] [will|muss] ich [handeln], damit [Leistung].
Oder kurz:
Als [Akteur] [will|muss] ich [Leistung].
Akteur: Der „Eigentümer“ der Benutzergeschichte. Obwohl es sich häufig um einen Benutzer handelt, ist es ratsam, sich in diesem Fall deutlicher auszudrücken. Die Einführung identifizierbarer Akteure wie „Administrator“, „Eingeloggter Kunde“ und „Nicht authentifizierter Besucher“ macht die User Story verständlicher und stellt sie in den richtigen Kontext.
Aktion: Das gewünschte Verhalten des Akteurs. Es ist möglich, einer Handlung ein „muss“ voranzustellen, wenn sie erforderlich ist. Wenn nicht, wird „Wunsch“ verwendet.
Leistung: Das, was der Akteur mit der Durchführung der Handlung zu erreichen hofft. Dies ist das Ergebnis der Handlung, wie es aus der Perspektive des Akteurs wahrgenommen wird.
Die Rolle simuliert, wie eine Person mit dem kompletten System umgehen könnte. Das Verhalten des Systems wird durch den Wunsch oder die Aktion beschrieben. Die meisten User Stories haben verschiedene Versionen. Dementsprechend bezieht sich das auf das eigentliche Ergebnis oder den Vorteil, der nichts mit dem System zu tun hat und nicht operativ ist. Die Nutzenaussage könnte in auch mehreren Geschichten vorkommen.
User Story Maps und warum du sie nutzen solltest
Das User Story Mapping ist eine beliebte Technik für das User Story Management. Mit dem User-Story-Tool kann man mehrere Ebenen und Dimensionen für ein Product Backlog (Item) erstellen, indem die Benutzeranforderungen in Benutzeraktivitäten, Benutzeraufgaben, Epics und User-Stories unterteilt werden. Normalerweise erstellt ein Entwicklungsteam eine Story Map in gemeinsamen Meetings, um die gewünschten Ergebnisse für die Endbenutzer zu ermitteln.
Einzeilige Produktrückstände sind eine eher schwache Methode zur Klassifizierung und Priorisierung der noch ausstehenden Arbeit. Eine bessere und feinere Struktur ist dafür erforderlich. Warum also Story Maps?
- Ein agiles Team kann seine Produktfreigaben so effizient planen und sein Product Backlog verwalten.
- Dokumentiert die Interaktionen, die Kunden mit dem Produkt haben, einschließlich der Aktionen und Aufgaben, die sie damit ausführen.
- Wenn eine Story Map gemeinsam erstellt wird, ist das Team vom Beginn des Projekts bis zur laufenden Produktion neuer Versionen auf derselben Seite.
Die berühmten 3 C's der User Stories
Vielleicht hast du schon einmal von den 3 C’s gehört, die helfen sollen, eine erfolgreiche User Story zu schreiben. Es gibt bereits einige Erklärungen dazu, daher werde ich diese nur kurz, knapp und verständlich anreißen.
Card, Conversation und Confirmation. Die drei Cs gehen auf Ron Jeffries zurück, der sie bereits 2001 in seinem Blogartikel Essential XP beschrieben hat: Card, Conversation, Confirmation (Karte, Konversation, Bestätigung). Auch heute noch gelten sie, neben den INVEST-Kriterien , als wichtige Grundregeln für die Entwicklung von User Stories.
Card
- Eine schriftliche Beschreibung der Geschichte, die für die Planung und Schätzung verwendet wird. Sie sollte kurz und informativ sein.
- Durch diese Praxis, die oft handschriftlich auf Karteikarten erfolgt, bleiben die User Stories übersichtlich.
- Die Angaben auf der Karte sind oft noch unvollständig.
- Der Inhalt auf der Karte ist einfach formuliert, damit jeder Story und Anforderungen verstehen kann.
Conversation
- Findet zu verschiedenen Zeiten und an verschiedenen Orten während eines Projekts zwischen den verschiedenen Personen statt, die von einer bestimmten Funktion eines Softwareprodukts betroffen sind: Kunden, Benutzer, Entwickler und Tester.
- Weitgehend mündlich, aber meist ergänzt durch Unterlagen.
Confirmation
- Akzeptanzkriterien, die die wesentlichen Anforderungen erfassen und dabei helfen, das erstellte Produkt zu testen, um sicherzustellen, dass es die definierten Kriterien erfüllt.
- Wird in der Regel vom Product Owner entwickelt und während der Backlog-Verfeinerung erweitert.
Fazit
User Stories sind nicht dazu gedacht, vollständige Spezifikationen durch eine magische Technik zu ersetzen, mit der das gleiche Ergebnis in der Hälfte der Zeit erreicht werden kann. Sie sollen als Ausgangspunkt für die weitere Verbesserung und Spezifikation durch Scrum-Teams dienen. Verschiedene Tools wie die 3Cs Card, Conversation, Confirmation und User Story Maps helfen, das Hauptziel von Scrum User Stories zu erreichen: Kommunikation anzuregen und Wissen zu teilen, damit das Team weiterhin nützliche Funktionen entwickeln kann.
