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.

title: “Wie sollte eine User Story formuliert sein?”
date: 2022-03-01T20:38:29
slug: wie-sollte-eine-user-story-formuliert-sein

Eine User Story sollte einfach und leicht verständlich sein. Das gelingt mit einfachen Satzkonstruktionen: Subjekt, Verb, Objekt. Mehrdeutige Begriffe gehören nicht in eine User Story.

Die User Story soll sich auch auf das Wesentliche konzentrieren. Rachel Davie, Co-Autorin des Buchs „Agile Coaching“, empfiehlt die Formulierung der User Story nach folgendem Muster:

„Als [Rolle] möchte ich [Funktion] um [Nutzen].“

Dabei ergeben sich Rolle, Funktion und Nutzen aus den Antworten auf die folgenden W-Fragen:

Wer fordert etwas an? (=Rolle)

Der Anforderer ist meist der spätere Nutzer des Systems oder der Nutznießer der zu entwickelnden Lösung.

Was wünscht sich der Anforderer? (=Funktion)

Der Anforderer wünscht sich, dass etwas Bestimmtes passiert. Je klarer und präziser der Wunsch in die User Story eingeht, desto hilfreicher ist die User Story für das Entwicklerteam, um die Anforderungen zu realisieren.

Warum ist das für den Geschäftsfall wichtig? (=Nutzen)

Durch die Anforderung soll ein Ziel erreicht werden. Der Anforderer verspricht sich davon einen Nutzen. Die Beschreibung des Grundes der Anforderung liefert dem Entwicklerteam weitere Informationen zur richtigen Ausführung.

Beispiele für die Formulierung einer User Story

Ein Beispiel für dieses Schema einer User Story ist: Ein E-Learning-Portal, das Seminare für Projektleiter anbietet, könnte für die Registrierung eines neuen Kunden diese User Story texten:

Als Neukunde möchte ich mich im E-Learning Portal registrieren, um mich auf die PMI-Zertifizierung vorzubereiten.

Ein weiteres Beispiel ist:

Als Mitarbeiterin möchte ich auf meiner Startseite des Intranets eine Liste der von mir am häufigsten genutzten Seiten haben, um schnell und direkt auf die Informationen zugreifen zu können.