User Story: Funktionalität aus Sicht des Anwenders agil perfektionieren – so geht’s in Scrum!

Von Sebastian Schneider // 10.10.2020 // 0 Kommentare

Die User Story ist eine gängige agile Praktik. Sie erlaubt es dir erlaubt Anforderungen aus Sicht des Anwenders zu beschreiben. Die Benutzergeschichten sind populär und werden in vielen Scrum Teams angewendet. In anderen agilen Methoden wird dieses Artefakt ebenso benutzt.

Die Historie der reicht weit zurück. User Storys kommen aus dem Kontext des Extreme Programming um das Jahr 1998. Du kannst diese aber auch außerhalb der Softwareentwicklung verwenden. Das schöne an diesem Artefakt ist: es ist nicht zu detailliert und der Aufwand einer User Story hält sich in Grenzen. Im Artikel spreche ich teilweise auch von Product Backlog Item bzw. PBI.

Ich zeige dir in diesem Artikel, wie du sie schreibst, auf was du achten musst und welche Feinheiten es gibt, damit du diese perfektionieren kannst!

Click to play


Inhaltsverzeichnis

Historie

Die Historie der User Story geht weit zurück. User Stories kommen aus dem Kontext des Extreme Programming um das Jahr 1998 rum.

Aufbau einer User Story

Viele Entwicklungsteams haben das folgende Format bereits angewendet.

Die drei C's einer User Story

User Stories bestehen aus drei Komponenten, die zusammen das Artefakt der User Story ausmachen.

Card

Die "Story Card" kennst du bestimmt als Form bestimmt am ehesten, wenn du an eine User Story denkst. Denn das ist schließlich das Artefakt, mit dem du in Berührung kommst. Diese Sicht des Anwenders ist die geschriebene Karte bzw. die Abbildung in einem elektronischen Tool.

Conversation

Communication ist ein wichtiger Bestandteil, es geht dabei um das eingangs erwähnte Kommunikationsversprechen. Sie ist verhandelbar und es darf und soll darüber gesprochen werden. Zudem soll die User Story auch den Austausch darüber fördern.

Confirmation

Wir wollen erkennen, wann wir fertig sind. Wann ist der Wunsch umgesetzt? Die User Story definiert dafür Akzeptanzkriterien, anhand derer wir das erkennen können.

Lösung und Zielorientierung

Ein spannender Punkt, den du bei vielen Teams findet und auf den du unbedingt mal achten solltest: sind deine Product Backlog Items und damit die Anforderungen zielorientiert oder lösungsorientiert?

Eine Entscheidung über die richtige oder falsche Verwendung einer der beiden Varianten kannst du nur für deinen Kontext fällen. Du nutzt immer eine der beiden Varianten bei der Formulierung der User Story. Und es hängt von deiner Umgebung ab. Machen wir ein Beispiel:

Zielorientierung bei einer User Story

Als Verkehrsteilnehmer möchte ich schnell von A nach B gelangen, um eine möglichst wenig Zeit zu verlieren.

Lösungsorientierung bei einer User Story

Als Autofahrer möchte ich mit dem Auto von A nach B gelangen, um meinen Zielort zu erreichen.

Natürlich wirst du nun argumentieren, dass die Rollen unterschiedlich sind und es vielleicht ja auch in deinem Kontext total klar ist, dass der Autofahrer von A nach B mit dem Auto gelangen soll und nicht mit dem Dreirad. Absolut klar und logisch für mich - darum geht es mir hier an der ersten Stelle gar nicht. Ich möchte einfach nur Bewusstseins schaffen für:

  • Wenn du eine Vielzahl an lösungsorientierte PBI's geschrieben hast prüfe, ob du tatsächlich in einem komplexen Umfeld tätig bist (z.B. mit der Stacey Matrix)
  • Bei der Lösungsorientierung - prüfe unbedingt, ob du auf das richtige fokussierst. Das Auto ist schnell genannt, ist es aber wirklich richtig diese Einschränkung hier zu tun?
  • Je früher du in deinem Produkt stehst, desto mehr müssten sich die User Stories auf ein Ziel fokussieren. Später im Verlauf oder auch bei der "Instandhaltung" werden diese User Stories oft eher lösungsorientiert sein (können).
  • Prüfe mal bei deiner Lösungsorientierung, ob du zu Gründen kommst, die oft inhärent schon klar sind und dir nichts weiter über die Absicht deiner Rolle verraten

