Manchmal kann es notwendig sein, dass verschiedene Scrum-Teams an Stories arbeiten, die voneinander abhängig sind. Dies kann z.B. bei Plattformfreigaben der Fall sein oder wenn ein Team nicht für alle Schichten der Software zuständig ist (Komponententeam). Ein leichtgewichtiges Konzept für die Koordinierung dieser Teams sind Boundary Stories.
Unsere Boundary Stories werden regelmäßig im Scrum of Scrums diskutiert. Das Bild zeigt ein Beispiel, in dem die nächsten 6 Sprints visualisiert sind. Für jedes Thema, bei dem Abhängigkeiten bestehen, gibt es eine Swimlane. Die Farbe der Karte gibt an, welches Team in einem Sprint an dem Thema arbeitet. Verschiebt sich eine Lieferung erkennt man auf einen Blick die Auswirkung auf die anderen Teams bzw. die Gesamtlieferung. Besonders wichtige Termine sind ganz oben hervorgehoben.
Das Boundary Story Board wird von den Product Ownern auf dem aktuellen Stand gehalten und hilft über den aktuellen Sprint hinauszublicken.
Hier ein paar Beispiele für die Anwendung. Bei Freigaben hat es sich bewährt, dass nicht alle Teams gleichzeitig anfangen, damit die Teams von den Erkenntnissen des Vorreiter-Teams profitieren. Auf dem Board sieht das z.B. so aus.
Das violette Team macht die OS-8-Freigabe in Sprint G. Das grüne und blaue Team folgen in Sprint H und die restlichen in Sprint i. Scheitert die Freigabe beim Vorreiterteam, wird darüber diskutiert, ob die anderen Teams einen weiteren Sprint warten, damit sie nicht an bekannten Problemen hängen bleiben, für die es noch keine Lösung gibt oder ob die Freigabe so wichtig ist, dass nun doch stärker parallelisiert werden muss.
Komplexere Abhängigkeiten entstehen, wenn man Komponententeams hat. Im folgenden Fall ist das blaue Team für ein komplexes UI-Framework zuständig. Dort muss eine neue UI-Komponente realisiert werden, auf deren Basis das grüne Team eine Mobile-Anwendung und das pinke Team die Portal-Lösung erweitern. Die Erweiterung des UI-Frameworks basiert wiederum auf einer Erweiterung der Search Engine, die zu Beginn vom gelben Team durchgeführt werden muss.
Manchmal müssen die Teams auch alle im selben Sprint eine konzertierte Aktion durchführen. Z.B. bei der Umstellung des Logging-Frameworks kurz vor einem Gesamtrelease.
Vorteile der Darstellung sind:
- Die Abhängigkeiten sind durch die kompakte Darstellung auf einen Blick erkennbar.
- Macht übergreifende Abhängigkeiten bewusster (insbesondere durch die regelmäßige Darstellung im DoD)
- Überlastungen eines Teams in einem Sprint sind anhand der Farbe erkennbar.
- Leichtgewichtig