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
Agile Product Development 
Schön Darstellung. Ich frage mich, wie Stories, die 5 Teams bearbeiten müssen bei euch refined werden. Hier geht es ja “nur noch” um die Abarbeitung, oder? Und wenn nicht, dann hat das Team, dass es zuerst macht mehr Gestaltungsfreiheiten als die folgenden Teams?
Eins vorweg: Es ist nicht so, dass mehrere Teams an derselben Story arbeiten. Jedes Team hat schon seine eigenen Stories und arbeitet die auch ganz normal ab.
Es gibt aber immer mal wieder den Fall (besonders bei Komponenten-Teams), dass eine Story von Team A Abhängigkeiten zu Stories zu anderen Teams hat. Genau dieser Umstand soll mit der Art von Visualisierung adressiert werden. Es geht bei den Boundary Stories auch nicht nur um das einfache „Abarbeiten“, sondern sie funktionieren als ein Hinweis darauf, dass es bei bestimmten Themen Überschneidungen gibt, über die geredet werden muss.
Deine Frage zielt aber auf die Koordinierung der Teams beim Refinement ab. Nun haben wir mittlerweile keine Komponenten-Teams mehr, sondern haben eher Feature Teams. Dadurch sind die Abhängigkeiten nicht mehr so häufig anzutreffen, wie das früher der Fall war.
Unsere Refinements finden ganz normal in den Workshops der einzelnen Teams statt. Sollte es aufgrund von Abhängigkeiten notwendig sein, dass es hier Absprachen zwischen Teams gibt, so werden in der Regel einzelne Team-Mitglieder aus anderen Scrum-Teams zu den Workshops mit eingeladen. Für übergreifende technische Themen kann es auch sein, dass es einen Team-übergreifenden Workshop zu genau einem Themenblock gibt.
Außerdem koordinieren sich unsere Teams zu speziellen Themen in Communities of Practice (CoP). In diesen werden nicht nur konzeptionelle technische Fragestellungen und Team-übergreifende Standards diskutiert. Die Mitglieder einer CoP stellen sich auch gegenseitig vor, woran sie gerade arbeiten bzw. informieren sich gegenseitig über geplante Stories.
Wichtig ist vor dem Refinement vor allen die Transparenz darüber, dass ein Team in einem bestimmten Bereich arbeitet oder dort Aktivitäten geplant sind. Diese Information wird u.a. in den Review Meetings der Teams, zu denen alle anderen Teams auch eingeladen werden, verteilt.