Befolgen der INVEST Kriterien

Mit dem Akronym INVEST (oder auch INVEST-Prinzip) steht dir eine wertvolle Checkliste zur Verfügung. User Storys sollten sich an dieser Guideline orientieren, damit sie für alle Stakeholder schnell Wert schaffen können.

Independent

Starten wir mit dem Buchstaben I. Independent bedeutet, dass die User Story unabhängig von anderen sein soll. Du wirst mit Sicherheit den Fall entdecken, dass du eine Story vor der anderen machen musst. Vermeide sie aber so zu schreiben, dass du zum Beispiel vier User Stories umsetzen musst, um überhaupt einen Wert zu erzeugen. Treten Probleme auf (z.B. eine wird nicht erfolgreich erstellt), läufst du Gefahr, innerhalb deiner Iteration gar nichts liefern zu können.

Negotiable

Negotiable bedeutet, dass die User Story immer verhandelbar sein muss. Sie ist also nie so ausspezifiziert, dass diese einmal festgelegt wird und dann in die Umsetzung kommt. Die Beschreibung ist bewusst so gewählt, dass schnell und kostengünstig neu über den Inhalt verhandelt werden und dieser schnell neu geschrieben werden kann. Während diese im Product Backlog vorhanden ist, besteht laufend die Möglichkeit diese zu verändern. Zu umfangreich sollte diese Beschreibung nicht sein. So vermeiden sie Missverständnisse durch fehlende Konversationen.

Value

Value bedeutet, dass wir mit ihr immer einen Mehrwert erzeugen wollen. Sie darf also nicht Mittel zum Zweck sein, sondern liefert einen (in sich abgeschlossenen) Mehrwert. Das hilft auch für die Bildung des Inkrements, welches am Ende des Sprints zur Verfügung stehen muss.

Estimation

Estimated bedeutet, dass die User Story eine Schätzung benötigt. Auch wenn sich die Story Points vielerorts durchgesetzt haben, sind diese nach dem Scrum Guide keine Pflicht.

Size

Size bedeutet, dass die User Story die richtige Größe besitzen muss. Passt die Story vollständig in eine Iteration?. Alles was innerhalb eines Sprints nicht geleistet werden kann, gehört in die Kategorie eines Epic. Und muss in kleinere User Storys zerteilt und verfeinert werden. Das tust du üblicherweise im Refinement.

Test

Eine gute User Story ist von einem Tester, Endanwender oder Stakeholdern testbar. Dazu gibt es in der Regel Akzeptanzkriterien aus Benutzersicht, damit ein Testen auch möglich ist. Zudem kann der Product Owner so seine Erwartungshaltung an diese User Story ausdrücken.

Zusammenfassung für die INVEST Kriterien einer User Story

Du hast eben also die sogenannten INVEST Kriterien kennengelernt. Betrachtest du sie noch etwas genauer, dann wirst du erkennen, dass dort bereits viel für agile, interative und inkrementelle Entwicklung als Grundstein gelegt ist. Deswegen wird sie absolut gerne in der agilen Softwareentwicklung verwendet.

Vergleich Product Backlog Items und User Story

In diesem Abschnitt möchte ich zum Abschuss noch einmal den Fokus auf den Scrum Guide legen, der Product Backlog Items beschreibt und dann die agile Praktik der User Story, die nicht im Scrum Guide steht.

Ein Product Backlog Item muss keine User Story sein!

