Bei der agilen Software-Entwicklung werden die Anforderungen der Nutzer an das Software-Produkt in Form von User Stories spezifiziert. Doch wir erleben in einigen Projekten, dass für Software-Entwicklungsteams die sinnvolle Verwendung von User Stories herausfordernd ist.

Wenn User Stories eingesetzt werden, ist es nicht damit getan, kurze strukturierte Sätze auf Post-its zu schreiben. Auch profitiert die Software-Entwicklung nicht von einer Sammlung von Features, bei denen unklar bleibt, welchen Nutzen Anwender der Software dadurch haben. User Stories helfen uns Software-Entwicklern, wenn wir uns vergegenwärtigen, dass es sich bei User Stories um Anforderungsspezifizierungen handelt. Und zwar um solche, die aus Nutzersicht Mehrwerte für bestimmte Rollen durch den Einsatz eines Software-Systems beschreiben. Die Spezifizierung von Anforderungen ist alles andere als trivial. Der Einsatz von User Stories als Repräsentation von Nutzeranforderungen erinnert uns in unserer alltäglichen Arbeit als Software-Entwickler daran, für wen wir in welcher Weise Software gestalten. Damit wir uns immer sicher sein können, dass wir das Richtige tun, wenn wir einen Blick auf die User Stories werfen, ist Einiges an Aktivitäten durchzuführen. Aktivitäten, die einen großen Teil unserer Arbeit ausmachen und nur grob erahnt werden können, wenn man die fertigen User Stories liest. Ziel dieses Artikels ist, zu beleuchten, was alles in den unscheinbaren Stories steckt und dabei zu unterstützen, User Stories zu schreiben und einzusetzen.

Dieser Artikel richtet sich an Software-Entwicklungsteams, die User Stories einsetzen und mit Begriffen aus dem Bereich der agilen Software-Entwicklung vertraut sind. Auch wenn User Stories kein Bestandteil von Scrum sind, hat sich eingebürgert, dass Backlog Items in Form von User Stories festgehalten werden. Daher verwende ich in diesem Artikel Begriffe aus dem Scrum-Kontext[1], um einzelne Aspekte von User Stories zu verdeutlichen.

Auch wenn es für das Lesen dieses Artikels hilfreich ist, Grundlagenartikel über User Stories bereits zu kennen, führt der Artikel zu Beginn kurz den Begriff der User Story ein. Der zweite Teil des Artikels beschreibt anhand aufeinander aufbauender Beispiele die Herleitung von User Stories, die aufgrund der Informationen, die sie beinhalten, sinnvoll für die Software-Entwicklung eingesetzt werden können. Das vorgestellte User Story Template als User Story Card ist als Download verfügbar. Separat werden die wichtigsten Fragen zur Verfügung gestellt, um das Template füllen zu können.

Einführung in User Stories

Was ist eine User Story?

Eine User Story

Ziele von User Stories

Ziele von User Stories sind,

Was ist eine User Story Map?

Eine User Story Map bricht einen Prozess über mehrere Ebenen so weit herunter, dass einzelne Stories so vollständig, verständlich und von ihrem Umfang her so festgelegt sind, dass sie innerhalb eines einzigen Sprints umgesetzt werden können.

Ausgehend von Nutzerzielen zeigt eine User Story Map auf der obersten, am wenigsten detaillierten Ebene zunächst die notwendigen Prozessschritte. Auf dieser Ebene bleibt noch unklar, wie die einzelnen Prozessschritte umgesetzt werden. Außerdem ist noch unklar, was bei den jeweiligen Prozessschritten konkret getan werden muss. In der Regel bestehen einzelne Prozessschritte aus mehreren Aktivitäten, die jeweils in Form einzelner User Stories detailliert beschrieben werden müssen. Wir sprechen bei den groben und umfangreichen User Stories auf dieser obersten abstrakten Ebene der User Story Map von Epics. Epics dienen der Übersicht über grundlegende Themen, über Gruppen von Nutzeranforderungen, die ähnliche oder gleiche Ziele verfolgen und die gleichen Mehrwerte für Nutzer schaffen.

