Kundenzentriertheit ist in der Produktentwicklung zum erfolgversprechenden Buzzword geworden. Auch in der agilen Softwareentwicklung wird dieses Vorgehen in den Fokus gerückt. Mithilfe sogenannter User Stories werden die Wünsche und Anforderungen der Kunden direkt in den Entwicklungsprozess überführt.
In diesem Beitrag erfahren Sie, was es mit der User Story auf sich hat und wie Sie diese gekonnt in Ihre Produktentwicklung einbinden können.
Was ist eine User Story?
Eine User Story erzählt das Produkterlebnis aus Sicht des Anwenders. Sie beschreibt in einfachen Worten, welchen Nutzen sich der Anwender mit welchem Ziel vom Produkt wünscht.
Neben den Kundenanforderungen können jedoch auch Bedürfnisse der Entwickler oder Designer in einer User Story festgehalten werden. Sie bietet somit einen Leitfaden für das, was realisiert werden soll und auch das, was tatsächlich realisierbar ist.
Die User Story sollte dabei stets kurz gehalten werden und einfach formuliert sein. Ist sie bereits sehr detailliert definiert, kann das Projektteam unter Umständen nicht agil genug arbeiten. Dennoch sollte die User Story präzise wiedergeben, welche Anforderung gestellt werden. Denn sie ist in der Produktentwicklung ein wichtiges Kommunikationsmittel.
Jede User Story wird auf einer sogenannten Story Card festgehalten. Story Cards können sowohl händisch auf einem Notizzettel oder einem Whiteboard oder aber mit entsprechenden Softwaretools visualisiert werden. Im User-Story-Mapping werden die einzelnen Stories dann geordnet und priorisiert.
Sprint-Planung mithilfe von User Story: Scrum als Anwendungsbeispiel
Vor allem in der agilen Softwareentwicklung werden User Stories verwendet — wie beispielsweise in Scrum, Kanban oder im „Extreme Programming“. Sie bilden hier die kleinste Einheit innerhalb der agilen Methode.
In Scrum werden die User Stories einzelnen Sprints zugeordnet und innerhalb dieser Sprints bearbeitet. User Stories befinden sich in Scrum im sogenannten „Product Backlog“, also dem Bereich, in dem Produktoptimierungen festgehalten und definiert werden.
Die Sprint-Planung kann mithilfe der User Story besser umgesetzt und auch abgeschätzt werden. Die User Stories werden nämlich in kleinere, einzelne Aufgaben zerlegt und anschließend an die Teammitglieder verteilt. Ist eine User Story zu komplex, wird sie als „Epic“ bezeichnet. „Epics“ müssen in ihrer Komplexität reduziert werden, da sie nicht in einen Sprint passen.
User Stories definieren und messen
Idealerweise haben User Stories innerhalb eines Projektes immer dieselbe Struktur, denn so können sie innerhalb eines Sprints zügig bearbeitet werden — ohne dass Verständnisschwierigkeiten auftreten. Versteht der Product Owner die Story Card nämlich nicht, muss das Ticket eventuell zurückgestellt werden, was zu einer Zeitverzögerung führt.
Eine einheitliche Struktur sorgt dafür, dass alle Projektteilnehmer direkt wissen, welche Anforderung in einer User Story gestellt wird. Besonders häufig wird dafür die folgende Satzstruktur verwendet:
Als „Anwender“ möchte ich „Funktion“, um damit „Nutzen“ zu erzielen.
Es geht also darum, zu klären, wer sich was und warum vom Produkt wünscht. Anschließend können noch Akzeptanzkriterien definiert werden. Sie beschreiben genauer, wie die gewünschte Funktion zu testen ist und wann sie als erfüllt gilt. Akzeptanzkriterien können als Aussagen oder mithilfe von W-Fragen formuliert werden.
Der Product Owner ist dafür verantwortlich, dass die User Stories priorisiert und analysiert werden. Doch für Ideen zu den einzelnen Anforderungen können und sollten Kunden, Mitarbeiter und natürlich auch die Projektbeteiligten mit einbezogen werden.
Möchte Kunde XY beispielsweise eine bestimmte Funktion in der Navigation aufgeführt haben, muss dies mit dem UX-Design abgesprochen und technisch sowie grafisch realisiert werden.
User Stories sind also ein guter Ausgangspunkt, um innerhalb des Produktteams zu entscheiden, welche Anforderungen möglich sind und welche eventuell auch nicht.
Gemessen werden können die User Stories dabei nach der INVEST-Checkliste von Bill Wake. Das Akronym „INVEST“ bezeichnet dabei die folgenden Kriterien:
Independent:
Die User Story ist unabhängig von einer anderen User Story.
Negotiable:
Die User Story ist verhandlungsfähig und nicht auf eine Funktion versteift.
Valuable:
Die User Story bietet einen klaren Mehrwert für den Nutzer. Dieser ist direkt erkennbar.
Estimable:
Der Aufwand der User Story kann durch den Entwickler eingeschätzt werden.
Small:
Die User Story ist präzise, aber kurz und knapp, sodass sie in einem Sprint bearbeitet werden kann.
Testable:
Die Anforderung kann mithilfe von Akzeptanzkriterien geprüft werden.
Komplexitätsreduzierung durch die User Story: Beispiel
Eine einfache Struktur und Formulierung der User Story trägt dazu bei, dass direkt verstanden wird, welche Anforderung der Nutzer an das Produkt oder die Dienstleistung stellt. Für die Story Card können Sie die obige Satzstruktur verwenden.
Selbstverständlich können Sie die Formulierung auch abwandeln. Achten Sie jedoch unbedingt darauf, dass die W-Fragen (Wer, Was, Warum) beantwortet werden, um die User Story genau zu spezifizieren.
Beispiel: Als „Kunde XY“ wünsche ich mir „eine Kalenderansicht im Content-Marketing-Tool“, um „eine Übersicht der geplanten Redaktionsinhalte“ zu bekommen.
Um die User Story testfähig zu machen, empfiehlt es sich außerdem, Akzeptanzkriterien zu formulieren. Für das obige Beispiel könnten diese wie folgt lauten:
-
Akzeptanzkriterium 1: Hat die User Story eine Kalenderübersicht?
-
Akzeptanzkriterium 2: Sehe ich geplante Redaktionsinhalte in der Kalenderübersicht?
Wurde die User Story im Sprint bearbeitet, lässt sich anhand der Akzeptanzkriterien feststellen, ob die Umsetzung wie gewünscht erfolgt ist.
Beispiel einer Story Card in Trello, Quelle: https://trello.com/
User-Story-Mapping: Die richtigen Tools verwenden
Mithilfe von User-Story-Mapping werden alle User Stories in eine visuelle Übersicht gebracht. Die Aufgaben werden dabei oftmals spaltenweise nach verschiedenen Tätigkeiten sortiert. Die User Stories werden dann unter der jeweiligen Spalte zeilenweise priorisiert.
Beispiel einer User-Story-Map in Trello, Quelle: https://trello.com/
Sie können das User-Story-Mapping auf verschiedenen Wegen umsetzen. Am einfachsten lässt sich der Workflow jedoch mit einem entsprechenden Softwaretool abbilden — so hat jedes Teammitglied jederzeit Zugriff auf die Darstellung.
Die User-Story-Map ist damit eine wichtige Kommunikationsgrundlage für das Produktteam und gibt Aufschluss über derzeitige und kommende Sprints.
Mögliche Tools, um User Stories zu erstellen, zu sortieren und zu priorisieren, sind:
Die User Story sorgt in der agilen Softwareentwicklung dafür, dass der Nutzer stets im Zentrum der Produktentwicklung steht, da die Kundenanforderungen direkt in den Sprint-Prozess überführt werden.
Dazu werden die User Stories kurz und präzise ausformuliert und an den Projektmaster weitergegeben. Akzeptanzkriterien helfen zusätzlich dabei, das Produkt hinsichtlich der User Story auf seine Funktionalität zu testen.
Titelbild: fabrycs / Getty Images
