• Jede Gruppe erhält ein Couvert mit Spielregeln & User Stories.
• Die Duplosteine sind auf einem neutralen Tisch, wobei jede Gruppe ihren eigenen Vorrat hat. Nicht verbaute oder zurückgebaute Teile müssen zwischen den Sprints zurück auf den Tisch.
• Die Gruppen dürfen also nicht einfach einen Vorrat bei Ihrem Bauplatz anlegen. Sie müssen für jeden Sprint möglichst die benötigten Bauteile holen.
• Jede Gruppe bestimmt einen Scrum Master, der die Zeit stoppt und einen Product Owner. Dieser prüft die User Stories im Sprint Review und entscheidet, welche Done sind.
• Dev Team entscheidet, welche Tiere sie in dem Sprint bauen möchten.
• Nur ganze Elemente bleiben stehen, alle anderen Teile werden abgebaut und wieder zurück auf den Tisch mit den Spielsteinen gelegt.
• Ziel in jedem Sprint ist es, die gewählten Stories vollständig umzusetzen..

• Nur im Doing darf gebaut werden.
• Nur einzelne Steine dürfen verbaut werden.
• Die Kiste darf nicht bewegt werden.
• Nur fertige Stories zählen.
• Unfertige Elemente müssen im Review zerlegt werden

• Das Scrum-Team wählt, welche User Stories es in diesem Sprint umsetzen will.
• Das Team plant gemeinsam, wie die Tiere gebaut werden sollen.
• Es darf noch nicht gebaut werden.
• Am Ende steht ein gemeinsames Sprintziel, z. B.: „Wir wollen in diesem Sprint einen Elefanten und eine Ente bauen.“

• Das Team baut – nur einzelne Steine dürfen verbaut werden, die Kiste bleibt stehen.
• Der Scrum Master achtet auf die Zeit.
• Es darf ausschließlich während dieser Phase gebaut werden!

• Das Team präsentiert die fertigen Tiere.
• Der Scrum Master überprüft, ob die Akzeptanzkriterien erfüllt sind.
• Nur fertige Stories zählen.
• Unfertige Tiere müssen zerlegt werden – das Team darf sie nicht in den nächsten Sprint übernehmen.

Das Team überlegt:

• Was hat gut funktioniert?
• Was können wir im nächsten Sprint verbessern?
• Der Scrum Master moderiert kurz, z. B. mit zwei Fragen:
• „Was lief gut?“ und „Was machen wir anders?“

Dann startet der nächste Sprint (zurück zu Schritt 2).