In funktionsübergreifenden Scrum Teams zeigt ein Sprint Backlog häufig vornehmlich, woran die Entwickler:innen im Team gerade arbeiten. Was parallel dazu und in welchen Teilschritten von Business Analystinnen oder UI-Designern für die Entwicklung vorbereitet wird, ist hingegen oft nicht gleichermassen sicht- und nachvollziehbar. Wie wir in meinem Umfeld mit einer Kombination aus Kanban- und Scrum Board mehr Transparenz geschaffen haben? Davon handelt dieser Blog.
In funktionsübergreifenden Scrum Teams, in welchen ich bisher als Product Ownerin tätig war, war die Ausgangslage hinsichtlich Transparenz und Fortschrittskontrolle über die Entwicklungsarbeiten und über das agile Requirements Engineering stets dieselbe: Um die Entwicklung kümmern sich die Entwickler:innen im Team, um die Erarbeitung von User Stories zeichne ich als Product Ownerin in Kooperation mit anderen Disziplinen (bspw. Business Analystinnen, UI Designer, Textredaktorinnen) verantwortlich. Die Entwicklung erfolgt auf Basis ausgearbeiteter User Stories, die in der Sprint Planung in Relation zur verfügbaren Entwicklungskapazität berücksichtigt und im Rahmen zeitlich begrenzter Sprints umgesetzt werden. In der Folge beantwortet das aktuelle Sprint Backlog im Wesentlichen „Was ist gerade in Entwicklung?“, lässt jedoch keinen unmittelbaren Rückschluss auf die Frage „Was ist gerade in Analyse?“ zu. Dies führt zum Umstand, dass die aktuellen Entwicklungsarbeiten transparent nachvollzogen werden können, die Vorarbeiten dafür hingegen einer gewissen Transparenz entbehren.
Wie also alle laufenden Arbeiten des ganzen Teams sicht- und nachvollziehbar machen, wenn das aktuelle Sprint Backlog „nur“ auf die Entwicklung fokussiert? In meinem derzeitigen Umfeld hat sich dafür eine an den Ansatz „Dual Track Agile“ angelehnte Sicht auf Tätigkeiten und Prozessschritte etabliert:
Zwei Tätigkeitsgebiete, zwei Tracks
Der Ansatz Dual Track Agile unterscheidet zwischen zwei sogenannten „Tracks“, die parallel zueinander laufen:
- Discovery Track: Ziele und Bedürfnisse der Nutzer:innen erfassen, Lösungsansätze erarbeiten, validieren und beispielsweise in Form von User Stories dem Development Track übergeben
- Development Track (oft auch «Delivery Track»): Produkt auf Basis validierter Lösungsansätze entwickeln, testen und ausliefern
Während die Tätigkeiten im Discovery Track in unregelmässigen Zyklen erfolgen können, werden die Arbeiten im Development Track in zeitlich fix definierten (2-4 Wochen) Sprint-Iterationen erledigt.
Zwei Tracks, zwei Boards
Von diesem Ansatz inspiriert, ordnen wir die Tätigkeiten des agilen Requirements Engineerings – hier verstanden als „alle Arbeiten, die zur Bereitstellung von User Stories erforderlich sind“ – dem Discovery Track zu. Für die Sicht- und Nachvollziehbarkeit der Aktivitäten im Discovery Track bedienen wir uns dem Kanban-Board. Für die Arbeiten im Development Track verwenden wir weiterhin ein Scrum-Board.
Das Kanban-Board gliedern wir in die Teilschritte zur Erarbeitung von User Stories bis diese die Definition of Ready erreicht haben und damit bereit für die Entwicklung sind. Bei uns sind dies:
Backlog > 3 Amigos > Design > Storywriting > Refinement > Textredaction > Ready for Dev
Für die Arbeiten im Development Track verwenden wir weiterhin ein Scrum-Board und verfolgen damit deren Fortschritt bis zur Erreichung der Definition of Done anhand der folgenden Status:
To Do > In Progress > In Testing > Done
Ist eine User Story im Discovery Track in der Spalte „Ready for Dev“ erhält sie den Status „To Do“ und kann in der Folge mit einem nächsten Sprint im Development Track in die Entwicklung gehen.
Ein Team, zwei Tracks
Das Separieren in zwei Tracks kann den Anschein erwecken, dass in „Silos“ gearbeitet wird. Dem ist nicht so: Die Entwicklungs- oder auch die Qualitätsperspektive fliesst in den Discovery Track ein. Bei uns beispielsweise in den Schritten „3-Amigos“ und „Refinement„. Umgekehrt engagieren sich im Development Track beispielsweise auch Business Analystinnen oder UX/UI Designer, sei es indem sie während der Entwicklung noch aufkommende Fragen beantworten oder bei einer User Story das Entwickelte prüfen.
Fazit
Mit diesem Mix aus Elementen verschiedener agiler Ansätze lässt sich eine holistische Sicht auf die aktuellen Arbeiten generieren, welche den Tätigkeiten rund um das agile Requirements Engineering ebenso Rechnung trägt wie den Entwicklungsarbeiten.
