User Stories sind ein klassisches Werkzeug aus der agilen Praxis. Sie werden beispielsweise im Framework von Scrum eingesetzt, um die Product-Backlog Einträge zu formulieren. Doch was steckt hinter diesen User-Stories? Was war der ursprüngliche Hintergrund dieses Tools und wie kannst du sie auch im Prozessmanagement einsetzen? All dies sowie ein paar hilfreiche Tipps erhältst du in diesem Beitrag. Dabei schaue ich speziell auf die Möglichkeit mit User-Stories ein Erwartungs-  & Schnittstellenmanagement für Prozesse zu realisieren.

Was sind User-Stories und wo werden sie eingesetzt?

Bevor wir uns die Möglichkeit des Einsatzes von User-Stories im Prozessmanagement anschauen, möchte ich dir kurz aufzeigen, was User-Stories eigentlich sind. User-Stories sind ein Werkzeug, um in agilen Projekten / der agilen Produktentwicklung Anforderungen seitens der Kunden zu beschreiben. Ein Hauptaugenmerk liegt dabei nicht auf der reinen, formalen Beschreibung einer Anforderung, sondern auch auf der Erläuterung des „Wozu“ eine bestimmte Anforderung benötigt wird.

Die Formulierung einer User-Story sieht im klassischen Fall folgendermaßen aus:

Als [Rolle] benötige ich [eine bestimmte Funktion], damit [ein bestimmter Nutzen] erzeugt wird.

Es geht also darum zu beschreiben „Wer“ eine bestimmte Funktion (also das „Was“) benötigt und „Wozu“ diese dann beiträgt. Punkt. Das reicht im ersten Moment völlig aus.

[Wer] benötigt [Was] [Wozu]?

In folgendem Video von Boris Gloger ist die Beschreibung einer User-Story aus meiner Sicht ganz anschaulich erklärt. Mit sieben einhalb Minuten Länge strapaziert das Video deine kostbare Zeit auch wirklich nicht viel 😉

Weshalb gibt es User-Stories und wie sind sie entstanden?

Speziell in der Einleitung des oben genannten Videos wird auch noch einmal deutlich wofür User-Stories konzipiert / entwickelt wurden. Es ging darum die bis dato oftmals sehr aufwendig ausformulierten Anforderungskataloge innerhalb von IT- bzw. Entwicklungs-Projekten stark zu reduzieren. Denn wenn du schon einmal ein solches Projekt begleitet hast, dann wirst du es kennen: Speziell in der heutigen VUCA-Welt verändern sich die Rahmenbedingungen so rasant, dass oftmals noch vor Beginn der eigentlichen Entwicklung die mehrseitig beschriebenen Anforderungen wieder obsolet sind.

Es ging also darum den oftmals unnötigen, meist nicht zielführenden Dokumentationsaufwand zu reduzieren. Einhergehend mit der Reduktion der Dokumentation wird natürlich auch die Notwendigkeit einer guten Zusammenarbeit in Entwicklungsprojekten stärker. Auch hier helfen die User-Stories ein gemeinsames Bild darauf zu kriegen über was gemeinsam gesprochen werden muss. Natürlich gibt es viele Stellen an denen vermutlich noch nachgeschärft oder an denen das gemeinsame Verständnis zu Funktionen oder dem versprochenen Nutzen erst generiert werden muss. Aber: Es ist wenigstens von Beginn an klar was der Inhalt dieser notwendigen Kollaboration sein muss bzw. sein wird. Und hier lässt sich nun wunderbar in Richtung des Prozessmanagements schwenken.

User-Stories für das Erwartungs- & Schnittstellenmanagement nutzen

Also, User-Stories sind dafür da bestimmte Anforderungen zu beschreiben. Seien es die Anforderungen von potentiellen oder bestehenden Kunden an ein Produkt oder von bestimmten Anwenderrollen an eine IT-Software.

Was spricht also dagegen User-Stories beispielsweise auch für das Erwartungsmanagement oder die grundlegende Beschreibung von Schnittstellen-Anforderungen zu nutzen? Meines Erachtens gar nichts!