Wenn du User Stories in deinem Product Backlog nutzt, dann sind das deine Product Backlog Items. Aber ein Product Backlog Item, muss keine User Story sein. Schauen wir uns dazu kurz den Vergleich einmal genauer an.

Product Backlog Item
  • Hat eine Beschreibung
  • besitzt eine entsprechende Position im Backlog (Reihenfolge)
  • Ist geschätzt
  • stellt einen Wert dar
User Story
  • hat ein entsprechende Format für die Beschreibung
  • besteht aus der Karte selbst, einem Gespräch und Akzeptanzkriterien
  • Orientiert sich an Akronym INVEST

Abgrenzung zu Epics

Oben bei dem Size aus dem Invest Kriterium habe ich Epics bereits einmal kurz erwähnt. Dieser Begriff wird oft unterschiedlich verstanden. Zum einen ist erstmal alles, was größer ist als eine User Story ein Epic. Das war es im Grunde auch schon. Epics werden allerdings auch in Tools und anderen Frameworks als andere Typ aufgefasst. Also alle Anforderungen, die größer und vielleicht auch abstrakter sind, werden dann als eigener Typ geführt, der letztendlich auch wieder herunter gebrochen wird.

Der Ablauf der Erstellung aus User Story Sicht

In diesem Abschnitt zeige ich dir, wie der Lebensweg und die Umsetzung der User Story in der Regel ist. Dabei gehen wir einen exemplarischen Ablauf durch und betrachten diesen aus Sicht des Prozesses und der User Story.

Die Erstellung einer User Story: Das Product Backlog

Das Verfassen von User Story geschieht meist sehr nah am oder gleich im Product Backlog. und das meistens bei einer der beiden Aktionen:

  • Eine Person nimmt Stift und Zettel in die Hand und beginnt zu schreiben. Das kann gleich im vorgestellten Format geschehen. Damit ist sie am Leben und geht den weiteren Weg.
  • Durch ein paar Tastenhiebe und dem Aufrufen eines Tools bekommst du das digitale Leben eingehaucht, da jemand kräftig in die Tasten gehauen hat und dich User Story auch mit einer bestimmte Form erstellt hat.

Im Product Backlog befindet sich die User Story gemeinsam mit allen anderen bereits erstellen PBI. Und natürlich auch allen denen, die es noch werden wollen. Alle Anforderungen, die das Produkt betreffen, gehen über diese einzige Anforderungsliste. Während des Lebenszyklusses befindet sich die User Story in diesem Product Backlog mit allen anderen Anforderungen.

Product Backlog Refinement

Im Product Backlog Refinement findet die Bearbeitung des Inhalt der User Story statt. Das ist wichtig und elementar für jede Scrum Implementierung. Wenn du das Refinement bei deiner Scrum Einführung nicht richtig berücksichtigst und gut implementierst, fällt es dir spätestens bei einer Scrum Skalierung auf die Füße.

In dieser entwicklungsbegleitenden Tätigkeit unterzieht sich die User Story einiger Bearbeitungszyklen. Und das so lange, bis die User Story von allen Beteiligten verstanden und dann fertig für das Sprint Planning ist. Damit kannst du auch keine Epics in der Planung haben, da diese schlicht die falsche Größe besitzen.

Die Beschreibung

Innerhalb des Product Backlog Refinements finden häufiger Anpassungen in der Beschreibung der PBI's statt. Das ist meistens dann der Fall, wenn...

  • ... der Eintrag noch eher ein Stichpunkt oder EPIC ist.
  • ... es Änderungen an einzelne Parameter (wie zum Beispiel der Rolle) sich ändern.
  • ... ein Parameter (zum Beispiel der Grund) noch nicht existierte oder nun einfach verfeinert wird.
  • ...

Die Größe

Im Refinement wird die User Story entweder initial oder neu geschätzt. Je länger sie in deinem Backlog liegt, desto höher ist auch die Wahrscheinlichkeit, dass du diese erneut betrachten und schätzen musst.

Die Akzeptanzkriterien

