In 4 Schritten von der User Story zur Anforderung

Für die Nutzung von User Stories gibt es gute Gründe. Durch eine User Story wird eine Anforderung für alle Beteiligten verständlicher und Korrekturschleifen lassen sich vermeiden. Im Ergebnis steht die neue Software schneller zur Verfügung. Im folgenden Beispiel aus dem Verwaltungsalltag sehen wir, wie die Definition einer User Story eine Anforderung konkreter macht und wie wir mit den User Stories weiterarbeiten.

Geplant ist die Entwicklung einer App, mit der sich Eltern auf einer Karte die Kitas im näheren Umkreis anzeigen lassen und Kontakt aufnehmen können.

1. Formulierung der User Stories

Zu diesem Kundenwunsch könnten die folgende User Stories entstehen:

  • User Story "Endgeräteunabhängigkeit für Eltern": Als Elternteil möchte ich egal von welchem Endgerät aus auf die App zugreifen können, damit ich auch zukünftig unabhängig bin bei meiner Kaufentscheidung für ein Smartphone.
  • User Story "Kartenansicht für Eltern": Als Elternteil möchte ich die Kitas auf einer Karte angezeigt bekommen, damit ich die Lage der KiTa zu meinem Wohnort besser einschätzen kann.
  • User Story "Infodetails für Eltern": Als Elternteil möchte ich nähere Informationen zu der Einrichtung angezeigt bekommen, damit ich mir ein Bild von der Situation vor Ort machen kann.
  • User Story "Kontaktaufnahme ermöglichen": Als Elternteil möchte ich die Möglichkeit haben die Einrichtung direkt mit dem Smartphone kontaktieren zu können, damit ich mit Kontaktinformationen nicht abschreiben muss.

2. Klassifizierung der einzelnen User Story

Im nächsten Schritt klassifizieren wir die User Stories. Dazu orientieren wir uns am INVEST-Schema, das Bill Wakes für den Aufbau einer User Story entwickelt hat.

  • Independent (I): Beschreibung ist nicht von einer anderen Beschreibung abhängig.
  • Negotiable (N): Beschreibung dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden. Zu viele Details sollten vermieden werden, um Flexibilität zu bewahren, damit das Team je nach Situation entscheiden kann, welche Bestandteile der Beschreibung umgesetzt werden.
  • Valuable (V): Die Beschreibung stellt immer einen Vorteil für den User, Kunden oder Auftraggeber dar.
  • Estimatable (E): Die Beschreibung ist schätzbar. Sie hat also so viele konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann. Das Team muss in der Lage sein, die Beschreibung für die Planung zu nutzen.
  • Small (S): Die Beschreibung hat die richtige Größe. Große Stories/Beschreibungen sind schwerer abzuschätzen und zu planen. Für die Iterationsplanung sollte die Story/Beschreibung eine geeignete Größe haben, sodass sie innerhalb der Iteration konzipiert, programmiert und getestet werden kann.
  • Testable (T): Sie kann getestet werden. Durch das Dokumentieren von Akzeptanzkriterien oder das Beschreiben der Story als "abgeschlossen", können Testfälle abgleitet werden.

Die vorgenannten Beschreibungen konzentrieren sich darauf, wie konkret oder detailliert die User Story ist. Hinzu kommen die Akzeptanzkriterien.

3. Akzeptanzkriterien der User Story

Die Akzeptanzkriterien einer User Story sind für den Erfolg entscheidend. Wir legen aus Sicht der Verwaltung Akzeptanzkriterien fest, um zu entscheiden, ob wir eine User Story "abnehmen", also in der Konzeption berücksichtigen. Mit der Abnahme tragen wir ein entscheidendes Detail zur fertigen Software bei.

In unserem Beispiel könnte die vorab definierte User Story "Endgeräteunabhängigkeit für Eltern" mit den definierten Akzeptanzkriterien so aussehen: Als Elternteil möchte ich egal von welchem Endgerät aus auf die App zugreifen können, damit ich auch zukünftig unabhängig bin bei meiner Kaufentscheidung für ein Smartphone.

