Scrum
Scrum Rollen
- Product Owner: Verantwortlich für die Produktvision, das Backlog und die Priorisierung der Aufgaben.
- Team: Verantwortlich für die Umsetzung der Aufgaben und die Lieferung des Produkts.
- Scrum Master: Verantwortlich für die Einhaltung der Scrum-Prinzipien und die Unterstützung des Teams.
| Role | Responsibility | Authority | Characteristics |
|---|---|---|---|
| Scrum Master | Proper implementation of Scrum; understanding of Scrum by all involved. | Leading change in the introduction and further development of Scrum; removal of obstacles for the team. | Very good Scrum and coaching competencies. |
| Product Owner | Maximizing the value of the product; managing the Product Backlog. | Creating the Product Backlog; prioritizing Product Backlog entries. | Very good product and customer understanding. |
| Team | Self-organization; exclusive creation of product increments. | Assembling interdisciplinary experts; determining how the Product Backlog is to be implemented. | Interdisciplinary experts. |
Scrum Artefakte
Artefakte sind die Ergebnisse der Scrum-Prozesse, die zur Entwicklung eines Produkts verwendet werden. Sie dienen als Kommunikationsmittel zwischen den verschiedenen Rollen und helfen dabei, den Fortschritt des Projekts zu verfolgen.
Product Backlog
Das Product Backlog ist eine priorisierte Liste von Anforderungen an das Produkt, die vom Product Owner erstellt und gepflegt wird.
User Story
Schema
Als <Rolle> will ich <das Ziel>, sodass <Begründung>.
INVEST
User Stories sollten INVEST sein:
- Independent: User Stories sollten unabhängig voneinander sein, damit sie flexibel bearbeitet werden können.
- Negotiable: User Stories sollten verhandelbar sein, damit sie angepasst werden können
- Valuable: User Stories sollten einen Mehrwert für den Kunden oder das Unternehmen bieten.
- Estimable: User Stories sollten schätzbar sein, damit sie in Sprints
- Small: User Stories sollten klein genug sein, um in einem Sprint bearbeitet werden zu können.
- Testable: User Stories sollten testbar sein, damit sie überprüft werden können, ob sie die Anforderungen erfüllen.
Epics
Ein Epic ist eine große User Story, die in mehrere kleinere User Stories unterteilt werden kann. Es ist eine Möglichkeit, komplexe Anforderungen zu organisieren und zu verwalten.
Sprint Backlog
Das Sprint Backlog ist eine Liste von Aufgaben, die vom Team während eines Sprints bearbeitet werden. Es wird aus dem Product Backlog abgeleitet und enthält die User Stories, die für den aktuellen Sprint ausgewählt wurden, sowie die Aufgaben, die zur Umsetzung dieser User Stories erforderlich sind.
Priorisierung
Es gibt verschiedene Methoden der Priorisierung:
- die Reihung der US
- die Vergabe von Punkten (z.B. 1-5), je höher/niedriger, nach konvention, die Punkte, desto wichtiger die US
- Klassifizierung der US in Kategorien (z.B. "Must have", "Should have", "Could have", "Won't have")
Je höher die Priorität, desto genauer sollte die User Story beschrieben sein, damit das Team sie umsetzen kann.
Velocity
Die Velocity ist ein Maß für die Produktivität des Teams und wird in der Regel als Anzahl der erledigten User Stories pro Sprint gemessen. Sie kann verwendet werden, um die Planung zukünftiger Sprints zu erleichtern und den Fortschritt des Projekts zu verfolgen.
Product Increment
Ein Product Increment ist das Ergebnis eines Sprints und besteht aus den User Stories, die während des Sprints bearbeitet wurden. Es sollte ein funktionsfähiges Produkt sein, das potenziell an den Kunden ausgeliefert werden könnte.
Daily Scrum
Das Daily Scrum ist ein tägliches Meeting, das vom Team abgehalten wird, um den Fortschritt des Sprints zu besprechen und mögliche Hindernisse zu identifizieren. Es sollte kurz (ca. 15 Minuten) und fokussiert sein und sich auf die folgenden Fragen konzentrieren:
- Was habe ich seit dem letzten Daily Scrum getan?
- Was werde ich bis zum nächsten Daily Scrum tun?
- Welche Hindernisse stehen mir im Weg?
- Welche Unterstützung benötige ich von anderen Teammitgliedern?
Sprint Review
Das Sprint Review ist ein Meeting am Ende eines Sprints, bei dem das Team das Product Increment präsentiert und Feedback von Stakeholdern erhält. Es dient dazu, den Fortschritt des Projekts zu überprüfen und mögliche Anpassungen am Product Backlog vorzunehmen.
Sprint Retrospective
Die Sprint Retrospective ist ein Meeting am Ende eines Sprints, bei dem das Team über den Sprint reflektiert und mögliche Verbesserungen für zukünftige Sprints identifiziert. Es dient dazu, die Zusammenarbeit im Team zu verbessern und die Effizienz des Entwicklungsprozesses zu steigern.
Review vs. Retrospective
| Review | Retrospective |
|---|---|
| Fokus auf das Produkt | Fokus auf den Prozess |
| Präsentation des Product Increments | Reflexion über den Sprint |
| Feedback von Stakeholdern | Feedback vom Team |
Das Review dient dazu, den Fortschritt des Projekts zu überprüfen und mögliche Anpassungen am Product Backlog vorzunehmen, während die Retrospective dazu dient, die Zusammenarbeit im Team zu verbessern und die Effizienz des Entwicklungsprozesses zu steigern.