Gastbeitrag: Katja Roth www.katjaroth.com
Das Team sitzt im Sprint Planning 2 zusammen und befasst sich mit der Frage, wie die im Sprint Planning 1 gezogenen User Stories umgesetzt werden sollen. Es klärt die technischen Details, stellt architektonische Fragen und schreibt das, was zu tun ist als Tasks auf Karteikarten. Typische Tasks sind: „Controller anpassen“ oder „Service schreiben“.
Nun beginnt der Sprint. Zwei Teammitglieder ziehen den Task „Controller anpassen“. Im Daily Scrum berichten sie am folgenden Tag darüber, was sie schon alles am Controller verändert haben und dass sie noch einen weiteren Tag benötigen, um die Arbeit zu beenden. Andere Teammitglieder wundern sich, warum dieser Task so viel Zeit in Anspruch nimmt, erinnern sich aber auch nicht mehr daran, was im Sprint Planning 2 zu diesem Task vereinbart wurde. Am Ende des Sprints ist die User Story nicht fertig, weil auch bei den anderen Tasks nicht klar war, was konkret getan werden sollte.
Eine Veränderung musste her. Aber was kann man also tun, um den Umfang eines Tasks besser zu umreißen? Das Team entscheidet sich zu einer radikalen Veränderung. Künftig soll es keine technischen Tasks mehr geben. Stattdessen setzt das Team auf ein feature-getriebendes Vorgehen. Und so sieht das dann aus: zunächst klärt das Team für jede User Story anhand der Akzeptanzkriterien, welche manuellen und automatischen Tests notwendig sind. So findet es heraus, ob es Unstimmigkeiten in den Akzeptanzkriterien gibt und ob die Story vollständig verstanden wurde. Dann wird jede User Story in aufeinander aufbauende Mini-Features zerlegt, die schrittweise umgesetzt werden sollen. Ein typischer Task lautet: „Straße und Hausnummer erfassen“. Um die technische Umsetzung nicht komplett aus den Augen zu verlieren, führt das Team für jede Story einen Code Dive durch (schaut sich also die betroffenen Stellen im Code an). So gelingt es die Eckpfeiler der technischen Realisierung festzulegen, was schließlich zentrale Aufgabe im Sprint Planning 2 ist.
Nach einigen Sprints kann das Team dieses Fazit ziehen: mit Feature Driven Development ist das Ziel jedes Tasks klar umrissen und das Team verzettelt sich nicht mehr bei der Umsetzung. Außerdem gibt es einen weiteren, wenn auch ungeplanten, positiven Nebeneffekt. Spezialisten, wie Frontendentwickler sind jetzt deutlich besser in das Team integriert. Sie bearbeiten nicht mehr den Task „Frontend erstellen“, da von jetzt an (fast) jeder Task einen Frontend-Anteil hat. Stattdessen arbeitet der Frontend-Experte jetzt interdisziplinär an allen Tasks mit. Durch die Vorab-Festlegung der Testfälle hat das Team außerdem ein deutlich besseres Verständnis der User Stories erreicht.
Versuchen Sie es doch auch einmal feature-getrieben!
