Leitfaden zu User Stories - Rally Software

Leitfaden zu User StoriesWas ist das?Die User Story beschreibt mit einem oder mehrerenSätzen in der Alltagssprache eines Benutzers oderKunden, was dieser mit der Software erreichenmöchte. Sie umreißt kurz, wie der Benutzer, Kundeoder andere Personen das System anwendenund welche Vorteile ihnen die Funktionenbringen werden.Die Story soll den Kontext liefern, der demProduct Owner hilft, den Backlog effektiv zuverwalten und zu priorisieren. Außerdem kanndas Team unter Berücksichtigung der Ziele derKunden besser nachvollziehen, wie die Funktionenumzusetzen sind.Auf wem beruht die User Story?Eine User Story beruht auf einem „User“ –einer Person, die sich eine bestimmte Funktionwünscht und von dieser profitiert. Für gewöhnlichverwenden wir eine imaginäre Person oder„Persona“, damit sich jeder genau vorstellen kann,welche Anforderungen und Motivationen dieserUser hat. Vermeiden Sie zu allgemeine Personas(z. B. „Benutzer“), denn die Beschreibungen sollendem Team helfen sich vorzustellen, für wen es dieSoftware entwickelt. Bei manchen Stories ist derUser auch ein System. Doch selbst sehr technischeStories sollten die Vorteile für Kunden undBenutzer berücksichtigen.Was ist der Inhalt einer User Story?Eine User Story beschreibt eine bestimmteLeistung oder Funktion, die der User sich wünscht.Diese Funktion wird vom Team in die Software oderden Service integriert. Der Inhalt der User Storysollte klar sein, damit das Team genau weiß,welche Funktion es entwickeln und integrieren soll.Was ist der grundlegende Nutzen?In einer User Story beschreibt der grundlegendeNutzen den Mehrwert, der durch die Bereitstellungder Funktion geschaffen werden soll. Erst durch dieAngabe des Nutzens wird eine User Story wertvoll,denn dies liefert den wichtigen Kontext, der demTeam bei der Entwicklung von Lösungen zurErfüllung echter Benutzeranforderungen hilft.Der Nutzen ist auch entscheidend für die agileSoftwareentwicklung, bei der es um die Schaffungvon Mehrwert geht. Der Nutzen steht imMittelpunkt und hilft dem Product Owner bei derFestlegung von Prioritäten. Wenn Sie den Nutzeneiner Story nicht finden können, bietet diese Storymöglicherweise keinen Mehrwert.VorlageDie Vorlage für User Stories soll Product Ownersund anderen helfen, User Stories mit eindeutigemUser, Inhalt und Nutzen zu erstellen. Die Vorlagedient nur als Richtlinie. Das Wichtigste ist, dassbei der Erstellung alle drei Elemente einbezogenwerden.• Als registrierter Benutzer möchte ich meinPasswort zurücksetzen, damit ich mich wiederauf der Website anmelden kann, wenn ich meinPasswort vergessen habe.• Als unregistrierter Benutzer möchte ich michauf der Website registrieren können, damitInhalte angezeigt werden, die auf michabgestimmt sind.• Ich, Thomas, möchte, dass nur Updates vonguten Freunden angezeigt werden, damit ichmir relevante Updates ansehen kann, währendich online bin.www.rallydev.com©2013 Rally Software Development1

Andere VorlageBei manchen Stories sind mehr als ein Userbetroffen. In diesen Fällen können mehrere User/Nutzen-Kombinationen angegeben werden.Inhalt: Es soll nachverfolgt werden, welcheProdukte sich registrierte Kunden angesehenhaben.User: Registrierte KundenNutzen: Damit ich Produkte, die ich mir schoneinmal angesehen habe, einfach wieder aufrufen(und kaufen) kann.User: Marketing-AbteilungNutzen: Damit wir Anzeigen schalten können,die auf die Interessen der einzelnen registriertenKunden abgestimmt sind.Erste SchritteZu Beginn wird eine einfache Aussage im Formateiner User Story verfasst. Dies reicht aber nochnicht aus. Das Team benötigt mehr Informationen.Deshalb wird die User Story in drei Schrittenerarbeitet: Karteikarte, Gespräch und Bestätigung.KarteikarteDie Karteikarte dient hier als Metapher (wobei oftauch wirklich eine Karteikarte verwendet wird),denn es soll auf kleinem Raum kurz und bündig einÜberblick über User, Inhalt und Nutzen der UserStory präsentiert werden. Dies hilft unter anderemauch bei der Einordnung der Story in den Backlog.Wie auf einer Karteikarte wird die allgemeineAussage kurz notiert, die dann als Ausgangspunktfür ein Gespräch dient.„Als registrierter Benutzer möchte ichmein Passwort zurücksetzen, damit ichmich wieder auf der Website anmeldenkann, wenn ich mein Passwortvergessen habe.“GesprächDer Karteikartentext dient als Grundlage für einGespräch zwischen dem Product Owner bzw.Kunden und dem Delivery Team. In dem Gesprächeinigen sich der Product Owner und das DeliveryTeam auf Ziele für die Funktionen undentsprechende Einschränkungen. Oft werdendabei vom Delivery Team Fragen gestellt.In unserem Passwort-Beispiel könnten folgendeFragen gestellt werden:• Welche Authentifizierung benötigen wir?• Welche Daten benötigen wir vom Benutzer?• Gibt es verschiedene Arten von Benutzern,an die wir denken müssen?Es ist hilfreich, wenn das gesamte Team an diesenGesprächen teilnimmt. Jedes Teammitglied hatnämlich seine eigenen Aufgaben und Ansichten,die verschiedene Fragen und Probleme aufwerfen.BestätigungDie Ergebnisse des Gesprächs sollten alsAkzeptanzkriterien festgehalten werden. Einegut definierte User Story lässt sich überprüfen.Denn wie kann sich der Product Owner sonstvergewissern, dass die Story korrekt umgesetztwurde?Akzeptanzkriterien sind die Voraussetzungenfür die Zufriedenheit des Benutzers. Die ProductOwners und das Delivery Team erstellen dieAkzeptanzkriterien gemeinsam und räumen alleMehrdeutigkeiten in der User Story aus. Fürgewöhnlich sind allgemeine Aussagen geeignet.Sie sollten in Akzeptanztests umgewandelt werden,wenn die Umsetzung der Story beginnt.Mögliche Akzeptanzkriterien für unsere Passwort-Story sind:• Es sind Benutzername, Passwort und E-Mail-Adresse erforderlich. Es kann ein Displaynameerstellt werden, aber dies ist optional.• Das Passwort kann 6 bis 200 Zeichen enthalten.• Passwörter sollten verschlüsselt gespeichertund nicht entschlüsselt werden können.www.rallydev.com©2013 Rally Software Development2