Auf der darunter liegenden User Story Ebene werden die notwendigen Prozessschritte in Aktivitäten heruntergebrochen und somit operationalisiert. Wichtig hierbei ist, dass die Aktivitäten immer aus der Nutzerperspektive formuliert werden.

Jede User Story wird schließlich in technische Anforderungen heruntergebrochen. Auf dieser Task-Ebene wird festgelegt, was technisch implementiert werden muss, um eine User Story zu erfüllen. Ein Task kann üblicherweise in maximal 12 Stunden umgesetzt werden. Eine User Story ist erst dann erfüllt, wenn sämtliche mit ihr verknüpfte Tasks implementiert wurden.

Bei dieser Einheit aus Epics, User Stories und Tasks sind die User Stories zentral, nicht nur bildlich, sondern auch was unsere Arbeit als Software-Entwickler angeht. Wenn User Stories aus Sicht unterschiedlicher Rollen erfasst und analysiert wurden und strukturiert vorliegen, können wir uns im Software-Entwicklungsteam Gedanken über deren inhaltliche Optimierung machen. Bei Gedanken über die Optimierung von User Stories stehen stets der Nutzer und die User Experience im Fokus. Unser Ziel bei der Optimierung eines Software-Produkts auf Basis von User Stories ist die Schaffung direkt wahrnehmbarer Mehrwerte für die Nutzer. Nutzer halten sich nicht immer an einen formalen Prozess, sondern setzen den Prozess in einer Weise um, die für sie am einfachsten und am effizientesten ist. Die Optimierung eines Geschäftsprozesses führt daher nicht zwangsläufig zu einer Optimierung auf der User Story-Ebene. Vielmehr kann eine Optimierung auf User Story-Ebene in Gegenteil zum Überdenken eines Geschäftsprozesses führen.

Eine User Story Map visualisiert Beziehungen von Tasks untereinander sowie zwischen Tasks und User Stories und zwischen User Stories und Epics. Eine User Story Map unterstützt uns dabei, durchzuführende Entwicklungsschritte zu priorisieren und das Große Ganze, also das Gesamtsystem, im Blick zu behalten.

Was ist das übliche Format einer User Story?

Als de facto Standard für das Schreiben von User Stories hat sich das Connextra User Story Template[2] etabliert:

Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.

Dieses Template umfasst auf den ersten Blick die für die Verständlichkeit und Notwendigkeit der User Story nötigen Informationen:

Als Beispiel für eine User Story nennt die Agile Alliance (eigene Übersetzung):

Beispiel:

Dabei sind alle drei Bestandteile relevant. Statt in dem “Was”-Abschnitt der User Story ein Ziel oder einen Wunsch zu formulieren, taucht hier häufig ein Feature des zu entwickelnden Software-Produkts auf, welches das zu Grunde liegende Ziel bzw. den zu Grunde liegende Wunsch unterstützt. Ein solches Feature würde ein Software-Entwicklungsteam auch dann bereitstellen, wenn es nicht explizit in einer User Story genannt wird. Die Nennung eines Features verdeutlicht aber dessen besondere Relevanz für die genannte Rolle. Auch erlaubt uns die Nennung eines Features, die zu Grunde liegenden Wünsche des Nutzers zu erfragen, die zu der Forderung des Features führten.

Für die Umsetzung eines Features scheint die Angabe des Nutzens, den eine Rolle durch die Umsetzung des Features für sich sieht, für einzelne Entwickler vielleicht irrelevant zu sein. Doch kann bei Angabe des Nutzens erfragt werden, wie aus Sicht der Rolle der Wunsch erfüllt und somit ein Mehrwert geschaffen werden kann. Die echten Anforderungen der Rolle werden deutlich. Ein genanntes Feature allein ist nicht unbedingt ausreichend, um die Anforderung des Nutzers vollständig verstehen und nachvollziehen zu können. Und doch ist die Angabe des Nutzens im Connextra User Story Template optional.

