Kapazität für Sprint und PI Planning rechnen
Vor jedem Sprint Planning kommt dieselbe Frage. Wie viel passt in diesen Sprint, wenn zwei Leute Ferien haben und am Freitag Feiertag ist? Der Rechner beantwortet sie für einen Sprint, für ein PI nach SAFe und für die Frage, wann ein Umfang fertig wird. Er rechnet im Browser, die Eingaben verlassen diese Seite nicht.
Kapazität für einen Sprint
Personentage nach Pensum, Ferien und Feiertagen, Stunden nach den Scrum-Events. Mit der Velocity der letzten Sprints kommt eine Prognose dazu.
| Name oder Rolle | Pensum % | Abwesend, Tage | Anteil | Entfernen |
|---|---|---|---|---|
Verfügbar in diesem Sprint
- Stunden für Sprintarbeit
- –
- Anteil am üblichen Sprint
- –
- Events und Termine je Person
- –
- Üblicher Sprint, Personentage
- –
Prognose Velocity
Kapazität für ein PI nach SAFe
Ohne Velocity rechnet der Rechner mit normalisierten Story Points nach SAFe: acht je Vollzeitperson und zwei Wochen, Teilzeit anteilig, minus einen Punkt je Ferien- oder Feiertag. Mit Velocity verteilt er sie nach den verfügbaren Personentagen auf die Iterationen. Die Abwesenheiten trägt man je Iteration ein.
Planbar im PI
- Mit Puffer
- –
- Vollzeitstellen im Team
- –
Wann ist der Umfang fertig?
Eine Monte-Carlo-Simulation zieht 10'000-mal zufällig aus den Velocities der letzten Sprints und zählt, nach wie vielen Sprints der Restumfang erledigt ist.
Fertig nach
Mindestens drei Velocity-Werte eintragen, dazu den Restumfang in Story Points.
Die Eingaben bleiben in diesem Browser. Der Link trägt sie mit, falls man sie jemandem schicken will.
So rechnet der Sprint-Teil
Für jede Person zählt der Rechner die Arbeitstage im Sprint ohne Feiertage und ohne ihre Abwesenheiten und multipliziert sie mit dem Pensum. Die Summe sind die verfügbaren Personentage. Davon gehen die Stunden für Scrum-Events und feste Termine weg, anteilig zur Anwesenheit.
Für die Events schlägt der Rechner einen Wert aus den Höchstdauern im Scrum Guide 2020 vor: Sprint Planning acht Stunden, Review vier Stunden und Retrospektive drei Stunden für einen Sprint von einem Monat, bei kürzeren Sprints anteilig, dazu 15 Minuten Daily Scrum je Arbeitstag. Für zwei Wochen sind das zehn Stunden. Die Dauern im Scrum Guide sind Höchstwerte, der Wert lässt sich deshalb überschreiben.
Die Prognose nimmt die durchschnittliche Velocity der letzten Sprints und passt sie an die Kapazität an. Hat das Team diesmal 80 Prozent der Personentage eines üblichen Sprints, rechnet sie mit 80 Prozent der üblichen Velocity. Die Spanne kommt aus dem tiefsten und dem höchsten Wert. Ohne Angabe gilt die volle Besetzung als üblicher Sprint; wer die Personentage seiner letzten Sprints kennt, trägt den Durchschnitt ein, sonst fällt die Prognose zu tief aus.
So rechnet der PI-Teil
Für ein Team ohne eigene Velocity schlägt SAFe normalisierte Story Points vor. Jede Vollzeitperson im Team bringt acht Punkte je Iteration von zwei Wochen, Teilzeit anteilig, und für jeden Ferien- oder Feiertag wird ein Punkt abgezogen. Gedacht ist das als Startwert für die ersten Iterationen; wibas erklärt in einem Artikel, warum die Formel danach nicht mehr passt. Bei anderen Iterationslängen rechnet der Rechner die acht Punkte anteilig um.
Mit einer Velocity rechnet der Rechner anders. Er zählt je Iteration die verfügbaren Personentage, setzt sie ins Verhältnis zur vollen Besetzung und nimmt diesen Anteil der Velocity. Eine Iteration mit Ferien bekommt so weniger Punkte als eine ohne.
Die letzte Iteration eines PI ist in SAFe die Innovations- und Planungsiteration. Sie wird nicht mit Features verplant, deshalb zählt der Rechner sie nicht mit, solange das Häkchen gesetzt ist. Der Puffer ist eine Annahme des Teams und keine Vorgabe von SAFe.
Normalisierte Punkte sind ein Startwert. Sobald ein Team ein paar Iterationen hinter sich hat, ist seine gemessene Velocity die bessere Grundlage; dafür ist das Feld Velocity da.
So rechnet die Prognose
Ein Durchlauf der Simulation zieht für jeden kommenden Sprint zufällig eine der eingetragenen Velocities und zählt die Sprints, bis der Restumfang erledigt ist. Nach 10'000 Durchläufen zeigt die Verteilung, wie wahrscheinlich ein Enddatum ist. Die Zeile mit 85 Prozent heisst: In 85 von 100 Durchläufen war der Umfang bis dahin erledigt.
Die Rechnung setzt voraus, dass die kommenden Sprints ähnlich laufen wie die vergangenen und dass der Restumfang stimmt. Kommt Arbeit dazu, verschiebt sich das Datum. Bei gleichen Eingaben kommt immer dasselbe Ergebnis heraus, damit sich ein geteilter Link nicht von Aufruf zu Aufruf ändert.
Grenzen
Story Points sind Schätzungen eines Teams. Zwischen Teams lassen sie sich nicht vergleichen. Der Rechner liefert eine Zahl für das Gespräch im Planning und ersetzt es nicht.