Das Scrum Framework — Zweite Ausgabe

Dieses Kapitel bewahrt den historischen und praktischen Lehrkontext der zweiten Ausgabe. Den Lehrplan der dritten Ausgabe finden Sie ebenfalls im nachfolgenden Inhaltsverzeichnis.

---

Scrum-Beispiel: ein Praxisbeispiel für leistungsstarke agile Teams

In diesem Artikel möchten wir Ihnen ein Beispiel zur Scrum-Methodik vorstellen, das Ihre Scrum-Teams, weitere geschäftliche Stakeholder und die an Ihren Projekten beteiligten Personen inspirieren kann. Wir haben häufig erlebt, dass Unternehmen Scrum-Fachkräfte ausbilden, diese jedoch aufgrund mangelnder Scrum-Erfahrung im täglichen Scrum-Betrieb und bei der Produktumsetzung vor Herausforderungen stehen.

Dieses Problem hindert Scrum-Teams häufig daran, ihre optimale Team-Velocity zu erreichen und ihre Ergebnisse termin- und budgetgerecht auszuliefern. Genau hier zeigt sich der Nutzen dieses Beispiels zur Scrum-Methodik.

In diesem kurzen Artikel helfen wir Ihnen deshalb, das Gesamtbild des Scrum Frameworks zu verstehen: vom Aufbau Ihrer Scrum-Prozesse, die außergewöhnlichen Wert für Unternehmen, Produkte und Dienstleistungen schaffen und Ihren Kunden umfassend erlebte Agilität ermöglichen, bis hin zur Einrichtung und Nutzung Ihres Scrum Burndown Charts, um die Velocity Ihrer Scrum-Teams zu verbessern und dauerhaft aufrechtzuerhalten.

Mit diesem Beispiel zur Scrum-Methodik helfen wir Ihnen zu verstehen, wie ein Scrum-Team arbeitet und welchen Nutzen es Ihrer Organisation bringen kann. Daten legen nahe, dass Scrum-Teams in den meisten Unternehmen üblicherweise aus einem Product Owner, einem Scrum Master und Entwicklern bestehen. Zusammen bilden sie das Scrum Team und arbeiten in kurzen, Sprints genannten Iterationen daran, wertvolle Produkt-Inkremente zu liefern. Dieser iterative Ansatz ermöglicht Flexibilität, Anpassungsfähigkeit und schnelleres Feedback.

Dies sind die Hauptpersonen unseres Beispiels zur Scrum-Methodik:

• Alex, der Scrum Product Owner.
• Frank, der Scrum Master.
• Das Scrum Team.

Vor Beginn des ersten Sprints

Alex wird zum Scrum Product Owner eines neuen Softwareentwicklungsprojekts ernannt. Zu seinen ersten Aufgaben gehört es, mit der Anforderungsanalyse zu beginnen. Er notiert die wichtigsten Anwendungsfälle und bespricht sie mit Architekten, Kundenvertretern und anderen Stakeholdern. Nachdem er die übergeordneten Anwendungsfälle und Anforderungen gesammelt hat, trägt er sie in das Scrum Product Backlog ein und organisiert mit den Architekten und einigen erfahrenen Entwicklern eine Schätzungs- und Priorisierungssitzung. Anschließend besitzen alle Elemente im Scrum Product Backlog eine erste grobe Schätzung und eine Priorität. Nun beginnt er, die übergeordneten Anforderungen in feiner ausgearbeitete User Stories zu zerlegen. Mit dieser Liste lädt er anschließend zum ersten Sprint Planning ein.

Einführung in Scrum – ein Praxisbeispiel über verschiedene Scrum-Phasen und Sprints hinweg

Sprint 1 - Tag 0

Während des Sprint Plannings stellt Alex die Elemente des Scrum Product Backlogs in absteigender Prioritätsreihenfolge vor. Das Team klärt offene Fragen und bespricht für jedes Element, ob ausreichende Kapazität, das erforderliche Know-how und alle weiteren Voraussetzungen vorhanden sind. Nach dieser Diskussion sagt es zu, die Stories 1, 2, 3, 6, 7 und 8 bis zum Ende dieses Sprints fertigzustellen. Die Elemente 4 und 5 lassen sich in diesem Sprint nicht umsetzen, da Teile der technischen Infrastruktur noch fehlen.