Bei so unspezifischen User Stories wie: Als Nutzer möchte ich mich einloggen können oder Als Nutzer möchte ich das System entspannt verwenden können, sind zwar ein Feature bzw. ein Nutzen bekannt, aber noch nicht in einem Detailgrad, mit dem wir als Software-Entwicklungsteam arbeiten können. Derartige Angaben bilden für uns aber den Ausgangspunkt für eine Erfragung der Software Qualitätsattribute, die das Feature aufweisen muss bzw. die zu dem Wunsch beitragen und die wir daher bei der Entwicklung der Software berücksichtigen müssen.

Systematische Entwicklung von User Stories

User Stories sind Spezifizierungen

Ihre einfache Struktur und ihre Kürze suggerieren, dass auch das Erstellen einer User Story einfach ist und schnell von Statten geht. Doch dieser Eindruck täuscht. In Projekten bemerken wir immer mal wieder, dass User Stories ihren Zweck nicht erfüllen, d.h., nicht zu dem Verständnis und zu der Strukturierung der Anforderungen beitragen. Gründe hierfür sind Paraphrasen des “Was” als “Warum” und fehlende Informationen, die für das Verständnis der jeweiligen User Story notwendig wären. Dadurch werden schließlich die an die Software gestellten Nutzeranforderungen nicht vollumfänglich erfüllt, Mehrwerte für Nutzer werden nur zufällig oder basierend allein auf Erfahrungen von Software-Entwicklern und Designern geschaffen.

Die Kürze einer User Story ist dabei nicht das Problem. Eine Strukturierung und ein schneller Überblick sind mit kurzen User Stories einfacher als mit hochdetaillierten. Was aber ab und an vergessen wird, ist, dass es sich bei einer User Story um eine Spezifizierung handelt. Daher unterliegt auch eine User Story den Qualitätsanforderungen an Software-Anforderungsspezifizierungen, wie sie beispielsweise in der ISO/IEC/IEEE Norm 29148 definiert sind [3].

Nach dieser Norm muss eine Spezifizierung einer einzelnen Softwarequalitätsanforderung folgende Eigenschaften aufweisen:

Als Software-Entwicklungsteam ist unsere Aufgabe, die als einfache User Story festgehaltenen Informationen nun so zu erweitern, dass sie diesen Eigenschaften entsprechen. Unsere eigentliche Arbeit endet also nicht mit dem Schreiben erster User Stories, sie fängt hier erst an. Denn jetzt beginnt der wichtigste Aspekt einer User Story: Die Kommunikation mit Fachabteilungen, die Kreation möglicher Lösungen und die Abstimmung von Lösungen mit technischen Gegebenheiten und Einschränkungen, jeweils auf Basis der in der User Story enthaltenen Informationen.

Formulierung von Akzeptanzkriterien

Während die User Story formuliert als kurzer Satz wie im Connextra Template der Verständlichkeit, Strukturierbarkeit und Priorisierbarkeit dient, ist eine Definition von Bedingungen nötig, um eindeutig entscheiden zu können, ob eine User Story als bearbeitet und abgenommen gelten kann. Diese Bedingungen halten wir für jede User Story individuell als Akzeptanzkriterien fest.

Es handelt sich bei den Akzeptanzkriterien um fachliche Anforderungen, also um Bedingungen aus Nutzersicht, die durch die Anwendung der Software evaluiert werden können und vollumfänglich erfüllt werden müssen. Eine Priorisierung der Akzeptanzkriterien ist also nicht nötig: Sobald auch nur ein Akzeptanzkriterium nicht erfüllt wird, kann die entsprechende User Story streng genommen nicht als erfüllt angenommen werden.

Akzeptanzkriterien werden einfach und eindeutig formuliert, sind messbar und spezifisch. Sie erhöhen somit die Verständlichkeit einer User Story weiter und beseitigen Unklarheiten. Akzeptanzkriterien werden von dem Product Owner definiert, nicht von Entwicklern. Der Product Owner nimmt bearbeitete User Stories auch ab, ggf. ist zusätzlich eine Abnahme durch Kundenvertreter nötig."

Ein Akzeptanzkriterium kann beispielsweise folgende Punkte umfassen:

Identifizierung weiterer Anforderungen innerhalb einzelner User Stories

