Projekte & Entwicklung
Agile Entwicklung für Einsteiger: Scrum-Rollen, Events und Artefakte im ersten Sprint
Einsteiger | 2 Whiteboard-Seiten · Aufgabenboard mit 5 Spalten (4 Hauptaufgaben, 12 Teilaufgaben)
Einsteiger: Ohne Fachbegriffe. Beantworten Sie einfach die Fragen auf dem Whiteboard anhand der Ausfüllbeispiele, dann nimmt das Ergebnis Gestalt an.
Wer agile Entwicklung neu lernt oder zum ersten Mal in ein Scrum-Team kommt, versteht mit dieser Vorlage für Einsteiger die 3 Rollen, 5 Events und 3 Artefakte und fährt den ersten Sprint. Auf dem Whiteboard stehen die Grundidee der agilen Entwicklung, der Ablauf eines Zwei-Wochen-Sprints in 5 Schritten, drei Rahmen für die 3 Rollen, drei Rahmen für die 3 Artefakte, eine Übersicht der 5 Events, vier MoSCoW-Spalten für die Auswahl dieses Sprints und ein KPT-Rückblick. Das Aufgabenboard hat fünf Spalten - Product Backlog, Sprint Backlog, In Arbeit, Wartet auf Review und Fertig - und startet mit 4 Hauptaufgaben und 12 Teilaufgaben, von den Begriffen bis zu Review und Retrospektive, alle offen. Wer ohne Kenntnis von Scrum einsteigt, verliert schnell den Anschluss an die Begriffe. Gehen Sie dieses Board für einen Sprint von oben nach unten durch, dann wissen Sie auch, was Sie im Daily sagen. Anders als ein Board für eingespielte Teams geht es hier um die Begriffe und den ersten Durchlauf.
Mit einem kostenlosen Konto können Sie diese Vorlage aus dem Marktplatz kopieren
Whiteboard-Vorschau
Whiteboard-Inhalt als Text lesen
Starter-Board für agile Entwicklung
So geht es: (1) Grundidee lesen → (2) Ablauf des Zwei-Wochen-Sprints durchgehen → (3) 3 Rollen und 3 Artefakte prüfen (Boards 3-8) → (4) Termine der 5 Events festlegen (Board #9) und mit MoSCoW sortieren, was hineinkommt und was wartet (Board #10) → (5) Mit KPT zurückblicken (Board #11)
1. Was agile Entwicklung ist (in kurzen Abständen bauen, zeigen, nachbessern)
- In einem Satz In etwa zwei Wochen etwas Lauffähiges bauen und zeigen, Rückmeldungen einholen und nachbessern. Das immer wieder.
- Unterschied zur bisherigen Arbeitsweise z. B. nicht erst alle Anforderungen festschreiben, sondern die Reihenfolge festlegen und von oben in kleinen Schritten bauen. Die Reihenfolge darf sich ändern.
- Was das bringt z. B. alle zwei Wochen ist etwas Echtes zu sehen, eine falsche Richtung fällt also binnen zwei Wochen auf. Nachgearbeitet wird nur ein Sprint.
2. Ablauf des Zwei-Wochen-Sprints (das Daily wiederholt sich täglich)
- 1. Sprint Planning Erster Tag des Sprints. Mit MoSCoW auf Board
- 2. Entwicklung (zwei Wochen) Nur das Ausgewählte bauen. Auch wenn ein neuer Wunsch kommt, gehört er grundsätzlich nicht in diesen Sprint. z. B. nur die 3 Login-Einträge mit 13 Punkten bearbeiten.
- 3. Daily Scrum (täglich 15 Minuten) An jedem Tag dieser zwei Wochen 15 Minuten zur festen Uhrzeit. Jede Person sagt, was sie gestern getan hat, was sie heute tut und wo sie hängt. Das läuft täglich parallel zur Entwicklung. z. B. jeden Morgen um 10 Uhr im Stehen.
- 4. Sprint Review Letzter Tag. Den Beteiligten etwas Lauffähiges zeigen und Rückmeldungen einholen. Höchstens 2 Stunden. Nicht Folien, sondern die Oberfläche zeigen. z. B. die neue Login-Maske live bedienen.
- 5. Retrospektive Direkt nach dem Review. Nicht auf das Gebaute schauen, sondern auf die Arbeitsweise. Höchstens 1,5 Stunden. Mit KPT auf Board
3. Product Owner
- Entscheidet, was zuerst gebaut wird
- Verantwortet die Reihenfolge im Product Backlog
- z. B. entscheidet, dass die Login-Verbesserung zuerst kommt
- Ansprechperson bei Unklarheiten zum Inhalt
4. Scrum Master
- Achtet darauf, dass die Arbeitsweise eingehalten wird
- Räumt Hindernisse aus und wahrt die Zeiten der Events
- z. B. nimmt einen Zwischenwunsch an und terminiert ihn neu
- Gibt keine Anweisungen und ist nicht zwangsläufig eine Führungskraft
5. Entwickler
- Die Bauenden, einschließlich Entwurf, Umsetzung und Test
- Was in zwei Wochen machbar ist, schätzen die Entwickler selbst
- z. B. drei Personen teilen sich den Sprint Backlog
- Entwickler ist ein Rollenname, keine Berufsbezeichnung
6. Product Backlog
- Alles Gewünschte, sortiert nach Reihenfolge der Umsetzung
- Oben heißt früher. Die Reihenfolge setzt der Product Owner
- z. B. Login-Verbesserung / Benachrichtigungen / Suche im Admin
- Eine Liste ohne Ende. Sie darf unterwegs wachsen
7. Sprint Backlog
- Nur das, was in diesen zwei Wochen entstehen soll
- Im Planning gewählt, unterwegs kommt nichts hinzu
- z. B. die 3 Login-Einträge mit zusammen 13 Punkten
- Hier ist auch zu sehen, wer was übernommen hat
8. Increment
- Das Lauffähige, das am Ende der zwei Wochen vorliegt
- Was die Definition of Done (die vorab im Team vereinbarten Bedingungen, ab wann etwas fertig heißt) nicht erfüllt, zählt nicht dazu
- z. B. die Login-Verbesserung samt Test und Abnahme
- Genau das wird im Sprint Review gezeigt
9. Die 5 Events auf einen Blick
| Was passiert | Wer nimmt teil | Zeitrahmen | |
|---|---|---|---|
| Sprint | Sprint Der Zwei-Wochen-Rahmen für die anderen vier. Er wird nie verlängert. | Das ganze Scrum-Team (Product Owner, Scrum Master, Entwickler) | Zwei Wochen Fest, höchstens ein Monat |
| Planning | Sprint Planning Auswählen, was in zwei Wochen entsteht, und den Sprint Backlog bilden. | Das ganze Scrum-Team | Bis 4 Stunden Vormittag des ersten Tages |
| Daily Scrum | Daily Scrum Sagen, was gestern war, was heute ansteht und wo es hakt. | Entwickler (die beiden anderen Rollen hören zu) | 15 Minuten Täglich, gleiche Zeit und gleicher Ort |
| Review | Sprint Review Lauffähiges zeigen und Rückmeldungen einholen. Oberfläche statt Folien. | Scrum-Team und Beteiligte (Auftraggeber, Nutzende) | Bis 2 Stunden Am letzten Tag |
| Retrospektive | Sprint-Retrospektive Nicht auf das Gebaute schauen, sondern auf die Arbeitsweise. | Das ganze Scrum-Team | Bis 1,5 Stunden Direkt nach dem Review |
10. Auswählen, was in diese zwei Wochen kommt (MoSCoW)
Must (unverzichtbar)
- Nur das, ohne das das Sprintziel nicht erreichbar ist. z. B. den Fehler beheben, dass die Mail zum Zurücksetzen nicht ankommt
Should (wichtig)
- Wichtig, aber das Ziel hält auch, wenn es diesmal entfällt. z. B. unverständliche Fehlermeldungen neu formulieren
Could (wenn Zeit bleibt)
- Kommt in den Sprint, fliegt aber bei Zeitmangel als Erstes heraus. Ohne diesen Punkt hält das Ziel. z. B. das Logo auf der Login-Maske austauschen
Won't (diesmal nicht)
- Bewusst nicht gemacht. Nicht löschen, sondern im Product Backlog (Board #6) lassen. z. B. Benachrichtigungen und Suche im Admin auf einen späteren Sprint schieben
11. Rückblick auf den ersten Sprint (KPT)
Keep (beibehalten)
- Seit das Daily fest um 10 Uhr liegt, sind alle vollzählig dabei
- Weil Hindernisse sofort genannt wurden, war die Blockade in einem halben Tag weg
Problem (nicht gelungen)
- Von den gewählten 13 Punkten wurden 5 in zwei Wochen nicht fertig
- Zwischenwünsche ließen sich nicht ablehnen, der Sprint Backlog wuchs
Try (als Nächstes testen)
- Den nächsten Sprint mit 8 Punkten beginnen und nur bei Luft aufstocken
- Zwischenwünsche nimmt zuerst der Scrum Master entgegen
Inhalt des Aufgabenboards
Product Backlog 16 Einträge
Scrum-Begriffe
Die erste Hürde sind die Begriffe. Wer sie als drei Bündel lernt, nämlich Rollen, Events und Artefakte, verliert im Gespräch nicht den Faden.
3 Rollen notieren
Schreiben Sie mit Namen auf, wer Product Owner, Scrum Master und Entwickler ist. Bei Doppelrollen vermerken Sie das ausdrücklich.
5 Events ordnen
Bringen Sie Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint-Retrospektive in die zeitliche Reihenfolge und tragen Sie Datum und Uhrzeit ein.
3 Artefakte prüfen
Klären Sie, wo Product Backlog, Sprint Backlog und Increment jeweils zu finden sind.
Sprint 1 planen
Begriffe auswendig zu lernen reicht nicht. Legen Sie den Zwei-Wochen-Rahmen fest und wählen Sie nur so viel aus, wie hineinpasst.
Termine festlegen
Bestimmen Sie Start, Ende sowie Wochentag und Uhrzeit jedes Events. Der Sprintzeitraum wird unterwegs nicht verlängert.
Backlog füllen
Schreiben Sie alles Gewünschte in die Spalte Product Backlog und sortieren Sie es in die Reihenfolge der Umsetzung. Über die Reihenfolge entscheidet der Product Owner.
Nur 2 Wochen
Verschieben Sie von oben nur so viel in den Sprint Backlog, wie in zwei Wochen fertig wird. Ist es zu viel, bestimmen Sie mit MoSCoW auf Board
Daily halten
Der tägliche Ablauf im Sprint, auch Stand-up genannt. Machen Sie daraus keine Statusrunde, sondern einen Ort, an dem Hindernisse sofort auf den Tisch kommen.
Gestern und heute
Jede Person sagt in einer Minute, was sie gestern getan hat und was sie heute tut. Ausführliche Abstimmungen finden nach dem Daily statt.
Hindernisse nennen
Sprechen Sie jede Blockade offen aus. Die Lösung übernimmt der Scrum Master im Anschluss an das Daily.
Karten bewegen
Ziehen Sie Karten nach In Arbeit, Wartet auf Review und Fertig, damit auf einen Blick sichtbar ist, was noch offen ist.
Review und Retro
Der Abschluss der zwei Wochen. Rückmeldungen zum Produkt und Rückmeldungen zur Arbeitsweise getrennt zu behandeln, gehört zum Scrum-Muster.
Lauffähiges zeigen
Zeigen Sie im Sprint Review keine Folien, sondern eine wirklich laufende Oberfläche, und holen Sie sich Rückmeldungen.
Feedback ins Backlog
Legen Sie die Rückmeldungen als Karten zurück in die Spalte Product Backlog, als Grundlage für die nächste Priorisierung.
Ein Try aus KPT
Schauen Sie in der Retrospektive auf die Arbeitsweise und legen Sie genau einen Try für den nächsten Sprint fest.
