Mit User Stories zum wirklich passenden App-Konzept

User Stories sind vielleicht der effektivste Weg, eine App nicht nur absolut nutzerfokussiert zu konzipieren, sondern auch, um ein gemeinsames Verständnis unter allen Projektbeteiligten zu schaffen. Heute schauen wir uns an, wie das geht und wie auch Sie User Stories für Ihr nächstes Projekt nutzen können.

Meistens ist zu Beginn eines App-Projektes nicht viel mehr da als eine grobe Idee dessen, wo es einmal hingehen soll. Und wenn man erst einmal anfängt, sich über die Details Gedanken zu machen, merkt man, dass eine Reihe schwieriger Fragen aufkommen und Entscheidungen getroffen werden müssen: Welche Features wollen wir sofort umsetzen, welche ziehen wir in einer späteren Version nach? Von welchen Ideen sollten wir uns wieder verabschieden? Lohnt sich das Investment für einzelne Dinge überhaupt ?

All das sind schwierige Fragen, und ich möchte Ihnen heute mit den sogenannten User Stories ein Konzept zeigen, das Ihnen künftig die Entscheidungsfindung während der App-Konzeption erleichtert.

Das Konzept hinter User Stories

Eigentlich ist die Idee hinter User Stories nichts neues. Einfach gesagt geht es darum, diejenigen, für die eine App gemacht wird doch einfach mal zu fragen, was sie eigentlich brauchen.
Komischerweise scheint in der Softwareentwicklung die Welt oft auf dem Kopf zu stehen. In den meisten Fällen, wird nämlich eine App von einem Projektteam komplett am Reißbrett vorkonzipiert, entwickelt und dann, wenn sie endlich fertig ist, dem eigentlichen Nutzer “aufgetischt”. Dann heißt es: Daumendrücken, dass der das Ergebnis so wie es ist annimmt und versteht.

Ich will Sie also heute dazu anregen, es einmal anders herum auszuprobieren. User Stories machen den späteren Nutzer sozusagen zum Drehbuchautoren Ihrer App. Dadurch wissen Sie von Beginn des App-Projektes an, in welche Richtung die Lösung gehen muss, um diesem „Nutzer-Drehbuch“ zu entsprechen. Und um die Bedürfnisse der Nutzer möglichst genau zu treffen.

Den Funktionsrahmen definieren

Stellen wir uns einmal vor, wir wollen zum Beispiel eine App entwickeln, die Ihren Außendienst bei Kundenbesuchen unterstützt. Und zwar möchten Sie sicherstellen, dass Ihre Außendienstmitarbeiter immer die aktuellsten Präsentationen und Preislisten bei sich haben, weil Sie in der Vergangenheit Probleme damit hatten und alte Preise kommuniziert oder falsche Ersatzteile verkauft wurden.
Im ersten Schritt sind jetzt erst einmal Sie gefragt: Es sollte grob der Funktionsrahmen abgesteckt werden, den die App bieten sollte um ihren gewünschten Zweck zu erfüllen. Das muss nicht mehr als eine Liste sein, in der grob die nötigen Funktionen beschreibt. In unserem Beispiel wären das:

  • Download von Preislisten und Präsentationen
  • Zeigen von Produktpräsentationen
  • Oder auch: Versand von Dokumenten an den Kunden

Diese sehr groben Funktionsbeschreibungen nennt man übrigens „Epics“.

User Stories einholen

Mit Ihrer App-Idee und der Liste von Epics gehen Sie also nun zu Ihren späteren App-Nutzern und bitten diese darum, User Stories zu verfassen.

Achtung! Denken Sie daran, dass eine App auch andere Nutzer haben kann als die Hauptnutzer. In unserem Beispiel könnten zum Beispiel auch diejenigen zu den Nutzern gezählt werden, die sich später darum kümmern müssen, dass die ganzen Dokumente auch immer aktuell gehalten und zeitnah für alle verfügbar gemacht werden.

Eine User Story ist aber in der App-Entwicklung keine Einladung, freie Prosa darüber zu verfassen, was alles schön und wünschenswert wäre. Um die Sache kompakt zu halten und die einzelnen User Storys später bewerten zu können, sollten sie einer bestimmten Form folgen. Diese Form entspricht einem fixen Lückentext, der bestimmte Inhalte abfragt und entsprechend von jeder Nutzergruppe ausgefüllt werden muss:
In meiner Rolle als [Position/Person] möchte ich [Bedürfnis], um [Nutzen, der aus Erfüllung dieses Bedürfnisses erfolgt].

In unserem Beispiel könnte eine ausgefüllte User Story dann wie folgt aussehen:

“Als Außendienstmitarbeiter möchte ich, dass meine versendeten E-Mails an den Kunden im CRM-System protokolliert werden, um eine Woche später nicht zu vergessen, noch einmal nachzufassen.”

