title: “Sprint Retrospective”
date: 2022-03-01T20:48:31
slug: sprint-retrospective

Mit der Retrospective, das zwischen dem Sprint Review und dem nächsten Sprint stattfindet, blickt das Scrum-Team in den Rückspiegel.

In dem etwa dreistündigen Meeting legt es seine Zusammenarbeit auf die Waage, prüft, ob die Arbeitsabläufe hilfreich und wirkungsvoll waren, und ob die Werkzeuge und Methoden passend ausgewählt wurden. Aus den gesammelten Erfahrungen leitet es ganz konkrete Maßnahmen für eine bessere Zusammenarbeit ab.

title: “Sprint Review Meeting”
date: 2022-03-01T20:48:13
slug: sprint-review-meeting

Sobald der Sprint beendet ist, präsentiert das Srum-Team die fertig gestellte Arbeit. Eingeladen sind Product Owner, Scrum Master und Stakeholder. Dieses informelle Treffen ist kein Status-Meeting, sondern es dient den Teilnehmern zur Klärung, welche Funktionen als „fertig“ und welche als „offen“ zählen. Die gesamte Gruppe überlegt, wie sie weiter machen will, und fixiert die Änderungen in einem überarbeiteten Product Backlog.

title: “Daily Scrum”
date: 2022-03-01T20:47:49
slug: daily-scrum

Das Scrum-Team trifft sich täglich zum Daily Scrum Meeting. Damit alles reibungslos abläuft, kümmert sich der Scrum Master um dessen Organisation. Damit hält er dem Scrum-Team den Rücken frei, sodass dieses sich auf sein Kerngeschäft, das Entwickeln, konzentriert. Für das Scrum-Team und den Scrum Master ist die Anwesenheit Pflicht, der Product Owner ist gern gesehen, doch ein Rederecht hat er nicht.

title: “Planning Poker”
date: 2022-03-01T20:47:29
slug: planning-poker

Aufwände schätzen

Planning Poker ist eine etablierte Vorgehensweise, um den Arbeitsaufwand in einem Sprint einschätzen zu können.

title: “Sprint Planning Meeting”
date: 2022-03-01T20:47:03
slug: sprint-planning-meeting

Vor dem Start des Sprints präsentiert der Product Owner die wichtigsten Funktionen, die er nach dem Sprint umgesetzt sehen will.

Das Scrum-Team schätzt deren Realisierungsaufwand ein und fügt gegebenenfalls weitere inhaltlich dazu passende Anforderungen aus dem Backlog ein. Es ist durchaus möglich, dass dadurch niedriger priorisierte User Storys nach oben rutschen.

Doch wenn sie im Zuge der Umsetzung für das gewünschte Feature mit erledigt werden können, ist das eine sinnvolle Vorgehensweise. Für die Sprint-Planung verordnet sich das Team einen festen zeitlichen Rahmen (Time Boxing), um sich nicht in endlosen Debatten zu verlieren. Ein frisches Sprint Backlog markiert das Ende der Planungen.

title: “Scrum Team”
date: 2022-03-01T20:45:22
slug: scrum-team

Das Scrum Team besteht aus Scrum Master, Product Owner und den Entwicklern (vormals Entwicklungsteam)

title: “Der Sprint Backlog”
date: 2022-03-01T20:44:20
slug: der-sprint-backlog

In jedem Sprint soll ein funktionsfähiges Zwischenprodukt entwickelt werden. Deshalb wird bereits vorab im Sprint Planning Meeting entschieden, welche Anforderungen aus dem Product Backlog im nächsten Sprint bearbeitet werden sollen. Das Sprint Planning Meeting findet zu Beginn jedes Sprints zur Planung dieser Projektetappe statt.

Nachdem die Anforderungen ausgewählt wurden, werden sie im jeweiligen Sprint Backlog festgehalten. Das Scrum Team ist Eigentümer des Sprint Backlogs und entscheidet welche Anforderungen im nächsten Sprint bearbeitet werden.

Zusammenfassend, enthält der Sprint Backlog also diejenigen Projektaufgaben, die im jeweiligen Sprint erledigt werden sollen. Ergänzt werden die Projektaufgaben um weitere Details, die das Scrum Team benötigt, um das Sprintziel (Sprint Goal) zu erreichen.

Was sind eigentlich Sprint Backlog Tasks?

