User Story Best Practices: Ein Leitfaden für agile Anforderungen

Anforderungen / Spezifikationen für traditionelle Softwareentwicklung

In der Vergangenheit haben wir das Wort „Anforderungen“ verwendet, um digitale Bedürfnisse eines Unternehmens zu beschreiben. Dieser Begriff stammt aus den 1960er Jahren und wurde durch die System Requirements Definition (SRD) Methodik von IBM populär.

Manche behaupten, dass User Stories die „Anforderungen“ ersetzen. Das ist nicht allgemein zutreffend. Um das zu erklären, müssen wir die herkömmlichen Anforderungen und die fehlende Perspektive, die User Stories bieten, verstehen.

Im Jahr 2015 veröffentlichte das International Institute of Business Analysis™ (IIBA®) den Business Analysis Body of Knowledge (BABOK™ Version 3.0), der uns eine gemeinsame Definition verschiedener Arten von Anforderungen gibt. Der BABOK™ unterscheidet Softwareanforderungen nach ihrem Detaillierungsgrad:

• Geschäftsanforderungen: Das gewünschte Ergebnis der digitalen Lösung.
• Stakeholder-Anforderungen: Die Funktionen, die Einzelpersonen oder Gruppen innerhalb der Organisation zugute kommen.
• Lösungsanforderungen: Auch bekannt als Systemanforderungen oder Spezifikationen – funktionale und nicht-funktionale Anforderungen für Entwickler.
• Transitionsanforderungen: Bedingungen, die erfüllt werden müssen, um die gelieferte Lösung zu implementieren.

Eine ausführlichere Behandlung der Unterschiede zwischen traditionellen Anforderungen und User Stories finden Sie in meinem Beitrag Geschäfts-, Stakeholder- und Lösungsanforderungen vs. User Stories.

User-Story-Struktur: Was sind die 3 Cs von User-Storys?

Während Geschäfts-, Stakeholder- und Lösungsanforderungen normalerweise in einem einfachen Satz oder einer kurzen Phrase ausgedrückt werden, folgt eine User Story normalerweise dem Drei-C-Konzept.

User Stories wurden in einer Softwareentwicklungsmethode namens „eXtreme Programming“ eingeführt. Sie waren notwendig, weil IT-Projekte notorisch schwer zu erfassen, abzuschätzen und zu liefern waren. Das Entwicklungsteam erstellte Storys, um zu verstehen, was es zum Erstellen benötigte, und um diese Anforderungen zu priorisieren.

User Stories beschreiben die Funktionalität eines Produkts anhand von drei Cs:

• Card (Die Karte die den Geschäfts- oder Benutzerbedarf ausdrückt.)
• Conversation (Das Gespräch zur Analyse der Bedürfnisse und der Kollaboration während der Entwicklung.)
• Confirmation oder Criteria (Die Bestätigung oder Kriterien, mit denen die Lösung getestet wird, um zu bestätigen, dass sie die Absicht der User Story erfüllt.)

Die Karte: Das Schreiben der User Story

Eine User Story ist eine Beschreibung dessen, was die Geschäftswelt möglicherweise braucht, vorausgesetzt, das Entwicklungsteam kann es innerhalb eines angemessenen Zeit- und Budgetrahmens liefern. Der Schwerpunkt liegt auf der Einfachheit.

Das User-Story-Format soll in diesem frühen Stadium erfassen, was ein bestimmter Stakeholder oder Benutzer von der IT erwartet und warum.

Warum heißt das „die Karte“?

Ursprünglich wurden User Stories handschriftlich auf eine Seite einer 3X5 Karteikarte geschrieben. Die Größe der Karte wurde bewusst gewählt, um die Menge der zu erfassenden Informationen zu begrenzen und um die User Stories kurz und einfach zu halten.

Obwohl die meisten User Stories in der heutigen Welt digital erfasst und gepflegt werden, ist das Konzept, sie kurz und einfach zu halten immer noch eine sehr gute Richtlinie.

Das Gespräch: Analysieren und Kollaborieren

Die User Story selbst ist keine Anforderung, sondern dient als Auslöser für ein klärendes Gespräch oder eine Diskussion zwischen dem Autor und dem Agile Team (oder den Entwicklern).

Gespräche über die User Story sollten nur stattfinden, wenn die Entwickler bereit sind, diese Story für eine bevorstehende Iteration (in der Scrum-Terminologie: Release oder Sprint) zu planen. Das Hauptziel des Konversation besteht darin, sicherzustellen, dass die Entwickler und Tester die Absicht des Autors hinter der User Story verstehen.

Das Meeting ist kein einmaliges Ereignis. Es findet je nach Bedarf statt. Der Product Owner, die Entwickler, die Tester und andere Stakeholder besprechen ausgewählte User Stories im Detail, analysieren sie, teilen sie auf, wenn sie zu umfangreich sind, legen User Story Akzeptanzkriterien fest und hören erst auf, wenn ein Konsens erreicht ist. Dann können die Entwickler mit dem Schreiben des Codes beginnen.

Kollaboration ist das A und O produktiver Teams, und ohne effektive Moderation kann es keine Zusammenarbeit geben. Einen Moderator zur Hand zu haben, sollte nicht Ihr Fallback-Plan sein. Von regelmäßigem partizipatorischem Feedback bis hin zu Agile 3 Amigo-Gesprächen kann effektive Moderation Kreativität fördern und die Ergebnisse verbessern.

Die Bestätigung (oder Kriterien): Validierung, dass die Intention der User Story erfüllt wurde

Akzeptanzkriterien sind die Grundlage für die Erstellung von Benutzerakzeptanztests. Sie legen fest, wie Entwickler erkennen können, ob die gelieferte Funktionalität die Absicht der User Story erfüllt.

Im ursprünglichen Konzept wurden diese Kriterien auf die Rückseite der Karte geschrieben. Auch wenn die User Stories heute elektronisch gepflegt werden, ist es wichtig, die Verbindung zwischen der Story als solcher und den Akzeptanzkriterien aufrecht zu erhalten.

Das Entwicklungsteam verwendet High-Level-Akzeptanzkriterien, um zu entscheiden, ob eine User Story geeignet ist, in eine kommende Version aufgenommen zu werden.

