Artefakte

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…

Team-Mission

Inhalt einer Mission Die Mission deckt die Verantwortungsbereiche (das Was) und die Kultur und Verhaltensstandards (das Wie) ab. Die Mission klärt folgende Punkte: Wie sieht unser Selbstverständnis aus. Was ist der Sinn (Purpose) des Teams? Wie verortet sich das Team innerhalb des Clusters und der Organisation? Wie wollen wir intern zusammenarbeiten (Verhaltensregeln im Team). Wie…

Team-Tasks

Team-Tasks sind Aufgaben und Aktionen, die ein Working-Team plant und durchführt, um Team-Ziele zu erreichen. Team-Tasks sind kein Teil des Team-Backlogs, aber Teil des Team-Iteration-Backlog und werden in der Regel erst im Team-Planning erfasst und geplant. . Passende und weiterführende Artikel: Events Rollen Gruppen Artefakte Team-Planning Team-Sync Team-Backlog-Refinement Team-Review Team-Retrospektive Team-Product-Owner Team-System-Engineer Working-Team . Team-Product-Owner-Gruppe…

Team-Ziele

Team-Ziele sind die meistgenutzten Elemente des Team-Backlogs. Sie beschreiben Ziele und (Zwischen-)Ergebnisse des Teams bezüglich eines Features, eines Moduls oder einer Dienstleistung, je nach Art und Verantwortung des Teams. Allgemein ausgedrückt: Durch die Arbeit des Working-Teams werden Team-Ziele in inspizierbare Ergebnisse verwandelt. Innerhalb einer Iteration kann ein einzelnes Team meist kein fertiges, potentiell auslieferbares System-Inkrement…

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…

Use-Case (Verwendungsszenario)

Use-Cases werden genutzt, um Szenarien zu beschreiben, in denen Nutzer und andere Stakeholder mit dem System interagieren. Use-Cases stellen eine gute Methode zur Beschreibung von funktionalen Anforderungen und dynamischen Verhalten des Systems dar. Dabei lassen sich auch viele nicht-funktionale Anforderugen entdecken. Um bei der Anforderungsanalyse keine wesentlichen Use-Cases zu vergessen, hat es sich bewährt den…