Die Akzeptanzkriterien drücken aus, was passieren muss, damit ein Product Owner diese Stories abnehmen kann. Sie zu formulieren und zu diskutieren wird durch Entwickler und Product Owner geleistet. Sie ergänzen sich sehr gut zum Rest des PBI und helfen Klarheit zu schaffen.

Wie die gewünschte Funktionalität durch Entwickler in einer Iteration umgesetzt wird, ist für eine User Story unerheblich. Details des zu entwickelnden Systems werden besser vermieden.

Die Sprint Planung

In der Sprint Planung geht es darum, dass die User Stories für den kommenden Sprint geplant werden. Hier wird es also für die Stories spannend, denn sie sind dann sehr weit oben im Backlog und haben einen Chance bald dran zukommen.

Teil 1

Im ersten Teil der Sprint Planung steht die User Story noch nicht direkt im Fokus. Es geht darum, warum der Sprint wichtig ist. Wir betrachten und beschreiben dazu ein Produkt Ziel. Das Produkt Ziel gibt aber die Priorisierung vor und hat damit natürlich auch Einfluss auf den Inhalt. Es verhindert damit auch Missverständnisse bei der Priorisierung.

Teil 2

Innerhalb des Backlogs befinden sich in Form der User Story die Anforderungen. Im zweiten Teil der Sprint Planung geht es nun um den Aufwand hinter einer User Story, damit die Entwickler erkennen können, wie viele sie in dem kommenden Sprint umsetzen können. Die Frage ist also immer "was" bzw. "wie viel" können wir voraussichtlich davon schaffen, um die gewünschte Funktionalität zu erreichen.

Teil 3

Im dritten Teil der Sprint Planung geht es oft um den technischen Aufwand hinter einer User Story. Du möchtest als Entwickler den technischen Hintergrund verstehen. Die User Story dokumentiert wie beschrieben das "was". Das haben die Entwickler im Backlog Refinement verstanden. Durch das Sprint Plannung Thema 2 wissen sie in etwa, wie viele sie schaffen und schauen nun genauer rein.

Das Daily Scrum

Im Daily Scrum steht die User Story nicht so in dem Mittelpunkt, sondern mehre ihre "Kinder". Hier legst du in der Regel den Fokus auf die Tasks, die sich das Entwicklungsteam zur Erledigung der User Story erstellt hat. Natürlich darf auch hier stolz berichtet werden, wenn bereits eine ganze User Story bearbeitet worden ist und nun bereits fertig gestellt ist.

Das Sprint Review

Im Sprint Review ist dann der große Auftritt der User Story. Sie darf nämlich vorgestellt werden, wenn sie fertig ist. Ist der Auftritt dann rum, wird es danach auch still um die User Story. Hier kannst du dir das "Conversation und Confirmation" ins Gedächtnis rufen.

Die Sprint Retrospektive

In der Sprint Retrospektive darf die User Story nur noch dann kurz ihr Antlitz zeigen, wenn sie Modell für eine Situation steht, die im Team betrachtet werden werden muss. In der Regel wird die User Story aber nicht mehr auftauchen.

Abhängigkeiten von User Stories

YouTube Video zu den Abhängigkeiten

Was mache ich mit Abhängigen User Stories? Diese Frage wird oft gestellt und auch hier habe ich auf meinem YouTube Kanal bereits ein Video dazu veröffentlicht. Schau es dir doch am besten mal an!

Chronologische Abhängigkeiten

Chronologische Abhängigkeiten sind im Grunde nicht schlimm. Sie treten dadurch auf, dass du irgendwann ein Inkrement entwickelt und eine bestimmte Funktonalität umgesetzt hast.

Wenn du im dritten Inkrement bist, dann ist klar, dass eine Funktionalität aus diesem Inkrement auf dem ersten und zweiten Inkrement aufbaut. So etwas meine ich mit chronologischer Abhängigkeit.