Das Akzeptanzkriterium des Kunden aus der User Story lautet: App funktioniert fehlerfrei auf aktuellen iOS- und Android-Smartphones

Für die Entwicklung leitet sich ab: Der Kunde nimmt die User Story erst dann ab, wenn die App auf iOS und Android fehlerfrei funktioniert. Nicht entscheidend wäre die fehlerfreie Nutzung auf Windows Phones. Zwar könnte man darauf schließen in der User Story, aber nicht aus dem Akzeptanzkriterium. Die Test-Szenarios für die Software beinhalten Funktionstests mit aktuellen iOS- und Android-Smartphones, nicht aber Funktionstests mit Windows-Phones.

Wir sehen, den Akzeptanzkriterien kommt eine zentrale Bedeutung zu. Der Kunde, also die Verwaltung, sollte deswegen der Definition viel Aufmerksamkeit widmen.

4. Die Definition von Personas

Gehen wir zurück zu unserem Beispiel, dem KiTa-Finder. Neben der Zielgruppe der Eltern als Nutzer gibt es gibt noch weitere Rollen, die im Rahmen der App-Entwicklung mit ihren Anforderungen einbezogen werden müssen. Typischerweise gibt man diesen Rollen kurze Bezeichnungen, wie beispielsweise "Herausgeber" (als Herausgeber der App im Appstore bzw. im Impressum benannt) oder "KiTa-Leitung". Dadurch entstehen während der Konzepterstellung weitere User Stories, wie die beiden nachfolgenden:

  • User Story "Herausgeber sichtbar machen": Als Herausgeber möchte ich von den Eltern wahrgenommen werden, um mich als Ansprechpartner bei der Kitaauswahl zu etablieren.
  • User Story "Betreuungseinrichtung optisch präsentieren": Als KiTa-Leitung möchte ich Bilder meiner Betreuungseinrichtung hochladen können, damit interessierte Eltern sich ein aktuelles Bild von meiner Einrichtung machen können.

Um sich in der Entwicklung ein besseres Bild von den Usern bzw. Rollen machen zu können, entwickeln wir so genannte Personas, die der benannten Rolle neben einem Namen auch biografische Details zuordnen.

Am Beispiel der KiTa-Leitung könnte die Persona wie folgt aussehen: Rita Rudolfs, 54 Jahre, verheiratet, 2 erwachsene Kinder. Sie ist gelernte Kinderkrankenschwester, arbeitet aber seit 18 Jahren als Erzieherin, davon die letzten 4 Jahre als KiTa-Leitung.

Was zuerst unwichtig für die Softwareentwicklung erscheint, hilft dabei, weitere, oft nicht-funktionale, Anforderungen an die Software abzuleiten. Das könnten zum Beispiel sein:

  • Einfache Bedienbarkeit, weil die KiTa-Leitung keine IT-Erfahrung hat.
  • Automatische Bildoptimierung, weil die KiTa-Leitung keine IT-Erfahrung hat.

Personas machen die abstrakten Zielgruppen konkret und ermöglichen es so allen Beteiligten, sich besser in andere Rollen und Perspektiven einzufinden. So erscheinen unter Umständen zuerst unverständliche Anforderungen plötzlich selbstverständlich und nachvollziehbar.

Lesetipp

Sind Sie neugierig geworden? Hier bekommen Sie Hintergrundinformationen, was eine User Story ist und wie Sie erfolgreich User Stories einsetzen:


Ausgewählte Kunden

Die Landesregierung Nordrhein-Westfalen
Land Brandenburg
LWL Für die Menschen, Für Westfalen-Lippe
Kunstsammlung Nordrhein-Westfalen
Ministerium für Gesundheit, Emanzipation, Pflege und Alter des Landes Nordrhein-Westfalen
Kreis Steinfurt