Eine Kurzgeschichte über ein Scrum Team

Eine Geschichte über ein Scrum Team, das früh und häufig lernt, wie es den Wert seines Produktes für die Nutzer maximieren kann.

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 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, 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 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 Kunden 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 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 und einen Scrum Master. 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 Developern Dana, Douglas und Daniel und dem Scrum Master Sam ist das Scrum Team bereit, loszulegen.

Gemeinsam beschließen 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 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 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 nutzbar ist und an diese ausgeliefert werden könnte.

Die Developer 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 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. Das Sprint Backlog visualisieren die Developer, 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 versprechen, ihr Bestes zu geben, um gemeinsam das Sprint Goal zu erreichen.

Am nächsten Morgen treffen sich die Developer 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 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 zum Sprint Review ein. Darunter befinden sich auch einige Kunden, die großes Interesse an dem Produkt haben. Sam hat den Ablauf des Sprint Reviews vorbereitet und führt die Teilnehmer 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 transparent sind, diskutieren alle gemeinsam, wie das Scrum Team den Wert des Produktes optimieren könnte. Die Nutzer geben wertvolle Hinweise zum Nutzen des Produktes, und die Stakeholder 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 Teilnehmern 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 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 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 Developern 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.

*Scrum Poster downloaden*

Durch seine enge Zusammenarbeit schafft es das Scrum Team, dass der zweite Sprint genauso erfolgreich ist wie der erste. Noch vor Ende des Sprints entscheidet Paula, das Increment zum ersten Mal an ausgewählte Nutzer auszuliefern. Damit wollen sie früh ein nutzbares Produkt zur Verfügung stellen und mehr darüber lernen, wie nützlich das Produkt tatsächlich für die Nutzer ist. Auch die Stakeholder sind zufrieden und gewinnen weiter an Vertrauen in das Scrum Team.

Als Scrum Team managen sie sich selbst und treffen die Entscheidung, Diana als weitere Developerin ins Team zu holen.

In jedem Sprint liefert das Scrum Team mehrmals ein nutzbares Increment. Paula entscheidet häufig, das Increment auszuliefern, sodass das Team oftmals weitere Erkenntnisse darüber sammelt, ob das Increment den Nutzen für die Kunden optimiert. Das Scrum Team gewinnt außerdem weiter an Erfahrung und Reife. Die regelmäßigen Inspektionen und Anpassungen sowie die Transparenz in Hinblick auf die Ziele und den Fortschritt motivieren das Scrum Team zusätzlich.

Als Geschäftsführerin von Amazing Decisions ist Kathryn dankbar für das motivierte Scrum Team und den wachsenden Wert des Produktes. Sie will Scrum zukünftig in ihrem Unternehmen noch mehr verbreiten und dafür die Rahmenbedingungen weiter verbessern. Dazu bittet sie Sam um Hilfe …

Wollen Sie mehr über Scrum erfahren?

Dann nehmen Sie an einem unserer Professional Scrum Trainings teil. Sprechen Sie uns an!

Bessere Produkte schneller entwickeln. Kontaktieren Sie uns!

Kristin Zwicker

Business Development


+49 178 3843187

kristin@amazing-outcomes.de

Termin buchen

Kristin Zwicker

Business Development


+49 178 3843187

kristin@amazing-outcomes.de

Termin buchen

Hilfe benötigt?

Brauchen Sie Hilfe, um Business Value mit Scrum zu generieren?