Was kann man tun, um Sprints besser zu organisieren?

Im allgemeinen wird das Team innerhalb eines Sprints mehr oder weniger sich alleine überlassen, doch kann man ihm eine Struktur mitgeben, um die Sprints besser zu organisieren? Generell arbeitet das Team autonom an seinen User Stories und trifft sich im Daily Scrum, um die klassischen Fragen zu  besprechen:

  • Was habe ich gestern getan?
  • Was tue ich heute?
  • Was blockiert mich in meiner Arbeit?

Zu beginn eines Sprints werden sich meist die leichtesten Arbeiten herausgenommen und mit diesen gestartet. Der Fortschritt ist optimal und es geht gut voran. Gegen Ende des Sprints merkt man, dass die komplizierten Aufgaben noch nicht finalisiert wurden und außerdem die Definition of Done noch gar nicht berücksichtigt wurde. Zum Ende eines Sprints wird es daher recht hektisch, um alle User Stories zu finalisieren und die offenen Tasks noch schnell abzuschließen. Dabei generiert oftmals das Testen von User Stories – zumindest als User Acceptance Tests den meisten Aufwand. Diese werden im Zweifel, wie auch bei klassischer Vorgehensweise „verkürzt“, um nicht zu sagen: „seitens des Teams gestrichen“, um zum Sprint Review die finale Version zu installieren und zur Präsentation vor dem Product Owner parat zu haben. Diese Art des Sprintverlaufs habe ich bereits mehrfach in der Praxis beobachten können. Und vermutlich bin ich da nicht der einzige.

Und so haben wir unseren Sprint aufgeteilt um diese besser zu organisieren

Für uns haben wir eine Variante erarbeitet, die ich hier kurz vorstellen möchte. Sie ist mit Sicherheit nicht für jedes Team eine gute Vorgehensweise, doch sie hat bei uns so funktioniert, dass die massiven Aufwendungen am Sprintende wesentlich gleichmäßiger über den Sprint verteilt werden konnten, sodass das Ende eines Sprints im Arbeitsaufwand nicht anders als jeder andere Arbeitstag für das Team verlaufen ist.

In unserem Umfeld haben wir uns auf eine optimale Sprintlänge von drei Wochen verständigt. Ein kürzerer Zeitraum generiert insgesamt zu viele Aufwendungen im Sinne der stetigen Deployments und Kundenpräsentationen, dass dies im Verhältnis zum Nutzen zu häufig stattfindet. Vier Wochen hingegen haben sich als ein zu langer Zeitraum herausgestellt, der für das Team und alle Planungen nicht mehr greifbar und zuverlässig planbar ist. Zu viele Unwägbarkeiten tauchen im Verlaufe von vier Wochen auf, sodass sich drei Wochen für uns als optimal herausgestellt haben.

Im Sinne des Test-First-Ansatzes haben wir die drei Wochen (15 Tage) ganz grob in drei Abschnitte aufgeteilt:

Aufteilung eines drei-wochen Sprints mit Fokus auf das Testing
Aufteilung eines drei-wochen Sprints mit Fokus auf das Testing
  1. User Stories verstehen/Konzeptioneieren/Testing vorbereiten (ca. Tage 1-5)
  2. Entwicklung/Implementierung (ca. Tage 6-12)
  3. Testing durchführen, Dokumentation finalisieren und Installation durchführen (ca. Tage 13-15)

User Stories verstehen/Konzeptioneieren/Testing vorbereiten (ca. Tage 1-5)

