Was eine User Story ist und was nicht
User Storys wurden entwickelt, als Extreme Programming (XP), Kanban und Scrum es erforderlich machten, Projekte in kleinere, inkrementelle Segmente für Sprints und Iterationen aufzuschlüsseln. Sie unterscheiden sich insofern von Anwendungsfällen, als sie sich auf die kleinstmögliche Arbeitseinheit konzentrieren. Anwendungsfälle, die ursprünglich von Ivar Jacobson entwickelt wurden, können aus mehreren Storys bestehen, die auf einem gemeinsamen Thema basieren. Die Storys selbst sind einfache Narrative, die eine einzelne Erwartung oder ein Benutzerziel skizzieren. Sie können die Erstellung einer User Story in drei Phasen aufschlüsseln:
- Beschreiben Sie den Bedarf.
- Planen Sie die Iteration.
- Implementieren und testen Sie die Story auf Ihre Fertigstellung.
In jeder Phase kann die User Story weiter perfektioniert werden.
User Storys enthalten keine Anforderungsliste oder Codierungsanleitungen, stehen aber in Zusammenhang mit Akzeptanzkriterien oder -tests. Das Ziel einer User Story ist jedoch nicht allein ihre Erstellung. Stattdessen liegt der Fokus darauf, wer die Funktion wünscht, wozu sie dient und warum sie wichtig ist. Storys verleihen Funktionen, die schließlich die Backlog-Aktivitäts-To-do-Liste bilden, ein menschliches Element.
Warum sind User Storys wichtig?
Storys sind mehr als nur eine Liste der Funktionen –sie bringen den Benutzer ins Gespräch. User Storys bieten Kontext für die Softwareentwicklung, indem sie sich auf den Mehrwert konzentrieren, von dem der Benutzer profitiert. Dieser benutzerorientierte Prozess schaltet die Agile-Sprache stumm, sodass Nicht-Entwickler zusammenarbeiten und an Gesprächen teilnehmen können.
User Storys helfen, einen fortwährenden Dialog während des gesamten IT-Entwicklungsprojekts zu erleichtern, um Bereiche wie Iterations-/Sprintplanung und Priorisierung des Backlogs für ein Release zu unterstützen. Im Gegensatz dazu steht im traditionellen Wasserfall-Modell der Dialog am Beginn und am Ende des Entwicklungsprozesses.
In seinem Buch User Stories Applied for Agile Software erklärt Michael Cohn von Mountain Goat Software: „Wir treffen Entscheidungen basierend auf den für uns verfügbaren Informationen, und das oft. Anstatt eine einzige umfassende Reihe von Entscheidungen zu Beginn eines Projekts zu treffen, verteilt man die Entscheidungsfindung über die Dauer des Projekts hinweg. Hierzu stellen wir sicher, dass wir einen Prozess haben, der uns so früh und so oft wie möglich Informationen liefert. Und hier kommen User Storys ins Spiel.“
Wer schreibt die User Story?
Produktverantwortliche, Beteiligte, Produktmanager und andere Geschäftsteam-Mitglieder nehmen an der Erstellung von User Storys teil. Viele sagen jedoch, dass es weniger wichtig ist, wer diese schriebt, als wer an den Diskussionen und Gesprächen teilnimmt, die die Storys zum Leben erwecken. Beginnen Sie damit, zu identifizieren, wer die Funktion verwendet (die Persona); der Detailgrad dieses Schritts hängt vom jeweiligen Bedarf ab. Der Benutzer kann in Bezug auf Funktion oder Stellenbeschreibung definiert werden, z. B. „Schüler“, „Vielflieger“ oder „Marketingmanager“.
Ein starkes Verständnis des Endbenutzers begrenzt die Voreingenommenheit oder Annahmen der Entwickler. Wenn die Benutzer verfügbar sind, können sie teilnehmen, aber oft verfügt das Team über Designer, Manager, Autoren und andere, die als Kundenstellvertreter fungieren. Die Teilnehmer können je nach Verwendung der User Story variieren. Beispiel:
- User-Story-Erstellung: Zu den Teilnehmern können Kunden, Produktmanagement, Engineering und andere Beteiligte wie die Personalabteilung, die Finanzabteilung und den Vertrieb gehören.
- User-Story-Pflege: Zu den Teilnehmern zählen das Produktmanagement oder ein Produktverantwortlicher.
- User-Story-Anwendung und -Nutzung: Zu den Teilnehmern gehören Ingenieure/Entwickler, technische Autoren und Qualitätssicherheits-Tester.
So schreiben Sie effektive User Storys
Eine User Story ist eine einfache, einzeilige Leistungsübersicht für eine nützliche Funktion. Bevor Sie die User Story schreiben, führen Sie Benutzerbefragungen durch, um den Benutzer zu notwendigen Funktionalitäten zu befragen. Beginnen Sie damit, indem Sie auf Karten im Format DIN A6 oder DIN A7 oder auf Post-its eine Customer Journey schreiben, die aus inkrementellen Storys besteht. Diese Karten können sofort in die Produktion aufgenommen werden oder den Kontext für das Backlog liefern.
Beim User-Story-Mapping können Sie Post-its entlang einer Wand im Konferenzraum platzieren, damit das gesamte Team die Story sehen und an der langfristigen Planung arbeiten kann.
Es gibt einige Techniken, die Sie verwenden können, um die von Ihnen benötigten Storys zu schreiben. Eine übliche Technik ist die Role-Feature-Reason- oder Role-Goal-Benefit-Struktur (RGB), die Sie erstellen, indem Sie die Lücken in folgenden Sätzen ausfüllen:
- Als (Benutzer/Persona/Kunde) möchte ich (etwas tun), damit ich (einen Vorteil erhalte).
Das Beitragen zur RGB-Frage ist eine Methode, die von Ron Jeffries entwickelt wurde und die dessen „Ansatz der drei Cs“ hervorhebt:
- Card (Karte): Schreiben Sie die Antwort auf die RGB-Frage (siehe oben) auf eine Karte.
- Conversation (Gespräch): Der begrenzte Detailgrad auf der Karte ist die Grundlage für ein Versprechen, das vom zweiten C erfüllt wird. In dieser Phase bespricht das Team die Details und legt eine Definition für „Erledigt“ fest.
- Confirmation (Bestätigung): Dies ist das Ergebnis von Feedback, das die Test- oder Akzeptanzkriterien bestimmt. Ein solches Akzeptanzkriterium wird oft auf die Rückseite der Karte geschrieben und wird als erste Checkliste während zukünftiger Meetings verwendet, um die Fertigstellung zu bestimmen.
Das Akronym INVEST, das erstmals in einem Artikel von Bill Wake im Jahr 2003 vorgestellt und durch Michael Cohns Buch User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a. populär gemacht wurde, ist eine Methode, User Storys zu bewerten. Die INVEST-Kriterien lauten wie folgt:
- Unabhängigkeit, um sich in jeder Sequenz zu entwickeln.
- Fähigkeit, das Entwicklungsausmaß der Story zu verhandeln.
- Bietet einen Mehrwert für den Benutzer oder das Unternehmen.
- Ist für die Fertigstellung schätzbar.
- Ist klein genug für Designs, Codes und Tests in einer einzigen Iteration.
- Ist testbar.
Das Schreiben von User Storys, die der RGB- und der Drei-Cs-Methode folgen, ist ein guter Ausgangspunkt. Die Bewertung der Effektivität im Hinblick auf die INVEST-Ziele sorgt für kleine, funktionale und testbare Storys.
Bennett Lauber, Chief Experience Officer with The Usability People, LLC, makes the following suggestions for someone preparing to write their first user story: “Make sure you do some research on your users and create personas. This will help the development team have empathy with the user.”
Vorlage für agile User-Story
Bereit, eine User Story zu schreiben? Laden Sie eine kostenlose Vorlage herunter, mit der Sie die Funktion klar aus der Perspektive des Endbenutzers definieren können. Es listet die Benutzertypen auf, was sie möchten und warum. Durch die Erstellung dieser kurzen, in einem Satz ausgedrückten User Storys kann das Entwicklungsteam Code entwickeln, der den Anforderungen der User Story entspricht. Weitere nützliche Agile-Vorlagen, die Sie herunterladen können, finden Sie hier.
Vorlage für agile User Story herunterladen
So schreiben Sie einen Testfall basierend auf einer User Story
Eine User Story bietet Orientierung für die Entwicklung von Test- oder Akzeptanzkriterien. Diese Checkliste hilft Entwicklern, zu bestimmen, wann die Funktion fertig ist. Wie bei allen Elementen von User Storys werden die Akzeptanzkriterien ebenfalls vom Standpunkt des Benutzers aus geschrieben. Die Test- oder Akzeptanzkriterien skizzieren die Elemente, die zur erfolgreichen Durchführung der erforderlichen Funktion erforderlich sind.
Diese Kriterien sollten Folgendes umfassen:
- Die vorgesehenen funktionalen und nicht funktionalen Anforderungen
- Negative Szenarien der Funktionalität
- Leistungsrichtlinien
- Der richtige Benutzerworkflow
- Auswirkungen auf andere Funktionen
- Benutzererfahrung
Thomas Stiehm, CTO at Coveros, writes test cases using Gherkin Language. “This is the given, when, then (GWT) format,” he says. “I use test automation in Cucumber and that consumes Gherkin for automated testing. In addition, involving an experienced tester helps create better stories. They can ask important functionality questions while the story is being developed, which in turn results in more usable functionality.”
Verwenden wir eine Konferenzanmeldung als Fallbeispiel: Ein Benutzer reicht ein Formular ein, das seine Kontaktinformationen enthält, er wählt eine Zahlungsoption aus und eine Bestätigung wird angezeigt und per E-Mail gesendet. Diese Aspekte werden Teil der Akzeptanzliste. Im Testfall werden auch die Leichtigkeit und der Flow bei der Benutzererfahrung (UX) berücksichtigt. Wie die User Story selbst spiegelt auch der Grad der getesteten Details nur wider, was notwendig ist, um sicherzustellen, dass die Funktion einen Mehrwert liefert.
Hernan Santiesteban, of Great Lakes Web, shares his advice. “One of the best ways to write a test case is to use the given, when, then template, which establishes test conditions, user actions, and expected outcome. For example: given an administrative user signs in successfully, when the admin opens the user dashboard, then the admin will be presented with user management functions.”
Vorteile des Schreibens starker User Storys
Einige Produktmanager und Entwicklungsteammitglieder können das Gefühl haben, dass das Schreiben von User Storys anstatt von Anforderungslisten mehr Schritte zum gesamten Agile-Prozess hinzufügt. Ein entscheidender Vorteil von User Storys besteht jedoch darin, dass sie abhängig von Zusammenarbeit sind und alle auf dem gleichen Stand halten. Dinge können sich während der Entwicklungsprozesse durch Entdeckungen und Stakeholder-Feedback ändern – daher können User Storys sich ändern oder sich an diese Umstände anpassen.
Zu den häufigsten Vorteilen gehören die folgenden:
- Zeigen Sie Fortschritte schnell an, indem Sie das Gesamtbild in kleinere Projekte aufschlüsseln.
- Motivieren Sie das Team und bringen Sie das Projekt mit schnellen Erfolgen voran.
- Priorisieren Sie die Endbenutzer und fördern Sie damit die Akzeptanz und Zufriedenheit der Benutzer.
- Priorisieren Sie Funktionen mit hohem Mehrwert.
- Stellen Sie eine Plattform zur Verfügung, über die Sie gemeinschaftliche Gespräche führen können, die eine kreative Lösungsplanung ermöglichen.
- Fördern Sie ein hohes Maß an Zusammenarbeit, durch das sich das Team auf die Ergebnisse konzentriert, was wiederum für bessere Produkte sorgt.
So schreiben Sie eine gute User Story
Es erscheint kontraintuitiv, dass große Softwareinitiativen mithilfe von Oldschool-Methoden zu Erfolg und Effizienz führen. Einfache Karten im Format DIN A6 oder DIN A7 in unterschiedlichen Farben und ein Permanent-Marker bilden eine bescheidene Grundlage für die Erstellung von User Storys, die einem Agile-Entwicklungsprozess Kontext verleihen. Die kleinen Karten fördern die Entstehung schlichter, vorteilorientierter Beschreibungen, die durch die Zusammenarbeit im Team entwickelt werden.
Alle User Storys sind einzigartig und sollten durch Story-Mapping, Diagramme, Storyboards und Mock-ups ergänzt werden. Nichtsdestotrotz finden Sie nachfolgend einige bewährte Vorgehensweisen, die Ihnen helfen können, eine effektive User Story zu schreiben:
- Kennen Sie Ihren Benutzer: Definieren und verstehen Sie Ihre Benutzerpersona(s).
- Beziehen Sie alle Beteiligten ein: Stellen Sie sicher, dass alle relevanten Beteiligten in den User-Story-Schreibprozess einbezogen werden. Das Testteam kann die Story eventuell sogar noch weiterentwickeln.
- Konzentrieren Sie sich auf den Benutzer: Diskussionen und Gespräche aus der Perspektive des Benutzers liefern Kontext und eine Definition davon, was als „erledigt“ gilt.
- Halten Sie es kurz und einfach: Beschreiben Sie in jeder User Story nur einen einzelnen Bestandteil der Funktionalität. Wenn eine Story zu umfangreich ist, um in einem kurzen Zeitraum entwickelt zu werden, untergliedern Sie sie in kleinere Schritte oder legen Sie bestimmte Bedingungen fest, die hinzugefügt werden können, um die Funktion zu begrenzen. Als Faustregel gilt, dass eine User Story kurz genug sein sollte, dass das Entwicklungsteam sie in einer Iteration abschließen kann.
- Diskutieren und zusammenarbeiten: Diskussionen über die Projektgröße und das Minimum Viable Product (MVP) sowie darüber, wer es verwendet, was es tut und warum dienen alle als Entscheidungshilfen im Hinblick auf die Einbeziehung und den Umfang.
- Vermeiden Sie technische Details: Nehmen Sie keine technischen Aufgaben oder konkrete Anweisungen in die User Storys auf, da sie Kreativität und Zusammenarbeit verhindern können. Technische Details werden später im Prozess aufgenommen und von Entwicklern, Testern und Systemarchitekten integriert. Eine Vorlage kann helfen, sich von technischen Details wegzubewegen.
- Konzentrieren Sie sich auf die 3 Ws: Wer wird es verwenden? Was ist es? Und warum ist es wichtig?
- Visualisierung fördern: Verwenden Sie alle Methoden (Zeichnungen, Story- und Impact-Mapping, Storyboards und Mock-ups oder Prototypen), die geeignet sind, um das fertige Produkt zu visualisieren.
- Klären Sie den Wert und den Nutzen: Stellen Sie sicher, dass der Zweck der Story klar ist, die Dringlichkeit vermerkt ist und die Story abgeschlossen ist.
Herausforderungen und häufige Fallstricke bei der Erstellung von User Storys
Eine User Story beantwortet Fragen wie zum Beispiel, wer die Funktion verwendet, was die Funktion tun wird und warum die Funktion wichtig ist. Die Details der Story bieten den Geschäftskontext, den Benutzerwert und fördern Teamdiskussionen. Eine häufige Herausforderung bei der Erstellung von User Storys besteht darin, sicherzustellen, dass die Story umfassend genug ist, um ihren Wert zu formulieren, aber einfach genug, um in einem kurzen Zeitraum wie einem Sprint (der normalerweise zwischen einer und vier Wochen liegt) für Ergebnisse zu sorgen. Die Story sollte weder technischen Details dazu enthalten, wie das Produkt erstellt wird, noch Codierungsanleitungen beinhalten. Diese Details sind zu diesem Zeitpunkt der Entwicklung nicht erforderlich.
Wenn eine Story zu lange oder zu umfassend ist, kann sie in kleine Teile unterteilt werden.
Hier ein gutes Beispiel:
- Als Bankkunde möchte ich in der Lage sein, meine Salden einzusehen, damit ich die Bezahlung von Rechnungen planen kann.
Es kann verlockend sein, mehr Details oder andere Funktionen hinzuzufügen, aber das schafft ein sperriges Narrativ. Diese Art von Story würde so aussehen:
- Als Vertriebsmanager möchte ich meine Prognosen, Vertriebs- und Personalberichte erhalten, damit ich mein Budget für ein ganzes Jahr festlegen kann.
Dieses Beispiel verfügt über mehrere Komponenten (die Erstellung einzelner Berichte: Prognose, Vertrieb und Personal), die in mehrere kleinere User Storys unterteilt werden sollten.
Achten Sie außerdem darauf, Akzeptanzkriterien aufzunehmen, die festlegen, was als „erledigt“ gilt. Wie oben erwähnt, werden Akzeptanzkriterien oft als Checkliste auf die Rückseite der User-Story-Karte geschrieben.
Zu den zusätzlichen Herausforderungen bei der Erstellung von Akzeptanzkriterien gehören die folgenden:
- Die natürliche Tendenz, sich darauf zu konzentrieren, wie etwas konzipiert ist. Wenn Sie auf diese technischen Details jedoch verzichten, ergeben sich sinnvollere Gespräche, die zu kreativen Lösungen führen, und die Einbeziehung von Benutzern und nicht-technischen Teammitgliedern in die Diskussionen wird ermöglicht.
- Dialoge und Gespräche können zeitaufwändig sein und werden oft vergessen, was die positiven Auswirkungen von User Storys begrenzt.
- Mangelnde Daten oder ein fehlendes echtes Verständnis des Benutzers oder der Persona gefährdet die Akzeptanz von Funktionalitäten, sobald diese dem Endbenutzer zur Verfügung stehen.
- Die Begrenzung von Storys auf die kleinsten Schritte ist nicht einfach, aber zu viele Details machen die User Story sperrig.
- Wenn Sie wichtige Informationen wie Akzeptanzkriterien oder Kundenvorteile auslassen, können Fragen während des Entwicklungsprozesses unbeantwortet bleiben.
In Mike Cohns Buch User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a. wird das Kernproblem in der Softwareentwicklung mit dieser einfachen Beobachtung identifiziert: „Softwareanforderungen sind ein Kommunikationsproblem.“
Die technische Sprache, die mit Softwareentwicklung und Agile-Methoden einhergeht, kann für viele ein Hindernis sein. Während des gesamten Entwicklungsprozesses werden beim Schreiben von User Storys offene Dialoge und Gespräche einbezogen, indem Aufgaben aufgeschlüsselt werden, um das generierte Momentum aufrechtzuerhalten, und eine starke Definition von „Done“ festgelegt wird. Die Erstellung von Software ist ein umfangreicher, zeitaufwändiger Prozess mit vielen Beteiligten und hohen Erwartungen. Wenn Sie jedoch einige einfache Richtlinien und einige altmodische Techniken befolgen, werden die Feinheiten bei der Erstellung von Software für ein ganzes Team besser sichtbar und am Ende besser handelbar.
Lernen Sie, wie Sie User Storys mit Smartsheet für die Softwareentwicklung schreiben
Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.