Beispiel: Schneiden von User Stories

In der Rolle des Product Owners steht man immer wieder vor der Aufgabe, eine Softwareanforderung (eine große User Story oder ein Epic) in mehrere kleinere zu schneiden. Dabei sollten diese kleineren Funktionspakete, wenn sie einzeln umgesetzt werden, immer noch sinnvoll nutzbar sein. Unerfahrene Product Owner und Teams haben aber oft keine Idee, wie sie dies bei ihren Anforderungen umsetzen können.

Daher möchte ich das an einem konkreten Beispiel, das ich aus einem Kundenprojekt entlehnt habe, zeigen.

Als Mitarbeiter möchte ich einen Konferenzraum im Intranet buchen, um dort eine Besprechung abzuhalten.

Diese User Story ist ein Platzhalter für einen ganze Gruppe an Funktionalität, die sich um das Thema Raumbuchungen dreht. Neben der direkten Buchungsfunktionalität soll es auch möglich sein, die hauseigene Bewirtung oder mobile Raumausstattung, wie Flipcharts oder Metaplanwände, zu bestellen. Die meisten Räume können, wenn sie noch frei sind, direkt gebucht werden, aber einige werden von Raumverantwortlichen verwaltet, die eine Buchung erst bestätigen müssen (z.B. Konferenzräume in der Vorstandsetage). Viele Raumbuchungen und Bewirtungsbestellungen werden nicht storniert, obwohl die Besprechung gar nicht stattfindet. So fallen unnötige Kosten durch die Bewirtung an und Besprechungsräume bleiben ungenutzt, obwohl andere Mitarbeiter Räume benötigen. Daher sollen die Buchenden vorab noch einmal an ihre Reservierung erinnert werden.

Dies alles als eine einzige User Story umzusetzen ist im agilen Umfeld keine Option, da die Umsetzungsdauer sehr lang ist und damit kein frühzeitiges fachliches Feedback möglich ist. Daher sollte diese große Story in mehrere kleinere User Stories herunter gebrochen werden.

Im ersten Schritt kann man mittelgroße Pakete rund um zusammenhängende Funktionalität bilden:

Aber selbst diese User Stories sind noch groß und unhandlich. So lassen sie sich in kleinere Stories aufteilen:

Raumbuchung

In diesem Thema befinden sich neben der grundlegenden Funktionalität auch einige „Komfort“-Features. Die Basisfunktionalität wird durch folgende User Stories abgedeckt:

 Als Mitarbeiter möchte ich mich über die Räume und die Buchungsregeln im Intranet informieren.

Als Mitarbeiter möchte ich die bestehenden Buchungen für einen gegebenen Raum (in einer Kalenderdarstellung) ansehen.

Als Mitarbeiter möchte ich für einen bestimmten Zeitraum und Raum eine Buchung tätigen.

Als Mitarbeiter möchte ich eine von mir getätigte Buchung stornieren, um den nicht mehr benötigten Raum wieder für andere verfügbar zu machen.

Jeder dieser Stories kann einzeln umgesetzt und so schon ein Feedback zur Umsetzung eingeholt werden. Aber erst wenn alle Stories umgesetzt sind ist die Funktionalität zwar rudimentär aber sinnvoll  nutzbar.

Als Mitarbeiter möchte ich an eine getätigte Buchung erinnert werden, um sie ggf. zu stornieren.

Als Mitarbeiter möchte ich eine von mir getätigte Buchung ändern um sie nicht erst zu stornieren und dann neu zu buchen.

Als Mitarbeiter möchte ich für einen bestimmten Tag die Buchungen aller Räume sehen, um ggf. zu fragen, ob bereits getätigte Buchungen verschoben werden könnten, so dass noch ein passender Raum frei wird.

Als Mitarbeiter möchte ich alle von mir getätigten Buchungen sehen, um schnell zu meinen Buchungen zu navigieren.

Als Mitarbeiter möchte ich für einen bestimmten Zeitraum nach freien Räumen suchen, um für eine schon angesetzte Besprechung einen Raum zu reservieren.

Als Mitarbeiter möchte ich für einen bestimmten Raum in einem gegeben Zeitraum freie Zeiten suchen, um zu sehen, welche Termine für eine Besprechung möglich sind.

Als Mitarbeiter möchte ich in einem gegebenen Zeitraum nach freien Zeiten und freien Räumen suchen.

Bewirtung

Als Mitarbeiter möchte ich bei der Buchung eines Raums eine Bewirtung mitbestellen.

Die Bestellung von Bewirtungen erfolgt nicht über ein technisches System, sondern durch Versenden eines ausgefüllten Formulars an die Kantine, daher erfordert die erste Story im Grunde keine Persistenz der Bestellung.

Als Mitarbeiter möchte ich zu einer getätigten Buchung eine Bewirtung bestellen.

Als Besteller einer Bewirtung möchte ich diese stornieren.

Bei diesen beiden Stories sollte man sich merken, ob für eine Buchung schon eine Bewirtung bestellt wurde oder nicht.

Als Besteller einer Bewirtung möchte ich diese ändern.