Detailliertere User Acceptance Criteria werden oft erst definiert, wenn ein Entwickler mit der Arbeit an einer User Story beginnt. Einige Organisationen ziehen es vor, die Akzeptanzkriterien im Gherkin Given-When-Then-Format zu schreiben, um Konsistenz und Klarheit zu gewährleisten (mehr dazu später).

Das User-Story-Format: Was ist eine effektive User Story?

Es gibt eine Fülle von Informationen über das User Story-Format. Ich beschreibe es hier nur kurz. In meiner KnowledgeKnugget™-Bibliothek finden Sie kostenlose Videos mit ausführlichen Erklärungen.

Eine User Story muss die Frage beantworten: WER will WAS und WARUM?

Jedes User Story-Format muss Folgendes klar zum Ausdruck bringen:

• Die ROLLE, die der Autor vertritt (beantwortet die WER-Komponente)
• Das ERGEBNIS oder die Aktion (beantwortet den WAS-Teil)
• Der NUTZEN oder Geschäftswert (beantwortet die WARUM-Dimension)

Zum Beispiel,

Als Reisender (die Rolle, die diese Person zu Beginn dieser Interaktion spielt), kann ich
den günstigsten Flug auswählen, der meinen Reiseanforderungen entspricht (das Ergebnis, das die Rolle wünscht), um Geld zu sparen (den Wert, den die Rolle erhält).

Dieses Beispiel einer User Story beantwortet alle drei Fragen:

Wer fordert etwas an (ROLLE – in diesem Beispiel ein Reisender)?
Sie möchten die Rolle – keine Berufsbezeichnung –, die diese Person in der Story spielt. Wenn Sie weitere Informationen zum Identifizieren und Modellieren von Benutzerrollen wünschen, sehen Sie sich bitte mein Video How to Define User Story Roles: User Role Modeling, Persona Development, and Stakeholder Identification an.

Was will der Anfragende (ERGEBNIS – Auswahl des günstigsten Fluges)?
Das Ergebnis der User Story kann qualifiziert werden. In unserer Story ist „günstigste“ ein Qualifikator. Sie können alles verwenden, was einschränkt oder klarstellt, wie genau die Rolle oder Persona etwas haben will oder wissen möchte.

Warum ist dieses Ergebnis wichtig (GESCHÄFTSWERT – um Geld zu sparen)?
Eine gute User Story wird die Vorteile dieser Funktion für die ROLLE klar skizzieren, und die Gründe, warum sie diese Funktion benötigen. Der Geschäftswert hilft sowohl Endbenutzern als auch technischen Teams, bessere Gespräche zu führen. Wenn Entwickler das „Warum“ oder den geschäftlichen Wert einer User Story verstehen, können sie bessere Softwarelösungen erstellen.

Das Format einer User Story ist flexibel

Sie müssen nicht einem strengen Muster wie „Als…, kann ich…, um…“ folgen. Solange alle drei Fragen – wer will was tun und warum – beantwortet sind, haben Sie eine gültige User Story-Struktur.

Hier ist ein weiteres Beispiel einer User Story:

Als Vertriebsleiter, kann ich einen monatlichen Bericht über Kundenbeschwerden erhalten , um die Leistung meiner Vertriebsmitarbeiter zu überprüfen.

Wir haben mit Unternehmen zusammengearbeitet, die einfache Sätze schreiben, die das WER, WAS und WARUM beantworten. Sie nennen diese dennoch User Stories. Andere Organisationen verwenden immer noch den Begriff „Anforderungen“, folgen aber dem User Story-Format.

Hier ist dasselbe User Story-Beispiel, ausgedrückt in einem zielorientierten User Story-Format:

Um die Leistung ihrer Vertriebsmitarbeiter zu überprüfen, können Vertriebsleiter einen monatlichen Bericht über Kundenbeschwerden erhalten.

Grenzen der User Story-Struktur

Eine digitale Lösung ist ein komplexes Unterfangen, an dem viele Stakeholder beteiligt sind. Obwohl die Benutzerfunktionalität wichtig ist, ist sie nur ein Aspekt der Lösung. Viele Stakeholder in Ihrem Unternehmen können mitbestimmen, was die Technologie ihrer Meinung nach erreichen soll.

Auf der Unternehmensseite sprechen wir von Führungskräften, die Initiativen genehmigen, und von Interessengruppen (Audit, Rechtsabteilung, Compliance usw.), die legitime Anforderungen an jede digitale Lösung stellen.

Auf der Technologieseite gibt es weitere Gruppen (Infrastruktur, Datenverwaltung, Sicherheit usw.), die sicherstellen, dass jede digitale Lösung technischen und organisatorischen Standards entspricht.

Überzeugte Befürworter der User Story-Struktur argumentieren, dass die meisten (wenn nicht alle) dieser Überlegungen im User Story-Format ausgedrückt werden können und sollten.

Zum Beispiel:

Als Datenbankadministrator kann ich Thrashing-Probleme erkennen, um sicherzustellen, dass die Anwendung unsere Leistungsstandards erfüllt.

Unabhängig davon, ob Sie diese Anforderungen von Nicht-Benutzer-Stakeholdern im User-Story-Format oder in einem anderen Format ausdrücken, stellen Sie sicher, dass Sie sie irgendwie erfassen.

Das INVEST-Modell: Ein Leitfaden zum Schreiben guter User Stories

Das Erstellen von User Stories ist einfach; die Grundstruktur ist unkompliziert. Aber das Erstellen guter User Stories kann eine Herausforderung sein.

Glücklicherweise bietet Bill Wake – der Erfinder des INVEST-Modells – Anleitungen zum Schreiben effektiver User Stories. Die Eselsbrücke INVEST hilft Ihnen dabei, sich an sechs Merkmale zu erinnern, die gute User Stories aufweisen, um Sie bei der Erstellung Ihrer eigenen zu unterstützen.

Independent User Stories sind unabhängig

Das „I“ steht für Independent (unabhängig), was bedeutet, dass jede User Story in sich abgeschlossen sein sollte, um Abhängigkeiten von anderen User Stories zu vermeiden. Das bedeutet nicht, dass Stories keine Vorbedingungen haben können.

