Extended Task Breakdown

extended task breakdown

Alle 14 Tage, immer Donnerstags, ist bei uns Sprintwechsel. In den meisten Fällen ist der Donnerstag bei uns so gefüllt mit Review, Planning und der Retrospektive, dass wir unseren Task Breakdown immer erst am Freitag Morgen schaffen. Dieser Task Breakdown ist bei uns durch die zwei unterschiedlichen Kernkompetenzen Frontend und Backend nicht durchgehend für alle Beteiligten interessant. Eine kurze Erklärung zu unserer Teamstruktur und warum das so ist könnt ihr in dem Artikel Teamstruktur. Trotzdem ist es natürlich wichtig dass beide wissen was die anderen zu tun haben und vor allem ist es wichtig die, Schnittstellen zwischen dem Frontend und dem Backend zu definieren.

Dies hat dazu geführt, dass wir inzwischen zuerst ein Taskbreakdown haben, wo das komplette Dev-Team anwesend ist. Hier wird dann durch alle Userstories gegangen und sowohl die Tasks für die Userstory erstellt, wie auch eine Stundenschätzung abgegeben, wie lange der Task ungefähr dauert. Allerdings nehmen wir es nicht so arg genau mit der Stundenschätzung, es dient uns mehr dazu einen groben Richtwert zu haben und des weiteren dient es dazu, dass wir einen Burndown generieren können, so dass wir ungefähr sehen wie es mit dem Sprint voran geht.

Sollten nun noch weitere Details beim Taskbreakdown benötigt werden, bei denen es notwendig ist dass entweder Frontend oder Backend intensiv diskutieren muss, bzw. es architektonische Entscheidungen zu treffen gibt, so haben wir das inzwischen in unseren sogenannten Extended Taskbreakdown ausgelagert. Hier haben die Entwickler dann die Möglichkeit sich in aller Ruhe noch mal zu den Implementierungsdetails auszutauschen.

Inzwischen hatten wir schon alle möglichen Varianten. Manchmal war gar kein extended Taskbreakdown nötig, manchmal war es nur beim Backend, bzw. Frontend nötig und manchmal war es überhaupt nicht nötig, da dem ganzen Team durch den normalen Taskbreakdown schon klar war, was zu tun ist.