Eine Kurzgeschichte über ein Scrum Team

Dies ist die Geschichte über ein Scrum Team, das Scrum nutzt, um ein Produkt zu entwickeln und um dabei früh und häufig zu lernen, wie es den Wert des Produktes für die Nutzer:innen optimieren kann. Während die Geschichte von einem fiktiven Team handelt, ist die dargestellte Anwendung von Scrum realistisch. So will diese Geschichte dabei helfen, ein besseres Verständnis von Scrum zu erreichen, insbesondere für Leser:innen, die Scrum bisher noch nicht selbst erleben konnten.

Ein Scrum Team bei Amazing Decisions

Kathryn ist Gründerin und Geschäftsführerin von Amazing Decisions. Ihr Unternehmen entwickelt digitale Produkte, die anderen Unternehmen helfen, kluge Entscheidungen zu treffen.

Kathryn hat eine Idee für ein neues Produkt. Was die potenziellen Nutzer:innen von der Idee und dem Produkt halten werden, kann sie allerdings nicht mit Sicherheit sagen. Da hat sie früher schon die eine oder andere Überraschung erlebt. Kathryn weiß, dass eine Investition in die Idee durchaus nicht zum gewünschten Ergebnis führen muss. Glücklicherweise weiß sie auch, wie sie dieses Risiko begrenzen und steuern kann.
  

Sie bittet Paula um Hilfe, die die Kund:innen von Amazing Decisions und deren Ziele, Herausforderungen und Bedürfnisse sehr gut kennt. Paula findet die Idee ebenfalls vielversprechend, kann aber auch nicht vorhersagen, wie nützlich die Nutzer:innen das Produkt finden werden. Kathryn überträgt ihr die Ergebnisverantwortung der Product Ownerin und bittet sie, mehr Erkenntnisse über den Wert der Idee und des Produktes zu erlangen.

Paula beginnt sofort damit, ein Scrum Team zusammenzustellen. Dazu braucht sie einige Developer:innen und eine:n Scrum Master:in. Kurze Zeit später trifft sie sich mit der Developerin Dana, um sie ins Scrum Team zu holen. Dana findet die Idee spannend und freut sich, Teil des Scrum Teams zu sein. Außerdem hat sie eine gute Vorstellung davon, welche weiteren Fähigkeiten notwendig sein werden, um das Produkt zu entwickeln. Daher holt sie die Developer Daniel und Douglas als Verstärkung ins Scrum Team. Schnell werden sich die vier einig, dass sie Sam überzeugen wollen, als Scrum Master mitzumachen. Sam ist dafür bekannt, dass er als Servant Leader bereits vielen Teams bei Amazing Decisions geholfen hat, ihre Ziele zu erreichen. Auch Sam freut sich, Teil des Scrum Teams zu werden. Mit Paula als Product Ownerin, den Developer:innen Dana, Douglas und Daniel und dem Scrum Master Sam ist das Scrum Team bereit, loszulegen.

Gemeinsam besprechen sie, ihren ersten Sprint gleich am kommenden Tag zu starten. Daniel und Douglas fühlen sich zunächst etwas überrumpelt. Sie glauben, dass man doch erst einmal in die Planung gehen sollte, um im Detail zu beschreiben, welche Anforderungen das neue Produkt erfüllen soll. Sam erklärt ihnen den Zweck von Scrum und den Ablauf von Sprints und bittet sie, Vertrauen in das Scrum Framework und ihn als Scrum Master zu haben.
  

Von Sams Erklärungen und Zuversicht motiviert, trifft sich das Scrum Team am kommenden Tag zum Sprint Planning: Paula beschreibt zunächst Kathryns und ihre Vision des Produkts sowie das nächste Etappenziel, das Product Goal. Dieses hat sie bereits im Product Backlog festgehalten, wodurch es für das Scrum Team und die Stakeholder:innen jederzeit transparent ist. Dann schlägt Paula das Sprint Goal vor und diskutiert dies mit dem Scrum Team. So erlangen alle ein gemeinsames Verständnis davon, warum sie diesen Sprint durchführen wollen. Da das Product Backlog zu diesem Zeitpunkt nur das Product Goal enthält, erarbeitet das Scrum Team direkt im Sprint Planning einige Product Backlog Items, die für das Sprint Goal relevant sind. In diesen beschreiben sie sowohl Produktfunktionen, von denen sich Paula einen Wert für die potenziellen Nutzer:innen verspricht, als auch einige Experimente, durch die sie mehr über den Wert der Idee herausfinden wollen. Dann erstellt das Scrum Team gemeinsam die Definition of Done. In der Definition of Done sind die Kriterien beschrieben, die das Increment erfüllen muss, damit es für Nutzer:innen nutzbar ist und an diese ausgeliefert werden könnte.