Es sollte jedoch für einen Entwickler möglich sein, die Story zu programmieren, zu testen und in Produktion zu geben, ohne dass er davon abhängig ist, dass andere User Stories zuerst funktionieren. Das ist natürlich mit Vorsicht zu genießen, aber jede User Story sollte so eigenständig wie möglich sein.

Ein guter Lackmustest für dieses Prinzip besteht darin, sich selbst zu fragen: „Wenn Sie diese User Story drastisch ändern, würde dann eine der anderen Storys hinfällig werden?“. Wenn Sie feststellen, dass Ihre User Storys voneinander abhängig sind, kombinieren Sie sie zu größeren Storys oder isolieren Sie die Abhängigkeit in einer eigenen User Story.

Negotiable User Stories sind verhandelbar

Das „N“ steht für Negotiable (verhandelbar). Dies ist ein wichtiges Kriterium in schlanken und agilen Entwicklungsumgebungen.

Viele Agilisten sind keine Fans des Begriffs „Anforderungen“, weil er einen negativen Beigeschmack hat. „Anforderung“ klingt so autoritär – quasi „so MUSS man es machen!“. User Stories sind keine rigiden Anforderungen.

Die Unterstützung der geschäftlichen Agilität ist eine der wichtigsten Triebfedern für die agile Bewegung, die wechselnde Anforderungen an digitale Lösungen zulässt und sogar fördert. Es gibt kein Versprechen, dass eine User Story im Backlog jemals so umgesetzt wird, wie sie ist.

User Storys können bis zum Zeitpunkt der Codierung immer geändert oder umgeschrieben werden. Sobald das Team mit dem Programmieren einer Story begonnen hat, werden Änderungen teuer und sollten vermieden werden.

Beispielsweise könnte ein Product Owner den Umfang und die Qualitäten einer User Story aufgrund dringender geschäftlicher Anforderungen spontan aushandeln. Um dies zu unterstützen, sollten Ihre User Stories niemals so detailliert oder restriktiv sein, dass Ihr Team daran gehindert wird, die beste Lösung zu finden. Halten Sie die Absichten fest, aber lassen Sie genügend Raum für Diskussionen im Team.

Valuable User Stories sind wertvoll

V steht für „valuable“ (wertvoll). Als ich das User Story-Format (Wer, Was, Warum) vorgestellt habe, schrieb ich, dass eine User Story immer den Wert liefern muss, den die Rolle in der User Story benötigt.

Der Geschäftswert einer User Story ist eine wichtige Komponente, um dem Team mitzuteilen, wie Erfolg aussieht. Wenn das Team nicht weiß, wie der Erfolg aussehen wird, wie kann es dann wissen, wann es ihn erreicht hat?

Estimateable User Stories sind schätzbar

Gute User Stories sind außerdem abschätzbar. Dies ist eine große Herausforderung, da eine User Story aus geschäftlicher Sicht geschrieben werden sollte, während die Schätzung der Größe einer Story etwas ist, das die Entwickler tun müssen. Sie müssen abschätzen, wie viel Zeit es dauern wird, den Code für diese User Story zu entwickeln.

Das bedeutet, dass jede User Story genügend Details enthalten muss, um eine vernünftige Schätzung der Komplexität der Story vornehmen zu können. Als wir über „verhandelbar“ sprachen, haben wir jedoch gelernt, dass eine Story nicht so detailliert sein sollte, dass sie die Entwickler bei der Lösungsfindung einschränkt oder den Fachbereich daran hindert, die Story zu ändern.

Hier gilt es, eine gute Balance zu finden. Schreiben Sie Ihre User Story mit gerade genug Details, damit das Team versteht, was es erstellt und warum. Es ist eher ratsam, zu wenig Einzelheiten anzugeben. Wenn das Agile-Team den Aufwand für eine User Story während der Release-Planung nicht abschätzen kann, wird es so lange mit dem Product Owner oder dem Autor sprechen, bis es das kann.

Small User Stories sind klein

Gute User Stories enthalten gerade genug Angaben, um einem Softwareentwickler den Einstieg zu ermöglichen. Klein bedeutet in diesem Zusammenhang, dass es eine Größe hat, die ein Entwickler innerhalb weniger Tage oder höchstens eines einzigen Sprints programmieren kann. Es sollte nie länger als zwei Wochen dauern, bis die Codierung abgeschlossen ist.

Wenn eine User Story zu groß ist (d.h. ein Epic), muss sie in mehrere kleinere Stories aufgeteilt werden. Diesen Vorgang nennt man auch Zerlegung oder Splitting der User Story. Später in diesem Beitrag werde ich einige Tipps und Tricks dazu hinzufügen.

Testable User Stories sind prüfbar

In Lean/Agile-Ansätzen haben wir endlich erkannt, dass die von den Abnahmekriterien abgeleiteten Akzeptanztestszenarien die wahren Anforderungen sind, die die IT benötigt.

Szenariosprachen wie Gherkin drücken die geschäftlichen Anforderungen auf eine Weise aus, die für Entwickler leichter zu verstehen ist. Das Erstellen von User Story Akzeptanzkriterien (ob in Form von Szenarien oder in irgendeiner anderen Form) vor dem Schreiben des Codes ist entscheidend für den Erfolg von Agile/Lean-Vorhaben.

Im letzten Abschnitt dieses Beitrags gebe ich Ihnen ein paar Anregungen, wie Sie gute Gherkin-Szenarien ausarbeiten können. Das Schreiben guter Testszenarien im Gherkin Given-When-Then-Format wird zu einer Grundvoraussetzung für jeden, der für die Kommunikation von User-Anforderungen an die IT verantwortlich ist.

Wenn Sie einmal angefangen haben, User Stories zu schreiben, werden Sie eine Vielzahl von Stories haben – einen ganzen Backlog voll davon. Wie geht es nun weiter?

User Story Elaboration erfordert Kommunikationsfähigkeit UND Analysetechniken