Wenn du das Cross-Refinement Board aus dem Nexus Framework kennst, dann ist das praktisch genau so etwas.

Inner-Sprint Abhängigkeiten

Wenn du User Stories im Sprint hast, die von einander abhängig sind, dann ist das nicht schön, mit der richtigen Betrachtung in der Sprint Planung kannst du dem aber entgegen wirken und gut planen. Wenn nichts unvorhergesehenes passiert, dann ist das in der Regel kein Problem.

Zusammengesetze Abhängigkeiten

Die Zusammengesetzten Abhängigkeiten wollen wir nicht. Das ist immer dann der Fall, wenn du eine Story als "Architektur" Story, als "Design" Story oder auch gerne als "Test" Story deklariert wird. Denn dann hast du nur noch eine Aneinanderreihung von User Stories, die im Grunde ein wassserfallartiges Vorgehen bedeuten.

Schätzen der User Stories

In den INVEST Kriterien haben wir schon gesehen, dass das E für Estimation steht. Die User Story (wie auch das Product Backlog Item) soll also geschätzt sein. Gesagt, getan, aber wie machen wir das nun konkret?

Aufwand

Eine Möglichkeit die User Stories zu schätzen ist der Aufwand. Das kennen wir, denn seit eh und je schätzen wir Menschen oft in Aufwand. Der Aufwand hat in der Regel einen großen Nachteil, wenn es um die Teamarbeit geht. Der Aufwand ist immer personenabhängig. Schätzt Peter, der 30 Jahre Berufserfahrung hat und die Aufgabe genau kennt, dann ist die Schätzung in Stundenanzahl sehr klein. Schätze ich die gleiche Aufgabe, die ich noch nie gesehen habe, geht meine Schätzung in die Tage hinein. Was machen wir nun, wenn wir im Team arbeiten? Ist der Aufwand jetzt groß oder klein?

Stunden

Den eben beschriebenen Aufwand können wir in unterschiedlichen Größen messen. Eine dieser Größen sind die allseits bekannten Stunden. Manche machen das auch in anderen Zeiteinheiten, im Grunde ist es egal und führt alles auf ein und das selbe zurück: die gute alte Stunde. 

Idealisierte Manntage

Idealisierte Manntage ist auch eine Größe, die gerne verwendet wird. Im Grunde ist es hier so, dass wir sagen "wenn nichts dazwischen kommt und wir einen Tag Zeit hätten uns nur auf diese Aufgabe zu konzentrieren, dann schaffen wir das". Während ich früher immer der Meinung war, es ist egal womit die Teams schätzen, solange sie die Fibonacci-Reihe nutzen, so stark ändert sich das nun gerade für mich. Idealisierte Manntage ist für mich im Grunde eine Erkenntnis, dass irgendwo etwas vorher nicht mit meiner Einstellung etwas stimmt. Nach und nach habe ich mir die bisherigen Projekte angesehen und kann oft die folgenden Punkte festmachen.

  • Das Team ist gar kein Team und jeder schätzt letztendlich für sich selbst.
  • Es wird nach wie vor kapazitativ und nicht wertorientiert geplant.
  • Ist der genannte Benutzer tatsächlich ein Benutzer im eigentlichen Sinne? Oder finden sich da Bezeichnungen, wie Product Owner oder System als Rolle?
Idealisierte Sprints

Auch die Sprints, die idealisiert betrachtet werden, ist im Grunde nichts anderes als idealisierte Stunden oder Manntage nur eine Ebene höher.

Komplexität

Die Komplexität einer User Story zu schätzen ist etwas komplett anderes, als dessen Aufwand. Tatsächlich bekommen klassische Teams (gerade in großen Unternehmen, die stark vom klassischen Projektmanagement geprägt sind), es so gut wie gar nicht hin, sich vom Aufwand zu lösen. Dort wird dann zwar durchaus die Fibonnaci-Reihe verwendet, allerdings oft ohne Sinn und Verstand.

Referenzwert

