Releaseplanung – Der erste Termin

Releaseplanung – Der erste Termin Releaseplanung – Der erste Termin

Um was geht´s?

Ein Release ist eine Menge von n erforderlichen Sprints, die dann ein verwendbares bzw. brauchbares Produktinkrement generieren. Wann also ist der erste Release fertig?

Kurze Erinnerungshilfe

Beantwortet die Frage: Wann sind wir fertig?
- Genauer: Wann haben wir das Product Backlog soweit abgearbeitet, dass wir das MVP releasen können?
Eingangswerte
- Product Backlog DEEP
- Summe Story Points bis MVP
- Sprint Management
  - Dauer
  - Teamgröße
Release Burndown
- Story Points gegen Sprintzahl auftragen
- Schätzung als „Zielgerade“ eintragen
- Nach jedem Sprint verbleibende Story Points eintragen
- Ist-Verlauf im Vergleich zur Zielgeraden sagt uns, ob wir schneller oder langsamer sind als gedacht
- Erfahrungswert: Nach drei Sprints hat sich die Velocity üblicherweise stabilisiert
Übliche Fehler bei der Releaseplanung
- Keine Releaseplanung oder kein Release Burndown vorhanden
- Product Owner ist nicht die treibende Kraft der Releaseplanung
- Ein zu dicker Release auf einen Schlag – Big Bang ist definitiv nicht agil
- Qualitätskompromisse zu Gunsten von mehr Funktionalität (MVP zu weit oben im Backlog)

Und in der Praxis?

Kommt jetzt drauf an, ob es ein Softwareprojekt oder Organisationsprojekt ist. Auch ein agiles Orga-Projekt hat ein Realeasedatum, allerdings könnten auch nach jedem Sprint bereits releasebare Elemente in die Organisation fließen. Das ist dann toll für die Projektgruppe, kann aber durch sprichwörtlich permanente Changes schnell an Akzeptanz verlieren.

In der Praxis kann die Releaseplanung schnell zu kurz kommen. Das permanente Rad der Sprintzuordnungen kann sich somit wunderbar drehen und produziert eine „Never-Ending-Story“ .

Reflexionsfragen

Releaseplanung ist nicht so trivial, wie sie im ersten Moment aussieht. Wie machen Sie Releaseplanung?
Verwenden Sie die oben genannten Eingangswerte?
Verwenden Sie noch weitere Eingangswerte?