Produktentwicklung beginnt mit der Vision und den Zielen. Verzichten Sie in dieser Phase nicht auf die Experten des Umsetzungsteams! Sie können Ihnen helfen, die richtigen Feature für Ihre fachlichen Ziele zu finden. Und nur indem Sie das Wissen und die Kreativität der Experten nutzen, Vision und Ziele teilen, erzeugen Sie Leidenschaft und Engagement für Ihr Produkt!
Das Estimating-Meeting hat das Ziel, ungefähre Kosten für die fachlichen Ziele heraus zu finden und mögliche Risiken frühzeitig zu erkennen. Dafür formuliert der Product Owner entweder alleine oder mit dem Team zusammen Stories.
Die Kraft dieses Meetings liegt darin, dass alle Experten an einem Tisch sitzen, Informationen direkt austauschen, Lücken evtl. schließen und Missverständnisse weitgehend unmittelbar beseitigen.
Oft kommt es vor, dass die Stories noch zu "groß" sind, also nicht schätzbar. Dann werden sie vom Team so lange in kleine Stories zerlegt, bis die einzelnen Teile schätzbar sind.
Das Estimating findet so oft statt, bis alle fachlichen Ziele in Stories formuliert und geschätzt worden sind.
Es sind nie alle Informationen zu Beginn eines Projekts vorhanden. Daher ist auch das Estimating ein iterativer Prozess. Je länger wir an einem Projekt arbeiten und Ergebnisse schaffen, desto mehr wissen wir. Es werden also auch Re-Estimatings stattfinden können.
Wenn dann genügend Stories geschätzt sind ist der Product Owner in der Lage, diese zu priorisieren und eine Langfristplanung zu erstellen. Voraussetzung dafür ist, dass die Leistungsfähigkeit des Teams bekannt ist. Es dauert in der Regel ca. 3 Sprints, bis das Team in der Lage ist, eine Aussage über die eigene Leistungsfähigkeit vor dem Hintergrund des aktuellen Projektes machen zu können. Eine verlässliche, langfristige Releaseplanung lässt sich somit erst nach den ersten Sprints und dem in diesen Sprints gewonnenen Wissen erstellen.
Beim Estimating erkennt das Team übrigens auch, wo evtl. Know-How fehlt, Arbeitsprozesse und Werkzeuge angepasst oder strategische Designentscheidungen getroffen werden müssen.
Wichtig:
Die Stories sind in Kundensprache formuliert und enthalten einen klar erkennbaren Geschäftswert!
Der Product Owner schätzt NICHT mit! Das Team zerlegt zusammen mit dem Product Owner die fachlichen Ziele in so kleine Häppchen, dass sie schätzbar werden.
Im Estimating werden Größenordnungen geschätzt - heben Sie sich die Details für das Planning auf!
Verabschieden Sie sich vom Vollständigkeitswahn - geben Sie Ihre Schätzungen ab und lernen Sie aus der Realität für die nächste Schätzung!
Teilnehmer: Product Owner, evtl. Anwender, alle Teammitglieder.
Ergebnis: ein geschätztes Product Backlog (Sammlung der Stories).
Das Estimating ist das beste Werkzeug für Macro-Risiko-Management und Langfristplanung.
To top
Voraussetzung für dieses Meeting ist ein priorisiertes, geschätztes Product Backlog.
Der Produkt Owner stellt dem Team die Stories vor, die er gerne in der nächsten Iteration geliefert haben möchte.
Im Planning1 werden alle funktionalen Anforderungen einer Story erläutert. Das bedeutet, der Product Owner informiert das Team über alle bekannten fachlichen Details und das Team stellt dem Product Owner entsprechende Fragen.
Hier wird weder Design noch Organisation diskutiert.
Es besteht auch nicht der Anspruch eines Lastenheftes. Selbst wenn ein solches existiert, wird es in diesem Meeting nochmals besprochen, um die typischen Missverständnisse zu verhindern oder essenzielle Lücken zu schließen. Außerdem: Fragen Sie sich einmal, wie es um die Nachhaltigkeit der Anforderungen eines Pflichten- oder Lastenhefts in klassisch abgewickelten Projekten bestellt ist...
Wichtig:
Eine Story besteht aus Anwender + Feature + Motivation! Nur dann ist der Product Owner überhaupt in der Lage zu priorisieren und nur dann ist messbar, ob die Story geliefert wurde oder nicht!
Oft haben Product Owner mit technischen Kryptographien zu kämpfen, deren Sinn, Ziel und Mehrwert sie gar nicht ermessen können.
Ein negativ-Beispiel:
"Oracle Datenbank aufsetzen;" ist KEINE Story sondern ein Task, um eine Story zu liefern!
So eine Formulierung kann im Ergebnis weder gemessen, noch vom Product Owner priorisiert werden.
Beispiel für eine mess- und priorisierbare Story:
"Der Redakteur kann im Redaktionssystem Beiträge von Mitgliedern ablehnen, um die Kommunikationsrichtlinien zu gewährleisten;"
Selbstverständlich benötigen Entwickler für die Umsetzung mehr Spezifikationen! Diese werden, falls noch nicht vorhanden, spätestens beim Planning 2 erfragt und dokumentiert.
Teilnehmer: Product Owner, Team, Anwender
Ergebnis: Sprintbacklog, Funktionalitäten sind bekannt und verstanden
 To top
