Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Product Owner und Vision

Party (Quelle: https://de.freeimages.com/photo/light-1179777)

Nehmen wir an, wir wollen eine Betriebsfeier für die Mitarbeiter veranstalten. Wer hat das höchste Interesse am Ergebnis? Wahrscheinlich jemand aus der GF. Aber diese Person hat vielleicht nicht genug Zeit, um sich um die Vorbereitung zu kümmern. Sie beauftragt den stellvertretenden Vertriebsleiter. Der stellvertretende Vertriebsleiter ist nun der Product Owner. Er spricht die Ziele, das Budget und die Rahmenbedingungen ab.

Der Product Owner formuliert eine Vision:
"Wir machen ein Sommerfest für alle Mitarbeiter, um uns für den Einsatz bei der Einführung der neuen ERP-Software zu bedanken. Bei diesem Fest soll es Essen und Getränke für alle geben. Es soll Musik für die gespielt werden, die tanzen wollen. Wer nicht tanzen will, kann die Atmosphäre und Gespräche genießen. Es soll irgendwas gemacht werden, um die durch das Projekt begonnene abteilungsübergreifende Zusammenarbeit zu verstärken. Und es soll irgendwie auf die Leistungen der bei der Projektarbeit eingegangen werden."

Product Backlog

Statt die Party in ihre technischen Komponenten zu zerlegen (Catering, Musik, Location etc.), gehen wir einen Schritt zurück und überlegen, wer zur Party kommt. Gibt es nur eine Rolle? Gibt es mehrere Rollen? Dem Product Owner fallen folgende Rollen auf:

• (normaler) Partygast: nimmt an der Party teil, isst, trinkt, tanzt vielleicht und möchte eine gute Zeit haben.
• Geschäftsführung: ist Partygast, begrüsst aber auch die Gäste
• Moderator: führt durch die Party
• Musikverantwortlicher: entweder ein DJ, eine Band oder eine andere Person, die dafür sorgt, dass alle gute Musik hören.
• Lieferant: Leute, die für Essen und Getränke sorgen; verantwortlich für die Location etc.

Die wichtigste Rolle ist der Partygast. Der PO fängt an ein paar User Storys zu notieren:

• Als Partygast esse und trinke ich etwas, um gute Laune zu haben.
• Als Partygast tanze ich allein oder mit anderen, um mich zu amüsieren.
• Als Partygast unterhalte ich mich mit Kollegen, um die Kollegen besser kennenzulernen und um Geschichten auszutauschen.
• Als Partygast benutze ich die Toiletten, um danach weiterfeiern zu können.

Zu den anderen Rollen fallen dem PO ebenfalls Storys ein, z. B.:

• Als Mitglied der Geschäftsführung begrüße ich alle Gäste, um dem Fest einen würdigen Rahmen zu geben.
• Als Mitglied der Geschäftsführung bedanke ich mich bei allen Mitarbeitern für die Projektarbeit, um die Mitarbeit an späteren Projekten zu erleichtern.
• Als Musikverantwortlicher sorge ich für gute Musik, damit viele Partygäste tanzen.

Erstes Backlog Refinement, Definition of Ready

Der Po hat ein paar Kollegen gefunden, die ihm bei der Vorbereitung helfen. Er trifft sich mit ihnen zum ersten Backlog Refinement, um das Backlog in einen guten Zustand zu bringen. Er stellt die Vision und die bisherigen User Storys vor. Dann überlegen alle, was eine gute Reihenfolge ist. Dabei fällt auf, dass es noch keinen Termin und keine Location gibt. Dafür werden 2 neue Storys geschrieben:

• Als Mitglied der Geschäftsführung lade ich alle Mitarbeiter zum Sommerfest ein, damit möglichst viele Leute kommen.
• Als Partygast melde ich mich beim Sommerfest an, damit genug Speisen und Getränke für alle vorhanden sind.

Das Umsetzungsteam stellt fest, dass dies die wichtigsten Anforderungen für den kommenden Sprint sind. Aber die Storys sind nicht gut vorbereitet. PO und Team besprechen, wann eine Story so gut ist, dass sie schnell abgearbeitet werden kann. Sie einigen sich auf folgende Punkte für die Definition of Ready:

• Wir verstehen den Sinn der Anforderung.
• Wir haben Spielraum bei der Umsetzung.
• Wir haben den Aufwand der Anforderung relativ geschätzt.
• Die Anforderung ist klein genug, um in einer Woche bearbeitet werden zu können.
• Wir vorher darüber gesprochen, wie das Ergebnis im Review vorgestellt wird.
• Wichtige Punkte sind als Akzeptanzkriterien notiert.

Die Anforderungen werden mit Akzeptanzkriterien konkretisiert.

• Als Mitglied der Geschäftsführung lade ich alle Mitarbeiter zum Sommerfest ein, damit möglichst viele Leute kommen.
• Einladung enthält Ort und Zeit, Sommerfest findet in 3-4 Monaten statt.
• Grobablauf
• Kleiderordnung
• Wird als E-Mail verschickt
• Erklärt, wie man sich anmelden kann.
• Als Partygast melde ich mich beim Sommerfest an, damit genug Speisen und Getränke für alle vorhanden sind.
• Name und E-Mailadresse kommen beim Umsetzungsteam an.
• Partygast kann besondere Wünsche zum Essen angeben (vegan/vegetarisch, kein Schweinefleich, Allergien)
• Partygäste aus anderen Städten geben an, ob sie eine Übernachtungs- und Mitfahrgelegenheit brauchen.
• Es gibt eine Liste mit allen Partygästen und Zusatzinformationen.

Auf die anderen User Storys werden konkretisiert, soweit es im Moment bekannt ist. Durch den Vergleich der User Story untereinander bekommt die Einladung der GF 8 Story Points als Schätzwert, die Anmeldung der Mitarbeiter 3 Story Points.

Der PO überlegt, nach welchen Regeln er das Product Backlog priorisiert:

• Anforderungen, bei denen externe Lieferanten oder andere Personen beauftragt werden müssen, werden vorgezogen.
• Dinge, die großen Abstimmungsaufwand brauchen, werden vorgezogen.
• Dinge, die viel Geld kosten, werden vorgezogen, damit sichergestellt ist, dass es keine großen finanziellen Überraschungen gibt. 
• Dinge, die die Grundlagen für viele andere Anforderungen schaffen, werden vorgezogen.

Erste Sprintplanung

PO und Umsetzungsteam wollen sich jede Woche abstimmen. Sie legen den Dienstagnachmittag als Termin für den Sprintwechsel fest. Nun wird der erste Sprint geplant. PO und Umsetzungsteam überlegen, was eigentlich das Inkrement ist, das sie sich am Ende des Sprints ansehen will, um Feedback zu bekommen. Nach einiger Diskussion wird deutlich, dass der Inhalt eines Dateiordners in der gemeinsamen Ablage am besten geeignet ist. Dort werden alle Dokumente und Informationen gesammelt.

Was muss denn grundsätzlich bei jeder Anforderung bedacht werden? PO und Umsetzungsteam einigen sich darauf, was Qualität bedeutet. Sie legen folgende Definition of Done fest:

• Die Anforderung ist fertig umgesetzt.
• Wir haben die Akzeptanzkriterien erfolgreich geprüft.
• Die Dokumente oder Informationen, die an andere verschickt werden, sind versandbreit und fehlerfrei.
• Die Dokumente oder Informationen liegen im vereinbarten Dateiordner.
• Die Kostentabelle ist immer auf dem aktuellen Stand.
• Die Teilnehmerliste ist immer auf dem aktuellen Stand.

PO und Umsetzungsteam legen das Sprint Ziel fest: "Die Einladung an die Mitarbeiter ist versandbereit." Das Umsetzungsteam zieht dazu die ersten beiden Anforderungen in den Sprint (Einladung und Anmeldung).

Nun überlegen alle, was konkret zu tun ist. Sie notieren die Aufgaben auf dem Sprint Backlog:

• Als Mitglied der Geschäftsführung lade ich alle Mitarbeiter zum Sommerfest ein, damit möglichst viele Leute kommen.
• Liste mit mindestens 3 Locations erstellen.
• Angebote und Termine einholen.
• Entscheidung vorbereiten, welche Location genommen wird.
• 2 unterschiedliche Entwürfe für die Einladung erstellen
• Remindertext erstellen.
• Als Partygast melde ich mich beim Sommerfest an, damit genug Speisen und Getränke für alle vorhanden sind.
• Leere Tabelle mit den Spalten Name, E-Mail-Adresse, Essenswünsche, Braucht Übernachtungsmöglichkeit, braucht Mitfahrgelegenheit erstellen.
• Tabelle im Dateiordner "(Aktuelle Teilnehmerliste)" ablegen.
• Ordner für eingehende E-Mails für Zusagen erstellen.
• Ordner für eingehende E-Mails für Absagen erstellen.
• Ordner für offene Fragen und geschlossene Fragen erstellen.

Das Umsetzungsteam vereinbart, sich täglich mindestens 4 Stunden zu treffen, um die Arbeit zu erledigen. An jedem Tag treffen sich die, die da sind, zum Daily Scrum um 8:30 für dem Sprint Backlog, um den Tag zu planen und um sich gegenseitig zu helfen.

Am Donnerstag vormittag nehmen sich alle mind. 30 Minuten Zeit, um im Backlog Refinement das nächste Sprint Planning vorzubereiten.

Erster Sprint Review

Am Dienstag nachmittag treffen sich PO und Umsetzungsteam, um sich die Ergebnisse anzusehen. Der PO hat je eine Person aus der Geschäftsführung und vom Betriebsrat dazugebeten, damit die wichtigen Entscheidungen an Ort und Stelle getroffen werden können.

Zunächst stellt ein Mitglied aus dem Umsetzungsteam die zwei Vorschläge für den Einladungstext vor. Dabei verweist es auch auf die unterschiedlichen Locations. Alle sehen sich gemeinsam die Angebote an. Die Geschäftsführung bestätigt den Favorit des Product Owners. Das Angebot wird sofort unterschrieben und verschickt.

Die Einladung wird angepasst. Die Geschäftsführung hat noch ein paar Änderungswünsche am Einladungstext, die sofort umgesetzt werden. Dem Betriebsratsmitglied fällt ein, dass es 2 Mitarbeiter gibt, die stark sehbehindert sind. Sie werden die Informationen auf der bunten Grafik nicht erkennen können. Dem Umsetzungsteam war dies nicht bewusst. Gemeinsam passen sie den Entwurf an.

Dann sehen sich alle an, wie mit eingehenden Anmeldungen umgegangen wird. Aus Sicht des Betriebsrates gibt es keine Einwände zu diesem Vorgehen.

Nun wird besprochen, ob neue Erkenntnisse ins Product Backlog einfließen. Alle sind sich einig, dass die Einladung im Laufe des nächsten Sprints verschickt werden soll.

Erste Sprint Retrospektive

PO und Umsetzungsteam sind mit den Ergebnissen zufrieden. Sie überlegen, was sie verbessern können. Es fällt auf, dass einige schöne Locations kein Angebot rechtzeitig abgeben konnten, weil wichtige Informationen fehlten. Es wird beschlossen, die Definition of Ready anzupassen:

• Wir verstehen den Sinn der Anforderung.
• Wir haben Spielraum bei der Umsetzung.
• Wir haben den Aufwand der Anforderung relativ geschätzt.
• Die Anforderung ist klein genug, um in einer Woche bearbeitet werden zu können.
• Wir vorher darüber gesprochen, wie das Ergebnis im Review vorgestellt wird.
• Wichtige Punkte sind als Akzeptanzkriterien notiert.
• Wenn Lieferanten angefragt werden: wir kennen vorher konkrete Mengen und konkrete Qualitätsanforderungen.

Einige Mitglieder im Unsetzungsteam geben zu bedenken, dass sie eigentlich keine Zeit für die Vorbereitung des Sommerfests haben. Als Verbesserungsidee stimmen alle der folgenden Kaizenkarte für den nächsten Sprint zu: "Wir finden einen Scrum Master, der uns dabei hilft mehr Zeit für die Vorbereitung zu gewinnen."

Nach einer entspannenden Kaffeepause beginnen PO und Umsetzungsteam mit der Planung des nächsten Sprints.

Brauchen wir dafür wirklich Scrum?

Einer meiner Söhne hat mich gefragt, was das denn für eine Party sei, wenn man sie planen müsse. Zugegeben, für einfache und bekannte Dinge ist der Aufwand nicht gerechtfertigt. Aber wir können die Komplexität schnell erhöhen:

• Anzahl der Teilnehmer steigt.
• Höhere Ungewissheit, wie viele Leute wirklich kommen (und nicht in der letzten Minute absage).
• Mehr Unsicherheit beim Essen.
• Mehr Unsicherheit beim Rahmenprogramm.
• Unsicherheit beim Wetter.
• Unsicherheit durch andere Veranstaltungen, die parallel stattfinden.
• Enges Budget
• Erhöhte Sicherheitsanforderungen

Wenn die Unsicherheit deutlich ansteigt und der PO wirklich eine Ziele erreichen will, braucht er häufiger Feedback. Wenn er z. B. sicherstellen will, das mind. 90 % der Belegschaft kommen, muss er in jedem Sprint dafür sorgen, dass die Anmeldequote hoch geht. Das Umsetzungsteam könnte auch Ideen entwickeln, wie man Absagen vermeiden kann, z. B. Anbieten einer Kinderbetreuung für Eltern.

Was macht eigentlich der Scrum Master?

Bisher haben wir einem erfahrenen Team bei der Arbeit zugesehen, das sich mit Scrum auskennt. Bei neuen Teams wäre der Scrum Master erst einmal damit beschäftigt, Scrum, die Hintergründe und bestimmte Techniken zu erklären.

Bei einem erfahrenen Team ist die Frage nicht, womit der Scrum Master den ganzen Tag ausgelastet ist. Die Frage ist, was der Scrum Master tun kann, damit das Team mit wenig Aufwand gute Ergebnisse liefern kann. Hier deutet sich ja schon in der Retro an, dass Teammitglieder keine Zeit haben.

• Der Scrum Master würde an organisatorischen Hindernissen arbeiten.
• Er könnte mit dem Team und dem PO Verhandlungstaktiken üben, damit Leute für die Vorbereitung freigestellt werden.
• Er könnte den Mitgliedern des Umsetzungsteams helfen, Zeit bei anderen Tätigkeiten zu sparen.
• Er könnte das Umsetzungsteam beraten, Dinge zu automatisieren. Statt z. B. Texte immer manuell auf Rechtschreibfehler zu prüfen, könnte man dies mit apell automatisch machen.
• Wenn große Ideen nicht umsetzbar sind (kein Geld oder keine Leute), könnte er Fragen stellen, das Ziel in kleinen Schritten zu erreichen.

Es gibt sehr viele Ideen. Der Schlüssel dazu ist, den Scrum Master weniger als formale Rolle aus dem Scrum Guide, sondern mehr als Person zu sehen, die dem Scrum Team und auch der gesamten Organisation hilft, schneller ihre Ziele zu erreichen.