Damit wir eine User Story sinnvoll einsetzen können, muss sie insbesondere alle Informationen beinhalten, die zu ihrer Verständlichkeit und zu ihrer Umsetzbarkeit beitragen. Wir versuchen dabei, Nutzer durch aktives Zuhören richtig zu verstehen und ihre Bedürfnisse in Erfahrung zu bringen. In diesem Zuge identifizieren wir häufig weitere Anforderungen in User Stories, die wir als neue User Stories notieren. Das genannte Beispiel birgt beispielsweise mindestens drei Nutzeranforderungen:

  1. höhere Effizienz durch Reduktion der Zeit zur Erledigung der Aufgabe des Geldabhebens durch die Vermeidung des Anstehens in einer Warteschlange an einem Bankschalter,
  2. Erhöhung der Flexibilität durch Unabhängigkeit von Öffnungszeiten der Bank, und
  3. Zugänglichkeit des Geldautomats auch außerhalb der Öffnungszeiten der Bank.

Was Nutzer als Anforderung an uns kommunizieren, ist der Wunsch nach der Erhöhung einer bestimmten wahrnehmbaren Software-Qualität. Eine derartige Qualität kann sich auf die Nutzung beziehen (Anforderungen 1 und 2) oder unabhängig von einer Nutzung allein durch die Merkmale eines Produkts bestehen (Anforderung 3).

Weil diese Anforderungen auch erfüllt werden, sobald das genannte Feature (“Was”) umgesetzt bzw. eingeführt wird, könnte der Eindruck entstehen, dass das “Warum” für die Software-Entwicklung nicht nötig ist. Über einen direkt in der User Story erkennbaren Nutzen, ist uns aber wichtig, Software so zu gestalten, dass sie Mehrwerte für die Nutzer schafft. Mehrwerte ergeben sich für Nutzer durch die Erfüllung ihrer Bedürfnisse. Daher ist es für uns essenziell, die Bedürfnisse der Nutzer zu kennen und als “Warum” in User Stories festzuhalten.

Identifizierung von Bedürfnissen

Nutzerbedürfnisse sind nicht direkt aus User Stories ableitbar. Wir können sie ausschließlich unter Anwendung von Befragungstechniken von Nutzern in Erfahrung bringen. Wenn wir nur schätzen würden, welche Bedürfnisse vorliegen könnten oder wenn wir von unseren eigenen Bedürfnissen auf die Bedürfnisse der Nutzer schließen würden, würden wir die tatsächlichen Nutzerbedürfnisse nur zufällig erfüllen. Einen solchen Zufall wollen wir umgehen, auch wenn es bedeutet, dass wir teilweise viele Ressourcen in die Erhebung und Ausarbeitung von Nutzeranforderungen stecken müssen.

Nutzerbedürfnisse im Kontext der Beispiel-User Story könnten beispielsweise sein:

Bedürfnisse der Nutzer zu kennen, versetzt uns in einem Software-Entwicklungsteam in die Lage, Software so zu gestalten, dass die gleichen Bedürfnisse auch erfüllt werden, wenn User Stories umgesetzt werden, deren Grundlage nicht die Erfüllung dieser Bedürfnisse war. Hierdurch werden Erwartungen der Nutzer übertroffen und die Ausprägung der User Experience gestaltet sich positiv. Genau das ist, warum wir Software entwickeln und warum wir User Stories verwenden.

Wenn beispielsweise bekannt ist, dass Autonomie ein wichtiges Bedürfnis für eine Nutzergruppe ist, können wir verstärkt Mechanismen implementieren, die dem Nutzer erlauben, die Abfolge und die Geschwindigkeit von Interaktionen mit dem Software-Produkt zu steuern.
Wenn das Sicherheitsgefühl des Nutzers gestärkt werden soll, können wir verstärkt Feedback-Mechanismen, aussagekräftige Funktionsbezeichnungen und sekundäre Navigation für die Positionsbestimmung innerhalb der Informationsarchitektur der Software implementieren.