Das Planning 2 folgt unmittelbar auf das Planning 1 und behandelt das Design, ist also im Wesentlichen ein Architektur- und Designworkshop. Das Team bespricht, wie die Umsetzung der geplanten Stories aussieht. Das "Abfallprodukt" dieses Meetings sind die Tasks.
Die Tasks werden in Aufwand geschätzt. Die Kapazität des Teams entscheidet letztendlich darüber, welche Stories tatsächlich geliefert werden können.
Wichtig:
Nur das Team entscheidet, wie viele Stories in einen Sprint passen! Diktatur durch den Product Owner führt unweigerlich zu Qualitätsverlusten!
Die Tasks sollten keinen größeren Aufwand haben als jeweils 1 Personentag, damit eine Fortschrittskontrolle im Daily Scrum möglich ist
Tagesgeschäft oder andere Tätigkeiten sowie Abwesenheiten sind Bestandteil der Kapazitätsbestimmung, werden also explizit mit eingeplant.
Jede Story ist erst dann "fertig" geplant, wenn Qualitätssicherung (innere und äußere), Dokumentation etc. Bestandteil der Planung sind.
Teilnehmer: Team
Ergebnis: Commitment auf die zu liefernden Stories der nächsten Iteration und Taskboard
To top
Das Daily Scrum ist während des Sprints ein tägliches Treffen, in dem die Teammitglieder sich gegenseitig über den Ergebnisfortschritt informieren und Hindernisse kommunizieren.
Dabei werden die erledigten Tasks auf "done" gehängt. Jedes Teammitglied sucht sich einen oder mehrere Tasks für den aktuellen Tag und hängt diese auf "in progress".
Hindernisse bekommen eine Lösung, einen Verantwortlichen und einen Termin!
Das Meeting wird im Stehen durchgeführt und dauert 15 Minuten.
Jeder im Team beantwortet diese 3 Fragen:
Was habe ich gestern erreicht?
Was möchte ich heute erreichen?
Was ist mir im Weg?
Wichtig:
Es werden Ergebnisse kommuniziert, nicht die Todo's!
Nur Tasks, die auch wirklich in Bearbeitung sind, hängen auf "in progress".
Jeder aus dem Unternehmen darf das Meeting besuchen, aber nur die Teammitglieder sprechen!
Details werden im Anschluss aufgegriffen, wenn notwendig.
Hindernisse werden beseitigt, nicht verwaltet! ;-)
Teilnehmer: Team, alle Interessierten
Ergebnis: Jeder im Team kennt den Projektstatus und weiß, was er an diesem Tag erreichen will.
To top
Bei diesem Treffen stellt das Team am Ende eines Sprints dem Product Owner das Ergebnis vor. Die Lieferung!
Der Product Owner nimmt das Ergebnis ab. Natürlich kann er "ja" oder "nein" zum Ergebnis sagen, das hängt davon ab, ob das Team entsprechend der Vereinbarung geliefert hat oder nicht.
Wichtig:
Es werden potenziell einsetzbare Produktinkremente geliefert. Solche Floskeln wie: "Stellen Sie sich an dieser Stelle vor, das System würde jetzt dies und das tun...", heißen: Wir haben nicht geliefert!
Teilnehmer: Product Owner, Anwender, Team
Ergebnis: Produktabnahme oder Ablehnung
To top
Die Retrospektive ist das Herz des agilen Organismus!
Hier passiert genau das, was iterative, inkrementelle Produktentwicklung ausmacht: Das Lernen! Die Ergebnisse und Ereignisse des vergangenen Sprints werden beleuchtet, bewertet, verarbeitet und fließen als geschäftswertsteigernde Maßnahmen in den nächsten Sprint ein!
Wichtig:
Damit die Retrospektive auch wirklich die richtigen Ergebnisse erzielt braucht das Team eine geschützte, sichere Atmosphäre. Wenn die Mitglieder nicht offen über ihre Probleme sprechen, kann auf die Retrospektive auch verzichtet werden.
Wichtig:
Schaffen Sie eine vertrauensvolle Atmosphäre!
Die Verbesserungsmaßnahmen dürfen keiner Verwaltung zum Opfer fallen sondern werden immer umgehend bearbeitet!
Schauen Sie sich auch die guten Dinge an, sie sind es Wert, beibehalten und gefestigt zu werden.
Teilnehmer: das Team und alle, die das Team dabei haben möchte.
Ergebnis: Teambacklog mit Verantwortlichkeiten und Terminen.
To top
Für eine solide Langfristplanung muss die Leistungsfähigkeit (Velocity) des Teams bekannt sein. In der Regel ist dieser Wert nach 3 Iterationen zu benennen.
Story = Anwender + Feature + Motivation.
Task = was getan werden muss, um die Story zu liefern
|
|