Die nächste Herausforderung für agile Teams ist die kontinuierliche Aufschlüsselung, Verfeinerung und Ausarbeitung von User Stories. In diesem Fall bedeutet „kontinuierlich“ verschiedene Aufgaben zu verschiedenen Zeiten im Softwareentwicklungszyklus. Es kann zum Beispiel bedeuten:

• Verfeinerung des Product Backlogs am Ende jedes Sprints
• Analysieren und Dimensionieren einer User Story während der Release-Planung
• Hinzufügen von Details zu einer User Story, während sich das Gespräch zwischen Entwicklern und Endbenutzern entfaltet
• . . .

Das Ausarbeiten und Analysieren von User Stories kann der schwierigste Teil des agilen Prozesses sein. Um diese zu meistern, benötigen Sie zwei unterschiedliche Kompetenzen:

• Kommunikationsfähigkeiten
  (das Wichtigste an einer User Story ist schließlich das Gespräch)
• Eine Vielzahl von Techniken, Tools und Tricks der Business-Analyse
  (Story-Zerlegung und -Splitting, Definition von Abnahmekriterien, Prozess- und Datenmodelle, Funktionale Dekomposition, Erstellung von Abnahmetests usw.)

Die Bedeutung einer effektiven Kommunikation wird oft unterschätzt. Tatsächlich können gute Kommunikationsfähigkeiten über den Erfolg oder Misserfolg Ihres Produkts oder Ihrer Anwendung entscheiden.

Kommunikation und Moderation sind der Schlüssel zu produktiven agilen Meetings und Workshops

Kollaboration, Kollaboration, Kollaboration. So lautet die Devise in der Philosophie der schlanken und agilen Softwareentwicklung. Zusammenarbeit ist ein Grundprinzip und effektive Meetings sind ein wesentlicher Bestandteil der Kollaboration.

Wenn Sie an einer agilen Besprechung oder einem Workshop teilnehmen,

• arbeiten Sie mit Ihren Teammitgliedern zusammen,
• besprechen mit Ihnen, wie Sie es beim nächsten Mal besser machen können und
• treffen gemeinsam Entscheidungen darüber, was das Beste für Ihre Kunden und Ihr Unternehmen ist.

Das ist die Stärke der User Story Collaboration: zusammen auf ein gemeinsames Ziel hinarbeiten

Workshops sind von Natur aus kollaborativ, aber das gilt nicht für alle Meetings. Allerdings sind alle Formen von agilen Meetings kollaborativ. In einem schlanken/agilen Umfeld haben Workshops und Teamsitzungen nur einen Zweck: zu diskutieren und zu entscheiden! Die Zusammenarbeit ist das, was Agile so gut funktionieren lässt. Das ist es, was Workshops zu einem so wichtigen Bestandteil moderner Softwareentwicklungsmethoden macht. 

Betrachten wir zum Beispiel drei gängige Arten von Meetings in einer agilen Umgebung:

• Ein großer User-Story-Workshop, um ein Product Backlog zu erstellen oder aufzufüllen.
• Ein 3-Amigo-Gespräch, zur Besprechung einer User Story für die bevorstehende Entwicklung.
• Ein 1-on-1 Interview mit einem Fachexperten zur Klärung einer volatilen Funktion oder User Story.

Alle arbeiten auf ein kollaboratives Ergebnis oder eine bestimmte Leistung hin. Um die Ziele zu erreichen, ist ein gewisses Maß an Zusammenarbeit erforderlich. Kommunikationsfähigkeiten helfen Ihnen, die Sichtweise anderer zu verstehen, so dass Sie effektiver zusammenarbeiten können. Die Schwierigkeiten nehmen leider oft zu, wenn wir versuchen, einen Konsens zu erzielen.

Wir alle haben das schon erlebt. Eine Gruppe von Leuten kommt mit einer losen Tagesordnung und ohne Moderator zusammen, und so entwickelt sich das Treffen zu einem chaotischen Durcheinander von widersprüchlichen Ideen, Tangenten und Nebengesprächen, die zu nichts führen.

Es ist frustrierend für alle Beteiligten, weil es so einfach zu sein scheint: Man versammelt alle an einem Ort, lässt sie darüber reden, was sie tun wollen, und nutzt dann das, was sich aus dieser Diskussion ergibt, um gute Entscheidungen zu treffen.

Aber das ist wie der Versuch, durch ein Minenfeld zu laufen – man wird mit Sicherheit in die Luft gesprengt. Es funktioniert nur, wenn Sie jemanden dabei haben, der weiß, was er tut, und die Sache in die Hand nimmt.

Unabhängig davon, wie viele Personen an einer Sitzung teilnehmen, jemand muss den Prozess der Kollaboration gestalten und leiten um die Ziele zu erreichen und den Zweck des Treffens zu verwirklichen.

Die Gruppe kann die Tagesordnung festlegen und die Ziele bestimmen, aber jemand muss sich während des Treffens auf die Einhaltung der Tagesordnung konzentrieren, um das Ziel zu erreichen. Das ist die Rolle des Moderators (Facilitators), und diese Rolle können verschiedene Teilnehmer von einem Tagesordnungspunkt zum nächsten übernehmen. Sogar innerhalb ein und derselben Sitzung.

User Story Gespräche und Workshops sind nichts für schwache Nerven

Doch Moderation kann frustrierend sein. Die Teilnehmer sind sich nicht immer über die Tagesordnung einig, Konzepte geraten ins Abseits, und das Gespräch dreht sich im Kreis.

Die Situation wird dadurch kompliziert, dass jeder Mensch eine andere Persönlichkeit hat und jede Persönlichkeit einen anderen Ansatz erfordert. Wir leben in einer Welt, in der sich aggressive und geradlinige Menschen oft durchsetzen, während zurückhaltendere, zweideutige und passive Angreifer oft beiseite geschoben werden.

Mit solchen Situationen umzugehen, kann selbst für die erfahrensten Moderatoren schwierig sein. Wenn dann noch virtuelle Meetings dazukommen, ist das Chaos vorprogrammiert. Zwar lassen sich Meetings nicht vermeiden, wenn Sie mit anderen zusammenarbeiten wollen, aber Sie können sich das Leben leichter machen, indem Sie die folgenden drei Fähigkeiten entwickeln:

