Artefakte

Stakeholder-Story

Die Stakeholder-Story stellt im P4-Framework die Erweiterung der User-Story auf alle Stakeholder dar. Damit können und sollen Bedürfnisse und Anforderungen aller Stakeholder an das Produkt formuliert werden. Diese sind viel mehr als nur die Nutzer, gerade im Umfeld der physischen Produktentwicklung. Stakeholder-Stories lassen sich ebenfalls in der Organisations- und Prozessentwicklung einsetzen, also z.B. wenn es…

System-Anforderungen & Funktionen

Systeme werden auf der obersten Ebene durch System-Anforderungen und Funktionen (Features) beschrieben. Anforderungen beschreiben dabei ausschließlich Fähigkeiten oder Eigenschaften im „Problemraum“, sind also noch losgelöst von konkreten System-Lösungen. Der Lösungsraum wird aber bereits durch die Quality Attributes & Constraints eingeschränkt. Schnittstellen zu Nachbarsystemen im Umfeld sowie deren Eigenschaften werden hier ebenfalls spezifiziert. Hierfür wird ein…

System-Inkrement

System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie durch Nutzer- und/oder Markttests verifiziert werden. System-Inkremente werden meist von den Applikationsteams des Clustes erzeugt d.h. durch die Integration von Teilergebnissen der verschiedenen Teams eines Clusters (Modul- und Plattformteams, sowie Feature-Teams). Für das System-Inkrement hat P4 die Arten und Definitionen von…

System-Konzepte, -Architekturen und -Fähigkeiten

Systemkonzepte beschreiben mögliche Lösungen für System- bzw. Produktvarianten (Applikationen = Feature-Sets) und deren Anforderungen. Systemkonzepte realisieren dabei die System-Anforderungen innerhalb der Einschränkungen (Contraints) und balancieren die Qualitätsanforderungen (Quality Attributes) aus. Das P4-Framework sieht im System-Backlog explizit mehrere Systemkonzepte als Lösungsoptionen für die Umsetzung von Systemanforderungen vor. Dies bedeutet, dass möglicherweise mehrere Lösungen für ein Problem…

Team-Backlog-Item (TBI)

Team-Backlog-Items (TBI) sind die einzelnen Elemente (Backlog-Items) eines Team-Backlogs und beschreiben Arbeiten für ein einzelnes Team. Von der Größe her ist ein TBI zu Beginn nicht beschränkt. Es muss aber vor der Einplanung im Team-Planning, d.h. vor dem Ziehen in das Team-Iterations-Backlog, in mehrere, in einer einzelnen Iterationen leistbare Einzelelemente, aufgeteilt werden. Dies geschieht normalerweise…

Team-Backlog

Team-Backlog Jedes Team hat für seinen Verantwortungsbereich und seine Aufgaben genau ein Backlog. Die darin enthaltenen Elemente (Team-Backlog-Items) bestehen in der feinsten Granularitätsstufe aus Team-Zielen für das Team. Das Team-Backlog wird vom Team-Product-Owner verantwortet und priorisiert. Ein großer Teil des Team-Backlogs wird durch die Team-Product-Owner-Gruppe und die Team-System-Engineer-Gruppe aus dem Cluster-Backlog, bzw. den System-Backlogs durch Verfeinerung…

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…

Team-Improvement-Backlog

Das Improvement-Backlog beschreibt den Vorrat an Verbesserungen und wird von der entsprechenden Einheit, selbst-organisiert, in die Arbeitsplanung integriert. Eine Regel, die beschreibt, wie viel Arbeitsaufwand für Verbesserungen investiert wird (z.B. 10-20%), hilft die Planbarkeit und Vorhersagbarkeit von anderen Backlog-Einträgen hoch zu halten. Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf…

Team-Iterations-Backlog

Das Team-Iterations-Backlog reflektiert die Arbeit eines Teams für eine gerade laufende Iteration. Es wird für jede Iteration im Team-Planning neu erstellt. Die geplanten Arbeiten, reflektiert durch Team-Backlog-Items (TBI), werden dabei zu Beginn der Iteration vom Working-Team in das Team-Iterations-Backlog gezogen, was als Pull bezeichnet wird, und dann ggf. durch weitere Aufteilung, in Aufgaben (Team-Tasks) verfeinert.…

Team-Kalender

Der Team-Kalender stellt die Verfügbarkeit der Nucleus- und Extended-Team-Mitglieder für eine Iteration tabellarisch dar. Jedes Team-Mitglied trägt geplante Abwesenheiten ein, um vor (oder spätestens in) der Iterationsplanung die Brutto-Kapazität des Teams zu ermitteln. Dieser Wert wird zur Anpassung des Team-Forecasts genutzt, in dem er ins Verhältnis zur Velocity des Teams gesetzt wird, wodurch sich wird…