Wenn wir die Bedürfnisse der Nutzer kennen, können wir User Stories nach diesen Bedürfnissen gruppieren. Wir können außerdem Sprintziele formulieren, um am Ende eines Sprints bestimmte Nutzerbedürfnisse zu erfüllen, indem wir entsprechende User Stories bearbeiten.

Das “Warum” ist entscheidend

In dem weit verbreiteten “Wer-Was-Warum” Connextra User Story Template gilt die Information über den Nutzen der User Story als optional, obwohl es sich hierbei aus Sicht des Nutzers um die essenzielle Information und den Grund für die Existenz der User Story handelt. Als optional wird die Beschreibung des Nutzens einer User Story angesehen, weil wir in vielen User Stories als Nutzen lediglich eine Umschreibung der Funktionalität bzw. den eigentlichen Zweck, der sich aus dem Feature ergibt, finden:

Die Angabe eines Nutzens einer User Story sollte aufgrund ihrer Bedeutung für die User Story und für ihre Umsetzung bereits zu Beginn der User Story genannt werden, nicht an ihrem Ende [4]. Auf diese Weise lassen sich User Stories nicht nur einfacher gruppieren, sie verdeutlichen auch ihren Wert für den Nutzer. Ein entsprechendes User Story Template von Chris Matts lautet:

Um <Nutzen>, möchte ich als <Rolle> <Ziel/Wunsch>.

Insbesondere die Wirksamkeit und die Gebrauchstauglichkeit von Software lassen sich auf diese Weise optimieren und entsprechende Features in Form einer User Story beschreiben.

Doch nicht immer ist ein Nutzen direkt durch die Bereitstellung eines Features zu schaffen. Wichtiger als die Bereitstellung von Features ist für Nutzer die positive Gestaltung ihrer Erfahrungen und ihrer Erlebnisse während der Nutzung von Software. Diese positive Gestaltung ist hauptsächlich davon abhängig, dass persönliche Ziele der Nutzer erfüllt werden. Auch diese Ziele spiegeln sich in User Stories wider, können aber nur indirekt durch Features einer Software erfüllt werden.

Um mich wohl zu fühlen, möchte ich als Nutzer erfahren, wie der Anbieter der Software mit meinen persönlichen Daten umgeht.

Das dieser User Story zu Grunde liegende Bedürfnis ist Sicherheit. Wir können die User Story also auch umformulieren in:

Um ein stärkeres Sicherheitsgefühl zu bekommen, möchte ich als Nutzer erfahren, wie der Anbieter der Software mit meinen persönlichen Daten umgeht.

Derartige User Stories, die persönliche Nutzerziele adressieren, beinhalten üblicherweise keine Informationen über geeignete Features, die zur Erfüllung der Ziele beitragen. Um persönliche Ziele zu erfüllen, muss Software aber mindestens ein Feature bereitstellen. Daher muss mindestens eine weitere User Story geschrieben werden, welche die funktionalen Ziele beschreibt. In einer User Story Map erkennen wir die enge Beziehung zwischen beiden Typen von User Stories.

Um die Beziehung zwischen User Stories leicht zu erkennen, ist die Angabe des Nutzens jeder User Story zwingend nötig. Dabei beschreibt jede User Story genau einen Nutzen. Hierdurch genügt eine User Story der Qualitätsanforderung der Atomarität, egal, ob es sich um eine funktionale oder um eine nichtfunktionale Anforderung handelt, die als User Story repräsentiert wird.

Die umstrukturierte und auf das Bedürfnis Autonomie fokussierende User Story aus dem Beispiel lautet:

Identifizierung von Absichten

Das Abheben von Geld allein bietet dem Nutzer keinen Mehrwert. Auch das Wissen um das adressierte Bedürfnis genügt nicht, um ein vollständiges Bild der Beweggründe des Nutzers zu erhalten, die Anforderung formuliert zu haben. Über die Angaben des zu erfüllenden Bedürfnisses und des gewünschten Features hinaus, ist es hilfreich, die Intention des Nutzers zu kennen, also dessen Absicht, etwas zu tun oder zu verhindern. Diese Absicht wird aus Sicht des Nutzers durch das angeforderte Feature unterstützt.

