Personentage und Sizes verheiraten

Abbildung von Scrum Sizes auf Personentage

In Scrum werden vom “Product Owner” (PO) die Wünsche (Features/Funktionen) an die zu entwickelnde Lösung in einem “Product Backlog” gesammelt. Diese Wünsche werden durch das “Scrum-Team” hinsichtlich Umsetzungsaufwand bzw. der zu erwartenden Komplexität in einem “Estimation-Meeting” bewertet. Im “Sprint-Planning” wird dann entschieden, welche Wünsche im nächsten Sprint umgesetzt werden sollen. Üblicherweise wünscht sich der PO so viele Dinge, dass die verfügbare Entwicklungszeit in einem Sprint genau ausreicht, um die Wünsche umzusetzen.

Für Abschätzungen in Scrum wird üblicherweise empfohlen nicht in Personentagen sondern in sogenannten “Scrum Sizes” zu schätzen, um Fehler im Schätzverhalten der beteiligten Personen zu reduzieren.

Eine große Herausforderung hierbei ist es, festzustellen, wie viele Wünsche (bewertet mit Sizes/Komplexität/Story Points) in X Tagen umgesetzt werden können. Es ist demnach eine Verbindung zwischen Size/Story Point und Personentag zu ermitteln.

Ich habe mittlerweile verschiedene Ansätze hierfür kennengelernt, ich möchte in den kommenden Sprints grob wie folgt vorgehen und dann die Ergebnisse bewerten:

  1. Verplanbare Team PTs =  Arbeitstage (Fehlzeiten abgerechnet) – administrative Tätigkeiten – Scrum Prozesskosten – weiterer Verpflichtungen
  2. Sizebare Tage (PT) = Verplanbare Team PTs – gedeckelte Support-Stories (bewertet in PT)
  3. Size Faktor = Sizebare Tage / Summe Sizes (Story Points) der Stories einer Iteration

Nach einigen Sprints sollte sich der Size Faktor stabilisiert haben (evtl. Mittelwert über die n letzten Sprints legen): Die Planung wird erleichtert, da jetzt besser zu bewerten ist, ob die Summe Sizes Stories auch in der Vergangenheit in die sizebaren Tage “gepasst hätte”.

Da ich (leider) mit Multi-Projekt-Scrum leben muss, wird diese Planung relativ schnell aufwändig, vorallem wenn man eine ausreichend belastbare Aussage über die Auslastung des Scrum-Teams in den nächsten N Sprints treffen soll. Andererseits ist eine solche Planung auch beliebig ungenau, d.h. sie kann nur ein Indikator sein. Es ist deshalb stets darauf zu achten “angemessen” in Excel-Turnerei zu investieren, um nicht “Muda” zu produzieren :-)