Beim agilen Vorgehen geht man davon aus, dass nach jedem Sprint funktionierende und brauchbare Features bereit stehen, die in Betrieb genommen werden können. Wann macht man einen Release?
Die Arbeit für ein Scrum Projekt wird im Product Backlog manifestiert. Hier steht, was am Ende geliefert werden soll, zum Zeitpunkt "heute".
Product Backlog
Das Product Backlog definiert das Fernziel, das Ende der Reise. Es hat teilweise einen visionären Charakter. Alle Aufgaben auf dem Weg werden in Form von User Stories festgehalten. Ordnet man jeder User Story im Product Backlog einen Business Value zu, erhält man eine Kennzahl, die den betriebswirschaftlichen Nutzen wiederspiegelt. Ebenso wichtig sind die Wünsche und Erwartungen der eigentlichen Endbenutzer. Er /sie wird entscheiden, ob die Software brauchbar ist und man damit arbeiten kann oder nicht. Nur wenn sich für Product Owner und Endbenutzer einen Win-Win Situation einstellt, kann man von einem Erfolg sprechen. Um die Wünsche und Erwartungen der Endbenutzer herauszufinden, gibt es mehrere Möglichkeiten, die hier nicht näher beschrieben werden sollen.
Priorisierung
Mit Hilfe des Business Value und der Gewichtung der Endbenutzer kann man die User Stories im Product Backlog priorisieren - die Basis für viele Sprint Backlogs. Das Product Backlog gibt dem Product Owner die Möglichkeit, die Priorisierung der User Stories zu ändern, hinzuzufügen, zu löschen, den Business Value neu zu bewerten, User Stories zusammenzufassen oder zu spitten - Changes are welcome.
Sprint Backlog
Der Product Owner präsentiert vor jedem Sprint im Planning Meeting seine Wünsche und beantwortet damit die Frage, welche User Stories aus dem Product Backlog im kommenden Sprint bearbeitet werden sollen. Das Team ordnet jeder User Story einen Aufwand (Effort) zu und nimmt die Arbeit an, die machbar ist. Man definiert gemeinsam das Sprint Backlog für den kommenden Sprint. Aufgrund von Erfahrungswerten kann man in etwa abschätzen, wie viele User Stories in einem Sprint vom Team abgearbeitet werden können. Das Sprint Backlog ist für die Dauer des Sprints eingefroren.
Releaseplanung
Während alle User Stories im Product Backlog quasi das Fernziel beschreiben, werden in den Sprints einzelne Etappen geplant und umgesetzt. Nach wievielen Sprints ist man nun so weit, das man einen ersten Release machen kann? Die Antwort gibt wiederum der Endbenutzer! Prof. Noriaki Kano hat in den 80-iger Jahren ein Model entwickelt, mit dem man Kundenbedürfnisse kategorisiert und gewichtet - bis heute ein wichtiges Instrument in der Produktentwicklung - Kano Model. Kennt man die Basic, Performance und Exciter kann man ein Paket schnüren, um mit Release One in Produktion zu gehen.
Keine Kommentare:
Kommentar veröffentlichen