Denn wenn du mal genauer nachdenkst, dann lässt sich auch bei der Definition von Schnittstellen oder bei der Ermittlung von Kundenanforderungen an einen Prozess festhalten, dass hier noch vor einiger Zeit vielerlei „Dokumente geschrieben“ wurden, aber im Endeffekt schon fast nach einer Nacht wieder über den Haufen geworfen werden konnten. Man sprach von „Schnittstellen-Vereinbarungen“ oder „Quality Function Deployment und House of Quality“. Ich möchte dir hier keinesfalls die Sinnhaftigkeit dieser Methoden und Tools ausreden, nein, darum geht es mir nicht. Ich denke es muss immer von Fall zu Fall entschieden werden, welche Hilfsmittel eingesetzt werden. Doch gerade wenn es eher pragmatisch sein soll und man auf eine schlanke Art und Weise sich dem Thema „Definition einer Schnittstelle“ oder der „Erfassung von Kundenanforderungen“ an einen Prozess widmet, bin ich der Meinung, dass die Nutzung von User-Stories schneller zu einem Erkenntnisgewinn und damit zu ersten Erfolgen führt. Zudem Klarheit über die nächsten, zielführenden Schritten bringt.

Wie können solche User-Stories aussehen?

Klar, nun kommt die Frage zurecht wie solche Stories dann bspw. für interne Schnittstellen aussehen könnten und dazu möchte ich dir natürlich meine Gedanken mitteilen.

Nehmen wir mal an, wir möchte nun die Schnittstelle zwischen dem Bereich des Lagers und der Produktion genauer beleuchten – also die Schnittstelle zwischen den Prozessen „Teile produzieren“ und „Teile lagern“. Eine mögliche User-Story als Anforderungsbeschreibung an die Produktion könnte dann lauten:

Für den Prozess „Teile lagern“ (Wer) benötige ich „die produzierten Waren in internen Behältern“ (Was), damit „wir Transportschäden vermeiden und eine optimale Lagerausnutzung erreichen können„ (Wozu).

Wenn wir uns das Beispiel genauer anschauen, dann sehen wir schon:

• • Über das genannte „Wozu“ kannst du klar erkennen, welchen Nutzen die Umsetzung der Anforderung (für dein Unternehmen) bringt. Das hilft dir schneller einschätzen zu können worum es hier wirklich geht.
  • Es ist nicht Sinn und Zweck so viele Informationen wie möglich nieder zu schreiben. Es geht um einen knackigen Satz. Natürlich bedingt das, dass du im Nachgang eventuell weitere, detailliertere Gespräche führen musst.
  • Das hat alles mal noch einen eher einseitigen Charakter, doch es spricht ja auch nichts dagegen im Gespräch User-Stories auszutauschen (bspw. eine weitere User-Story von Produktion an Logistik: Als Produktion benötigen wir die internen Behälter mit einem ausreichendem, zeitlichen Vorlauf, um die Anforderungen erfüllen zu können)
  • und so weiter

Was genau bringt uns das und wie geht es weiter?

Ich denke du siehst schon, dass es hier im wesentlichen um Transparenz geht. Durch den gegenseitigen Austausch der unterschiedlichen Anforderungen erhältst du schnell und ohne großen (schriftlichen) Aufwand ein Gesamtbild der Anforderungen und Erwartungen an deinen Prozess.

Und eins sei an dieser Stelle noch ergänzend gesagt: Das obige Beispiel bezieht sich zwar auf eine interne Schnittstelle, allerdings sehe ich auch keinen Showstopper darin es mit externen Stakeholdern und deren Anforderungen / Erwartungen an deinen Prozess zu machen. 

Nach Erhalt dieser Transparenz kannst du wesentlich besser priorisieren und sagen an welcher Stelle / mit welcher Anforderung oder Erwartung es aktuell vielleicht noch nicht so gut läuft oder auch aussortieren. Aussortieren im Sinne von einer Bewertung der Anforderungen auf ihre Relevanz und / oder Zugehörigkeit zur eigentlichen Wertschöpfung. Auch eine Risikobewertung ließe sich anschaulich gestalten. Mir fallen da noch viele weitere, ganz witzige und spannende Dinge ein. Doch an dieser Stelle erst einmal genug der heutigen „Stories“ 😉

Wenn du auch in Zukunft über Neuigkeiten in meinem Blog informiert werden möchtest, dann melde dich zu meinem Newsletter an. Ganz einfach über das Formular neben / unter diesem Beitrag!