XP Series III - Let's go Kano

Das Team ist zusammengestellt, alle User Stories im Product Backlog aufgenommen, geschätzt und priorisiert. Womit soll begonnen werden? Eine Entscheidung, die mit einer vorausgegangen Zielgruppen- und Benutzerstudie einfach zu beanworten ist. Der Product Manager ist hier federführend.

Beim der Umsetzung wird mit den User-Storys begonnen werden, welche das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach werden diejenige User-Storys zu verwirklichen, die geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die User-Storys an, die geringes Risiko und geringen Nutzen auf sich vereinen. Die Fertigstellung von User-Storys mit geringem Nutzen aber hohem Risiko ist zu vermeiden. Zur Analyse wird das Kano-Modell verwendet.

Anschliessend beginnt das gesamte Team den Aufwand der User Stories zu schätzen. Hierfür werden Story Points verwendet, eine releative Kenngrösse, den Aufwand im Vergleich zu anderen User Stories wiederspiegelt. Es kann sein, dass erste Abschätzungen im Verlaufe des Projektes geändert werden.

Alle User Stories, mit Business Value und Risiko gewichtet und vom Team geschätzt, werden im Product Backlog festgehalten. Eine erste Releaseplanung aufgrund der Kano Analyse und der Aufwandschätzung und Zeitplanung wird vorgenommen.

Ausgehend vom Product Backlog in Verbindung mit der Release Planung beginnt das Team die User Storys in Iterationen umzusetzen.

Wie plant man einen Release?

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.

Scrum Projekt Abschluss

Wir schreiben die 10. Woche im aktuellen Scrum-Projekt und nach der Auslieferung von Release 4.0. am 18.Juni geht das Projekt dem Ende zu.
Momentan gibt es noch ein paar Abnahmen mit dem Kunden und die Inbetriebnahme beim Provider. Dannach ist das Projekt abgeschlossen. Zeit, mal ein paar Zahlen zu generieren:

Zeitraum: 13. April bis 18. Juni, 47 Arbeitstage
Team: 4 Developer, 1 Product Owner, 1 Scrum Master

# Story Points: 80 PT
Gesamtaufwand: 188 MT (47 Tage x 4 Developer)

# Sprints: 5, davon 1x 3 Wochen, 2x 1 Woche, 2x 2 Wochen
User Stories/Sprint: 9PT/1, 1PT/2, 26PT/3, 23PT/4, 21PT/5
Durschnitt/Sprint: 16 PT pro Sprint

# Releases: insgesamt 4
User Stories/Release: 9PT/1, 27PT/2, 23PT/3, 21PT/4
Durchschnitt/Release: 20 PT pro Release

# Bugs: 24

Ok, der Blick zurück - jetzt wird's interessant. Wie wurde denn das gesamte Projekt vor Beginn vom Team geschätzt?

Insgesamt wurden 50 Story Points für die gesamte Realisierung VOR Projektbeginn geschätzt. Aus Erfahrung aus anderen Scrum Projekten ist man von 2.5 MT pro 1 SP ausgegangen. Das ist die Basis für die Schätzung. Mit einer pessimistischen und optimistischen Abweichung kann man den Know-How Gap vom neuen Projekt ein bischen ausbalancieren. Mit einer Abweichung von -25% und + 40% kommt man dan bei optimisticher, realistischer und pessimistischer Schätzung auf:

Mit heutigem Wissen kann man dass richtige Verhältniss MT pro User Story leicht errechnen:

Die Aufwandschätzung lag also im realistischen Bereich oberhalb der +40% Grenze!!! Mehr als doppelt so teuer! Die berichtigte Aufwandschätzung sieht wie folgt aus:



Bleibt die Frag offen, wieso 50 SP geschätzt und doch 80 realisert worden..... Das genau ist der Vorteil von agiler Entwicklung. Ein mal mehr war der Kunde "moving target" - d.h. er hat seine Prioritäten im Projekt verlangert, neue Ideen eingebracht und andere verworfen.

Was ist ein Story Point

Soll man eine Aussage über den Aufwand für eine Aufgabe machen, ist man gezwungen zu Schätzen. Je nachdem, wieviel Erfahrungen man hat, um die Aufgabe zu lösen, oder ob man eher optimistisch oder pessimistisch schätzt, oder, oder, oder kommt man zu einer anderen Aussage - eben einer Schätzung.

Wie auch immer man zu einer Schätzung kommt wurden meistens folgende Punkte mit einkalkuliert:

• Risiko
• Know-How
• Komplexität
• Zeit
• Qualität
• Resourcen

Story Points sind eine Einheit für Komplexität (ausschliesslich). Sie dienen der Schätzung von Aufwand für die Erledigung einer Aufgabe. Beispiel:

Wie komplex ist es, vom der Wohnungstür zum nächstgelegenen Supermarkt zu gelangen. Nehmen wir an, es ist 1. Wie komplex ist es dann wohl, von der Wohnungstür zum nächstgelegenen Flugplatz zu kommen? Vielleicht eine 3. Dass bedeutet, dann die Bewältigung der zweiten Aufgabe 3-mal so komplex ist, wie die für Aufgabe eins.

Man macht also bewusst keine Aussage über Zeit, Resourcen, Know-How oder ähnliches. Man versucht vergleichbare Aufgaben in Komplexitätsrelationen herunterzubrechen. Gebräuchlich ist die Fibonacci Folge 1,2,3,5,8 - nicht mehr!
Wenn man ein paar mal mit Story Points geschätzt hat, bekommt man sehr schnell ein Gefühl dafür, wass eine 1, 2 oder 5 ist. Da das Team die Story Points pro User Story definiert, hat der Kunde einen Feedback. Zusammen mit dem ihm bekannten Business Value kann er nun die Priorisierung festlegen. User Stories mit hohem Business Value und geringer Komplexität werden in aller Regel zu Beginn realisiert. Für alle anderen Kombinationen gibt es unterschiedliche Ansätze. So geht man bespielsweise davon aus, dass ein Feature mit einer hohen Komplexität, aber geringem Business Value auch möglichst früh in einem Projekt begonnen werden sollte, da eine hohe Komplexität das Team und den Kunde bezüglich gewonnenem Know-How am weitesten voranbringt. Man geht davon aus, dass nicht die Entwicklung des Produkts die grösste Errungenschaft ist, sondern das gewonnen Know-How ...