User Storys mit Beispielen und Vorlage

Zusammenfassung: Eine User Story ist eine informelle, allgemeine Erklärung eines Software-Features, die aus der Sicht des Endbenutzers verfasst wurde. Ihr Zweck ist es, zu zeigen, welchen Wert ein Software-Feature für einen Kunden hat.

Man könnte meinen, User Storys seien, einfach gesagt, Software-Systemanforderungen. Doch das stimmt nicht.

Ein wichtiger Punkt bei der agilen Softwareentwicklung lautet: Menschen an erster Stelle. Und bei User Storys stehen die Endbenutzer im Mittelpunkt. Dabei wird ohne Fachsprache Kontext für das Entwicklerteam und seine Arbeit bereitgestellt. Wenn ein Team eine User Story gelesen hat, weiß es, warum es etwas entwickelt und welchen Wert es damit schafft.

User Storys zählen zu den wichtigsten Aspekten agiler Programme. Mit ihnen kann ein benutzerorientierter Rahmen für die tägliche Arbeit geschaffen werden – und der fördert die Zusammenarbeit, die Kreativität und ein besseres Gesamtprodukt.

Eine User Story ist die kleinste Arbeitseinheit in einem agilen Framework. Es stellt kein Feature dar, sondern ein Endziel aus der Perspektive des Softwarebenutzers.

Eine User Story ist eine informelle, allgemeine Erklärung eines Software-Features, die aus der Sicht des Endbenutzers verfasst wurde.

Der Zweck einer User Story ist es, zu formulieren, wie eine einzelne Aufgabe dem Kunden einen bestimmten Wert liefert. "Kunde" muss hier nicht der externe Endbenutzer im herkömmlichen Sinn sein. Es kann sich auch um interne Kunden oder Kollegen in deinem Unternehmen handeln, die von deinem Team abhängig sind.

User Storys werden mit einigen Sätzen in einfacher Sprache verfasst, in denen das gewünschte Ergebnis beschrieben ist, ohne ins Detail zu gehen. Anforderungen werden vom Team besprochen und anschließend ergänzt.

Storys lassen sich problemlos in agilen Frameworks wie Scrum und Kanban anwenden. In Scrum werden User Storys zu Sprints hinzugefügt und im Verlauf des Sprints "abgearbeitet". Kanban-Teams ziehen User Storys in ihren Backlog und durchlaufen sie in ihrem Workflow. Durch User Storys verbessern Scrum-Teams ihre Schätzungen und ihre Sprint-Planung und erreichen dadurch präzisere Prognosen und höhere Agilität. Kanban-Teams lernen mithilfe von User Storys, wie sie laufende Aufgaben (Work-in-Progress, WIP) steuern können, und können ihre Workflows weiter optimieren.

User Storys sind außerdem die Bausteine größerer agiler Frameworks wie Epics und Initiativen. Epics sind umfangreiche Aufgabenelemente, die in mehrere Storys aufgeteilt sind. Mehrere Epics bilden eine Initiative. Diese größeren Strukturen sorgen dafür, dass die tägliche Arbeit des Entwicklungsteams (an Storys) einen Beitrag zu den Unternehmenszielen leistet, die in Epics und Initiativen berücksichtigt sind.

Mehr zu Epics und Initiativen

Für Entwicklerteams, die mit Agile noch nicht vertraut sind, wirken User Storys manchmal wie ein zusätzlicher Schritt. Warum nicht gleich das große Projekt (oder Epic) in mehrere Schritte unterteilen und damit weitermachen? User Storys vermitteln Teams jedoch wichtigen Kontext und damit verbundene Aufgaben und verdeutlichen zudem den Wert dieser Aufgaben.

User Storys bieten viele entscheidende Vorteile:

• Dank User Storys bleibt der Benutzer im Fokus. Mit einer To-do-Liste behält das Team die zu erledigenden Aufgaben im Blick, aber mit einer Reihe von User Storys konzentriert sich das Team darauf, die Probleme echter Benutzer zu lösen.
  
• User Storys ermöglichen Zusammenarbeit. Wenn ein Endziel festgelegt ist, kann das Team an einem Strang ziehen und entscheiden, auf welchem Weg es dem Benutzer am besten gerecht wird und das Ziel erreicht.
  
• User Storys fördern kreative Lösungen. User Storys animieren das Team, kritisch und kreativ über die beste Lösung für ein Endziel nachzudenken.
  
• User Storys sorgen für neuen Schwung. Nach jeder User Story hat das Entwicklerteam eine kleine Herausforderung gemeistert und kann einen kleinen Erfolg feiern – und das bringt Schwung in die Sache.

See how user stories work in Jira

Sobald eine User Story erstellt ist, muss sie in deinen Workflow integriert werden. In der Regel wird sie vom Produktinhaber, Produktmanager oder Programmmanager verfasst und anschließend überprüft.