Wir Menschen sind recht schlecht im Schätzen von absoluten Werten, können aber Relationen gut schätzen. Ich erinnere mich gerne noch an ein Projekt von lauter Mathematiker und Physiker, die mir alle weiß machen wollten, ich könne niemals deren Aufgaben schätzen. Ich habe die meisten User Stories nur basierend auf dem Referenzwert richtig schätzen können.

Kleiner oder größer?

Das Schöne an Referenzwerten ist, dass wir ziemlich gut schätzen können, ob ein neuer Wert größer oder kleiner ist. Oder eben genauso groß. Wenn wir das wissen, ist in den ersten beiden Fällen nur noch nötig zu entscheiden "wie viel".

Story Points

Die Story Points basieren meisten auf der angepassten Fibonacci-Folge oder aber auch auf einer nicht angepassten. Damit sehen die Werte mal wie folgt aus:

  • Angepasste Fibonacci-Folge: 1,2,3,5,8,13,20,40,100
  • Fibonacci-Folge: 1,2,3,5,8,13,21,34,55,89

Welche du nimmst ist im Grunde egal, es geht nur darum, dass mit zunehmender Größe die Abstände zwischen den Zahlen auch größer werden. Das drückt aus, dass wir mit allem was wir schätzen und was weiter in der Zukunft liegt bzw. größer ist einfach ungenauer werden.

Wie du User Stories schätzen kannst

In meinem Artikel zum agilen Schätzen habe ich dir die entsprechenden Schätzmethoden einmal aufgeführt. Schau doch dort gerne mal vorbei!

Tipps für die Erstellung

User Story

Frage nach dem Benutzer

Wenn du die User Story erstellst, dann frage bitte immer nach dem Benutzer. Das klingt einfach, weil da natürlich <ROLLE> in dem Format der User Story steht. Trotzdem hilft es sich dazu einige Fragen zu stellen.

  • Ist der Benutzer, den du in der Rolle beschrieben hast, wirklich der einzige Benutzer, den es gibt?
  • Wenn der Benutzer nicht da wäre, gäbe es sonst noch jemanden, für den die User Story wertvoll wäre?
  • Ist der genannte Benutzer tatsächlich ein Benutzer im eigentlichen Sinne? Oder finden sich da Bezeichnungen, wie Product Owner oder System als Rolle?
  • ...

Ist der Grund wirklich ein Grund?

Manche User Stories brauchen einfach keinen Grund. Es ist implizit und explizit klar. Viele User Stories haben einen Grund, der nicht passend ist. Frage immer nach dem Grund - ist es wirklich ein Grund? Ist es nur eine Phrase, weil jemand ein bestimmtes Format ausfüllen muss? Ist der Grund implizit schon klar

Suche Beispiele

Du kannst bei der Beschreibung deines Feature auch immer vergleichbare Aufgaben und Beispiele suchen. Wir Menschen tun uns mit der Formulierung oft einfacher, wenn wir existierende Beispiele oder Vergleiche haben.

Spike Storys

Wenn du einmal gar nicht weißt, was du entwickeln kannst und du komplettes Neuland begehen musst, kann es hilfreich sein, mit einem sogenannten Spike zu arbeiten und dafür schriebst du eine Spike Story. Der Unterschied, denn du hier beim User Stories schreiben die Größe (also die Schätzung) gleich mit gibst und damit die Länge begrenzt und auf das erarbeite Wissen setzt. Und letztendlich ist das auch keine andere Form der Schreibweise und du musst dir keine zu großen Gedanken über den Unterschied machen.

Vermeide Technical Storys

User Storys führen Gedanken und Wünsche der Stakeholder zu der Umsetzung durch die Entwickler zusammen. Sie sind also aus Sicht von Kunden zu schreiben. Natürlich hast du auch technische Aufgaben im Produkt zu erledigen. Hier hilft es manchmal sich nicht zu verbiegen und einfach technische Aufgaben als Aufgaben zu lassen.

User Story Vorlage