Nachdem die Anforderungen für den nächsten Sprint vom Product Owner ausgewählt wurden, werden sie in Aufgaben, die innerhalb eines Tages erledigt werden können, unterteilt. Deshalb nennen wir die Bestandteile des Sprint Backlogs auch Sprint Backlog Tasks. Genau wie im Product Backlog wird für jedes Bestandteil des Sprint Backlogs eine Aufwandsschätzung durchgeführt.

title: “Product Backlog”
date: 2022-03-01T20:42:32
slug: product-backlog

Der Product Backlog besteht bei Scrum aus einer Liste mit Punkten (User Stories), die bei der Entwicklung des Produkts erledigt werden müssen. Im Product Backlog werden Änderungen und Ergänzungen aufgeführt, die auf das Produkt anzuwenden sind . Der Product Owner nimmt eine Einteilung nach Prioritäten vor, bei der die wichtigsten Punkte an erster Stelle stehen. Das heißt, dass diese Aufgaben zuerst erledigt werden.

Allen Items im Product Backlog wird ein Wert zugewiesen, beispielsweise ein Geschäftswert. Der Product Owner und das Scrum-Team schätzen ein, welcher Arbeitsaufwand mit jedem einzelnen Punkt verbunden ist. Auf der Grundlage der erwarteten Werte und des Aufwands kann das ROI (Return On Investment) berechnet werden.

title: “Backlog Refinement”
date: 2022-03-01T20:40:55
slug: backlog-refinement

Backlog Refinement Definition

Die kontinuierliche Pflege und Weiterentwicklung des Product Backlogs wird als Backlog Refinement (oder alternativ Backlog Estimation oder Backlog Grooming*) bezeichnet. Es ist ein regelmäßiger Prozess, bei dem Product Owner und Entwickler das Backlog auf den aktuellen Stand bringen. Typische Tätigkeiten im Backlog Refinement sind:

• Aufnahme von neuen User Storys, Features und Epics in das Backlog
• Verfeinerung von vorhandenen Epics, Features und User Storys und gegebenenfalls Aufteilung in mehrere kleine Backlog Items
• Zusammenfassen von User Storys
• Diskussion der Akzeptanzkriterien, Annahmen und Einschränkungen
• Identifikation von Abhängigkeiten
• Korrektur von Aufwandsschätzung aufgrund neuer Erkenntnisse
• Veränderung der Priorisierung aufgrund neuer Erkenntnisse
• Entfernen von irrelevanten User Storys, Features oder Epics aus dem Backlog
• Beseitigung von Unklarheiten durch gemeinsame Diskussion, wobei es um das „was“ und nicht das „wie“ geht

Das Ziel beim Backlog Refinement

Das Ziel beim Backlog Refinement ist es, die höher priorisierten Items im Backlog so vorzubereiten, dass sie sich gut für das Sprint Planning nutzen lassen. Dies führt in der Folge zur Verkürzung von Planungsmeetings bei gleichzeitiger Berücksichtigung aktueller Informationen.

Laut aktuellen Scrum Guide ist der Product Owner für das Product Backlog verantwortlich, als Konsequenz daraus ist er auch für das Refinement verantwortlich, selbst wenn er die Aufgabe delegiert und/oder Entwickler aktiv bei der Verfeinerung mitwirken.

title: “Epic, Story und Task”
date: 2022-03-01T20:38:52
slug: epic-story-und-task

Die folgende Grafik illustriert den Zusammenhang zwischen Epics, Storys und Tasks als Elemente eines Scrum-Projekts.

Epic

Epic ist eine User Story auf höchster Abstraktionsstufe. Für einen Sprint ist sie zu groß. Der Product Owner zerlegt sie deshalb in mehrere kleinere User Storys.

Story

Die Story ist eine User Story und Teil einer Epic. Eine Story enthält die Anforderungen, geschrieben als kleine handhabbare Texte. Auf dieser Basis schätzt das Scrum-Team den Aufwand für die Realisierung der Anforderung ein.

Task

Entwickler und Tester zerlegen eine Story in einzelne Aufgaben (Tasks). Wenn eine Aufgabe eine vereinbarte Zeitspanne überschreitet, kann sie in zusätzliche Aufgaben aufgeteilt werden. Eine Story ist dann erledigt, wenn alle Aufgaben der Story erledigt sind.