Nach dem Sprint Planning versammelt Frank, der Scrum Master des Teams, das Team, um die Einzelheiten der Umsetzung der zugesagten Elemente zu klären. Die daraus entstehenden Aufgaben werden auf den Karten des vorbereiteten Sprint-Aufgabenboards festgehalten. Nun wählt jedes Mitglied des Scrum Teams eine Aufgabe zur Bearbeitung aus.

Profitipp für Scrum-Teams:

Alex leitet als Scrum Product Owner ein neues Softwareentwicklungsprojekt in seiner Organisation. Seine Rolle ähnelt der eines Dirigenten, bei dem jeder seinen eigenen Part spielt. Seine funktionsübergreifende Rolle bringt erhebliche Verantwortung mit sich und konzentriert sich darauf, selbstorganisierte agile Rahmen für die Softwareentwicklung zu schaffen, in denen Verbesserung ein fortlaufender Prozess ist. Dieser Rahmen ist keine Universallösung, sondern ein abgesteckter Kurs, der den Entwicklern bei ihrer Arbeit Orientierung gibt. Alex gibt den Takt des Unternehmens vor und stellt sicher, dass die entstehenden Endprodukte den Bedürfnissen der Kunden entsprechen. Ein solcher agiler Ansatz verläuft in kontinuierlichen Iterationen und fördert damit die ständige Verfeinerung von Produkten und Methoden.

Anschließend stößt Alex eine Schätzungs- und Priorisierungssitzung auf Basis von User Stories an (mehr dazu unter Scrum User Stories) und verwendet Story Points als relative Schätztechnik. Eine Visualisierung nach Kanban-Art kann diese Arbeit ergänzen, indem sie Aufgaben und Arbeitsabläufe für das gesamte Team sichtbar macht. Dadurch erhalten alle Elemente im Scrum Product Backlog eine erste ungefähre Schätzung und eine Priorität. Alex greift auf seine Erfahrungen im Projektmanagement zurück, um übergeordnete Anforderungen in nutzerorientierte Stories zu zerlegen und so in lieferbare Einheiten zu übersetzen. Diese User Stories veranschaulichen als konkrete Beispiele für Kundenwünsche mögliche Wege zu den Projektzielen. Mit dieser Liste lädt er zum ersten Sprint Planning ein und fördert eine Kultur enger Zusammenarbeit im Softwareentwicklungsteam.

Sprint 1 - Tag 1

Am Morgen kommt das gesamte Team zum Daily Scrum zusammen. Alle erläutern kurz den bisherigen Fortschritt, aktualisieren die Schätzung der verbleibenden Stunden auf den Karten des Sprint-Aufgabenboards, nennen ihre Vorhaben für den Tag und erklären, ob Hindernisse den Fortschritt blockieren. Heute berichtet ein Teammitglied, dass es ein Problem hat, weil es für eines seiner Softwarewerkzeuge eine neue Lizenz benötigt. Frank fragt nach, ob andere Teammitglieder dasselbe Problem haben, und erklärt, dass er sich nach der Besprechung darum kümmern wird. Nach 15 Minuten gehen alle wieder an die Arbeit.

Nach der Besprechung aktualisiert Frank das Sprint Burndown. Anschließend ruft er den Softwareanbieter an, bestellt Lizenzen und leitet sie an die Personen weiter, die sie benötigen.

Profitipp für Scrum-Teams:

Während des Sprint Plannings erläutert Alex die nach Priorität geordneten Elemente des Scrum Product Backlogs. In seiner Organisation trägt er die Verantwortung dafür, dass alle das übergeordnete Projektziel verstehen. Die Stand-up-Besprechungen des Teams ermöglichen offene Gespräche, in denen Rollen geklärt und mögliche Probleme gelöst werden.

Frank, der Scrum Master, spielt eine weitere wichtige Rolle in diesem vielseitigen Team. Er begleitet das tägliche Stand-up und hilft bei Bedarf dabei, die Gespräche auf das Sprint-Ziel auszurichten. Die Entwickler verantworten ihren eigenen Plan und wählen ihre Aufgaben gemeinsam aus; Frank teilt ihnen keine Arbeit zu.

Sprint 1 - Tag 2