• Planung und Vorbereitung eines Workshops/Meetings, um einen reibungslosen Ablauf zu gewährleisten
• Know-how zur ergebnisorientierten Durchführung eines Workshops/Meetings
• Erkennen, dass es nicht vorbei ist, wenn es vorbei ist – ein gutes Follow-up ist unerlässlich

Da People Skills und Facilitation ein so großes Thema ist, hebe ich es mir für einen anderen Beitrag auf. Wenn Sie jedoch daran interessiert sind, mehr über diese Themen zu erfahren, schauen Sie sich bitte meinen englishsprachigen Kurs How to Facilitate Agile Meetings and User Story Workshops an.

Hier sind zwei Previews aus diesem Kurs:

• How to Prepare and Start Face-to-Face or Virtual Requirement Meetings Effectively
• Creative Collaboration Is at the Heart of an IT Business Analyst’s Day

Nachdem wir nun die Kommunikations- und Moderationsfähigkeiten behandelt haben, richten wir unsere Aufmerksamkeit auf die nächste Kompetenz, die Sie während der Ausarbeitung benötigen: das Aufschlüsseln und Splitten von User Stories!

User Story Dekomposition: So zerlegen Sie Epics, Features und User Storys

Die Zerlegung von User Stories ist der Prozess, bei dem eine User Story aufgeschlüsselt wird, um die Low-Level-Funktionalität zu spezifizieren. Auf diese Weise können Sie besser verstehen, was das Team entwickelt, Bereiche identifizieren, in denen Probleme auftreten können, und ein besseres Verständnis für die Bedürfnisse der Endbenutzer entwickeln.

Bei der Ausarbeitung von User Stories hat das agile Team zwei Hauptaufgaben:

1. User Stories und Epics aufteilen oder richtig skalieren
2. User Story Akzeptanzkriterien schreiben

Zur Klarstellung: Epics sind sehr große User Stories, die einfach zu groß für ein einzelnes Release oder eine Iteration sind.

Das Aufteilen von User Stories in Sub-Stories erleichtert es Entwicklern, sie zu verstehen, zu priorisieren und umzusetzen. Dieser Vorgang ist allgemein als User Story Splitting oder Story Slicing bekannt.

Die Größe einer User Story hängt von mehreren Faktoren ab, darunter Teamerfahrung und Arbeitsgeschwindigkeit sowie Iterationslänge. Idealerweise sollten User Storys ungefähr so groß sein, wie das Entwicklungsteam in einer Iteration bewältigen kann.

Das Splitten von User Stories ist eine Kernkompetenz für jedes agile Team, aber auch für Repräsentanten der Business Community. Um effektiv zu sein, sollte Story Splitting eine Gruppenarbeit sein.

Lesen Sie meinen Beitrag „8 Techniken zum richtigen Aufteilen (Splitten) von User Stories”, um ein paar einfache Techniken zum Aufteilen von User Stories zu lernen, gefolgt von einer kurzen Beschreibung fortgeschrittenerer Techniken.

User Story Akzeptanzkriterien – Der Schlüssel zum Erfolg

User Stories sind ein wertvolles Werkzeug für die agile Softwareentwicklung. Allerdings reichen User Stories allein nicht aus, um die Arbeit eines technischen Teams zu steuern. Es werden Akzeptanzkriterien benötigt, um gut definierte und testbare Stories zu erstellen, die von den technischen Teams umgesetzt werden können.

Mit Hilfe von Akzeptanzkriterien kann sichergestellt werden, dass sich alle Beteiligten darüber einig sind, was getan werden muss, bevor die Entwicklung einer Softwarelösung fortgesetzt werden kann. Sie legen fest, wie die Anwendung sowohl aus funktionaler als auch aus nicht-funktionaler Sicht implementiert werden soll.

Akzeptanzkriterien beantworten auch die Frage: Woher wissen wir, wann wir fertig sind?

Für viele Entwickler sind Akzeptanzkriterien die „echten“ Anforderungen

Akzeptanzkriterien werden von vielen als die eigentlichen Anforderungen angesehen – sie werden in einer Detailtiefe geschrieben, die in einer User Story nicht erfasst werden kann. Wie die User Stories werden auch die Akzeptanzkriterien in der Regel geschrieben, bevor mit der Codierung begonnen wird.

Der Erfolg oder Misserfolg von Projekten hängt von der Fähigkeit des Teams ab, die definierten und vom Kunden erwarteten Akzeptanzkriterien zu erfüllen. Wenn Sie die Kriterien im Voraus klar festlegen, vermeiden Sie Überraschungen am Ende eines Sprints oder einer Version und sorgen für ein höheres Maß an Kundenzufriedenheit.

Wenn Sie Akzeptanzkriterien für eine User Story schreiben, ist es Ihr Ziel, klar auszudrücken, was Sie als Ergebnis dieser User Story erwarten. Die Abnahmekriterien bieten Ihnen auch die Möglichkeit, Annahmen oder nicht offensichtliche Faktoren mitzuteilen, die in der Beschreibung der Story vielleicht nicht deutlich geworden sind. Denken Sie bei der Definition der Kriterien an zwei Fragen:

• Was ist das gewünschte Ergebnis dieser User Story?
• Welche verschiedenen Szenarien sind denkbar, damit die Story akzeptiert wird?

Arten von Abnahmekriterien: Funktionale Anforderungen vs. nichtfunktionale Anforderungen

User Acceptance Criteria lassen sich in 2 Kategorien einteilen:

Funktionale Story-Kriterien (auch als funktionale Spezifikationen bezeichnet) beschreiben die Aktionen, die ein Benutzer oder ein System ausführen muss, um eine Geschäftsfunktion erfolgreich zu erfüllen. Sie sind am effektivsten, wenn sie aus der Sicht derjenigen erstellt werden, die die Software nutzen werden, und nicht aus der Sicht derjenigen, die sie implementieren werden. Ziel der funktionalen Akzeptanzkriterien ist es, das von der Software erwartete Verhalten klar zu formulieren.