Die Developer:innen Dana, Daniel und Douglas wählen dann die Product Backlog Items aus, die das Sprint Goal erfüllen würden und die sie im Sprint für machbar halten. Diese Auswahl ist der Forecast für den Sprint. Dabei berücksichtigen sie sowohl ihre verfügbare Kapazität als auch ihre Definition of Done. Hin und wieder hat Sam das Gefühl, dass einige unausgesprochene Fragen im Raum stehen. Dann fragt er nach und trägt so zu einem noch besseren gemeinsamen Verständnis bei. Auch Paula kann noch Fragen beantworten und freut sich über den Forecast. Die Developer:innen erarbeiten dann einen Plan, wie sie das Sprint Ziel erreichen und das Increment gemäß der Definition of Done erstellen wollen. Sprint Goal, Forecast und der Plan ergeben gemeinsam das Sprint Backlog der Developer:innen. Das Sprint Backlog visualisieren die Developer:innen, damit sie jederzeit ein gemeinsames Verständnis davon haben, woran sie gerade arbeiten und was sie noch tun müssen, um das Sprint Goal zu erreichen. Am Ende des Sprint Plannings haben alle ein gutes Gefühl, und die Developer:innen versprechen, ihr Bestes zu geben, um gemeinsam das Sprint Goal zu erreichen.
  

Am nächsten Morgen treffen sich die Developer:innen zum Daily Scrum und besprechen, wie sie den Tag nutzen wollen, um einen Fortschritt hin zum Sprint Goal zu machen. Danach arbeiten sie gemeinsam am wichtigsten ausgewählten Product Backlog Item. Im weiteren Verlauf des Sprints treffen sie sich an jedem Arbeitstag zum Daily Scrum. Gemeinsam inspizieren sie ihren Fortschritt und besprechen, was sie tun werden, um das Sprint Goal zu erreichen. Wenn sie durch ihre Arbeit lernen, dass etwas anders als geplant besser zu realisieren ist oder zu einem besseren Ergebnis führt, dann passen sie ihren Plan und das Sprint Backlog an. So bleiben Fortschritt und die verbleibende Arbeit für das Sprint Goal für sie immer transparent. Neben ihrer Arbeit am Sprint Goal verfeinern sie gemeinsam mit Paula das Product Backlog und bereiten Product Backlog Items — Funktionen, Ideen, Anforderungen und Experimente — für die nächsten Sprints vor. Dadurch erlangen sie ein gemeinsames Verständnis davon, woran sie voraussichtlich bald arbeiten werden.

Als die Developer:innen während des Sprints einmal auf ein Problem stoßen, das sie alleine nicht lösen können (Impediment), unterstützt sie Sam und findet mit Kathryns Hilfe eine Lösung. Weil sie so jeden Tag konzentriert arbeiten und wirklich ihr Bestes geben können, erreichen sie ihr Sprint Goal.

Paula lädt die wichtigsten Stakeholder:innen zum Sprint Review ein. Darunter befinden sich auch einige Kund:innen, die großes Interesse an dem Produkt haben. Sam hat den Ablauf des Sprint Reviews vorbereitet und führt die Teilnehmer:innen sicher durch: Paula stellt zunächst das Product Goal und das Sprint Goal vor. Freudig teilt sie mit, dass sie das Sprint Goal erreicht haben. Sie erläutert die Product Backlog Items, die dazu erledigt wurden, und dann zeigen Dana, Daniel und Douglas das Increment und beantworten einige Fragen dazu. Paula stellt daraufhin vor, was das Scrum Team als Nächstes tun will, um das Product Goal zu erreichen. Nachdem der aktuelle Stand und das Ziel für alle Teilnehmer:innen transparent sind, diskutieren alle gemeinsam, wie das Scrum Team den Wert des Produktes optimieren könnte. Die Nutzer:innen geben wertvolle Hinweise zum Nutzen des Produktes, und die Stakeholder:innen tragen Informationen zu Markttrends und Wettbewerbern bei. Allerdings können sie sich nicht darauf einigen, was der nächste Schritt sein sollte. Sam erklärt, dass Paula als Product Ownerin diese Entscheidung treffen und anhand des Inhalts und der Reihenfolge im Product Backlog transparent machen wird. Paula hat durch den Austausch mit den Teilnehmer:innen wichtige Informationen erhalten, die sie für das Product Backlog Management nutzen wird. Aufgrund der Transparenz, die das Scrum Team geschaffen hat, steigt das Vertrauen der Stakeholder:innen in das Scrum Team. Alle verlassen das Sprint Review mit einem guten Gefühl und sind schon gespannt auf das nächste.

Bevor der Sprint zu Ende ist, reflektiert das Scrum Team die Erfahrungen aus dem Sprint in der Sprint Retrospective. Sam sorgt als Scrum Master dafür, dass die Sprint Retrospective für alle Teilnehmer:innen produktiv ist. Zusammen stellen sie fest, was sie im Sprint gelernt haben und welche Verbesserungen sie umsetzen wollen, um sich als Team zu verbessern und die Qualität ihres Produktes zu steigern. Das Scrum Team entscheidet sich, der Definition of Done ein weiteres Kriterium hinzuzufügen, damit die Qualität des Increments verbessert wird. Sam hilft den Developer:innen zu verstehen, dass sich die Ergänzung der Definition of Done auf ihre zukünftige Arbeit auswirken wird. Froh über die vielversprechenden Ergebnisse des ersten Sprints und motiviert von dem Gefühl, dass sie wertvolle Erkenntnisse über den Wert der Idee und über sich als Scrum Team gewonnen haben, möchten die Teammitglieder direkt in den nächsten Sprint starten. Sie fragen sich, was dazu notwendig ist. Sam erklärt dem Team, dass ein Sprint automatisch auf den nächsten folgt und dass Sprints maximal einen Monat lang sein können. Das macht Fortschritt transparent und begrenzt das Risiko.