Sprint 0 für den Flurmonitor: Vision, Product Backlog, Definition of Done und Planning Poker

Sprint 0 für den Flurmonitor: Vision, Product Backlog, Definition of Done und Planning Poker

https://bildung.social/@oerinformatik/

https://oer-informatik.de/flurmonitor-scrum-projektstart

Scrum, Product Backlog, User Stories, Abnahmekriterien, Definition of Done, Planning Poker, Story Points, Release-Plan, Sprint-Ziel, Produktvision, Datenschutz, Flurmonitor

tl/dr; (ca. 29 min Lesezeit): Bevor der Flurmonitor die erste Zeile Thymeleaf bekommt, startet das Team das Projekt nach Scrum: Es besetzt die Verantwortlichkeiten, formuliert eine Produktvision und ein Produktziel, schreibt das Product Backlog mit User Stories und Abnahmekriterien in der Form Angenommen – Wenn – Dann, vereinbart die Definition of Done, schätzt mit Planning Poker und leitet daraus Release-Plan, Sprint-Ziel und Sprint Backlog für Sprint 1 ab. Dabei zeigt sich, warum die anonyme Anzeige eine Anforderung ist und kein Extra [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über den Flurmonitor mit Thymeleaf: Projektübersicht / Scrum-Projektstart / Thymeleaf einbinden / Templates / Ansichtsmodell / Integrationstest der Web-Schicht / Konfiguration und Formatierung / Aktualisierung / Hinweise mit Formularen / Robustheit und Betrieb / GUI-Test mit Selenium / Akzeptanztest / Change Request Keycloak

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Dieser Artikel baut auf der Kann-Liste der Artikel Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick, Scrum und User Stories auf.

Als Scrum-Projektstart-Grundlagen kann ich nach Durchlesen des Artikels…

• … die drei Verantwortlichkeiten, fünf Ereignisse und drei Artefakte von Scrum nennen und Situationen aus einem Projekt zuordnen.

• … eine Produktvision nach einer Satzschablone formulieren und von einem Produktziel unterscheiden.

• … Einträge eines Product Backlogs als User Stories mit Abnahmekriterien in der Form Angenommen – Wenn – Dann (Given – When – Then) schreiben.

• … Abnahmekriterien einer Story von der Definition of Done unterscheiden und eine Definition of Done für ein Projekt aufstellen.

• … Story Points als relatives Maß erklären und den Ablauf einer Schätzung mit Planning Poker beschreiben.

• … die anonyme Anzeige als nichtfunktionale Anforderung einordnen und begründen, wo sie im Backlog und in der Definition of Done steht.

Darüber hinaus kann ich als Scrum-Projektstart-Expertenwissen…

• … aus geschätzten Stories und einer vermuteten Velocity einen Release-Plan ableiten und seine Unsicherheit einschätzen.

• … für einen Sprint mit begrenzter Kapazität ein Sprint-Ziel formulieren und ein passendes Sprint Backlog auswählen.

• … ein Burndown-Chart lesen und daraus Fragen für Daily Scrum und Retrospektive ableiten.

Der Auftrag ist klar: Die Flurmonitore des DBH-Berufskollegs sollen offene Fahrten der Mitfahr-App Mitfahrlabor zeigen. Im Überblick der Reihe ist auch entschieden, wie: als serverseitig gerenderte Seite im Spring-Boot-Backend, entwickelt nach Scrum. Trotzdem schreibt in diesem Artikel noch niemand Code. Zuerst muss das Team klären, wer welche Verantwortung trägt, was das Produkt leisten soll, wann eine Aufgabe fertig ist und wie groß die einzelnen Wünsche sind. Diese Vorbereitung heißt in vielen Teams Sprint 0.

Das Bild zeigt den Ablauf, in dem das Team ab Sprint 1 arbeitet. Alles, was dieser Artikel erarbeitet, steht links: die Vision, das Product Backlog und die Definition of Done.

Stand im Projekt: Sprint 0

Sprint 0 ist kein Begriff aus dem Scrum Guide. Viele Teams nennen so die kurze Vorbereitung vor dem ersten richtigen Sprint. Er liefert noch kein Inkrement, also keine lauffähige Software, sondern die Grundlage, auf der Sprint 1 starten kann. Damit er nicht ausufert, bekommt auch er einen festen Zeitrahmen: Im Fahrplan der Reihe sind dafür fünf Projekttage vorgesehen. Das Team arbeitet die folgenden Punkte ab; am Ende dieses Artikels sind alle erledigt:

Die Ergebnisse legt das Team als Markdown-Dateien im Backend-Repository ab, im Ordner src/a01-scrum: product-backlog.md, definition-of-done.md und sprintplan.md. So liegen die Absprachen neben dem Code und sind versioniert.

Wer macht was? Das Scrum Team und seine Stakeholder

Der Scrum Guide in der Fassung von 2020 kennt keine Rollen mehr, sondern drei Verantwortlichkeiten (accountabilities) innerhalb eines Scrum Teams. Ein Scrum Team ist klein, meist zehn Personen oder weniger, und hat keine Unterteams und keine Hierarchie. Im Flurmonitor-Projekt sind die Verantwortlichkeiten so verteilt:

• Product Owner: Thomas Becker, der als Projektleitung den Auftrag erteilt hat. Er verantwortet den Wert des Produkts und damit das Product Backlog: Er formuliert das Produktziel, schreibt oder beauftragt die Einträge, ordnet sie und entscheidet, was als Nächstes kommt. Wichtig ist, dass es genau eine Person ist. Wünsche anderer laufen über ihn, damit das Team nicht zwischen widersprüchlichen Aufträgen steht.

• Developers: das Projektteam der Auszubildenden, im Szenario unter anderem Jonas Wolff und Oksana Melnyk, und Du. Die Developers erstellen in jedem Sprint ein nutzbares Inkrement, planen ihre Arbeit im Sprint selbst und sind gemeinsam für die Qualität verantwortlich. „Developers“ meint nicht nur Programmierende: Auch wer testet, gestaltet oder dokumentiert, gehört dazu.

• Scrum Master: Das Team entscheidet sich im Projektstart für die Lehrkraft, die das Projekt betreut. Sie entwickelt selbst nicht mit, leitet die Ereignisse an, achtet auf die Zeitrahmen und räumt Hindernisse aus dem Weg, etwa fehlende Zugänge zum Netz der Monitore. Inhaltlich entscheidet sie nichts; das bleibt beim Product Owner und bei den Developers. Eine Person aus dem Team wäre ebenfalls möglich, hätte aber zwei Hüte auf: Wer gleichzeitig Code schreibt und auf den Prozess achtet, kommt in hektischen Phasen meist nur noch zum Code.

Neben dem Scrum Team gibt es Menschen, die vom Produkt betroffen sind oder etwas dazu beitragen, ohne mitzuarbeiten. Sie heißen Stakeholder. Sie sind im Sprint Review eingeladen, sehen das Inkrement und geben Rückmeldung. Ihre Anforderungen bringen sie über den Product Owner ins Backlog. Eine ausführliche Methode dazu beschreibt der Artikel zur Stakeholderanalyse.

Die Produktvision: ein Satz für die Richtung

Wer im Sprint Planning zwischen zwei Einträgen abwägen muss, braucht einen Maßstab. Diesen liefert die Produktvision: ein kurzes Bild davon, für wen das Produkt da ist, welches Problem es löst und was es von anderen Lösungen unterscheidet. Sie gehört nicht zum Scrum Guide, wird aber in fast allen Teams vor dem ersten Sprint formuliert. Eine verbreitete Satzschablone stammt aus dem Buch „Crossing the Chasm“ von Geoffrey Moore:

Für ⟨Zielgruppe⟩, die ⟨Bedürfnis⟩, ist ⟨Produkt⟩ ein ⟨Produktart⟩, das ⟨Nutzen⟩. Anders als ⟨Alternative⟩ ⟨Unterschied⟩.

Für den Flurmonitor hat das Team gemeinsam mit Thomas Becker formuliert:

Produktvision: Für Auszubildende des DBH-Berufskollegs, die für den nächsten Schultag eine Mitfahrgelegenheit suchen, ist der Flurmonitor eine Anzeige in Foyer und Fluren, die offene Fahrten im Vorbeigehen sichtbar macht. Anders als die App muss man dafür nichts öffnen und sich nicht anmelden, und der Monitor zeigt niemals, wer fährt.

Die Vision ist bewusst unscharf in den Details. Konkreter wird das Produktziel (Product Goal), das der Scrum Guide seit 2020 als Verpflichtung des Product Backlogs verlangt. Es beschreibt einen künftigen Zustand des Produkts, auf den das Team hinarbeitet, und lässt sich überprüfen:

Produktziel: Nach Sprint 3 zeigen alle vier Flurmonitore die offenen Fahrten und Hinweise der Schulverwaltung, aktualisieren sich selbst, enthalten keine personenbezogenen Daten und sind durch automatisierte Tests über die Oberfläche abgesichert.

Ein Team verfolgt immer nur ein Produktziel. Ist es erreicht, formuliert der Product Owner das nächste, zum Beispiel „Gesuche erscheinen ebenfalls auf den Monitoren“.

Vom Auftrag zum Product Backlog

Das Product Backlog ist die geordnete Liste aller Dinge, die am Produkt noch getan werden sollen. Seine Einträge heißen Product Backlog Items (PBI). Der Scrum Guide schreibt keine Form vor; viele Teams nutzen User Stories in der Schablone „Als ⟨Rolle⟩ möchte ich ⟨Funktion⟩, damit ⟨Nutzen⟩“. Daneben stehen oft technische Einträge, Fehler oder Untersuchungen, die keine Nutzenden als Rolle haben.

Für den Flurmonitor beginnt das Backlog nicht bei null. Aus dem Backend gibt es schon die Story US-08 „Offene Angebote anonym anzeigen“ mit ihren Abnahmekriterien. Sie beschreibt, was die Schnittstelle liefern muss. Für die Oberfläche kommen weitere Einträge dazu, die das Team in einem Workshop mit Thomas Becker, Andrea Wolf und Heike Brinkmann sammelt. Die IDs beginnen mit MON, damit sie sich nicht mit den Backend-Stories US-01 bis US-08 vermischen:

Am Backlog fallen drei Dinge auf:

• Es ist geordnet, nicht nur priorisiert. Jeder Eintrag hat einen eigenen Rang; zwei Einträge mit „Priorität hoch“ gibt es nicht. Die Reihenfolge legt der Product Owner fest. Er wägt dabei Nutzen, Risiko und Abhängigkeiten ab: MON-01 kommt zuerst, weil ohne Anzeige alles andere wertlos ist; MON-08 steht hinter MON-07, weil es ohne angelegte Hinweise nichts anzuzeigen gibt.

• Oben ist es fein, unten grob. Die oberen Einträge sind so klein und klar, dass sie in einen Sprint passen. Weiter unten stehen ein Epic (MON-13), also eine Story, die für einen Sprint zu groß ist und noch geschnitten werden muss, und eine bloße Idee (MON-14). Beide sind nicht geschätzt. Das ist Absicht: Aufwand in Einträge zu stecken, die vielleicht nie umgesetzt werden, lohnt nicht. Das laufende Verfeinern heißt Backlog Refinement; es ist kein eigenes Ereignis, sondern eine fortlaufende Tätigkeit des Teams.

• Es ist nie fertig. Nach jedem Sprint Review kommen Einträge dazu, andere fallen weg oder rutschen nach unten. Ein Product Backlog ist kein Pflichtenheft, das einmal unterschrieben wird.

Ein Eintrag gilt im Flurmonitor-Projekt als bereit für einen Sprint, wenn er geschätzt ist, Abnahmekriterien hat und das Team ihn verstanden hat. Manche Teams schreiben das als Definition of Ready auf. Auch sie gehört nicht zum Scrum Guide, hilft aber, im Sprint Planning nicht über unklare Einträge zu stolpern.

Abnahmekriterien: Angenommen – Wenn – Dann

Eine Story ist ein Versprechen auf ein Gespräch. Was genau gemeint ist, halten Abnahmekriterien (auch Akzeptanzkriterien, acceptance criteria) fest. Im Backend sind sie in der Form Angenommen – Wenn – Dann notiert, im Englischen Given – When – Then: Angenommen beschreibt die Ausgangslage, Wenn die Handlung, Dann das erwartete, prüfbare Ergebnis. Dieselbe Form nutzt später die Sprache Gherkin, mit der das Team im Akzeptanztest die Kriterien automatisiert prüft. Wer sie jetzt sauber schreibt, spart sich dort die Übersetzung.

Für MON-01 übernimmt das Team die Kriterien von US-08 und ergänzt, was die Oberfläche betrifft:

• AK-MON-01.1: Angenommen, es gibt für morgen ein offenes Angebot ab Gütersloh, Hauptbahnhof ZOB Steig 3, um 07:00 Uhr mit 2 freien Plätzen. Wenn der Monitor im Foyer die Seite lädt, dann zeigt er eine Zeile mit Gütersloh, dem Treffpunkt, „zur Schule“, dem Datum, 07:00 und 2.

• AK-MON-01.2: Angenommen, ein Angebot ist voll oder abgesagt. Wenn der Monitor die Seite lädt, dann erscheint es nicht.

• AK-MON-01.3: Angenommen, ein Angebot stammt von Ben Richter mit dem Pseudonym „Funkenflug“. Wenn der Monitor die Seite lädt, dann kommen weder der Name noch das Pseudonym im HTML der Seite vor.

• AK-MON-01.4: Angenommen, es gibt keine offenen Angebote. Wenn der Monitor die Seite lädt, dann zeigt er den Satz „Gerade keine offenen Fahrten – schau in die App.“ statt einer leeren Tabelle.

Gute Abnahmekriterien sind konkret (echte Werte statt „ein Angebot“), prüfbar (ein Test kann eindeutig grün oder rot werden) und beschreiben das Was, nicht das Wie. „Die Tabelle wird mit th:each erzeugt“ wäre kein Abnahmekriterium, sondern eine Entscheidung der Developers. Für MON-07, die Hinweise der Schulverwaltung, sehen die Kriterien so aus:

• AK-MON-07.1: Angenommen, Heike Brinkmann ist an der Verwaltungsseite angemeldet. Wenn sie den Hinweis „Linie 61 fällt morgen aus“ mit Gültigkeit bis morgen 18:00 Uhr speichert, dann erscheint er beim nächsten Laden auf allen Monitoren.

• AK-MON-07.2: Angenommen, ein Hinweis ist bis gestern gültig. Wenn ein Monitor die Seite lädt, dann erscheint der Hinweis nicht mehr.

• AK-MON-07.3: Angenommen, niemand ist angemeldet. Wenn jemand die Verwaltungsseite aufruft, dann wird er zur Anmeldung geleitet.

Datenschutz ist eine Anforderung, kein Extra

AK-MON-01.3 sieht aus wie eine Kleinigkeit. Tatsächlich steckt dahinter eine der wichtigsten Anforderungen des ganzen Projekts. Die Monitore hängen in öffentlich zugänglichen Bereichen. Ein Name neben „Herford, 06:50 Uhr“ würde verraten, wo und wann eine bestimmte Person regelmäßig unterwegs ist. Das ist ein personenbezogenes Datum nach der Datenschutz-Grundverordnung (DSGVO), und für die Anzeige auf dem Flur gibt es keinen Zweck, der es rechtfertigt.

Eine solche Anforderung beschreibt keine Funktion, sondern eine Eigenschaft: Sie ist eine nichtfunktionale Anforderung. In der Qualitätsnorm ISO/IEC 25010 gehört sie zum Merkmal Sicherheit (security), genauer zur Vertraulichkeit. Rechtlich steht sie auf zwei Grundsätzen der DSGVO: Datenminimierung (Art. 5 Abs. 1 lit. c), also nur so viele Daten wie nötig, und Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen (Art. 25), also Schutz von Anfang an statt nachträglich.

Weil sie für jede Seite des Monitors gilt, taucht sie im Projekt an mehreren Stellen auf:

Genauso arbeiten auch andere nichtfunktionale Anforderungen im Backlog: Lesbarkeit (MON-02) und Barrierefreiheit (MON-09) sind eigene Stories, weil sie eigene Arbeit bedeuten; danach sichert die Definition of Done, dass sie bei neuen Seiten nicht wieder verloren gehen.

Die Definition of Done des Flurmonitors

Abnahmekriterien gelten für eine Story und beschreiben, was sie leisten muss. Die Definition of Done (DoD) gilt für jedes Inkrement und beschreibt, welche Qualität alles haben muss, was das Team als fertig bezeichnet. Nach dem Scrum Guide ist sie die Verpflichtung des Inkrements: Ein Eintrag, der sie nicht erfüllt, darf nicht im Sprint Review vorgeführt werden und wandert zurück ins Product Backlog.

Das Team vereinbart für den Flurmonitor diese Fassung; sie steht als definition-of-done.md im Repository:

Der Kontrastwert stammt aus den Web Content Accessibility Guidelines (WCAG 2.2, Stufe AA). Ein paar Regeln helfen beim Aufstellen einer eigenen DoD:

• Nur, was das Team selbst prüfen kann. „Der Product Owner ist zufrieden“ gehört nicht hinein; das entscheidet sich im Review.

• Prüfbar formulieren. „Code ist sauber“ lässt Streit offen; „Review durch eine zweite Person“ nicht.

• Klein anfangen, in der Retrospektive schärfen. Eine DoD, die in Sprint 1 niemand einhalten kann, wird stillschweigend ignoriert. Das Team kann sie in jeder Retrospektive verschärfen, etwa nach Sprint 3 um „Systemtest über den Browser grün“.

Schätzen mit Planning Poker

Damit Thomas Becker abschätzen kann, was bis wann fertig wird, braucht er eine Größe für jeden oberen Eintrag. Das Team schätzt dazu in Story Points. Ein Story Point ist keine Zeiteinheit, sondern ein relatives Maß für Umfang, Komplexität und Unsicherheit eines Eintrags im Vergleich zu anderen. Wie viele Story Points ein Team pro Sprint schafft, die Velocity, zeigt sich erst nach einigen Sprints.

Als Bezugsgröße wählt das Team zuerst einen kleinen, gut verstandenen Eintrag: MON-04, das Hervorheben von Fahrten mit nur einem freien Platz, bekommt 2 Punkte. Alles andere wird damit verglichen: „Ist MON-02 ungefähr so groß wie MON-04, oder größer?“ Geschätzt wird mit Planning Poker. Jede Person der Developers hat einen Kartensatz mit den Werten 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 und „?“, einer abgewandelten Fibonacci-Folge. Die wachsenden Abstände sind Absicht: Zwischen 5 und 8 lässt sich noch unterscheiden, zwischen 37 und 40 nicht mehr. Der Product Owner schätzt nicht mit, er beantwortet Fragen zum Inhalt.

Eine Runde für MON-07 (Hinweise anlegen) läuft so ab:

1. Vorstellen: Thomas Becker liest die Story und die Abnahmekriterien vor. Die Developers fragen nach: Muss ein Hinweis bearbeitet werden können? Antwort: Nein, Löschen und neu Anlegen reicht vorerst.

2. Verdeckt wählen: Alle legen eine Karte verdeckt auf den Tisch.

3. Gleichzeitig aufdecken: Die Karten zeigen 3, 5, 5 und 13.

4. Ausreißer begründen: Die Person mit 3 hat an ein einfaches Formular gedacht. Die Person mit 13 hat bemerkt, dass es für Hinweise noch keine Tabelle in der Datenbank gibt und die Verwaltungsseite eine Anmeldung braucht. Beides war den anderen nicht klar.

5. Neu schätzen: In der zweiten Runde liegen 5, 5, 8 und 5 auf dem Tisch. Das Team einigt sich auf 5 und schreibt die neue Datenbanktabelle als Notiz zur Story.

Der Wert der Methode liegt weniger in der Zahl als im Gespräch: Die Abweichung in der ersten Runde hat eine Lücke im Verständnis aufgedeckt, bevor jemand eine Zeile Code geschrieben hat. Verdecktes Wählen verhindert, dass sich alle an der ersten genannten Zahl orientieren (Ankereffekt). Zeigt jemand „?“ oder kommt das Team immer wieder bei 20 und mehr an, ist der Eintrag zu groß oder zu unklar und muss zuerst geschnitten oder geklärt werden. Deshalb hat das Epic MON-13 noch keine Punkte.

Vom Backlog zum Release-Plan

Mit geschätzten Einträgen lässt sich eine grobe Vorschau rechnen. Die Velocity kennt das Team noch nicht. Es schätzt sie aus der verfügbaren Zeit und dem Gefühl für die Bezugsgröße: Vier Developers mit je etwa 15 Stunden Projektzeit in zwei Wochen, davon ein Teil für Ereignisse und Einarbeitung in Thymeleaf. Das Team traut sich für Sprint 1 etwa 13 Punkte zu und hofft, danach schneller zu werden. Der Product Owner schneidet das Backlog daraufhin in Sprints:

Der Release-Plan ist keine Zusage, sondern eine Prognose. Sprint 2 ist mit 18 Punkten sichtbar voller als Sprint 1. Das geht nur auf, wenn die Velocity nach dem ersten Sprint steigt. Genau das wird das Team im ersten Review prüfen und den Plan anpassen. Reichen die Punkte nicht, rutscht der Eintrag mit dem niedrigsten Rang (MON-10) in Sprint 3. Als Zeitplan dargestellt, mit fünf Projekttagen für Sprint 0 und zehn je Sprint:

Einen Release-Plan gibt es im Scrum Guide nicht als eigenes Artefakt. Er ist eine verbreitete Ergänzung, die das Product Backlog mit der Zeit verbindet. Er hilft dem Product Owner, Stakeholdern wie der Schul-IT zu sagen, wann sie die übrigen drei Monitore vorbereiten sollten. Das Team legt ihn als sprintplan.md ab und aktualisiert ihn nach jedem Review.

Sprint-Ziel und Sprint Backlog für Sprint 1

Mit dem Ende von Sprint 0 beginnt Sprint 1 mit dem Sprint Planning. Der Scrum Guide gliedert es in drei Fragen. Als Zeitrahmen nennt er höchstens acht Stunden für einen Sprint von einem Monat, bei kürzeren Sprints entsprechend weniger; für zwei Wochen planen viele Teams bis zu vier Stunden:

• Warum ist dieser Sprint wertvoll? Das Scrum Team formuliert gemeinsam das Sprint-Ziel. Es ist die Verpflichtung des Sprint Backlogs und hält den Sprint zusammen, auch wenn sich Einzelheiten ändern: „Ein erster sichtbarer Monitor: Im Foyer erscheinen die offenen Fahrten, ohne Namen und aus 5 m lesbar.“

• Was kann in diesem Sprint fertig werden? Die Developers wählen Einträge aus dem oberen Teil des Product Backlogs, hier MON-01 bis MON-04 mit zusammen 13 Punkten.

• Wie wird die Arbeit erledigt? Die Developers zerlegen jeden Eintrag in Aufgaben von höchstens einem Tag. Einträge und Aufgaben zusammen mit dem Sprint-Ziel bilden das Sprint Backlog.

Für MON-01 sieht der Anfang des Sprint Backlogs zum Beispiel so aus; die Aufgaben entsprechen den nächsten Artikeln der Reihe:

Während des Sprints trifft sich das Team täglich für höchstens 15 Minuten zum Daily Scrum und prüft den Fortschritt zum Sprint-Ziel. Viele Teams zeichnen dafür ein Burndown-Chart: Es zeigt die verbleibenden Story Points über die Tage des Sprints. Ein Eintrag zählt erst als erledigt, wenn er die Definition of Done erfüllt; halb fertige Arbeit verringert die Linie nicht. Wie das für Sprint 1 aussehen könnte, zeigt die Skizze mit angenommenen Werten:

Lange waagerechte Strecken sind typisch für Teams, die viele Einträge gleichzeitig beginnen und spät abschließen. Das Diagramm bewertet niemanden; es liefert Fragen für das Daily Scrum („Was hält MON-01 auf?“) und für die Sprint Retrospective, in der das Team am Sprintende über seine Zusammenarbeit spricht. Im Sprint Review davor zeigt es das Inkrement den Stakeholdern, und das Product Backlog wird angepasst.

Die Ergebnisse im Repository

Sprint 0 endet mit drei Dateien im Ordner src/a01-scrum des Backend-Repositorys:

• product-backlog.md: Produktvision, Produktziel und alle Einträge mit Rang, Story Points und Abnahmekriterien,

• definition-of-done.md: die Definition of Done mit der Art der Prüfung,

• sprintplan.md: Release-Plan, Sprint-Ziel und Sprint Backlog von Sprint 1 sowie Termine der Ereignisse.

In größeren Projekten stehen Backlog und Sprint Backlog meist in einem Werkzeug wie den Issues und Boards von GitLab oder Jira. Für ein kleines Team genügen Markdown-Dateien, die mit dem Code versioniert werden. Ein Vorteil: Wer später einen Merge Request liest, sieht im selben Repository, zu welcher Story er gehört.

Nächster Schritt: Sprint 1 beginnt

Sprint 0 ist abgeschlossen: Das Scrum Team steht, die Vision gibt die Richtung vor, das Backlog ist geordnet und geschätzt, und die Definition of Done legt fest, was fertig heißt. Im nächsten Artikel beginnt Sprint 1 mit dem Sprint Planning. Danach bindest Du Thymeleaf ins Backend ein und lieferst den ersten Teil von MON-01: eine Seite unter /flurmonitor, die der Server selbst erzeugt.

In den Übungsaufgaben zu diesem Artikel ordnest Du Situationen aus dem Projekt den Bestandteilen von Scrum zu, schreibst Stories für die Anzeige der Mitfahrgesuche und planst einen Sprint mit knapper Kapazität.

Leitfragen

1. Welche Verantwortlichkeiten gibt es im Scrum Team, und wie sind sie im Flurmonitor-Projekt besetzt? Antwort

Product Owner (Thomas Becker, verantwortet und ordnet das Product Backlog), Developers (das Projektteam, setzt das Inkrement um) und Scrum Master (die betreuende Lehrkraft, achtet auf den Prozess und beseitigt Hindernisse). siehe Abschnitt „Wer macht was?“

2. Was unterscheidet die Produktvision vom Produktziel? Antwort

Die Vision beschreibt langfristig und knapp, für wen das Produkt welches Problem löst und was es besonders macht. Das Produktziel ist ein überprüfbarer künftiger Zustand, auf den das Team hinarbeitet; es ist laut Scrum Guide die Verpflichtung des Product Backlogs. siehe Abschnitt „Die Produktvision“

3. Wie ist ein Abnahmekriterium in der Form Angenommen – Wenn – Dann aufgebaut? Antwort

Angenommen beschreibt die Ausgangslage, Wenn die Handlung, Dann das erwartete, prüfbare Ergebnis, möglichst mit konkreten Werten und ohne technische Umsetzung. siehe Abschnitt „Abnahmekriterien“

4. Was unterscheidet Abnahmekriterien von der Definition of Done? Antwort

Abnahmekriterien gelten für eine Story und beschreiben ihr Verhalten; die Definition of Done gilt für jedes Inkrement und beschreibt die Qualität, etwa Tests, Review, Pipeline, Datenschutz und Barrierefreiheit. siehe Abschnitt „Die Definition of Done des Flurmonitors“

5. Warum steht die anonyme Anzeige sowohl als Abnahmekriterium als auch in der Definition of Done? Antwort

Die anonyme Anzeige ist eine nichtfunktionale Anforderung (Vertraulichkeit nach ISO/IEC 25010, Datenminimierung und Datenschutz durch Technikgestaltung nach DSGVO), die für jede Seite gilt. Als Abnahmekriterium wird sie bei der ersten Story getestet, in der DoD gilt sie automatisch für alle weiteren. siehe Abschnitt „Datenschutz ist eine Anforderung“

6. Wie läuft eine Runde Planning Poker ab, und warum wird verdeckt gewählt? Antwort

Der Product Owner stellt den Eintrag vor, die Developers klären Fragen, wählen verdeckt eine Karte und decken gleichzeitig auf; die Personen mit dem höchsten und niedrigsten Wert begründen, dann wird neu geschätzt. Verdecktes Wählen verhindert, dass sich alle an der ersten Zahl orientieren. siehe Abschnitt „Schätzen mit Planning Poker“

7. Warum ist der Release-Plan eine Prognose und keine Zusage? Antwort

Er beruht auf Schätzungen in Story Points und auf einer vermuteten Velocity, die das Team erst nach den ersten Sprints kennt. Nach jedem Review wird er mit der gemessenen Velocity und dem geänderten Backlog angepasst. siehe Abschnitt „Vom Backlog zum Release-Plan“

8. Welche drei Fragen klärt das Sprint Planning, und was gehört zum Sprint Backlog? Antwort

Warum ist der Sprint wertvoll (Sprint-Ziel), was kann fertig werden (Auswahl aus dem Product Backlog), wie wird die Arbeit erledigt (Aufgaben). Das Sprint Backlog besteht aus Sprint-Ziel, ausgewählten Einträgen und dem Plan der Aufgaben. siehe Abschnitt „Sprint-Ziel und Sprint Backlog für Sprint 1“

Links und weitere Informationen

• für den Einstieg: Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick

• als Hintergrund: Scrum, User Stories und Stakeholderanalyse

• zum Szenario: Szenario Mitfahrlabor mit Personas und Flurmonitoren

• als Nachschlagewerk: Der Scrum Guide, auch in deutscher Übersetzung

• als Nachschlagewerk: Web Content Accessibility Guidelines (WCAG) 2.2

• als Nachschlagewerk: Datenschutz-Grundverordnung, Art. 5 und Art. 25

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Sprint 0 für den Flurmonitor: Vision, Product Backlog, Definition of Done und Planning Poker” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/flurmonitor-scrum-projektstart veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/java-springboot/Backend. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]