Selbst nach einem guten Planning, in dem keine Fragen mehr offen blieben sollte sich das Team nicht direkt in die Implementierung stürzen. Hier hilft es meiner Erfahrung nach nochmal gemeinsam die User Stories zu durchdenken und im Team gemeinsam ein Konzept für die Umsetzung zu erstellen. Hierbei geht es in erster Linie nicht darum viel Papier zu erstellen, aber wenigstens ein architekturielles Grundgerüst zu erstellen. Welche Klassen werden verwendet, wo haben wir Schnittstellen zu anderen Systemen/Komponenten, gibt es Patterns, die wir anwenden sollen, wie könnte das User Interface aussehen etc.. Hier ist die Unterstützung von Architekten notwendig aber auch jedes Teammitglied hat seine Erfahrungen, die an dieser Stelle mit eingebracht werden können und auch müssen. Dieses Konzept wird dann schriftlich/digital fixiert und stellt die Grundlage für die Dokumentation dar, die nach der Implementierung dann finalisiert wird. An dieser Stelle kann auch die Erstellung von Use Cases sinnvoll sein. Den Unterschied zwischen User Stories und Use Cases habe ich in einem anderen Artikel nochmal hervorgehoben, siehe User Stories.

Im Zuge der Konzeptionierung werden auch die Testfälle aus Anwendersicht erstellt. Hierbei sind User Acceptance Tests gemeint, die eine Nutzung aus Anwender Sicht erläutern (Salopp gesagt: klicke hier, klicke da…). Diese Tests können schon VOR der Implementierung geschrieben werden, sofern die groben Parameter des Konzeptes klar sind. Sie prüfen maßgeblich die Akzeptanzkriterien der User Stories ab – müssen aber eventuell nach der Implementierung nochmal ein wenig in Details angepasst werden, da eventuell Abweichungen zustande gekommen sind. Optimalerweise findet der Product Owner noch Zeit vor Implementierungsbeginn die Testfälle zu prüfen und freizugeben. Hier fällt schnell auf, ob das Verständnis des Teams den Erwartungen des Product Owners entspricht. Dies ist oft zeitlich ein schwieriges unterfangen, kann sich aber schnell lohnen, wenn sich dadurch Missverständnisse schon früh erkennen lassen.

Entwicklung/Implementierung (ca. Tage 6-12)

Die Implementierung kann optimalerweise dann nach Freigabe der Testfälle durch den Product Owner begonnen werden. Hier sollte wesentlich darauf geachtet werden, dass dies nicht zu formell stattfindet, sonst kann hier für das Team Zeitverlust entstehen, den es sich nicht leisten kann.

Für die Auswahl der User Stories mit denen begonnen wird hat sich für mich folgende Prämisse bewährt:

Beginne mit der schwierigsten Aufgabe. Wenn diese gelöst ist, dann wird der Sprint erfolgreich und alle nachfolgenden Aufgaben werden leichter.

Im besten Falle findet eine test-driven Implementierung statt. Doch dieses Thema ist ein eigenen Kapitel für sich, auf welches ich hier nicht weiter eingehen werde. Es hat sich bewährt, dass Entwickler, bevor sie eine User Story abschließen selbst den User Acceptance Test, der zuvor geschrieben und geprüft wurde, auch durchführen. Dies verhindert, dass der Effekt entsteht:

„Ich bin fertig mit dem Code – aber ob es funktioniert wird ja noch getestet.“

und der Tester findet schon im ersten Testschritt Fehler. Dies generiert unnötige Reibungsverluste, die man verhindern kann.

Tipp: Dies ist die beste Zeit ein Backlog Refinement durchzuführen.

Testing durchführen, Dokumentation und Installation (ca. Tage 13-15)

Im letzten Sprintabschnitt sollten die wesentlichen Implementierungen abgeschlossen sein. Die User Stories sind bereits mindestens von den Entwicklern selbst anhand der User Acceptance Tests getestet worden. Nun können Teammitglieder mit der Rolle „Tester“ sich die implementierten User Stories nochmal anschauen und testen. Die gefundenen, offensichtlichen Bugs werden noch gefixt, die Dokumentation, die aus der Konzeptphase schon begonnen wurde noch finalisiert. Die Installation auf dem Abnahmesystem für den PO wird durchgeführt.

In dieser Phase sollte das Team nochmals sicherstellen, dass die DoD (Definition of Done) für alle User Stories erreicht wurde.

Schreibe einen Kommentar