Ist eine komplette Nikolausliste mit allem Wünschen (aus dem ersten Teil dieses Tutorials) erfasst und priorisiert worden. Kommt es nun darauf an, einen ordentlichen Zeit- und Aufgabenplan in Einklang zu bringen, bei dem mir (dann im dritten Teil) auch ausreichend Bier zur Verfügung gestellt wird.
Da die Wunschliste des Kunden (von welchen Anforderungen auch immer) nicht nur mit der Zeit gewachsen ist, sondern sich auch permanent verändert, ist es notwendig sich erst einmal eine Übersicht über den tatsächlichen Aufwand des Produktes bzw. dessen Auslieferung zu verschaffen.
Auch der Nikolaus kann nur max. 12 Rentiere vor seinen Schlitten spannen, daher muss sich der Kunde (mit dem Projektleiter) zusammen setzten und all die vielen grossen und kleinen Wünsche auf mehrer Auslieferungsschlitten bzw. Releases verpacken. Das Ergebnis dieser Meetings mit dem Kunden und dem Projekleiter sind also mehrere Auslieferungsreleases.
Zum Beispiel:
Die Wünsche (Features) 2,5,242,318,4 und 9 müsssen gleich im ersten Release zur Verfügung stehen.
Die Features 3,126,34,18,22,58, und 63 kommen dann in die Version 2 des Produktes.
Die Features … ins Release 3 … und so weiter…
Das Ergebnis ist eine gruppierte Liste – dem Release Backlog – in dem ganz klar drin steht, was in welchem Release gemacht werden soll bzw. enthalten sein muss. Dabei ist noch nicht definiert worden was das an Zeit und Geld kostet oder gar wann es fertig sein soll. Diese Dinge kommen erst im nächsten (Scrum-)Schritt und können sich aufgrund dessen dann auch wieder ändern. Also die Dinge wie Geld/Zeit/Aufwand die im 2 Schritt definiert werden, können den Release Backlog auch wieder ändern. Wünsche fallen aus dem Release Backlog raus weil sie zu lange dauern und/oder zu teuer werden oder aus Marketinggründen erst in die 2. Version (dem 2. Release) erscheinen sollen etc.
Zum Schluss kommt ein wesentlicher Teil hinzu, bei dem zum einen der Entwickler hinzu kommen und zum anderen der Kunde nicht mehr dabei sein muss. Meist möchte das der Kunde auch gar nicht, weil es viel zu technisch ist. Es geht nämlich darum, fest zu legen, wie lange ein Entwickler für ein bestimmtes Feature haben wird. Also wie lange der Entwickler dafür warschneinlich benötigt in Stunden. „Warscheinlich benötigt“ daher, weil man es in voraus ja nicht genau wissen kann und es daher eine reine Schätzung ist.
Von den sagen wir 20 Features die in eine Release gepackt werden sollen, wird also jedes einzelnen in Stunden Entwicklungszeit geschätzt.
Feature 4: 5 Stunden
Feature 2: 22 Stunden
Feature 3: 46h
Feature 8: 12h
Feature 13: 7h
etc. etc.
Die Reihenfolge spielt in diesem Fall keine Rolle, denn es sollen ja alle geschätzt werden.
Wie bereits erwähnt kann es sich dabei durchaus heraus stellen, das ein bestimmtes Feature entweder keinen Sinn mehr macht, zu teuer ist, oder aus anderen Gründen komplett rausfällt oder in ein späteres Release verschoben wird.
Wichtig dabei ist, das man immer nur ein Release Backlog anschaut. Es geht also immer nur um ein Release das geplant werden soll. Anfangs somit um das erste Release. Was mit dem 2. Release wird ist zu diessem Zeitpunkt noch völlig unwichtig.