Am Morgen trifft sich das gesamte Team wieder zum Daily Scrum. Am Nachmittag ist sich ein Mitglied des Scrum-Teams über Einzelheiten einer User Story unsicher. Es ruft Alex, den Scrum Product Owner, an und bespricht mit ihm die offenen Punkte. Sobald das Teammitglied weiß, was zu tun ist, kann es mit der Umsetzung fortfahren.

Sprint 1 - Tag 28

Dies ist der letzte Tag des ersten Sprints, und Frank, der Scrum Master, hat das Team zum Sprint Review eingeladen. Das Team hat einen Rechner mit dem aktuellen Softwarestand vorbereitet. Alex, der Scrum Product Owner, setzt sich davor und prüft, ob die Umsetzung seinen Erwartungen entspricht und die Funktionen wie verlangt dokumentiert sind. Am Ende des Reviews hält er fest:

• Die Stories 1, 2, 6 und 7 sind wie erwartet fertig.
• Story 3 konnte nicht rechtzeitig abgeschlossen werden und wurde daher gar nicht vorgestellt.
• Bei Story 8 müssen einige Punkte überarbeitet werden.

Am Nachmittag trifft sich das Team zur Sprint Retrospective und bespricht, was im Sprint gut gelaufen ist und was verbessert werden könnte. Eine Rückmeldung lautet, dass sich das Team mit der gesamten Systemarchitektur noch nicht ausreichend vertraut fühlt. Frank übernimmt die Aufgabe, den Systemarchitekten zu einer ausführlicheren Einführung einzuladen.

Beispiel zur Scrum-Methodik

Profitipp für Scrum-Teams:

Am letzten Tag des ersten Sprints begleitet Frank das Team durch das Sprint Review. Die kontinuierliche Zusammenarbeit führt zu einem greifbaren Prototyp, der das Engagement und die geleistete Arbeit des Teams widerspiegelt.

Am Nachmittag kommt das Team zur Sprint Retrospective zusammen. Hier tauschen die Mitglieder Erkenntnisse über ihre Fortschritte aus und besprechen Aspekte, die sie in künftigen Sprints verbessern möchten. Dieses Treffen erweist sich als entscheidender Bestandteil des agilen Ansatzes und liefert erheblichen Nutzen für das gesamte Projekt.

Bei der Planung des nächsten Sprints wird Alex’ entscheidende Rolle als Scrum Product Owner erneut deutlich: Auf Grundlage seiner jüngsten Kundengespräche ergänzt er das Scrum Product Backlog um neue Elemente. Mit Beginn des zweiten Sprints zeigt sich, dass Teamarbeit, Transparenz und wirksames Projektmanagement dieses informationsgestützte Team weiterhin zum Erfolg führen.

Sprint 2 - Tag 1

Alex, der Scrum Product Owner, ergänzt das Scrum Product Backlog anhand seiner jüngsten Kundengespräche um neue Elemente. Außerdem fügt er zusätzliche Elemente für die Überarbeitung von Story 8 hinzu. Anschließend lädt Alex das Team zum Sprint Planning für Sprint 2 ein. Mit Unterstützung von Frank, dem Scrum Master, bespricht das Team die Stories und sagt deren Umsetzung zu; der zweite Sprint beginnt.

Profitipp für Scrum-Teams:

Im zweiten Sprint setzt das Team seine Erkenntnisse in die Praxis um: Das überarbeitete Product Backlog spiegelt Kundenfeedback wider, die unvollendete Arbeit wird neu betrachtet, und die Zusammenarbeit richtet sich auf das nächste Sprint-Ziel.

Die Beschäftigung mit Scrum-Beispielen und Fallstudien ist für Organisationen unverzichtbar, die effiziente und leistungsstarke Scrum-Teams aufbauen möchten. Die Analyse realer Situationen liefert wertvolle Erkenntnisse zu erfolgreichen Umsetzungen und hilft ebenso dabei, häufige Fallstricke zu erkennen und zu vermeiden. Indem Teams aus diesen Beispielen lernen, können sie schneller zu Spitzenleistungen gelangen, bewährte Praktiken nutzen, mögliche Fehler umgehen und rasche Erfolge bei ihrer Scrum-Arbeit erzielen.

Freuen Sie sich auf weitere Praxisbeispiele und Fallstudien, die Ihr Verständnis des Scrum Frameworks und seiner praktischen Anwendungen vertiefen werden.