Erst für diese Story ist es sinnvoll, die Daten einer Bestellung zu persistieren.

Ausstattung

Bei der Ausstattung ist eine ähnliche Aufteilung wie bei der Bewirtung möglich, sie unterscheiden sich nur in der inhaltlichen Ausgestaltung der erfassten Daten und den Empfängern der Bestellung.

Als Mitarbeiter möchte ich bei der Buchung eines Raums zusätzliche Raumausstattung mitbestellen.

Als Mitarbeiter möchte ich zu einer getätigten Buchung zusätzliche Raumausstattung bestellen.

Als Besteller von zusätzlicher Raumausstattung möchte ich diese stornieren.

Als Besteller von zusätzlicher Raumausstattung möchte ich diese ändern.

Freigabe/Verwaltete Räume

Die Aufteilung hier erfolgt entlang der Schritte im Freigabeprozess.

Als Mitarbeiter möchte ich eine Buchungsanfrage für einen verwalteten Raum stellen.

Auf den ersten Blick hat es dadurch den Anschein, dass nur wenn alle Schritte abgedeckt sind ein produktiver Einsatz sinnvoll ist. Aber diese Story lässt sich auch so umsetzen, dass sie alleine produktiv funktioniert. So könnte man nur den Raumverantwortlichen ermöglichen, den jeweiligen Raum zu buchen (bisherige Funktionalität) und die Buchungsanfrage erzeugt nur eine Nachricht an den jeweiligen Raumverantwortlichen. Alle weiteren Prozessschritte erfolgen dann außerhalb der Lösung. In dem man die (noch) nicht umgesetzten Schritte durch Kommunikation außerhalb der Anwendung löst, kann man auch die weiteren Stories einzeln umsetzen.

Als Raumverantwortlicher möchte ich alle offenen Buchungsanfragen für den verwalteten Raum sehen.

Als Raumverantwortlicher möchte ich eine Buchungsanfrage bestätigen oder ablehnen.

Als Mitarbeiter möchte ich alle meine noch offenen Buchungsanfragen sehen.

Als Mitarbeiter möchte ich eine offene Buchungsanfrage zurückziehen.

Serientermine

Als Mitarbeiter möchte ich für eine Terminserie einen Raum buchen.

Als Mitarbeiter möchte ich eine von mir erzeugte Serienbuchung stornieren.

Als Mitarbeiter möchte ich eine von mir erzeugte Serienbuchung ändern.

Die Einführung der Terminserien erweitert implizit auch alle anderen User Stories. So muss die Bewirtungsfunktionalität auch mit Serien funktionieren. Sollte diese schon implementiert sein, wäre sie anzupassen. Diese Anpassungen können aber (falls sie zu aufwendig sind) in eine weitere Story verlagert werden.

Als Mitarbeiter möchte ich eine einzelne Buchung einer von mir erzeugten Serie stornieren.

Als Mitarbeiter möchte ich eine einzelne Buchung einer von mir erzeugten Serie ändern.

Je nach Umsetzung der Serientermine sind die Stories bzgl. einzelner Buchungen einer Serie gar nicht notwendig.

Administration

Unter der Administration kann man sich natürlich noch viele weitere Stories ausdenken. Darunter fallen alle möglichen Konfigurationen (Raumverantwortliche, Bewirtungsoptionen, Erinnerungszeitraum, Beschreibung der Räume, …), die aber selten verändert werden und damit auch von einem technischen Administrator vorgenommen werden können. Als Beispiel sind hier zwei Stories aufgelistet.

Als Intranetadministrator möchte ich einen weiteren Raum für Buchungen verfügbar machen, da dieser Raum in einen Besprechungsraum umgebaut wurde.

Als Intranetadministrator möchte ich einen Raum aus dem Intranet löschen, da er nicht mehr als Besprechungsraum zur Verfügung steht.

Fazit

Aus der einen epischen User Story sind jetzt über dreißig kleine User Stories entstanden. Diese können jetzt von einem Team jeweils in akzeptabler Zeit (mehrere pro Iteration möglich oder eine geringe Cycle Time in ein kontinuierlichem Vorgehen) umgesetzt werden. So besteht die Möglichkeit, schon kurzfristig fachliches Feedback zu den einzelnen Punkten zu erhalten.

Weiterhin ermöglicht eine solche feine Aufteilung, die einzelnen Punkte unabhängig zu priorisieren, sowohl untereinander als auch in Bezug auf andere Anforderungen, die nichts mit dem Thema “Raumbuchungen” zu tun haben. Dies ermöglicht ggf. auch, mit einer nicht vollständigen Funktionalität produktiv zu starten.

Diese Zerteilung berücksichtigt keine technischen Aspekte, sondern basiert auf einem fachlich sinnvollen Funktionsschnitt. Bis auf einen initialen Satz an Stories (MVP) kann (bei einer sinnvollen Reihenfolge) nach jeder Story ein fachlich sinnvoller Produktstand erreicht werden.

Ich hoffe, dieses Beispiel hilft, Ideen zum Zerschneiden von Epics und großen User Stories zu entwickeln.