Der alleinige Wunsch nach einem Feature kann schnell zu Feature Creep führen, also zur fortlaufenden Hinzunahme neuer und erweiterter Anforderungen oder Funktionen, die aber keinen Mehrwert schaffen. Was uns interessiert ist, was ein Nutzer mit Hilfe des Features tatsächlich erreichen möchte. Der ursprünglich wie in dem Beispiel angegebene Nutzen stellt oft genau die Intention des Nutzers dar, nicht den tatsächlichen Nutzen. Das umformulierte Beispiel kann also lauten:

Ähnlich wie bei der Angabe des Nutzens, gilt auch für die Angabe der Intention, dass sie für die reine technische Umsetzung als unerheblich wahrgenommen werden könnte. Wofür ein Nutzer ein implementiertes Feature verwendet, hat vor allem dann eine Relevanz, wenn wir die Implementierung von Features nicht als zentrale Aufgabe verstehen. Sobald die Schaffung von Mehrwerten für den Nutzer im Vordergrund steht, können wir ausarbeiten, welche Features zur Umsetzung einer angegebenen Intention optimal angeboten werden müssen. Ein genanntes Feature kann sich dabei als wenig hilfreich oder überflüssig herausstellen. Schließlich handelt es sich bei Stakeholdern, von denen wir Informationen und Wünsche erhoben haben, normalerweise nicht um technische Experten. Darüber hinaus erleben wir häufig, dass in dem Software-Entwicklungsteam diverse Erfahrungen vorhanden sind, die zu neuen Denkweisen und Lösungen führen, die sich von Ideen einzelner Entwickler unterscheiden und Synergien schaffen. Beispielsweise wird die Intention, Öffnungszeiten und Warteschlangen zu vermeiden, nicht nur durch die Bereitstellung eines Geldautomaten erfüllt, sondern auch durch die Möglichkeit, Geld im Supermarkt abzuheben und durch das Anbieten der Zahlung per Smartphone in jeglichem Kontext.

Features, die in User Stories festgehalten werden, sind also keine technisch/funktionalen Anforderungen, die wir stur umsetzen sollten, ohne die echten Wünsche des Nutzers zu kennen und ohne die Features innerhalb des Software-Entwicklungsteams diskutiert zu haben. Wie für Software-Spezifizierungen verlangt, sollten Anforderungen frei von Lösungen sein. Wir beachten den Unterschied zwischen einer Anforderung, einer Lösung und einem Feature bei der Erstellung und bei der Verwendung von User Stories immer. Ein Feature stellt den Wunsch eines Nutzers dar, den der Nutzer als Lösung an uns kommuniziert, wobei er die Lösung unterschiedlich detailliert beschreibt. Die Lösung ist dabei nicht das zentrale unbedingt genau so umzusetzende Element, sondern nur Mittel zum Zweck, den Wunsch zu verdeutlichen. Aus diesem Wunsch eine Anforderung zu spezifizieren obliegt uns im agilen Software-Entwicklungsteam.

Von der Quelle ans Ziel

Zur Verdeutlichung der Intention des Nutzers bzw. warum ein Nutzer bestimmte Wünsche äußert ist es hilfreich, die Quelle seiner Anforderung zu kennen. Als Menschen greifen wir stets auf unsere individuellen Vorerfahrungen zurück. Wir vergleichen und kombinieren. Etwas völlig Neues können wir allein nicht erzeugen. Was aber gut möglich ist, ist, dass unsere Erinnerungen nicht der Realität zum Zeitpunkt ihres Stattfindens entsprechen. Doch ganz gleich, ob die Erinnerungen eines Nutzers der Realität entsprechen oder nicht, User Stories und unserem Vorgehen bei der Software-Entwicklung liegen die Vorstellungen der Nutzer zu Grunde. Dies gilt auch, wenn die Abläufe und Interaktionen nicht in der Weise erfolgten, in der sich Nutzer daran erinnern. Wenn wir also die relevanten Vorerfahrungen von Nutzern in User Stories aufnehmen, vergrößern wir damit unser Verständnis der User Story enorm.