Nichtfunktionale Story-Kriterien beschreiben, wie gut die Software / das Produkt funktionieren muss. Diese Anforderungen leiten sich häufig aus nichtfunktionalen Erwägungen wie Leistung, Benutzerfreundlichkeit, Interoperabilität, Sicherheit usw. ab. Nicht-funktionale Anforderungen haben in der Regel einen großen Einfluss auf die Kosten, die Qualität und den Zeitplan des Projekts.

Funktionale und nicht-funktionale Akzeptanzkriterien sind die Bausteine der Akzeptanzprüfung. Sie bilden den Rahmen, auf dem Abnahme- oder Akzeptanztests aufgebaut werden können.

Akzeptanztests stellen nicht nur sicher, dass der Code wie erwartet funktioniert, sondern auch, dass er sicher, zugänglich und effizient ist und dass die Benutzererfahrung nahtlos ist.

Warum sind Akzeptanzkriterien wichtig?

Die Abnahmekriterien dienen dazu, unsere Gespräche mit den Entwicklern auf das zu konzentrieren, was wirklich wichtig ist – die funktionalen und nicht-funktionalen Spezifikationen der User Story. Sie helfen dabei, sicherzustellen, dass das Team auf der Grundlage des Feedbacks von Stakeholdern und Benutzern das Richtige bauen.

Akzeptanzkriterien dienen auch als Sicherheitsnetz für das Team, um zu gewährleisten, dass es bei der Implementierung einer Story keine Lücken in der Abdeckung gibt, dass alle Beteiligten auf derselben Seite stehen und dass bei der Implementierung einer Story keine Schritte fehlen.

Darüber hinaus gewährleisten User Story Acceptance Criteria, dass genügend Details vorhanden sind, damit die Entwickler zuverlässig abschätzen können, wie viel Arbeit eine Aufgabe in Anspruch nehmen wird, und die Projektmanager die Aufgaben entsprechend planen können.

Einer ihrer wichtigsten Nutzen ist jedoch, dass sie für die Definition von Akzeptanztests verwendet werden, um nachzuweisen, dass die implementierte User Story gemäß den Benutzerspezifikationen funktioniert.

Wie schreibe ich Akzeptanzkriterien für User Storys?

Die erste Frage, die sich beim Verfassen von Abnahmekriterien stellt, lautet: „Welches Format soll ich verwenden?“ Diese Frage ist nicht leicht zu beantworten, es sei denn, Sie arbeiten in einem Unternehmen, das ein eigenes, individuelles Format zum Schreiben von Akzeptanzkriterien entwickelt hat.

Einige Unternehmen verwenden Checklisten, andere Gherkin Given-When-Then-Szenarios, einige haben Business Rules, andere funktionale Feature-Listen. Viele haben eine Mischung daraus.

Ihr Ansatz zum Schreiben von Akzeptanzkriterien hängt auch davon ab, welche Art von Akzeptanztests das Team benötigt. Wenn Sie Ihre Tests mit Cucumber oder einem anderen Testtool automatisieren, werden Sie sie höchstwahrscheinlich im Gherkin-Format schreiben. Ich werde Ihnen im letzten Abschnitt dieses Beitrags mehr über die Gherkin-Sprache erzählen.

Funktionale und nicht-funktionale Anforderungen sind Akzeptanzkriterien

Die Zerlegung einer User Story in ihre funktionalen und nicht-funktionalen Komponenten (auch bekannt als funktionale Dekomposition) ist eine effektive Technik, um eine User Story zu detaillieren.

Bei der funktionalen Dekomposition wird die User Story in kleinere Stories oder Aufgaben unterteilt. Wenn Sie die User Story als eine Reihe miteinander verbundener kleinerer Schritte betrachten, können Sie das große Ganze sehen und die Komplexität verschwindet.

Zu diesem Zeitpunkt wird nicht darüber gesprochen, wie das System zu entwickeln ist oder welche Technologien verwendet werden sollen. Stattdessen konzentriert sich die Dekomposition auf die Übersetzung der Benutzeranforderungen in funktionale und nicht-funktionale Anforderungen (oder Lösungsanforderungen in der IIBA-Terminologie). Wie bereits erwähnt:

• Funktionale Anforderungen beschreiben, was die Software tun soll
• Nichtfunktionale Anforderungen (NFRs) beschreiben, wie gut die Software funktionieren soll

Um die funktionale Dekomposition besser zu verstehen, haben Angela und ich diesem Thema ein Kapitel in unserem Buch User Stories: Geschäftsziele in IT-Lösungen umsetzen gewidmet. Es ist voll von Beispielen aus dem wirklichen Leben. 

Funktionale Dekomposition: Spezifikation von Softwareanforderungen

Die funktionale Dekomposition ist kein neues Konzept. Es hört sich technisch an, ist aber einfach und etwas, das Sie wahrscheinlich schon tun, ohne es zu merken. Stellen Sie sich die funktionale Dekomposition als eine Methode vor, die eine User Story in alle ihre Teile zerlegt:

• Funktionale Anforderungen beschreiben die Funktionen, die die Lösung ausführen wird, UND die damit verbundenen Daten, die die Funktionen verarbeiten werden.
•  
• Qualitätsanforderungen (Nichtfunktionale Anforderungen) definieren die Merkmale und Eigenschaften, die eine digitale Lösung aufweisen muss.
•  
• Constraints/Einschränkungen (Nichtfunktionale Anforderungen) sind absolute Einschränkungen, Regeln, Gesetze und Umweltfaktoren, die bei jeder Lösung berücksichtigt werden müssen.

Der grundlegende Unterschied zwischen Qualitäten und Constraints ist die Frage, was bei Nichteinhaltung dieser Anforderungen zu erwarten ist.

• Wenn eine Qualitätsanforderung nicht erfüllt wird, ist der Stakeholder mit der Lösung unzufrieden.
• Wenn eine Einschränkung verletzt wird, kann die Lösung nicht implementiert werden.

Um Nacharbeit zu vermeiden oder das Risiko eines Fehlschlags zu minimieren, ist es wichtig, so viele Einschränkungen wie möglich so früh wie möglich zu entdecken.

Was sind nichtfunktionale Anforderungen (NFRs)?

