Manager von agilen Projekten aller Art lieben es, ihre Wünsche in User Storys zu packen:

„Als <Rolle> möchte ich <Ziel/Wunsch>, um “

Dieses Vorgehen hat sich nicht ohne Grund durchgesetzt. Anstatt nur irgendwelche diffusen Dinge zu beschreiben, zwingt es den Stakeholder zumindest die wichtigsten Fragen zu beantworten: wer, was, wieso überhaupt. Auch für Tester ist diese Art der Formulierung praktisch, denn Sie definiert bereits den “Happy Path”.

Als Entwickler, insbesondere in großen Teams und komplexen Projekten, ist dieser Wunsch der Stakeholder aber nur der Anfang. Die Umsetzung wirft eine ganz neue Klasse von Fragen auf, die beantwortet werden müssen:

• Welche Komponenten sind davon betroffen?
• Ist das technisch überhaupt machbar?
• Wen muss ich über Änderungen informieren?
• Welche Seiteneffekte können auftreten?
• Was müssen wir genau machen?
• In welcher Reihenfolge müssen wir vorgehen?

Wem jetzt bereits der Schweiß von der Stirn tropft, weil er sich an stundenlange, unproduktive Meetings erinnert, um genau diese Fragen zu beantworten, den kann ich beruhigen, denn das muss nicht sein!

Darf ich vorstellen: das Simple Change Board Planning

Das Simple Change Board Planning hilft Teams aus User Storys umsetzbare Aufgabenpakete zu generieren und gleichzeitig den Überblick über die Folgen und Bestandteile der Änderungen durch eine User Story zu behalten. Als Hilfsmittel reichen ein (Online-) Whiteboard und ein paar Post-its in verschiedenen Farben. Das Vorgehen ist wie folgt:

1. Identifiziere existierende Entitäten, die mit der User Story in Zusammenhang stehen. Ein Post-it repräsentiert eine Entität. Entitäten können dabei Softwarekomponenten, Stakeholder, Prozesse oder Gegenstände sein.

2. Stelle die Entitäten in logische oder prozedurale Zusammenhänge mit Pfeilen, Hinweisen oder anderen Repräsentationen. Erstelle bei Bedarf neue Kategorien durch neue Post-It Farben.

3. In einer besonderen Post-It Farbe, füge neue Entitäten hinzu, die durch die User Story entstehen sollen.

4. Identifiziere Änderungen, die an vorhandenen Entitäten durchgeführt werden müssen. Erstelle für jede Änderung ein Post-it an der Entität in derselben Farbe wie neue Entitäten, die durch die User Story entstehen.

5. Die Menge an neuen Entitäten und Änderungen an vorhandenen Entitäten sind die Aufgaben, die erledigt werden müssen, um die User Story zu implementieren. Sofern notwendig, sortiere die Aufgaben nach der Reihenfolge, in der sie erledigt werden müssen.

Das klingt erst mal komplizierter, als es in der Praxis ist. Spielen wir das Simple Change Board Planning anhand eines Beispiels durch. Unsere User Story lautet:

“Als Nutzer einer Website möchte ich Daten aus einem Real Life Prozess auf eine neue Art dargestellt bekommen”

1. Identifiziere existierende Entitäten, die mit der User Story in Zusammenhang stehen. Ein Post-it repräsentiert eine Entität. Entitäten können dabei Softwarekomponenten, Stakeholder, Prozesse oder Gegenstände sein.

Jetzt ist Brainstorming angesagt. Was müssen wir alles anfassen, um die Daten anzuzeigen? Dabei kommt vielleicht ein solches Bild zustande:

2. Stelle die Entitäten in logische oder prozedurale Zusammenhänge mit Pfeilen, Hinweisen oder anderen Repräsentationen. Erstelle bei Bedarf neue Kategorien durch neue Post-It Farben.

Sortieren wir mal. Was hängt wie zusammen und in welcher Reihenfolge? Wahrscheinlich wird das Ergebnis so ähnlich wie dieses hier aussehen:

Jetzt sollten alle Teammitglieder ein gemeinsames Verständnis vom aktuellen Status des Systems haben, an dem Änderungen vorgenommen werden müssen. Das ist zwingend notwendig, denn die meisten Projekte sind komplex genug, sodass niemand alle Bestandteile gleichzeitig im Kopf haben kann. Erst wenn alle dasselbe Verständnis vom aktuellen Stand haben, macht es Sinn, Änderungen daran zu diskutieren. Verzichtet man auf diesen Schritt, redet man oft zwangsweise aneinander vorbei, da die einzelnen Teammitglieder von unterschiedlichen Annahmen ausgehen.

3. In einer besonderen Post-It Farbe, füge neue Entitäten hinzu, die durch die User Story entstehen sollen.

Sollte eine User Story nur existierende Entitäten ändern, kann dieser Schritt natürlich übersprungen werden.

4. Identifiziere Änderungen, die an vorhandenen Entitäten durchgeführt werden müssen. Erstelle für jede Änderung ein Post-it an der Entität in derselben Farbe wie neue Entitäten, die durch die User Story entstehen.

Mit der Vorarbeit, die wir geleistet haben, können wir nun endlich die wichtigste Frage beantworten: Was müssen wir genau machen, um die Story zu erfüllen? Auch wenn es erst mal kontraintuitiv scheint, diese Frage fast am Ende des Prozesses zu stellen, zeigt unsere Erfahrung, dass wir vorher gar nicht in der Lage waren, die Frage korrekt zu beantworten. Dafür fällt das Identifizieren von Änderungen jetzt umso leichter.

5. Die Menge an neuen Entitäten und Änderungen an vorhandenen Entitäten sind die Aufgaben, die erledigt werden müssen, um die User Story zu implementieren. Sofern notwendig, sortiere die Aufgaben nach der Reihenfolge, in der sie erledigt werden müssen.

Aus den roten Stickies im Beispiel werden konkrete Aufgaben, die direkt auf das Sprint- oder Kanban Board übertragen werden können. Eventuelle Abhängigkeiten in der Reihenfolge können im letzten Schritt abschließend diskutiert werden.

Das Ergebnis aus Schritt 4 sollte dabei aber immer als Referenz erhalten bleiben, denn es hilft auch während des Sprints den Überblick über das geplante Vorgehen zu behalten. Sollten im Laufe eines Sprints neue Erkenntnisse gewonnen werden, die eine Änderung der Planung erzwingen, kann man direkt damit einsteigen und behält ein gemeinsames Verständnis über das existierende System und kann das Vorgehen entsprechend anpassen.

In meinem Entwicklerteam verwenden wir die Methode im Sprint Planning zum Task Breakdown. Im aktuellen Scrum Guide steht dazu im Planning Topic 3 lediglich:

“This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.”

Dafür hat sich Simple Change Board Planning als sehr nützlich erwiesen. Es erlaubt uns besser gemeinsam zu planen und ermöglicht einen effektiven Task Breakdown. Es hilft uns alle Aufgaben, die wir erledigen wollen, auf dem Sprint Board transparent zu machen. Wir können Änderungen untereinander klarer kommunizieren und wir verlieren uns nicht mehr in langen Diskussionen, die auf falschen Annahmen über den aktuellen Zustand des Systems, das wir bauen, basieren.