Immer nach dem Strickmuster: Wer stellt die Anforderung, was will derjenige tun können und mit welcher Begründung?

Übrigens: Damit bei den User Stories nicht irgendwelche schwammigen Ergebnisse herauskommen, die Ihnen später immer noch nicht weiterhelfen, hat sich als Faustregel das Akronym „INVEST“ durchgesetzt. User Stories sollten immer „INVEST“ sein, und das steht für:

  • Independent, also unabhängig von anderen Anforderungen.
  • Negotiable, also frei übersetzt diskutierbar was bedeutet, dass es immer möglich sein muss, User Stories frei zu priorisieren oder auch gar nicht umzusetzen.
  • Valuable — die User Story sollte einen klar definierten Wert oder Nutzen bringen.
  • Estimate-able, also einschätzbar in Bezug auf den Aufwand, der nötig ist, um die User Story umzusetzen.
  • Small, was nichts anderes heißt, als dass die Story klein genug sein muss, um innerhalb von ein paar Tagen umgesetzt werden zu können.
  • Testable, was bedeutet, dass es bei jeder User Story möglich sein muss, durch einen Test herauszufinden, ob sie umgesetzt ist oder nicht.

Sie haben also nun von Ihren späteren Nutzern hoffentlich viele, sinnvolle User Stories zurückbekommen.

Erstellung von Story Cards

Als nächstes erstellen Sie nun zu jeder Story sogenannte Story Cards. Eine Vorlage für User Story Cards finden Sie hier zum Download.

Auf diesen Karten können Sie vorn die jeweilige User Story beschreiben und dann für jede User Story Punkte vergeben, die den geschätzten Aufwand beziffern. Warum nennt man das Punkte und nicht einfach Arbeitstage? Das liegt vor allem daran, dass man in die Punkte gleich noch eine gewisse Unsicherheit einfließen lässt, die immer besteht, wenn die Zeitschätzung größer wird. Angenommen, ein Arbeitstag ist bei Ihnen also ein Story Punkt, dann kann es sein, dass zehn Arbeitstage besser mit 15 Story Punkten beziffert werden sollten, weil die Chance, dass etwas unvorhergesehenes den Aufwand erhöht, hier größer ist. Manche arbeiten bei der Vergabe von Story Punkten übrigens mit festen Faktoren, andere werden fancy und nehmen Fibonacci-Folgen, wieder andere gehen nach Bauchgefühl. Was bei Ihnen passt, zeigt erst die Erfahrung.

Nun haben Sie also auf Ihren Karten schon die Story selbst und die geschätzten Story Punkte. Als nächstes fehlt die Priorisierung, und die entsteht normalerweise aus der Frage, wie hoch der geschöpfte Nutzen ist plus der Schätzung, wie aufwändig die Umsetzung wird. Hoher Nutzen und geringer Aufwand werden also höher priorisiert als geringer Nutzen und hoher Aufwand. Ist glaube ich klar…

Test- und Bewertungskriterien festlegen

Als letzter Schritt werden nun noch auf den Rückseiten der Story Cards die Kriterien beschrieben, nach denen getestet wird, ob die Story erfüllt wurde. Unser Beispiel von eben war: Als Außendienstmitarbeiter möchte ich, dass meine versendeten E-Mails an den Kunden im CRM-System protokolliert werden, um eine Woche später nicht zu vergessen, noch einmal nachzufassen.
Als Testszenario für diese Story können auf der Rückseite nun also die Kriterien vermerkt werden, die hier getestet werden können:

“Im CRM System wurde der Versand einer E-Mail protokolliert und eine Woche nach Versand wird der Außendienstmitarbeiter daran erinnert nachzufassen.”

Mit den fertigen Story Cards haben Sie nun ein klares Bild davon, was vom Nutzer als sinnvoll erachtet wird, welche Storys welche Priorität bekommen und welchen Aufwand die Umsetzung mit sich bringt. Damit können Sie nun beginnen, einzelne Tasks zu definieren, die für die Erfüllung notwendig sind und damit sehr zielgerichtet in Ihr Projekt zu starten.


Ich hoffe, Sie haben jetzt Lust, diesen Weg einmal auszuprobieren, wenn Sie ihn bisher noch nicht kannten. Eine Vorlage für User Story Cards finden Sie hier zum Download.

Entdecken Sie auch unser YouTube-Video zu diesem Thema:


Ramona Peters ist Projektmanagerin bei rabbit mobile, einer Agentur für die Entwicklung digitaler Businessanwendungen mit Mobile-First-Ansatz.
rabbit mobile unterstützt seine Kunden von konzeptionell-strategischen Vorüberlegungen bis hin zur Realisierung und Pflege laufender Anwendungen, sowie deren Integration in eine bestehende Systemlandschaft.

Sie erreichen Ramona Peters hier auf Xing, hier auf LinkedIn oder:
via E-Mail: r.peters@rabbit-mobile.de
via Telefon: +49 69 256288–244