Planning Pattern II – Test Driven Sprint Planning

Im ersten Teil dieser Reihe habe ich erklärt, wie ein Team im Sprint Planning dafür sorgt, dass während des Sprints ein Flow entsteht. Diesmal möchte ich darauf eingehen, wie die Struktur auf dem Scrum Board den Verlauf des Sprints beeinflusst und wie man im Sprint Planning darauf Einfluss nehmen kann.

Auch wenn Scrum Teams in der Regel cross functional sind, ist es doch weit verbreitet, dass es eine Aufteilung der Rollen zwischen Testern und Entwicklern gibt. Für viele Teams ist das auch völlig in Ordnung, wenn die Zusammenarbeit klappt. Bei einem Team, für das ich als ScrumMaster arbeiten konnte, hatte ich die Gelegenheit, mit dieser Zusammenarbeit zu experimentieren und mit dem Team gemeinsam das entwickelt, was wir später als Test Driven Sprint Planning bezeichnet haben.

Generische Test Tasks
Generische Test Tasks

Zunächst verliefen die Plannings in diesem Team so wie ich es auch schon von anderen Teams kannte: Der Product Owner präsentierte seine Storys, die Entwickler schnitten Tasks und am Ende klebten die Tester drei Zettel ans Board auf denen stand: „Test Design“, „Test Automation“, „Test Execution“. Solche generischen Tasks sind natürlich wenig hilfreich, wenn man einen guten Flow im Sprint haben möchte und sie geben auch kein Gefühl dafür, was schon erreicht wurde und was noch fehlt.

Im Laufe der Zeit gelang es uns, das Planning umzudrehen. Nachdem der Product Owner seine Storys präsentiert hatte, übernahmen die Tester die Führung des Plannings. Anhand der Akzeptanzkriterien entwickelten sie Testideen. Das waren grobe Beschreibungen eines Tests, die auf die gleichen Post-Its passten, wie die Tasks.

Scrum Board mit Testideen
Scrum Board mit Testideen

Die Testideen klebten wir neben die Storys untereinander und überlegten dann, welche konkreten Tests sich daraus ergeben würden – und was implementiert werden müsste, damit der Test grün würde. Damit erarbeiteten Tester und Entwickler gemeinsam eine Reihe von Aufgaben zu jeder der Testideen, die dann in eine Zeile neben jede Testidee passten. Das Scrum Board entwickelte ganz von selbst eine sehr übersichtliche Struktur, die es erlaubte, Fortschritt im Sprint und auch Probleme während des Tests für alle im Team extrem gut sichtbar zu machen.

Diese Erkenntnis lieferte uns dann das zweite Planning Pattern:

Entwickle aus den Akzeptanzkriterien Testideen und überlasse die Führung des Sprint Plannings den Testern. Entwickler machen die Tests grün.

Der Ansatz hat nicht nur auf dem Scrum Board zu einer Veränderung geführt. Auch während des Sprints lief die Zusammenarbeit besser. Die Idee des Test Driven Development funktioniert also nicht nur mit Unit Tests, sondern lässt sich auch auf anderen Abstraktionsebenen anwenden.

Dieser Artikel erschien zuerst im adesso Blog.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.