Mit dem Wissen um die Quelle einer User Story fällt es uns leichter, weitere Nutzeranforderungen zu identifizieren. Basierend auf der Quelle einer Anforderung können wir im Software-Entwicklungsteam hinterfragen, ob sich noch weitere Anforderungen in der Quelle verbergen und ob bestehende Anforderungen verfeinert werden können, wenn wir sie auf die Quelle beziehen. Vorerfahrungen bergen häufig deutlich mehr Informationen als ursprünglich von einem Nutzer geäußert. Gemeinsam können unter Zuhilfenahme bestimmter Befragungstechniken daher oft deutlich mehr Informationen in Erfahrung gebracht werden, als es der Fall ist, wenn die Quelle von Nutzeranforderungen nicht bekannt ist.

Das Beispiel erweitert um eine Quelle der Nutzeranforderung lautet:

Zu wissen, auf welche Vorerfahrung ein Nutzer zurückgreift, um dessen Anforderung zu formulieren, dient dem Zweck, den Nutzer und die Anforderung besser zu verstehen. Insbesondere verstehen wir das mentale Modell besser, das der Nutzer von der Software hat.

Es geht uns allerdings nicht darum, ein Feature aus der Vorerfahrung des Nutzers zu kopieren. Vielmehr nutzen wir die Vorerfahrung, um positive und negative Aspekte des Features zu identifizieren. Positive Aspekte des Features behalten wir dann bei, negative Aspekte beseitigen wir.

Wichtig ist, dass relevante Vorerfahrungen nicht zwingend aus derselben Domäne stammen müssen. Es muss sich dabei nicht einmal um Software-Lösungen handeln. Jede Vorerfahrung, die aus Sicht des Nutzers relevant für das aktuelle Problem bzw. die aktuelle Entwicklung ist, kann uns sehr hilfreiche Einblicke in die Vorstellungswelt des Nutzers gewähren und sollte daher festgehalten werden. Als Illustration kann die User Story durch eine grafische Abbildung desjenigen Systems oder Features ergänzt werden, auf das ein Nutzer Bezug genommen hat, während er die als User Story repräsentierte Anforderung kommuniziert hat. Eine solche Abbildung erinnert uns nicht nur daran, welches Feature für den Nutzer besonders wichtig ist, sondern erhöht auch unser Verständnis der Anforderung weiter und gibt uns Anhaltspunkte für die Umsetzung der Anforderung. Der Detaillierungsgrad der Abbildung wird dabei von der Notwendigkeit für das Verständnis der Anforderung bestimmt. Ein Foto der räumlichen Umgebung, ein Screenshot, ein einzelnes UI-Element oder auch eine einfache Skizze von Abläufen oder Zusammenhängen sind mögliche Abbildungen. Um Details erkennen zu können, ist es auch möglich, die Abbildung größer auszudrucken und eine User Story Card darauf zu befestigen. Mehrere User Stories, die sich auf die gleiche Quelle beziehen, können rund um die Abbildung platziert werden. Auf diese Weise schaffen wir direkt eine Gruppierung der User Stories.

Durch Objektive Features zu subjektiver Zufriedenheit

Eine sinnvolle Information im Kontext einer User Story ist schließlich, welche objektive Software-Qualität erhöht werden muss, um die User Story zu erfüllen. Objektive Software-Qualität ist eine Qualität der Software, die auch dann vorliegt, wenn kein Nutzer mit der Software interagiert. Sie kann daher implementiert und quantitativ gemessen werden.

Die Angabe einer objektiven Software-Qualität erzeugt eine Verbindung zwischen dem menschlich/empathischen Teil und dem technisch/funktionalen Teil einer User Story. Mit Angabe einer objektiven Software-Qualität dient uns eine User Story neben der Strukturierung und dem Verständnis auch der besseren Umsetzungsplanung und Aufwandsschätzung und gibt Implementierern einen Anhaltspunkt, worauf sie sich technisch fokussieren können, um die User Story umzusetzen. Somit schlägt eine objektive Softwarequalität auch die Brücke zwischen frühen und späten Entwicklungsphasen, zwischen Mensch und Technik, zwischen Vorstellung und Realität.

