Willkommen zum 2. Artikel der „Scrum im Selbststudium“-Artikelreihe. Solltest du den letzten Artikel verpasst haben, findest du ihn hier.
1. Der Product Owner maximiert den Wert des Produkts
Scrum beginnt mit einem Product Owner. Jemand, der eine Nachfrage im Markt erkannt hat und von der Organisation ermächtigt ist, ein Produkt zu erschaffen. Dieses Produkt soll die Nachfrage in Wert verwandeln. Der Product Owner berät sich mit den Stakeholdern, wie eine erste Version des Produkts aussehen könnte. Stakeholder können in Scrum jeden umfassen, der ein Interesse an dem Produkt oder Einfluss darauf hat. Dieses Produkt-Ziel dient dem Scrum Team als erstes Ziel für seine Planung. Ein neues Produkt-Ziel wird erst dann definiert, wenn das vorherige erreicht oder aufgegeben wurde. Der Product Owner tauscht sich regelmäßig mit den Stakeholdern aus. Sie besprechen fortlaufend, welche Dinge notwendig sind und in welcher Reihenfolge sie passieren sollten, um die Ziele des Produkts zu erreichen. Somit kümmert sich der Product Owner darum, dass der Wert des Produkts maximiert wird.
2. Das Product Backlog: Eine geordnete Liste, wie das Produkt verbessert werden kann, um das Produkt-Ziel zu erreichen
Das Product Backlog enthält das Produkt-Ziel. Und alle Arbeiten, die das Scrum Team zum gegenwärtigen Zeitpunkt kennt und die für den Erfolg des Produkts erforderlich sind. Es ist also niemals vollständig. Der Product Owner ist für die Reihenfolge der Einträge im Product Backlog verantwortlich. Natürlich unterstützen das restliche Scrum Team und die Stakeholder den Product Owner bei der Verwaltung des Product Backlogs. Wie er den Wert des Produkts maximieren will, spiegelt sich in der Reihenfolge der Einträge im Product Backlog wider. Das Product Backlog ist geordnet. Elemente, die weiter oben im Product Backlog stehen, sind voraussichtlich wertvoller als Elemente, die weiter unten im Backlog zu finden sind. Viele Faktoren spielen bei der Wertbetrachtung eine Rolle: Nutzen, Priorität, Dringlichkeit, Abhängigkeiten, technische Umsetzbarkeit, rechtliche Erwägungen, Größe usw. Die Einträge oben im Product Backlog wurden bereits besser verstanden. Die Product-Backlog-Einträge, die weiter unten stehen, liegen weiter in der Zukunft und sind deshalb erst mal weniger detailliert ausgearbeitet. Das Detaillieren umfasst:
die Zerlegung von Einträgen, die für einen einzelnen Sprint zu groß sind,
die Klärung von Fragen zur Arbeit und
die Schätzung des Aufwands für die Umsetzung.
Die fortlaufende Aktivität der Detaillierung von Product-Backlog-Einträgen wird als Refinement bezeichnet. Scrum Teams gewinnen kontinuierlich neue Einsichten während ihrer Arbeit. Somit ist es Zeitverschwendung, viel Zeit auf detaillierte Spezifikationen der Arbeiten in ferner Zukunft zu verwenden.
3. Der Sprint: Das Zeitfenster, um ein neues Inkrement zu erstellen
Die Produktion und der Betrieb von Produkten sind unvorhersehbar, da sie von vielen Faktoren abhängen. Zum Beispiel können unerwartete Marktreaktionen die Koordination innerhalb eines Scrum Teams oder technische Probleme das Produktionstempo stark beeinflussen. Eine solche Situation erfordert eine regelmäßige Überprüfung des Produkts und gegebenenfalls Anpassungen daran. Deshalb erstellt das Scrum Team das Produkt in Inkrementen. Den festen Zeitraum, in dem ein neues Inkrement erstellt werden muss, nennen wir Sprint. Sprints haben eine feste Länge von maximal 4 Wochen. Wird eine Aufgabe während des Sprints nicht abgeschlossen, wandert er in das Product Backlog zurück. Der Product Owner entscheidet dann, wie damit umgegangen werden soll. Damit ermöglichen Sprints Vorhersagbarkeit, da sie regelmäßige Überprüfung und Anpassung der Fortschritte in Richtung eines Produkt‐Ziels gewährleisten. Es gibt keinen Zeitraum zwischen zwei Sprints.
4. Das Sprint Planning: Planung der Arbeit für den Sprint
Der Sprint beginnt mit dem Sprint Planning. Während dieses Events entscheidet das Scrum Team, woran es in diesem Sprint arbeiten wird.
Der Product Owner schlägt zu Beginn vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das Scrum Team verfeinert diese grobe Richtung zu einem Sprint-Ziel. Ein Sprint-Ziel vereint die Arbeit im Sprint und gibt dem Sprint somit einen Zweck: Warum ist dieser Sprint für die Stakeholder wertvoll? Dieser Fokus hilft dem Scrum Team, zusammenzuarbeiten, anstatt sich auf separate Aufgaben zu konzentrieren.
Die Entwickler wählen aus dem Product Backlog so viel Arbeit, wie sie für möglich und notwendig halten, um das Ziel des Sprints zu erreichen.
Dann zerlegen sie üblicherweise die ausgewählten Product-Backlog-Einträge in Arbeitseinheiten von einem Tag oder weniger. Damit erhalten sie einen konkreten Plan, wie sie eine neue Version des Produkts entwickeln und liefern wollen. Dieser Plan zusammen mit den ausgewählten Product-Backlog-Einträgen und dem Sprint-Ziel stellt das Sprint Backlog dar. Es ist Eigentum der Entwickler und wird nicht ohne deren Zustimmung geändert.
5. Das Sprint Backlog: Die Prognose der bevorstehenden Arbeit, um das Sprint-Ziel zu erreichen
Das Sprint Backlog wird sich wahrscheinlich während des Sprints verändern, wenn neue Einsichten oder Probleme auftauchen. Vielleicht wurden auch wichtige Arbeiten vergessen, die zum Erreichen des Sprint-Ziels erforderlich sind. Das Sprint Backlog kann sich zwar ändern, das Sprint-Ziel jedoch nicht. Die Entwickler verpflichten sich zum Erreichen des Sprint-Ziels. Das Sprint Backlog betrachten sie als Vorhersage, welche Arbeit dazu nötig sein wird.
6. Der Scrum Master verantwortet die Effektivität des Scrum Teams
Der Scrum Master ist dazu da, Scrum in die Tat umzusetzen. Er unterstützt das Scrum Team in der Planung des Sprints, etwa, indem er den Planungsprozess facilitiert. Diese Person ist in keiner Weise ein Manager des Teams. Der Scrum Master ist verantwortlich für die Effektivität des Scrum Teams. Effektiv bedeutet hier besser und nicht schneller. Scrum Master übernehmen also die Verantwortung, damit das Team besser arbeitet. Durch seine Arbeit wird das Scrum Rahmenwerk mit Leben gefüllt. Das Scrum Team verbessert kontinuierlich seine Arbeitspraktiken.
7. Die Entwickler schaffen jeden Sprint ein Inkrement
Während des Sprints führen die Entwickler alle notwendigen Arbeiten aus, um das Sprint-Ziel zu erreichen. Dies setzt voraus, dass das Team über alle dafür erforderlichen Fähigkeiten und Kenntnisse verfügt. Die Entwickler managen ihre Arbeit selbst. Das heißt, die Art und Weise, wie die Entwicklung des Inkrements erledigt wird, hängt ganz von ihrem Fachwissen ab. Scrum Teams bestehen in der Regel aus weniger als zehn Mitgliedern.
8. Das Daily Scrum: Tägliche Überprüfung des Fortschritts in Richtung des Sprint‐Ziels und Justierung der geplanten Arbeit
Während des Sprints gibt es alle 24 Stunden ein Daily Scrum. Das Daily Scrum dient der Überprüfung des Fortschritts in Richtung des Sprint‐Ziels und der Anpassung des Sprint Backlogs. Es geht also darum, die Arbeit im Team zu synchronisieren und gemeinsam auf das Sprint-Ziel hinzuarbeiten.
9. Das Inkrement: Das nutzbare Ergebnis eines Sprints
Der Zweck von Scrum ist, bis zum Ende des Sprints ein neues Inkrement zu erstellen. Scrum Teams erstellen also in jedem Sprint eine neue Version des Produkts. Da allerdings der Produktbegriff in Scrum sehr weit gefasst ist, sprechen wir nicht von Versionen, sondern von Inkrementen. Ein Produkt kann sowohl eine Dienstleistung als auch ein digitales, physisches Produkt oder eine Kombination aus beidem sein. Das Inkrement besteht aus der Summe der abgeschlossenen Product-Backlog-Einträge. Um unterschiedliche Erwartungen zu vermeiden, ist ein Product-Backlog-Eintrag erst dann „fertig“, wenn er nutzbar und gründlich überprüft ist. Diese Qualitätserwartungen werden in der Definition of Done festgehalten.
10. Das Sprint Review: Überprüfung der Ergebnisse des Sprints und Planung, was als Nächstes getan werden sollte
Am Ende des Sprints organisiert das Scrum Team für die Stakeholder ein Sprint Review. Nach der Überprüfung der Sprint-Ergebnisse werden die nächsten Schritte geplant. Während des Sprint Reviews wird das Inkrement von den Anwesenden begutachtet und Feedback eingeholt. Die daraus entstehenden Ideen können als Einträge im Product Backlog festgehalten werden. Das Sprint Review sollte ein Arbeitstermin sein. Eine Präsentation oder der Moment, in dem der Product Owner das Ergebnis der Arbeit zum ersten Mal sieht, werden einem Sprint Review nicht gerecht.
11. Die Sprint Retrospektive: Überprüfung, wie das Scrum Team gearbeitet hat, und Planung von Verbesserungen
Nach dem Sprint Review nutzt das Scrum Team die Sprint Retrospektive, um über die Arbeit nachzudenken. Während das Sprint Review den Fokus auf das Inkrement und die Ziele legt, setzt die Sprint-Retrospektive den Fokus auf den notwendigen Prozess, um dorthin zu gelangen. Der Zweck der Sprint-Retrospektive ist, Wege zur Steigerung von Qualität und Effektivität zu planen. Das Resultat des Termins sollte eine konkrete Verbesserung für den nächsten Sprint sein. Die Sprint Retrospektive beschließt den Sprint.
Dieser Überblick vermittelt einen ersten Eindruck von Scrum. Morgen werden wir alle Elemente im Detail besprechen und die Beschreibung von Scrum im Scrum Guide erklären.
Wenn du Fragen hast, schreibe sie in die Kommentare. Wenn der Artikel für dich hilfreich war, dann gib ihm einen Daumen nach oben. Morgen geht es weiter mit Teil 3: Warum ist die regelmäßige Überprüfung und Anpassung erfolgversprechender als Vorabanalyse und detaillierte Planung?