Qualitätsanforderungen und Constraints sind Attribute einer Lösung, die messen, wie gut die Software funktionieren muss. Fehlende und missverstandene nicht-funktionale Anforderungen sind oft Schuld am Scheitern von Produkten und Projekten.

In den Annalen der IT-Projekte gibt es viele Beispiele, in denen Anwendungen jede einzelne definierte Anforderung umgesetzt haben. Sie waren gut genug, um diese Anforderungen zu erfüllen, aber nicht gut genug, um die Anforderungen der Kunden zu erfüllen.

Als die Obamacare-Website online ging, versuchten Millionen von Amerikanern, sich auf der Website anzumelden. Die hohe Nachfrage führte zu Abstürzen, und selbst wenn sie funktionierte, wurden die Wartezeiten in Stunden gemessen.

Das Scheitern der Website war darauf zurückzuführen, dass die nichtfunktionalen Anforderungen nicht beachtet wurden. Anträge konnten zwar sofort nach ihrer Einreichung bearbeitet werden, aber es dauerte einfach zu lange, bis sie ankamen. Erst nach monatelanger Überarbeitung und Feinabstimmung begann die Website, das Vertrauen der Kunden zu gewinnen.

Die NFRs, die für das gesamte Produkt von Bedeutung sind, sollten zu Beginn einer Initiative definiert werden. Die NFRs, die für eine Story oder ein Feature einzigartig sind, sollten während einer Iteration im Rahmen der Entwicklung ermittelt werden.

Wenn Sie mehr über funktionale Dekomposition wissen wollen, was sie ist und wie man sie durchführt, lesen Sie meinen Beitrag Funktionale und nicht-funktionale Anforderungen: Was sind sie und wie erstellt man sie? Er beschreibt detailliert und mit Beispielen aus der Praxis einige Tipps und Tricks, mit denen sich funktionale und nicht-funktionale Anforderungen schnell ermitteln lassen.

Benutzerakzeptanztests sind wichtiger als je zuvor

In der Vergangenheit wurde User Acceptance Testing (UAT) als eines der Dinge angesehen, die Sie vielleicht in Ihren Zeitplan einbauen könnten, wenn Sie Zeit übrig hätten. Es war ein kleiner zusätzlicher Schritt im Entwicklungszyklus, kurz bevor Sie das Produkt auf den Markt brachten.

Kurz gesagt, UAT litt unter einem Mangel an Respekt und Aufmerksamkeit; es wurde oft wie ein notwendiges Übel behandelt. Aber die Zeiten haben sich geändert, und auch UAT hat sich weiterentwickelt.

Benutzerabnahmetests sind heute wichtiger denn je. Und warum? Weil der zunehmende Wettbewerb bedeutet, dass Unternehmen es sich nicht mehr leisten können, die Zufriedenheit ihrer Kunden aufs Spiel zu setzen – sonst werden sie schnell vom Markt verdrängt.

Für Unternehmen ist es heute von entscheidender Bedeutung, ihren Kunden regelmäßig neue Funktionen anbieten zu können. Diese neuen Funktionen können zu höheren Verkaufszahlen und zufriedeneren Kunden führen, aber nur dann, wenn Sie sie zum richtigen Zeitpunkt bereitstellen können.

Aus diesem Grund ist die Abnahmeprüfung ein integraler Bestandteil moderner Entwicklungsprozesse und nicht nur ein nachträglicher Einfall. Die Absicht ist immer noch dieselbe: zu überprüfen, ob die Software die Erwartungen der Kunden und Endbenutzer erfüllt.

Akzeptanzkriterien vs. Akzeptanztests: Was ist der Unterschied?

Wie bereits erwähnt, Akzeptanzkriterien sind die Bedingungen, die erfüllt werden müssen, um eine User Story als vollständig zu akzeptieren. Sie dienen den Entwicklern als Leitfaden für den Entwurf und die Codierung und werden auch von den Stakeholdern und dem Product Owner verwendet, um sich darüber zu einigen, was das Team entwickeln soll.

Abnahmetests sind Szenarien, die von Abnahmekriterien abgeleitet werden. Mit anderen Worten, jedes Akzeptanzkriterium kann einen oder mehrere Akzeptanztests haben. Sie belegen, dass die gelieferte Lösung das tut, was in den Abnahmekriterien vereinbart wurde.

Wenn Sie beispielsweise ein Auto testen, haben Sie möglicherweise ein Akzeptanzkriterium, das besagt: „Das Auto muss auf allen Straßen fahren können, ohne eine Panne zu haben.“ Sie könnten dann mehrere Abnahmetests durchführen, z. B. das Fahren auf einer unbefestigten Straße mit 40 km/h oder das Fahren auf einer Autobahn mit 130 km/h.

Nachdem wir nun ein gemeinsames Verständnis davon haben, was Akzeptanzkriterien und Akzeptanztests sind, wollen wir uns eine weit verbreitete Technik ansehen, mit der man beide ausdrücken kann – Gherkin Given-When-Then-Scenarios (zu deutsch, Gegeben-Wenn-Dann-Szenarien).

Verwendung von Gherkin-Szenarien für Akzeptanzkriterien und/oder Akzeptanztests

Gegebene Wenn-Dann-Szenarien erleichtern Ihrem Team die Erstellung von Akzeptanzkriterien oder User-Tests. Die Verwendung der Gherkin-Syntax (Gegeben-Wenn-Dann) ist eine bewährte Methode zur Beschreibung der Geschäftslogik Ihrer Anwendung. Szenarien liefern den Kontext, indem sie detailliert beschreiben, wie Benutzer mit dem Produkt oder der Anwendung interagieren werden.

Die Einfachheit der Gherkin-Sprache ermöglicht es Geschäftsteams (z. B. Product Owner, Domänenexperte, Endbenutzer, Business Analysten usw.), Akzeptanztests in einer Sprache zu dokumentieren, die sowohl von der Geschäftswelt als auch von Entwicklern und Testern verstanden wird. Dies fördert die Zusammenarbeit und das gegenseitige Verständnis für die erforderlichen Benutzertests.

Die Gherkin-Syntax, auch bekannt als Given-When-Then, ist ein narratives Format zur Spezifikation des funktionalen Verhaltens von Software. Sie besteht aus drei Teilen:

