Als Refinement (Verfeinerung) des Cluster-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Cluster-Backlog bestimmt werden.
Schlagwort: Akzeptanzkriterien
Team-DoD (Definition-of-Done)
Das Team, der Team-Product-Owner und die Stakeholder müssen sich darauf einigen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als „Done“ bezeichnet wird. Obwohl sich dies erheblich von Team zu Team unterscheiden kann, müssen alle Team-Mitglieder ein gemeinsames Verständnis davon haben, wann Arbeit erledigt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition-of-Done des jeweiligen Teams, Clusters bzw. der Organisation.
Die DoD ist das Qualitätsversprechen des Teams
Die DoD leitet das Working-Team auch bei der Entscheidung, wie viele Team-Backlog-Einträge es während des Team-Planning in das Iteration-Backlog ziehen kann. Der Zweck jeder Iteration ist es, inspizierbare Ergebnisse, verwendbares Wissen oder potenziell auslieferbare Funktionalität innerhalb eines System-Inkrements zu liefern, die der aktuellen Definition-of-Done entsprechen. Working-Teams liefern in jeder Iteration ein Inkrement an Ergebnissen, Wissen und/oder Systemfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Team-Product-Owner sich jederzeit dazu entscheiden kann, es zu freizugeben.
Wenn die Definition-of-Done für ein Team Teil von Konventionen, Standards oder Richtlinien des Clusters oder der Organisation ist, müssen alle Teams diese Cluster-DoD als Minimalziel befolgen. Wenn „Done“ für ein Team nicht Teil der Konvention des Clusters oder der Organisation ist, muss das Team eine für die Team-Ergebnisse geeignete Definition-of-Done formulieren. Wenn es mehrere Teams gibt, die am selben System arbeiten, müssen alle Teams gemeinsam eine Definition-of-Done erstellen. Jedes System-Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet, um sicherzustellen, dass alle Inkremente gemeinsam funktionieren. Von reiferen Teams wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet anpassen, um strengere Kriterien für eine höhere Qualität sicherzustellen. Neue Einträge in der Definition-of-Done können dazu führen, dass noch zu erledigende Arbeit in früheren „Done“ System-Inkrementen aufgedeckt wird.
Jedes einzelne Ergebnis, Produkt oder System sollte eine Definition-of-Done haben, die den Standard für jegliche daran durchgeführte Arbeit darstellt.
Die Definition-of-Done entspricht daher in ihrem Wesen, den Prozessbeschreibungen und „Standard-Operation-Procedures“ einer klassischen Organisation, allerdings in einer starkt kondensierten Form.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning | Team-Product-Owner | Working-Team | Team-Backlog
. . |
Typen von Backlog-Einträgen
„Das Backlog ist die einzige Quelle der Arbeiten.“ Die allgemeine Beschreibung eines Backlogs und seiner Eigenschaften ist hier zu finden.
Backlog-Einträge bzw. Backlog-Items sind die Einzelbausteine von Backlogs. Sie werden innerhalb der Backlogs eindeutig nach Rang geordnet, also eindeutig priorisiert. Je weiter oben ein Backlog-Eintrag steht, desto wichtiger ist er und desto früher wird er bearbeitet.
Gemeinsamkeiten
Alle Backlog-Einträge haben folgende Eigenschaften und Attribute:
- Einen eindeutigen Kurznamen oder eine sonstige Identifikation (z.B. eine Nummer)
- Eine möglichst kurze, aber aussagekräftige Beschreibung
- Einen Hinweis darauf, wer die Quelle bzw. der Verfasser des Backlog-Eintrags ist. Damit soll klar werden, wen man bei Unklarheiten fragen kann.
- Zur Konkretisierung und Abgrenzung sind Akzeptanzkriterien definiert
- (Optional) Auf Portfolio- und Systemebene schätzen die jeweiligen Product-Owner den Nutzwert von Applikationen und Features ab. Hierfür werden Nutzwerte verschiedener Appikationen/Features relativ gegeneinander bewertet, wobei die Product Owner dazu z.B. Planning Poker verwenden.
- Um anzuzeigen, dass das betreffende Team eine Analyse und Abschätzung durchgeführt hat, wird der geschätzte Aufwand auf dem Backlog-Eintrag notiert
Unterteilung von Backlog-Items nach Typ, Ebene, Größe und Format
Formate
In der Software-Entwicklung hat sich das Spezifizieren von Backlog-Items im Format von User-Stories etabliert. Hierbei wird eine Benutzer-Anforderung in Form eines Satzes beschrieben (Wer möchte Was, Warum). P4 bevorzugt hier den Begriff der Stakeholder-Story, da die Benutzer des Systems nur einen Teil der Anforderer darstellen.
Zur weiteren Ausarbeitung werden häufig Use-Cases genutzt, die in verschiedene Szenarien aufgeteilt werden können.
Mittels Prosa-Anforderungen können einzelne Komponenten, Schnittstelle und deren Fähigkeiten und Eigenschaften beschrieben werden.
Größe
Zur Bearbeitung einer Story durch ein Team, muss diese so klein sein, dass sie in eine Iteration passt. Größere Stories sind per Definition Epics, wobei Epics wiederum in mehrere Stories geteilt werden müssen.
Typ und Ebene
Jede Backlog-Item-Ebene stellt in der Summe ihrer Einträge, den Gesamtaufwand der Produktentwicklung bzw. einer auslieferbaren System-, Markt- oder Applikationsvariante dar.
Dies ist auch die Idee von Epics, Stories und Tasks, die viele Teams bei der Verwendung von Scrum nutzen. Die Summe des Aufwands in allen Epics entspricht der Summe des Aufwands in allen Stories. Dies basiert auf der (theoretischen) Annahme, dass eine Story fertig ist, wenn alle Tasks fertig sind und ein Epic fertig ist, wenn alle enthaltenen Stories fertig sind. Genauso verhält es sich mit dem Gesamtaufwand.
Wenn ein Applikationsteam oder die Cluster-System-Engineer-Gruppe in der Lage ist, alle Backlog-Einträge auf Basis der System-Anforderungen & Funktionen mit den limitiernden Quality Attributes & Constraints, zu schätzen, ist der Gesamtaufwand einer Applikation komplett geschätzt. Da dies meist nicht einfach möglich ist, müssen die Anforderungen weiter auf die Lösungsebene der Systemkonzepte, Architektur und Fähigkeiten herunter gebrochen werden. Auch auf dieser Ebene wird es meist nicht möglich sein, alle Konzeptelemente genau genug zu schätzen, da noch viele Unbekannte und Unsicherheiten (in P4: Wissenslücken) bezüglich der Machbarkeit und der Art der Umsetzung bestehen.
Das Konzept der Wissenslücken basiert auf der Annahme, dass nach dem Schließen aller Wissenslücken die Produktentwicklung erfolgreich beendet ist. Die Summe der Aufwände zum Schließen aller Wissenslücken entspricht also ebenfalls dem Gesamtaufwand der Produktentwicklung. Die Schätzung auf dieser Ebene möglich zu machen erfordert allerdings eine gewisse Zeit, bis die Organisation gelernt hat, dies mit einer genügenden Genauigkeit zu tun.
Normalerweise schätzen Organisationen ihre Aufwände auf Basis der Samples & Integrations, da hierbei die Aufwände zum Schließen der Wissenslücken, deren Randbedingungen und Annahmen wesentlich konkreter definiert sind und die Backlog-Einträge bis auf die Ebene der aufzubauenden Simulationen, Muster und Prototypen verfeinert sind. Wichtig hierbei ist, dass das inkrementelle und ggf. mehrfache Erzeugen und Integrieren von Mustern ausreichend berücksichtigt wird und je nach Innovationsgrad und dem Risikograd der Wissenslücken, mehrere „Prove-of-concepts“ bzw. Wegwerfprototypen nötig werden können.
Ein noch weiteres Herunterbrechen ist auf der Arbeitsebene dann nötig, wenn Samples & Integrations von mehreren Teams realisiert werden. Hierfür werden die Backlog-Einträge gemäß der beteiligten Teams in Team-Ziele aufgeteilt und jedes Team schätzt die bei ihm anfallenden Aufwände. Diese können retrospektiv tatsächlichen Aufwänden zugeordnet werden und damit die relativen Schätzungen normiert oder geeicht werden.
Auf jeder Ebene der Backlog-Typen wird die Produktentwicklung also komplett beschrieben und geschätzt. Bei Nutzung von relativen Punkten zur Abschätzung, wird also auf jeder Ebene eine eigene „Währung“ verwendet. Die Währungen können ineinander umgerechnet werden, wenn nach einiger Zeit Daten vorliegen, die aufzeigen, welche Arbeitsgeschwindigkeit die Organisation auf den verschiedenen Ebenen entwickelt (Velocity).
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning
. . |
Team-Product-Owner
. . |
Working-Team
. . |
Team-Backlog
. . |
Team-Planning
Iterationsplanung (Scrum)
Jede Iteration beginnt mit einem Team-Planning-Event. In diesem präsentiert der Team-Product-Owner dem Working-Team den aktuellen Stand des Team-Backlogs. Neue Einträge oder Änderungen, die dem Working-Team seit dem letzten Team-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Product-Owner innerhalb des Team-Backlogs priorisiert.
Das Working-Team ermittelt die Kapazität für die nächste Iteration durch einen Blick auf die bisherige Arbeitsgeschwindigkeit des Teams (Team-Velocity) und durch Ausfüllen des Teamkalenders, der für jedes Team-Mitglied die Arbeitszeit anzeigt, die es für das Working-Team in der kommenden Iteration leisten kann.
Das Working-Team zieht die Anzahl von Team-Backlog-Items (TBI), die der Einschätzung des Teams über die Kapazität der nächsten Iteration entspricht, in das Iteration-Backlog (Pull) und verfeinert danach die TBIs, je nach Komplexität, durch Definition von Aufgaben (Tasks), die zur Fertigstellung des TBI nötig sind.
Danach startet das Working-Team die Iteration durch ziehen der ersten Aufgaben von „open“ nach „in progress“.
Kontinuierliches Team-Planning (Kanban)
Alternativ zum Planungsrhythmus in Iterationen, kann die Planung der Arbeiten für das Team auch kontinuierlich erfolgen. Hierfür werden die Team-Backlog-Refinements genutzt, wobei ein Team-Backlog-Items, direkt nach der Analyse und Schätzung, in Bearbeitung gehen kann.
–
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Sync
. . |
Team-Product-Owner | Working-Team | Team-Backlog |