Das Schokoriegelspiel
Wozu das Schokoriegelspiel?
Im Schokoriegelspiel geht es vor allem darum, anders als beim Bauklotzspiel, konkret über MEHRERE Sprints mit den Anforderungen des Kunden ein Produkt zu optimieren. Es zeigt die Möglichkeit des iterativen Requirements-Engineerings auf. Weiterhin bildet es, im Gegensatz zu den bisherigen Spielen, einen etwas größeren Ausschnitt mehrerer Bestandteile einer echten Scrum-Entwicklung in einem einzigen Spiel ab, konkret sowohl einige Stakeholder, mehrere Sprints, Aspekte der Kommunikation kombiniert mit Planung und Requirements Engineering.
Bevor es losgeht
- Hinweis: Bei Kursen über 9 Personen empfiehlt es sich, das Spiel zu parallelisieren, also vor der Gruppeneinteilung den Kurs in zwei oder mehr gleich große Teile zu splitten, die untereinander die beiden Gruppen bilden, um das Spiel durchzuführen.
- Teilt euren Kurs in zwei gleich große Gruppen auf. Definiert außerdem eine Person als Product Owner.
- Eine Gruppe begibt sich als Kundensample in einen anderen Raum (Kundenraum), die andere Gruppe bleibt als Entwicklerteam im Raum (Entwicklerraum).
- Das Entwicklerteam bekommt zur Erstellung des Scrumboards entweder
- Eine Pinnwand, Kärtchen und Stifte.
- Computer mit Internetzugang zur digitalen Nutzung eines beliebigen Scrum-Board Tools.
- Der Productowner bekommt einen Stapel Papier und einen Stift.
Ablauf
- Die Entwicklerfirma stellt ein Schokoriegeldesignlabor dar. Sie versucht einen möglichst optimalen Schokoriegel zu designen, der sich gut verkaufen kann, um sich später mit dem verdienten Geld in die Karibik absetzen zu können.
- Das Kundensample dient zur Findung der Anforderungen.
- Der Product Owner vermittelt zwischen beiden Parteien. Er muss aus den Fragen des Entwicklerteams konkrete, zielführende Fragen formulieren und an das Kundensample stellen und die durchschnittlichen Antworten an das Entwicklerteam weitergeben. Notizen sind in diesem Fall erlaubt.
- Das Entwicklerteam kennt die Anforderungen des Kunden zunächst nicht. Es kann sie nur raten. Deshalb wird der Schokoriegel in mehreren Sprints Stück für Stück aufgebaut.
- Das Budget des Schokoriegeldesignlabors reicht für 3 Sprints. In jedem Sprint können bis zu zwei User Stories bearbeitet werden.
- Die zahlreichen Schokoladenfotos auf dieser Seite können der Entwicklerfirma als Inspiration dienen.
- Die User Stories beschreiben in diesem Fall die Komponenten, welche sich der Kunde wünscht.
- Das Entwicklerteam muss für die im aktuellen Sprint bearbeiteten User Stories ("In Progress") herausfinden wie diese implementiert werden sollen, also z.B. Form, Größe, Farbe, Art vom Kundensample in Erfahrung bringen
- Und nach Abschluss eines Sprint gemäß eurer "Definition of Done" erledigt haben. Erst dann können die User Stories nach "Done" verschoben werden.
Beispiel: Im ersten Sprint legt das Entwicklerteam die Sorte der Basisschokolade als Ausgangspunkt fest. Dazu schlägt es verschiedene Sorten (z.B. Milchschokolade, Bitterschokolade, weiße Schokolade) vor. Der Productowner begibt sich nun in den Kundenraum um das Kundensample zu befragen. Geeignete Mittel könnten eine Abstimmung über die Sorte oder eine detailierte Befragung sein. Der Productowner übergibt sein Ergebnis an das Entwickelerteam, dieses nutzt das Ergebnis als Entscheidungsgrundlage. In den nächsten Sprints wird dann zum Beispiel ein Zusatzaroma und die Füllung festgelegt.
Einige Elemente eures Scrum Boards
Unbearbeitete User-Stories | In Progress | Done |
---|---|---|
Topping | Füllung | Grundschokolade - Implementierung: "Zartbitter" |
Weitere Zutaten | Schichtanzahl |
Aufgabe 1
Erstellt ein Scrum-Board entsprechend der obigen Tabelle anhand von Karteikarten auf Pinnwand oder durch Nutzung eines digitalen Tools. Es ist in diesem Fall bewusst nur eine grobe Vorlage für ein Scrum-Board mitgeliefert, da Scrum-Boards wie bereits genannt sehr individuell sind. Denkt daher selbst über dessen Gestaltung nach und erweitert das Scrum-Board daher noch mit mindestens zwei weiteren individuellen Aspekten, wie beispielsweise einer "Definition of Done" (Definition für: Wann gilt eine User-Story als implementiert) und Start- und Endzeiten für Sprints.
Aufgabe 2
Führt das Spiel durch.
Quellen
- [1]: (letzter Zugriff: 11.03.2024) - Urheber: André Karwath aka User:Aka - Lizenz: Creative Commons Attribution-Share Alike 2.5 Generic
- [2]: (letzter Zugriff: 11.03.2024) - Urheber: Evan-Amos - Lizenz: Creative Commons CC0 1.0 Universal Public Domain Dedication
- [3]: (letzter Zugriff: 11.03.2024) - Urheber: Evan-Amos - Lizenz: Public Domain
- [4]: (letzter Zugriff: 11.03.2024) - Urheber: Evan-Amos - Lizenz: Public Domain
- [5]: (letzter Zugriff: 11.03.2024) - Urheber: Mr Thinktank, modeled in CAD (Rhino3D) - Lizenz: Creative Commons BY 2.0 DEED