GEGEBEN (die Vorbedingung), WENN (die Aktion), DANN (das erwartete Ergebnis)

Der Zweck der Gegeben-Wenn-Dann-Methode ist es, sicherzustellen, dass alle Beteiligten genau wissen, was zu tun ist, bevor sie mit der Entwicklung beginnen.

• GEGEBEN setzt den Kontext für das, was passieren muss, bevor die User Story beginnen kann
• WENN definiert das Ereignis oder die Handlung, die das Szenario auslöst
• DANN definiert eindeutig, was passiert, wenn das Szenario erfolgreich ist

Beim Schreiben der GEGEBEN Anweisung, sollten Sie alle für einen erfolgreichen Test erforderlichen Setup-Daten bereitstellen. Dazu gehören Hardwarebedingungen sowie Daten, die bestimmte Kriterien erfüllen müssen, um den Test durchzuführen.

WENN definiert alle Ereignisse, die das Szenario auslösen. Es ist die Interaktion zwischen einem Stakeholder des Systems und dem System selbst.

Schließlich definiert DANN die Ergebnisse, die bestimmen, ob ein Test erfolgreich war. Wenn die Bedingungen in der DANN-Klausel erfüllt sind, ist der Test erfolgreich; andernfalls schlägt er fehl. Dabei kann es sich um ein berechnetes Ergebnis eines bestimmten Wertes handeln, aber auch um ein beliebiges anderes überprüfbares Ergebnis.

Was ist die Cucumber-HINTERGRUND-Anweisung?

Manchmal stellen Sie fest, dass mehrere Szenarien die gleichen Setup-Bedingungen erfordern. Hier kommt die Gherkin-Sprache ins Spiel, die eine einfache Lösung bietet, die Ihnen Zeit und Mühe erspart. Mit dem Schlüsselwort BACKGROUND oder HINTERGRUND können Sie Setup-Kriterien für eine Gruppe von Szenarien definieren.

Wenn Sie GEGEBEN-Anweisungen haben, die in jedem Szenario wiederholt verwendet werden, ist es eine gute Idee, diese Anweisungen vor dem ersten Szenario mit dem Schlüsselwort „BACKGROUND“ zu platzieren. Alle Gherkin-Anweisungen zwischen der BACKGROUND-Anweisung und dem ersten SZENARIO werden als erster Schritt für jedes SZENARIO in einer Feature-Datei ausgeführt.

Dies kann z. B. für Benutzerprofilinformationen oder andere Informationen, die für alle Szenarien erforderlich sind, nützlich sein.

Hier ist ein Gherkin User Story Beispiel mit Given-When-Then und BACKGROUND:

User Story:

Um ihre Karrierewege zu planen (WARUM), können Studenten (WER) Kurse (WAS) einsehen, die sie noch belegen müssen, basierend auf ihren BASE-Ergebnissen (QUALIFIER).

Szenarien:

Um die Redundanz zu reduzieren, habe ich zwei Setup-Bedingungen in einer Background-Anweisung verwendet. Die erste gibt an, dass Fred bei der Website angemeldet sein muss, und die zweite besagt, dass er den Business Analysis Skills Evaluation (BASE)-Test absolviert haben muss.

Effizienteres Testen einer Lösung mit verschiedenen Datensätzen

Was passiert, wenn man ein Szenario mehrmals mit unterschiedlichen Daten testen möchte? Müssen Sie dann für jeden Datensatz ein eigenes Szenario erstellen? Das wäre eine echte Zeitverschwendung – definitiv nicht LEAN!

Diese Situation ist beim Testen sehr häufig. Typischerweise reicht ein einziger Test nicht aus, um zu beweisen, dass die Funktion so reagiert, wie wir es beabsichtigt haben. Wir müssen nachweisen, dass die Anwendung unter verschiedenen Umständen korrekt reagiert.

Das Umschreiben von Szenarien mit vielen verschiedenen Datenwerten wird schnell mühsam und repetitiv. In meinem Beitrag Mit Gherkin-Szenarien schnell und einfach Akzeptanzkriterien und Abnahmetests erstellen beschreibe ich eine Reihe von einfach anzuwendenden Techniken, mit denen Sie diesen Aufwand reduzieren können.

Szenariogliederungen mit Beispieltabellen zum schnellen Testen von Datenvariationen

Eine Szenariogliederung oder Szenario Outline verwendet ebenfalls die Gherkin-Syntax. Sie enthält jedoch Variablen anstelle von Konstanten, um die Ausführung einer Vielzahl von Tests mit einer einzigen Scenario-Anweisung zu ermöglichen. Es werden keine konstanten Werte wie „Fred“ verwendet, sondern es wird auf eine „Person“ oder einen „Namen“ verwiesen.

Auf die Szenariogliederung folgt eine Beispieltabelle, die die verschiedenen Werte enthält, die den einzelnen Variablen zugeordnet sind. Jede Zeile in der Beispieltabelle steht für einen einzelnen Test.

Zum Abschluss

User Stories sind ein leistungsfähiges Kommunikationsinstrument, um Geschäfts- und Entwicklungsteams aufeinander abzustimmen. Sie ersetzen überflüssige Dokumentation durch wichtige Gespräche, damit jedes Teammitglied versteht, was von der anderen Seite benötigt wird.

Meiner Meinung nach lässt sich die Stärke des User Story-Paradigmas am besten in zwei User Stories zusammenfassen:

Als Domain-Experte kann ich meine geschäftlichen Anforderungen in meinen eigenen Worten ausdrücken, um sicherzustellen, dass die Entwickler das liefern, was ich brauche.

und

Als Entwickler kann ich einen ständigen Dialog mit den Domänenexperten führen, um sicherzustellen, dass meine Lösung die Absicht hinter einer User Story erfüllt.

Wenn Sie diese beiden Epics umsetzen können, werden Ihre digitalen Lösungen auf die Bedürfnisse und Wünsche Ihrer Kunden abgestimmt sein, um den Erfolg Ihrer Produkte zu gewährleisten.

Bitte teilen Sie unten Ihre Erfahrungen mit: z.B., was funktioniert hat, was nicht und warum. Wir lernen alle voneinander!