Während eines Meetings zur Sprint- oder Iterationsplanung legt das Team fest, welche Storys es im aktuellen Sprint in Angriff nimmt. Dabei bespricht es die Anforderungen der jeweiligen User Storys und die nötigen Funktionen, die sich daraus ableiten. Bei der Umsetzung der Story hat das Team Gelegenheit, fachliche und kreative Ideen einzubringen. Sobald es sich über diese Anforderungen geeinigt hat, werden sie der Story hinzugefügt.

Ein weiterer wichtiger Schritt in diesem Meeting ist das Bewerten der User Storys mit Punkten, abhängig von ihrer Komplexität oder dem erforderlichen Aufwand. Um korrekte Schätzungen anzugeben, verwenden manche Teams T-Shirt-Größen oder die Fibonacci-Folge, andere wiederum spielen Planning Poker. Eine Story sollte innerhalb eines Sprints zu bewältigen sein. Bei der Zusammenstellung einer User Story stellt ein Team also sicher, dass zu umfangreiche Storys aufgeteilt werden.

Beim Verfassen von User Storys solltest du Folgendes berücksichtigen:

• Was bedeutet "erledigt"? Im Allgemeinen ist eine Story "erledigt", wenn der Benutzer die beschriebene Aufgabe ausführen kann. Wie das genau aussieht, solltet ihr unbedingt definieren.
  
• Unteraufgaben und Aufgaben festlegen: Besprecht, welche Schritte im Einzelnen abzuschließen sind und wer jeweils dafür verantwortlich ist.
  
• Benutzertypen: Wer ist der Benutzer? Gibt es unterschiedliche Endbenutzer, könnte es sinnvoll sein, mehrere Storys anzulegen.
  
• In Schritte unterteilen: Verfasst für jeden Schritt des Prozesses eine Story.
  
• Feedback berücksichtigen: Sprich mit deinen Benutzern und gib das Problem oder die Anforderung in ihren Worten wieder. Du brauchst dir keine Storys auszudenken, wenn deine Kunden sie dir liefern.
  
• Zeit: Zeit ist ein heikles Thema. Viele Entwicklerteams reden überhaupt nicht darüber und verlassen sich stattdessen auf ihre Schätzungen. Da Storys innerhalb eines Sprints abgeschlossen sein sollten, empfiehlt es sich, Storys, die wochen- und monatelange Arbeit erfordern, in kleinere Storys zu unterteilen oder selbst zum Epic zu erklären.
  

Wenn die User Storys genau festgelegt sind, sorge dafür, dass sie für das gesamte Team zugänglich sind.

User Storys werden oft als einfacher Satz formuliert und sind wie folgt aufgebaut:

"Als [Kundentyp] [möchte] ich, [damit]."

Sehen wir uns das im Einzelnen an:

• "Als [Kundentyp]": Für wen entwickeln wir? Wir begnügen uns nicht mit einem Berufstitel, sondern bemühen uns um den Kundentyp der Person: Max. Unser Team sollte ein gemeinsames Verständnis von Max haben. Wir haben hoffentlich viele Maxe interviewt und können nachvollziehen, wie diese Person tickt, wie sie denkt und fühlt. Wir können uns in Max hineinversetzen.
• "Möchte": Damit beschreiben wir die Absicht – und nicht die Funktionen, die der Benutzer verwendet. Welchen Zweck möchte der Kunde eigentlich erreichen? Bei dieser Aussage geht es nicht um die Umsetzung: Wenn du einen Teil der UI beschreibst, statt das Benutzerziel zu erläutern, hast du den Sinn verfehlt.
• "Damit": Wie passt der unmittelbare Wunsch des Kunden, etwas tun zu können, in sein Gesamtbild? Von welchem Nutzen möchte er allgemein gesehen profitieren? Welches große Problem muss hier gelöst werden?

User Storys könnten beispielsweise so aussehen:

• Als Max möchte ich meine Freunde einladen, damit wir diesen Service gemeinsam nutzen können.
• Als Sascha möchte ich meine Arbeit organisieren, damit ich mehr Kontrolle darüber habe.
• Als Manager möchte ich die Fortschritte meiner Kollegen nachvollziehen können, damit ich über unsere Erfolge und Fehlschläge besser berichten kann.

Du musst diese Struktur nicht übernehmen, aber sie hilft dir, zu definieren, wann eure Arbeit erledigt ist. Wenn der gewünschte Nutzen dieses Kundentyps klar ist, ist die Story vollständig. Wir empfehlen Teams, ihre eigene Struktur festzulegen und einzuhalten.

User Storys beschreiben die Hintergründe und Details der täglichen Arbeit des Entwicklerteams. Man spricht dabei oft von Kundentyp + Anforderung + Zweck. Entscheidend für einen reibungslosen Ablauf ist zum einen, zu verstehen, dass jeder dieser Aspekte für die Bereitstellungen deines Teams eine Informationsquelle darstellt, und zum anderen, auch die Gründe dafür zu kennen.

Beginne damit, das nächste, dringendste Großprojekt (z. B. ein Epic) zu bewerten. Teile es in kleinere User Storys auf und verbessere es gemeinsam mit dem Entwicklerteam. Sobald deine Storys für das gesamte Team einsehbar sind, kannst du dich ans Werk machen.