Velocity (Arbeitsgeschwindigkeit)

Die Velocity (= Arbeitsgeschwindigkeit) ist eine Größe zur Messung der erledigten Backlog-Elemente, die pro Zeitraum (Iteration oder Zyklus) geliefert wurden. Sie wird verwendet, um eine Prognose der in Zukunft geleisteten Arbeit bereitzustellen. Bedingungen sind, dass das Team und die Zeiträume über die Zeit stabil sind.

Velocity berechnen

Es ist möglich, die Geschwindigkeit einer einzelnen Iteration oder eines einzelnen Zyklus zu berechnen. Für bessere Ergebnisse nehmen wir die Summe aller „erledigten“ Arbeiten aller Iterationen/Cycles, gemessen in Story Points (SP), und teilen sie durch die Anzahl der Iterationen/Cycles. Damit bekommen wir einen Mittelwert der Arbeitsgeschwindigkeit.

Nutzung der Velocity

  • Teams nutzen die Velocity, um während der Iterationsplanung zu ermitteln, wie viel Arbeit in das Iteration-Backlog gezogen werden kann (= Forecast). Um bessere Ergebnisse zu erzielen, werden geplante Abwesenheiten, wie Feiertage berücksichtigt und von dem Forecast abgezogen.
  • Product-Owner verwenden die Velocity, um Meilensteine ​​und Veröffentlichungstermine von Produktversionen (Product Releases) vorherzusagen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Planning-Poker

Planning Poker dient dem gruppenbasierten und relativen Schätzen von Größen, meist dem Aufwand oder der Komplexität von Backlog-Elementen in Entwicklungsprojekten. Genau so lässt sich aber auch der Wert (Business Value) von Features oder ganzen Produkten schätzen.

Warum gruppenbasiert?

  • Es vermeidet einseitige Sichtweisen durch den Blick aus vielen Blickrichtungen.
  • Es fördert die strukturierte Diskussion in der Gruppe. Auch stille Team-Mitglieder werden angeregt, ihre Meinung zu äußern.
  • Allen in der Gruppe wird klarer, um was es sich genau handelt (was gehört dazu, was nicht). Diese Erkenntnisse werden in Form von Akzeptanzkriterien, Randbedingungen und Umsetzungsideen notiert.

Bei der Schätzung in Gruppen gibt es allerdings das sogenannte „Ankerproblem“, wobei der Erste, der eine Zahl nennt, bei allen anderen eine unbewusste Anpassung ihrer ursprünglichen persönlichen Schätzung auslöst. Dies lässt sich durch eine vorherige geheime Festlegung der persönlichen Schätzung beseitigen. Genau hierfür gibt es die Planning-Poker-Karten.

Warum relativ?

Auch hier gibt es mehrere Gründe:

  • Menschen sind im vergleichenden Schätzen besser als im Schätzen von absoluten Größen
  • Realative Schätzungen werden durch den nachträglichen Vergleich tatsächlicher Werte kalibriert. Der tatsächlich benötigte Aufwand zur Realisierung eines Backlog-Elements mit 1 Punkt ist zu Beginn nicht bekannt, kann aber nachträglich ermittelt werden. Da meist nicht einzelne Werte, sondern Summen von Werten interessant sind, gleichen sich außerdem Fehler aus.

Wie funktioniert Planning Poker?

Es gibt eine einfache und klare Gebrauchsanweisung für Planning Poker. Halten Sie sich am besten anfangs strikt daran und verändern ggf. erst dann Dinge, wenn Sie das System wirklich verstanden haben.

Die Vorgehensweise sieht dabei folgendermaßen aus:

  1. Jedes Team-Mitglied bekommt einen Kartensatz.
  2. Der Product-Owner erklärt das Backlog-Element und es wird kurz diskutiert.
  3. Jedes Team-Mitglied wählt eine Karte, die seiner Schätzung entspricht.
  4. Die Karten werden gleichzeitig umgedreht, so dass sie von allen gesehen werden.
  5. Die unterschiedlichen Schätzungen werden diskutiert, insbesondere die Team-Mitglieder mit der niedrigsten und höchsten Schätzung sollten erläutern, warum sie diese Werte gewählt haben.
  6. Die Schätzrunden werden wiederholt, bis diese konvergieren. Das Ergebnis ist ein einziger Wert (kein Bereich)

Referenz

Planning-Poker benötigt mindesten eine Referenz, um vergleichend Schätzen zu können. Es muss also vor der ersten Schätzung festgelegt werden, was einer 1 entspricht. Bei Aufwandsschätzungen verwenden viele Teams als erste Referenz die Definition das 1 Punkt einem Aufwand von einem halben Personentag entspricht (1SP = 1/2PD)

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Backlog-Refinement

.

Cluster-Planning

Cluster-Backlog-Refinement

.

Portfolio-Planung

Portfolio-Refinement

Team-Product-Owner

.

Cluster-Product-Owner

.

Portfolio-Owner

Working-Team

.

Team-System-Engineer-Gruppe

.

Cluster-System-Engineer-Gruppe

Team-Backlog

.

Cluster-Backlog

.

Portfolio-Backlog

Upswing-Gravity-Field

Das Upswing-Gravity-Field ist eine wunderbare Visualisierung zur Feature-Priorisierung von Cluster- und Portfolio-Backlogs.  Der Upswing (Auftrieb) beschreibt die Wertschöpfung eines Systems oder einer Funktion, die Gravity (Schwerkraft) beschreibt den Aufwand, den die Organisation aufwenden muss, um dies zu erreichen. Die Priorität, entspricht dem Quotienten von Wert und Aufwand (Prio = Wert / Aufwand). Durch die Verwendung logarithmischer Größen, wie in der Fibonacci-Folge, einer doppelt-logarithmischen Darstellung und einer Drehung um 45 Grad, erhalten wir diese schönen parallelen Prioritätslinien.

Typischerweise können Product-Owner die Wertschöpfung bzw. des Marktwert verschiedener Produkte am besten gegeneinander abschätzen, haben aber weniger Expertise bei der Abschätzung des Aufwands zu deren Realisierung. Genau umgekehrt verhält es sich bei den Working-Teams: Sie haben von allen Beteiligten der Produktentwicklung das beste Verständnis über Realisierungsaufwände, können aber den Marktwert nicht so gut einschätzen. Daher werden im P4-Framework Wertschöpfung und Aufwände getrennt abgeschätzt und im Upswing-Gravity-Field dargestellt. Es ist damit ein starkes Hilfsmittel für den Product-Owner, um Prioritäten einschätzen zu können.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Backlog-Refinement

.

Cluster-Planning

Cluster-Backlog-Refinement

.

Portfolio-Planung

Portfolio-Refinement

Team-Product-Owner

.

Cluster-Product-Owner

.

Portfolio-Owner

Working-Team

.

Team-System-Engineer-Gruppe

.

Cluster-System-Engineer-Gruppe

Team-Backlog

.

Cluster-Backlog

.

Portfolio-Backlog