Die Vorlage für eine User Story ist recht simpel. Meistens brauchst du hier gar keine wirkliche Vorlage, denn im analogen Kontext, kannst du "als <ROLLE> möchte ich <WUNSCH>, um <GRUND>" schnell auf einen Zettel schreiben - da ist der Aufwand größer eine Vorlage zu basteln, als etwas auszudrucken.Wenn du aber etwas weiter gehen möchtest und mehrere Dinge auf so einer User Story Vorlage festhalten möchtest, dann kann ich dir empfehlen, mal meine analoge User Story Vorlage mit den INVEST Kriterien zu prüfen.

Meine PDF Vorlage zum Ausdrucken (analog)

Du kannst dir die User Story PDF Vorlage auch direkt hier herunterladen.

User Story Vorlage (digital)

Wenn du digitale Whiteboards nutzt, dann hilft es dir oft auch in dem Kontext mit Vorlagen und Templates zu arbeiten. Dort kannst du in der Regel so etwas wie digiatle Klebezettel verwenden.

Kopiere dir dann einfach einen Zettel als Vorlage und dann kopierst du ihn dir entsprechend oft.

Nutzt du Tools wie Jira & Co, dann findest du direkt in den Tools in der Regel Vorlagen, die du auch erstellen und verändern kannst. Da fragst du am besten den Administrator, denn je nach Unternehmen gibt es dort die unterschiedlichsten Einschränkungen.

Probleme, die du besser vermeidest

Den Kunden vergessen

Denke immer an den Kunden. Für ihn macht du die ganze Arbeit. Wenn du diesen mal nicht mehr im Blick hast, frage dich warum? Was ist gerade passiert und warum kannst du das entwickeln, ohne den Kunden zu adressieren?

Format nehmen, weil es jemand will

Das Format der User Story passt gut in einen komplexen Kontext, in dem für einen Kunden entwickelt wird. Wenn du dich erwischt, dass das Format öfters "nicht passt" und du es nur nimmst, "weil man das eben so nimmt" - probiere doch mal etwas anders aus. Ändere das Format, was ist anders, und was ist das Ergebnis?

Kein Produkt für den Kunden

Wenn du ein Produkt entwickelst und gar keinen Kunden hast, dann hilft dir die User Story auch nur bedingt weiter. Probiere da vielleicht andere Formate einmal aus. Dir fehlt die Sicht des Nutzers.

Epics als User Stories verkaufen

Denke dran: User Stories sind keine Epics. Wenn du Epics (zu unscharf und zu groß) als User Stories verkaufst oder nutzt, dann wirst du diese nicht innhalb von Sprints schaffen. Wenn doch, dann sind deine Anforderungen bestimmt kleiner geworden und damit tatsächlich keine Epics mehr.

Use Case

Use Cases und User Storys sind verschiedene Dinge und die haben auch nichts miteinander zu tun. Wer die Use Cases wie User Storys behandelt macht einen Fehler, denn zwischen diesen beiden Techniken liegen gravierende Unterschiede in der Detaillierung. Natürlich kannst du agile Praktiken verwenden, wie du möchtest. Die Kombination beider Methoden macht aus meiner Sicht nur wenig Sinn.

Beispiele für User Storys

Um dein Verständnis für agile User Stories zu verbessern, schauen wir uns ein paar Beispiele für User Stories an. Bei der Erstellung von User Storys stehen sich Teams und Menschen oft mal selbst im Weg, weshalb wir hier anhand von einigen Beispielen uns der Erstellung dieser PBI's widmen wollen.

Schlechte Beispiele mit Humor

Wenn du schmunzeln kannst, dann schaue dir gerne mal den Twitter Account "Shit User Story" an.

Einige weitere Beispiele

Als Administrator möchte ich mich in die Oberfläche einloggen, um Benutzer anlegen zu können.

Als HR Mitarbeiter möchte ich Job Interviews dokumentieren, um das Wissen über die Kandidaten festhalten zu können.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>