Die ISO/IEC Norm 25010 stellt mit ihrem Produktqualitätsmodell eine Übersicht über objektive Software-Qualitäten bereit, an denen man sich gut orientieren kann [5]. Dieses Modell umfasst die objektiven Qualitätsfaktoren “Funktionale Tauglichkeit”, “Performanz”, “Kompatibilität”, “Gebrauchstauglichkeit”, “Zuverlässigkeit”, “Sicherheit”, “Wartbarkeit” und “Übertragbarkeit”. Für die Umsetzbarkeit dieser Faktoren beschreibt das Produktqualitätsmodell jeweils entsprechende Kriterien.

Mit der Angabe einer objektiven Software-Qualität lautet das Beispiel wie folgt:

‘Verfügbarkeit’ ist ein Faktor der objektiven Softwarequalität ‘Zuverlässigkeit’ [6].

Das 6W User Story Template

Aus den Ausführungen im Abschnitt “Systematische Entwicklung von User Stories” ergibt sich das User Story Template, das ich “6W User Story Template” nenne, da es sechs W-Fragen beantwortet. Das Template als PDF Dokument kann heruntergeladen werden. Die Seitengröße des Dokuments entspricht der Größe eines Post-Its. Das Dokument umfasst auf der ersten Seite das Template und auf der zweiten Seite Raum für die individuellen Akzeptanzkriterien. In einem separaten PDF Dokument stehen die wichtigsten Fragen, die zum Ausfüllen des Templates beantwortet werden sollten.

Das 6W User Story Template sieht wie folgt aus:

Titel der User Story

Die für die einzelnen Teile des 6W User Story Templates zu beantwortenden Fragen lauten:

Quellen

  1. Agile Alliance, Scrum, https://www.agilealliance.org/glossary/scrum/  ↩

  2. Agile Alliance, User Story Template, https://www.agilealliance.org/glossary/user–story–template/  ↩

  3. ISO/IEC/IEEE, IEEE 29148–2018, ISO/IEC/IEEE International Standard, Systems and software engineering – Life cycle processes – Requirements engineering.  ↩

  4. David Evans und Gojko Adzic, “‘As a, I want, So that’ Considered Harmful”,  ↩

  5. ISO/IEC 25010:2011, Systems and software engineering – Systems and software Quality Require ments and Evaluation (SQuaRE) – System and software quality models, 2011.  ↩

  6. DIN Deutsches Institut für Normung, Ergonomie der Mensch–System–Interaktion – Teil 110: Grundsätze der Dialoggestaltung (EN ISO 9241–110:2006), Berlin, Beuth Verlag, 2008.  ↩

Fazit

Eine User Story repräsentiert die Spezifizierung einer Nutzeranforderung. Sie ist daher nicht völlig frei formulierbar, sondern bestimmten Qualitätsanforderungen unterworfen. Ihre vornehmlichen Ziele sind die Schaffung von Verständlichkeit der Anforderung und die Strukturierung der Aufgaben des Software-Entwicklungsteams unter Berücksichtigung der Mehrwerte für die Nutzer aus deren Perspektive. Das Kommunizieren dieser Mehrwerte innerhalb des Entwicklungsteams schafft die Wahrnehmung der Gründe für die Software-Entwicklung und ermöglicht eine Optimierung von Lösungen unter Berücksichtigung der Nutzerbedürfnisse. User Stories müssen nicht stur in Templates gegossen werden. Stattdessen dienen Templates der Konsistenz verschiedener User Stories und gewährleisten die Angabe der wichtigsten Informationen über die unterstützten Rollen, die gewünschten Features und insbesondere die zu schaffenden Mehrwerte. Eine User Story Map bietet einen strukturierten Überblick über die zu erledigenden Aufgaben aus Nutzerperspektive und ihren Beitrag zu einzelnen Schritten des Geschäftsprozesses, um bestimmte Geschäftsziele zu erreichen. Die persönlichen Ziele der Nutzer und die zu Grunde liegenden Bedürfnisse sollten hierbei nicht außer Acht gelassen werden.

TAGS