Der Scrum Guide: Was ist Scrum und wie funktioniert es?
30. August 2018 / Susanne Grätsch, Kassandra Knebel
Vielleicht haben Sie ja schon von Scrum gehört und fragen sich, was genau es damit auf sich hat und ob es sinnvoll wäre, Scrum in Ihrem Unternehmen zu nutzen?
Auf diese Fragen wollen wir in diesem und im nächsten Artikel eingehen: Von der Definition und Entstehung von Scrum bis hin zu den Vor- und Nachteilen, die entstehen können, wenn eine Organisation Scrum einführt – wir beleuchten das Thema Scrum von allen Seiten!
Der Scrum Guide: Was ist Scrum?
Inhalt
Warum Scrum?
Kommt Ihnen das bekannt vor?
Irgendwann merkte Herr M., dass er keine Lust mehr hatte. Er war Chef einer kleinen Firma mit ca. 30 Leuten – überwiegend Bauingenieure – im Bereich Tiefbau. Er war überlastet: Ständig wurde von ihm erwartet, dass er seinen Senf dazu gab, stets liessen sich seine Mitarbeiter Aufgaben von ihm geben und bei aktuellen Projekten wollten alle wissen, was er als Chef davon hielt. Auf die Einhaltung der Hierarchien wurde sorgfältig geachtet. Dadurch allerdings, dass er sich ständig damit befassen musste abzusegnen und zu verantworten, konnte er sich kaum den Aufgaben widmen, die die Firma weiter gebracht hätten – wie Strategie, Marketing, Recruiting.
Verdriesslicherweise zogen sich obendrein die Projekte lange hin und das obwohl er stets sein Bestes gab. Land war nicht in Sicht, denn sein Team war eingefahren; alles würde in diesem Trott endlos weitergehen.
Nach reiflicher Überlegung befand er, dass er etwas anders machen müsse, dass er sogar grundlegend etwas verändern müsse.
Er beschloss Scrum in seinem Unternehmen einzuführen…
Zu Ihrer Orientierung:
In diesem Artikel widmen wir uns der Theorie – also wie Scrum funktioniert, welche Begriffe zugrunde liegen und so weiter.
Die Praxis betrachten wir im nächsten Beitrag: Dort berichten wir dann, welche Erfahrungen unser Kunde Herr M. und seine Mitarbeiter mit Scrum in der Praxis gemacht haben.
Was ist Scrum? Die Definition – das Wichtigste in Kürze
Scrum ist eine agile Methode mit der sich Projekte managen lassen, mit der Entwicklungen voran getrieben werden können und die geeignet ist, Selbstorganisation in einem Unternehmen zu etablieren. Scrum zeichnet sich durch engmaschige Kommunikation unter sämtlichen Beteiligten, durch hohe Anpassungsfähigkeit an Veränderungen und durch flache Hierarchien aus. Mit Scrum ist es möglich bei hoher Unklarheit und Komplexität „auf Sicht“ zu managen; es ist nicht nötig vor Projektbeginn einen detaillierten Projektplan zu entwerfen. Scrum arbeitet mit Teams, die crossfunctional beziehungsweise interdisziplinär zusammengesetzt sind. Ziel und Richtung sind vorgegeben, die Teams jedoch haben die Freiheit den Weg dorthin selbst zu gestalten.
Der Nutzen von Scrum: Wann ist Scrum die richtige Lösung für Sie?
Scrum ist eine geeignete Methode für Sie, wenn…
Sie mit einem Team arbeiten
viele Faktoren noch ungewiss und nicht planbar sind
Sie Ihre Projekte mit höchster Geschwindigkeit bearbeiten und erledigen wollen
Sie maximale Flexibilität benötigen
die Orientierung an Kundenwünschen im Vordergrund steht
Ihre Mitarbeiter in ihrer Motivation und Eigenverantwortung bestärkt werden sollen
Sie ein attraktiver Arbeitgeber werden wollen, der flache Hierarchien, viel Handlungsspielraum und Verantwortung zu bieten hat.
Die Geschichte von Scrum: Wie Scrum entstanden ist
Der Begriff Scrum
Die japanischen Wissenschaftler Ikujirō Nonaka und Hirotaka Takeuchi gelten als die bedeutendsten Forscher auf dem Gebiet des Wissensmanagements. Im Jahre 1986 erschien ihr Artikel „The New New Product Development Game“ in der Harvard Business Review. Dieser legte den Grundstein dafür Projektmanagement und Produktentwicklung auf neue Art und Weise zu begreifen:
Nonaka und Takeuchi betonten die Wichtigkeit der Zusammenarbeit, da diese Synergien und verborgenes Wissen zu Tage fördere und damit neuen Ideen den Weg bereite. Neu war hier Impulse aus dem Team aufzunehmen, statt Top down zu organisieren.
Sie nutzen erstmals die Worte „Scrum“ und „Sprint“, die sie aus dem Rugby entlehnten. Scrum bedeutet Gedränge. Im Rugby handelt es sich um eine dichte Ansammlung von 5 – 8 Spielern, die in die selbe Richtung drücken und so versuchen als Einheit den Ball in ihrem Sinne in´s Spiel zu bringen. Dies ist das Sinnbild für verschiedene Mitarbeiter, die als ein eng zusammenarbeitendes Team spontan reagierend in die selbe Richtung arbeiten, um erfolgreich zu sein.
Scrum in der Softwareentwicklung
Die US-amerikanischen Softwareentwickler Ken Schwaber und Jeff Sutherland gelten als die Erfinder von Scrum.
Zu Beginn der 1990er Jahre entwickelte Sutherland mit seinem Softwareentwicklungsteam die Grundlagen dieser Art der Zusammenarbeit. Neu war hier, dass der Projektleiter nicht mehr als Manager fungierte, sondern eine moderierende Funktion übernahm. Scrum trug dem Umstand Rechnung, dass in der sich rasant verändernden Welt der Softwareentwicklung der Entwicklungsprozess oft schnell an plötzliche Veränderungen angepasst werden muss und insofern eine langfristige Vorplanung des Prozesses nicht möglich ist.
1994 brachte Sutherland zusammen mit Ken Schwaber die Erkenntnisse des Teams in eine Form.
1995 stellte Ken Schwaber auf einer wissenschaftlichen Konferenz mit Schwerpunkt Computer/Programmierung Scrum erstmals vor.
2001 erschien das erste Buch über Scrum „Agile Software Development with Scrum“, geschrieben von Ken Schwaber und Mike Beedle.
2001 entstand das agile Manifest, in welchem Sutherland und Schwaber zusammen mit anderen die Werthaltungen hinter agiler Softwareentwicklung verschriftlichten. Dazu gleich mehr.
2003 begann Schwaber die ersten Scrum Master auszubilden und brachte ein weiteres Buch heraus: „Agile Project Management with Scrum“.
Scrum in anderen Branchen
2007 brachte Schwaber sein drittes Buch auf den Markt „The Enterprise and Scrum“. Die Prozesse, Rollen und Grundlagen von Scrum wurden nun auf andere Branchen übertragbar gemacht. Seitdem haben immer mehr Unternehmen Erfahrungen mit Scrum gesammelt.
Scrum sowie weitere agile Methoden stellen einen Gegensatz zum klassischen Management dar: Aufgaben werden nicht mehr von Vorgesetzten zugeteilt und kontrolliert. Ein sogenannter „Product Owner“ gibt dem Team ein Ziel vor und das Team kümmert sich eigenverantwortlich um dessen Umsetzung.
Im Winter 2001 verbrachten 17 unabhängig denkende Menschen aus der Software-Entwicklung eine vermutlich amüsante Skifreizeit in einem Skiresort in den Bergen Utahs miteinander. Viele von ihnen arbeiteten bereits mit Methoden wie Scrum. Ken Schwaber und Jeff Sutherland, die Begründer von Scrum waren ebenfalls unter ihnen. Neben zahlreichen Freizeitaktivitäten suchte man gemeinsam nach Wegen und Werten, nach Verbesserungsmöglichkeiten in der Software-Entwicklung. Und die fand man auch: die Anwesenden einigten sich auf vier grundlegende Werte. Diese Werte sind mittlerweile weltweit die Basis für agiles Arbeiten, auch in von der Software-Entwicklung weit entfernten Branchen. Dies sind die vier ursprünglichen Werte, zusammengefasst im sogenannten Agilen Manifesto.
Das agile Manifesto
„Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.“
Wichtig ist es an dieser Stelle noch zu erwähnen, dass das Agile Manifesto keineswegs auf Pläne, Prozesse und Dokumentation verzichten will; lediglich gibt es Dinge die Vorrang haben.
Wir haben vom agilen Manifesto ausgehend die Wertehaltungen definiert, die Scrum zugrunde liegen. Diese gelten für alle Arbeitsbereiche und Branchen – also nicht nur für die Software-Entwicklung.
Fokus auf die beteiligten Menschen und das Miteinander im Team und mit dem Kunden statt auf Prozesse, Verträge und Dokumentation.
Fokus auf den Kundennutzen und Flexibilität statt auf langfristige Pläne und deren Befolgung.
Selbstorganisation: Das Team plant seine Arbeit selbst und trifft die notwendigen Entscheidungen (Vertrauen).
Schnelligkeit: Kontinuierliche Lieferung von Projektfortschritten an den Kunden.
Flexibilität: Änderungswünsche des Kunden werden auch im weiteren Projektverlauf immer gerne übernommen.
Zusammenarbeit: Interdisziplinär gemischte Teams, persönliche Kommunikation ist die effizienteste.
Ständige Verbesserung: Kollegenfeedback und Kundenfeedback fließen immer wieder ein.
Transparenz: Das Team ist regelmäßig über den aktuellen Stand der Dinge informiert. Zeitnah können Anpassungen vorgenommen werden.
Struktur: Das Team setzt feste Zeitgrenzen, an die sich alle verbindlich halten.
Einfachheit: Fokus auf das Wesentliche, Dinge auch weglassen.
Video Was ist Scrum
Susanne vom berliner team erzählt in diesem 2:30 Minuten Video von Scrum.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube. Mehr erfahren
In der Grafik ganz am Ende dieses Beitrages können Sie erkennen, wie die einzelnen Faktoren zusammenhängen, wie die Methode Scrum abläuft. Wir erklären nun die Bedeutung der einzelnen Begriffe, Funktionen und so weiter. Wie weiter oben schon erwähnt bestehen die Grundlagen von Scrum (der Core) aus drei Rollen, fünf Aktivitäten und drei Artefakten.
Die drei Rollen bei Scrum
Werfen wir zunächst einen Blick auf die drei Rollen, die von Teammitgliedern, teilweise auch von Außenstehenden während eines Scrumprozesses eingenommen werden können: Product Owner, Scrum Master und Scrum Team.
Der Product Owner – Ziele und Prioritäten
Mittler zwischen Team und Außenwelt
Der Product Owner ist derjenige, der das Ziel und die Anforderung des Projektes formuliert und beim Scrum Team in Auftrag gibt. Dazu fungiert er als Schnittstelle zwischen dem Scrum Team und der Außenwelt, also Kunden, Stakeholdern und anderen Beteiligten.
Soll das Ergebnis der Zusammenarbeit beispielsweise ein Produkt sein, so bringt der Product Owner Kundenwünsche- und Bedürfnisse in Erfahrung und definiert anhanddessen, wie das Produkt schlussendlich aussehen soll, was es können muss, welche Eigenschaften es braucht, um dem Kunden zu gefallen.
Das heißt, der Product Owner ist verantwortlich dafür, dass das entstandene Produkt später beim Kunden auch gut ankommt, dass es für den Kunden attraktiv und dadurch marktfähig ist.
Die Informationen, die er vom Kunden erhält, schlüsselt er in einzelne Arbeitsaufgaben auf und stellt dem Team dann das zu erreichende Ziel sowie die Schritte dorthin zur Verfügung; dafür erstellt er eine Anforderungsliste (Product Backlog).
Prioritäten festlegen
Weiterhin fällt in seinen Verantwortungsbereich die Priorisierung der Aufgaben: Womit wird angefangen, was ist im Moment das Wichtigste? Er kann einschätzen, worauf der Kunde gerade seinen größten Schwerpunkt legt; so könnte es in der Softwareentwicklung vorrangig sein, dem Kunden einen bestimmten Teil eines Programms zügig zum Testen vorlegen zu können.
Das Scrum Team nimmt die Anforderung entgegen und arbeitet für die Länge eines Arbeitszyklus (Sprint) selbstständig daran. Es entscheidet selbst wieviel Arbeitsvolumen es in den meist zwei bis vier Wochen dauernden Arbeitszyklen (Sprints) bewältigen kann. Das Team handelt ohne Arbeitsanweisungen; der Product Owner ist nicht der Vorgesetzte.
Sprint Review
Nach Abschluss eines Sprints nimmt der Product Owner die gemachten Fortschritte ab, gibt seine Meinung dazu und holt die Rückmeldungen von Kunden und Stakeholdern dazu ein. Diesen Arbeitsschritt nennt man Sprint Review.
Der Scrum Master – Unterstützung des Teams
Während der Product Owner für das Produkt und für dessen Kriterien verantwortlich ist, sorgt der Scrum Master für einen möglichst reibungslosen Prozess. Er hat also mit dem Inhalt, dem Produkt an sich nicht wirklich viel zu tun; dafür weiß er am besten wie Scrum funktioniert.
Moderator und Mediator
Der Scrum Master moderiert den Prozess indem er sicherstellt, dass die Kommunikation fließt und dass die verschiedenen Meeting-Formate und Strukturen auch gelebt werden. Statt Aufgaben zu organisieren und zu verteilen, stellt er die Plattform zur Verfügung, die dem Entwicklungsteam ermöglicht selbst zu entscheiden wer wann welche Aufgaben übernimmt, wie sie organisiert werden und wie viele davon in welchem Zeitraum zu schaffen sind. Bei diesen Entscheidungen steht er moderierend zur Seite. Wenn einmal Konflikte auftreten, dann übernimmt er die Rolle des Mediators. Der Scrum Master räumt Hindernisse aus dem Weg und schützt sein Team vor Störungen von außen.
Er leitet den Prozess an, ohne jedoch Führungskraft zu sein, denn klassische Führungskräfte braucht es in der Arbeit mit Scrum nicht. Auf hierarchische Strukturen wird verzichtet; vielmehr gibt es verschiedene Rollen, die die Team-Mitglieder übernehmen können und einige davon beinhalten auch Führungsaufgaben.
Das Scrum Entwicklungsteam – selbstständige Ausführung
Eigentlich nennt man alle zusammen, also Product Owner, Scrum Master und das Entwicklungsteam zusammen das Scrum Team.
Wir fassen Scrum allerdings etwas weiter: Scrum ist nicht nur eine Methode, um zu entwickeln, sondern auch eine Möglichkeit Zusammenarbeit zu organisieren. Wir nennen das Team, dass die Anforderungen schließlich umsetzt das Entwicklungsteam. Dieses Team fällt Entscheidungen gemeinsam. Wenn das Team vom Product Owner die Anforderungsliste (Product Backlog) vorgelegt bekommt, entscheidet es, wie es mit den Anforderungen in der nächsten Arbeitsphase (Sprint) umgeht. Es erörtert gemeinsam folgende Fragen:
Wie viel schaffen wir?
Wer schafft was?
Wie kriegen wir das hin?
Wie organisieren wir uns?
– Und macht sich dann schließlich an die Umsetzung.
Ein Team sollte aus 7 Personen aus verschiedensten Disziplinen bestehen. Sollten mehr Mitarbeiter als 10 nötig sein, dann sollte auf kleinere Teams aufgeteilt werden. Die geringe Größe stellt sicher, dass untereinander ausreichend kommuniziert werden kann und macht die Selbstorganisation leichter.
Weitere Rollen in Scrum
Die drei zentralen Rollen in Scrum haben wir betrachtet. Es sei noch betont, dass die oben genannten Rollen sich deutlich von Rollen im klassischen Projektmanagement unterscheiden.
Neben den genannten Rollen gibt es natürlich noch weitere Menschen, die an einem Scrumprozess beteiligt sind – die so genannten Stakeholder. Dabei handelt es sich zum Beispiel um Kunden, Anwender oder auch das Management – alles Menschen, die auf die ein oder andere Art ein Interesse an der Entwicklung des Produktes oder Services haben.
Der Sprint – Das Zeitmaß der Arbeitszyklen
Ein Sprint ist ein Zeitraum von meist 2-4 Wochen. In dieser Zeit arbeitet das Entwicklungsteam gemeinsam an den gestellten Aufgaben, die der Product Owner im Product Backlog festgehalten hat.
Wie läuft ein Sprint ab?
Am Anfang jedes Sprintzyklus steht die gemeinsame Sprintplanung und darauf folgt die Arbeitsphase. In der Sprintplanung wird das Ziel des aktuellen Sprintzyklus definiert und die Arbeit verteilt. Während der Arbeitsphase wird untereinander regelmäßig nach einem vorgegebenen Plan kommuniziert. Diese Meeting- und Kommunikationsformate schildern wir weiter unten. Am Ende des Zyklus gibt es ein so genanntes Sprint Review. Hier betrachtet man gemeinsam, welches Ergebnis man innerhalb der 2-4 Wochen erzielen konnte. Obendrein gibt es eine Sprint Retrospektive, in der man die Form der Zusammenarbeit betrachtet: Wie haben wir zusammen gearbeitet? Was können wir verbessern?
Während eines Sprints arbeitet das Entwicklungsteam ungestört. D.h., es verfolgt das vorgegebene Ziel, welches innerhalb dieses Zeitraumes nicht verändert werden kann. Während eines laufenden Sprints darf nicht umgelenkt werden, es gibt zwischen den Sprints genug Gelegenheit Ziele und Vorgehensweisen zu aktualisieren.
Nach Beendigung eines Sprints folgt unmittelbar darauf der nächste Sprint.
Die Länge eines Sprints
Sprints sind bewusst relativ kurz gehalten, damit man die Gelegenheit hat, immer wieder zwischendurch die Meinung des Kunden einzuholen und damit man Veränderungen von Markt oder Situation berücksichtigen kann. So stellt man sicher, dass man nicht zu lange in die falsche Richtung arbeitet. Es hat sich herausgestellt, dass zwei bis vier Wochen ein guter Zeitraum sind. Innerhalb dieser Zeit sind mögliche Veränderungen von außen meist nicht zu groß, so dass das Team sich erst einmal in die gegebenen Aufgaben stürzen kann.
Ein Sprint ist so lange, wie vorher vereinbart; er kann nicht verlängert werden. Sämtliche Sprints sollten die gleiche Länge haben, damit der gesamte Prozess eine Art Taktung erhält.
Der Product Owner kann einen Sprint abbrechen, wenn sich an der Aufgabe zwischenzeitlich derart Grundlegendes verändert hat, so dass das Weiterarbeiten keinen Sinn mehr machen würde oder wenn abzusehen ist, dass das Team das Sprint Ziel nicht erreichen kann, zum Beispiel weil es das Arbeitsvolumen falsch eingeschätzt hat. Im Falle eines Abbruchs wird zunächst in einer Sprint Retrospektive betrachtet, wie man gearbeitet hat und was daran verbesserungswürdig ist – und danach geht man wieder in die nächste Sprintplanung über.
Ein ideales Tool für einen Sprint ist eine so genannte Sprintwand, auf der für alle jederzeit ersichtlich die Aufgaben zu sehen sind, die innerhalb des aktuellen Sprintzyklus zu erledigen sind. Dazu später mehr.
Das Sprint Ziel
Das Sprint Ziel beschreibt das Ergebnis, dass am Ende eines Sprints, also nach 2-4 Wochen vom Team erreicht worden sein soll. Wichtig ist hier, dass dieses Ziel etwas ist, dass sichtbar ist; ein Ergebnis, von dem man sagen kann, man hat etwas Konkretes vorliegen. So hat das Team Ziel, Orientierung und Motivation zugleich.
Hier einige Beispiele für mögliche Sprintziele: Am Ende des Sprints wollen wir…
… die Unterlagen für alle 250 Teilnehmer des Veränderungsprozesses fertig gestellt haben.
… ein neues Element im Shop auf der Webseite veröffentlichen.
… den Sensor fertig entwickelt haben.
Sie sehen – auch wenn sich viele Aufgaben darunter subsumieren – diese Ziele sind greifbar und nutzbar. Schließlich sollen sie von allen Beteiligten inklusive Stakeholdern im Sprint Review auch ausprobiert, angefasst, überprüft und angeschaut werden.
Die Artefakte in Scrum
Kommen wir nun zu den so genannten Artefakten. Wikipedia beschreibt Artefakt wie folgt:
Ein Artefakt (Softwareentwicklung), ist ein Produkt, das als Zwischen- oder Endergebnis in der Softwareentwicklung entsteht
An diesem Wort erkennt man, dass Scrum aus dem Bereich der Softwareentwicklung stammt. In Scrum gibt es drei Artefakte: den Product Backlog, das Sprint Ziel und das Product Inkrement. Diese beschreiben die jeweiligen Ziele, den jeweiligen Stand.
Der Product Backlog
Der Product Backlog beschreibt die Vision des fertigen Produktes oder Services. Sämtliche Anforderungen werden hier so detailliert wie möglich aufgeführt: Wie soll es aussehen, welche Features soll es haben, was braucht es? Dafür zuständig diese Informationen mithilfe der Stakeholder, insbesondere der Kunden, zu ermitteln und zusammenzutragen ist der Product Owner.
Desweiteren finden sich im Product Backlog die Aufgaben, die bewältigt werden müssen, um das Produkt zu entwickeln.
Auch während der Sprints arbeitet der Product Owner permanent daran, den Product Backlog aktuell zu halten: Er stellt den Stakeholdern jeweils nach einem Sprintzyklus den aktuellen Prototyp vor und arbeitet Kritik, Wünsche und weitere von den Stakeholdern definierte Details in den Product Backlog ein.
Er prüft auf diese Weise die Zwischenergebnisse auf Herz und Nieren: Sind wir mit unserer Entwicklung noch auf der Spur? Ist das noch das Richtige? Was muss verändert werden?
Der Ablauf
Das ursprüngliche Start-Backlog kann man zum Beispiel in einem Design Sprint entwickeln.
Aus dieser Idee bricht man herunter, welche Aufgaben zu erledigen sind.
Durch das Abarbeiten dieser Aufgabenliste entwickelt man einen Prototypen.
Dieser wird permanent durch Kunden und Stakeholder auf seinen Nutzen überprüft wird (Product Backlog Refinement).
Gemäß dieses Feedbacks werden Anforderungen und Aufgaben im Product Backlog aktualisiert.
Die Aufgaben im Product Backlog
Im Detail kann man sich das folgendermaßen vorstellen:
Es gibt immer wieder größere Aufgabenpakete. Aus diesen werden dann einzelne Aufgaben priorisiert und näher ausgeführt. So gewinnt man schließlich eine Liste von relativ detailliert beschriebenen Aufgaben, so dass sich der nötige Arbeitsaufwand einschätzen lässt.
Damit lässt sich dann die Planung für die Arbeit im nächsten Sprint machen.
Man arbeitet sich also von der großen Vision, vom großen Ziel hin zu einzelnen Arbeitsschritten, die in einem Sprintzeitraum von 2-4 Wochen erledigt werden können.
Der Sprint Backlog
Der Sprint Backlog zeigt die Aufgaben, die aus dem Product Backlog für die Bearbeitung im nächsten Sprint ausgewählt wurden.
Um die Aufgaben und ihren jeweiligen Bearbeitungsstand zugänglich zu machen, wird häufig eine so genannte Sprintwand benutzt. Diese Wand oder Tafel teilt sich in vier Spalten von links nach rechts.
Die Sprintwand
Ganz links stehen die Backlog Einträge, also die spezifizierten Aufgaben, bei denen detailliert beschrieben wird, was getan werden muss.
In der Mitte werden diese Aufgabe noch einmal in kleinere Aufgaben unterteilt.
Im dritten Teil, also ein Stück weiter rechts, befinden sich die Aufgaben, die gerade in Bearbeitung sind.
Und schließlich findet sich ganz rechts die Spalte in der die bereits erledigten Aufgaben zu finden sind.
Der Prozess
Aufgaben wandern von links nach rechts. Damit wird visualisiert, wie weit man in diesem aktuellen Sprint bereits gekommen ist. Ob die Sprintwand eine tatsächliche Wand, ein Whiteboard oder eine Online Funktion wie zum Beispiel Trello ist, bei der jeder die aktuelle Sprintwand auf seinem Handy hat, das kann jedes Team so gestalten, wie es mag. Natürlich ist es von Vorteil eine Online Sprintwand zu nutzen, wenn man eher virtuell miteinander zu tun hat und nicht immer im selben Arbeitsraum arbeitet.
Wichtig zu erwähnen ist noch, dass auf den Aufgaben, die in Bearbeitung sind, die Namen der Team Mitglieder stehen, die die Aufgabe jeweils bearbeiten. Hat ein Teammitglied eine Aufgabe fertig gestellt, so bewegt es diese in die entsprechende vierte Spalte.
Das Team Mitglied sucht sich dann in der Spalte, in der Aufgaben zu finden sind, die noch erledigt werden müssen eine passende, neue Aufgabe aus, packt seinen Namen darauf und hängt es in die Spalte „In Arbeit“.
Das Product Inkrement
Beim Product Inkrement handelt es sich um sämtliche Einträge im Product Backlog, die während des aktuellen Sprints fertiggestellt wurden plus das, was aus vorherigen Sprints schon fertig war. Es ist quasi der aktuelle Stand des Produktes, der der „Definition of Done“ entspricht. Da es sich bei den Sprintzielen jeweils um greifbare, nutzbare Ziele handelt, muss auch das Product Inkrement nutzbar und anschaulich sein.
Ein Beispiel für ein solches Inkrement könnte eine lauffähige Software sein: ein Teil eines neuen Programms, der aber für sich genommen schon funktioniert. In einem Change Prozess könnte ein Inkrement ein abgeschlossener Prozess in einem Teilbereich der Organisation sein, wenn in diesem Teilbereich bereits veränderte Strukturen, Abläufe und neue Formen der Zusammenarbeit implementiert wurden.
Definition of Done
Bei der „Definition of Done“ handelt es sich um ein gemeinsames Verständnis des Scrum Teams darüber, wann eine Arbeit als fertig bezeichnet wird. Sie enthält zum Beispiel so etwas wie Qualitätskriterien.
Das Product Inkrement, als der aktuelle Stand, dient gleichermaßen der Motivation, sowie der Überprüfung des Ergebnisses.
Die Scrum Meeting-Formate
Die Sprintplanung
Am Anfang eines Sprints steht die gemeinsame Sprintplanung.
Dauer: je nach Sprintlänge 4 – 8 Stunden.
Sprintplanung Phase 1
Hier kommen Product Owner, Scrum Master und Entwicklungsteam zusammen. Wie immer hat der Scrum Master eine moderierende Funktion. Der Product Owner stellt das aktuelle Product Backlog vor, also: wie genau schaut aktuell die Version des von uns zu entwickelnden Produktes oder Services aus? Da er in der Vorarbeit bereits Aufgabenpakete herausgearbeitet und priorisiert hat, präsentiert er als nächstes die Aufgaben, die er für den kommenden Sprint vorgesehen hat.
Das gesamte Team arbeitet daran, dass für jeden verständlich wird, worum genau es geht, was zu erreichen ist und welche Aufgaben anstehen. Das Entwicklungsteam überlegt sodann unter sich, wie viele der Aufgaben, die der Product Owner vorgelegt hat, sie im nächsten Sprintzyklus tatsächlich schaffen können. Hat das ausführende Team sich dahingehend besprochen, dann definiert es gemeinsam mit Product Owner und Scrum Master das nächste Sprint Ziel: Wie soll das Ergebnis nach dem Sprint aussehen?
Sprintplanung Phase 2
Nach diesem ersten Teil der Sprintplanung zieht sich das Entwicklungsteam mitsamt Scrum Master zurück. Das Team berät sich, was genau es braucht, um das Sprint Ziel zu erreichen. Es stimmt sich darüber ab, welche Aufgaben im Detail noch nötig sind und wie es sich organisieren möchte. Bei dieser Detailplanung muss der Product Owner nicht dabei sein. Er kann, aber vonnöten ist es nicht.
Wenn die Detailaufgaben benannt sind, dann werden sie auf der Sprintwand allen zugänglich gemacht. Sie werden nicht an die Team Mitglieder verteilt, sondern die Team Mitglieder wählen selbst aus, welche Aufgabe sie wann bearbeiten möchten. Erst wenn ein Teammitglied für sich entschieden hat, dass eine Aufgabe gerade gut passt, dann schreibt es den eigenen Namen darauf und verschiebt es auf der Sprintwand in die Spalte „in Arbeit“.
Das Daily Scrum
Zu Beginn jeden Tages innerhalb eines Sprints trifft sich das Entwicklungsteam mitsamt Scrum Master.
Dauer: ca. 10-15 Minuten
Das Daily Scrum
Das Daily Scrum ist ein kurzes Meeting jeden Tag zur selben Zeit. Idealerweise findet es gleich zum Tagesbeginn statt. Es geht darum, kurz Informationen auszutauschen. Es ist zeitlich bewusst sehr knapp gehalten, um sich nicht zu verzetteln. Dafür dass es kurz und knackig bleibt ist der Scrum Master verantwortlich. Jeden Tag werden die folgenden drei Fragen gestellt:
Was haben wir seit dem letzten Daily Scrum erreicht?
Was werden wir bis zum nächsten Daily Scrum erreichen?
Gibt es Hindernisse? Und welche Hindernisse sind das?
Mögliche Hindernisse können sein: fehlende Informationen, Uneinigkeit darüber, wie man die Aufgabe umsetzt, ein Konflikt oder organisatorische Hindernisse. Der Scrum Master sammelt die Informationen zu den Hindernissen ein und sorgt dafür diese zu beseitigen, so er denn kann.
Wie kann das aussehen?
Zum Beispiel hat das ausführende Team ein organisatorisches Problem: es braucht mehr Kapazität, jemanden der es unterstützt. Der Scrum Master organisiert die Unterstützung. Das soll natürlich nicht heißen, dass er grundsätzlich jeden Wunsch des Teams erfüllen muss. Denn ist das Team in der Lage ein Hindernis selbst aus dem Weg zu räumen, dann muss es das auch angehen.
Fehlen zum Beispiel Informationen und müssen diese innerhalb des Teams ausgetauscht werden, dann wird dafür ein Termin vereinbart, in dem diese inhaltlichen Informationen fliessen; dafür wird nicht die knappe Zeit des Daily Scrum verbraucht. Hier geht es tatsächlich nur darum, dass alle auf dem aktuellen Stand sind.
Burndown-Chart
Es empfiehlt sich, den aktuellen Stand auch in einem Burndown-Chart zu visualisieren. Hier wird in einer Grafik täglich die Menge der noch vorhandenen Aufgaben eines Sprints im Verhältnis zur noch zur Verfügung stehenden Zeit erfasst. Damit erhält man einen Anhaltspunkt, ob das geplante Ziel zu erreichen ist.
Das Sprint Review
Das Sprint Review ist das Meeting zum Vorstellen des Sprint Ergebnisses.
Dauer: 2-4 Stunden
Das Sprint Review
Nach Vollendung eines Sprintzykluses wird ein Sprint Review Meeting einberufen. Eingeladen sind Team, Product Owner, Sprint Master und Stakeholder. Im Sprint Review präsentiert das Team das Ergebnis des letzten Sprints und beantwortet Fragen dazu. Im Idealfall ist das Sprint Ergebnis etwas, das man anfassen und ausprobieren kann, so dass die Steakholder Erfahrungen mit dem Produkt sammeln können. Die Stakeholder schauen sich das Ergebnis an: Wie funktioniert das Produkt eigentlich? Komme ich damit klar? Was fehlt mir? usw.
Der Product Owner notiert das Feedback der Stakeholder und pflegt es in den Product Backlog ein, so dass die daraus gewonnenen Informationen direkt in den nächsten Sprint miteinfliessen.
Das Ziel des Sprint Reviews ist es, das Produkt zu verbessern.
Sollte eine weitere Sitzung vonnöten sein, um das Product Backlog auf den neuesten Stand zu bringen, also Ziele, Aufgaben und Prioritäten zu aktualisieren, dann nennt sich diese Product Backlog Refinement Ereignis.
Das Product Backlog Refinement Ereignis
Das Product Backlog Refinement ist eine fortlaufende Tätigkeit des Product Owners, um das Product Backlog auf den neuesten Stand zu bringen.
Product Backlog Refinement
Während des Sprints arbeitet der Product Owner weiter daran das Product Backlog zu aktualisieren. Das kann er nicht ganz alleine machen; er muss dazu Stakeholder, also Kunden, Benutzer, Management und auch Mitglieder des Arbeitsteams befragen. So lädt er diese zu einem Product Backlog Refinement Ereignis ein, welches ein bis zwei mal während eines Sprints stattfindet. Die Stakeholder können bei diesem Meeting spezifizieren, welche Funktionalitäten sie sich beim Produkt wünschen. Die Mitglieder des ausführenden Teams können Rückmeldung darüber geben, was funktioniert und was nicht. Der Product Owner ist dafür verantwortlich, das Feedback der Stakeholder in die Aktualisierung des Product Backlogs mit einfliessen zu lassen. Auch kümmert er sich darum, dass die Aufgaben die anfallen definiert, eingeschätzt und priorisiert werden. Er sorgt dafür, dass das Product Backlog auf dem neuesten Stand bleibt, das heißt zum Beispiel, dass neue Einträge hinzugefügt, alte entfernt werden und er gibt vor, welche Aufgaben im nächsten Sprint bearbeitet werden sollen.
Sprint Retrospektive und Ausblick
Dauer: 1- 3 Stunden
In der Sprint Retrospektive reflektiert das Team die Zusammenarbeit während des letzten Sprints.
Sprint Retrospektive
Nach dem Sprint Review und vor dem Start des nächsten Sprints kommt das Entwicklungsteam zusammen und überlegt, was im letzten Sprint gut gelaufen ist und was das Team optimieren kann. Es geht darum, die Arbeitsabläufe möglichst optimal zu gestalten und auch darum eine für das Team möglichst angenehme Art der Zusammenarbeit zu finden. Moderiert wird dieses Meeting vom Scrum Master. Diesem stehen dazu verschiedene Techniken zur Verfügung. Da es die Aufgabe des Scrum Masters ist, das Team bei der Arbeit zu unterstützen und die Zusammenarbeit zu optimieren, ist die Sprint Retrospektive ein wichtiger Teil seiner Arbeit.
Fragen, die sich das Team hier stellen kann:
Wie waren wir beim letzten Sprint? Wie haben wir gearbeitet?
Was lief gut?
Was lief nicht so gut?
Passt unser Team?
Sind wir gut in der Kommunikation miteinander?
Wie besprechen wir uns? Was können wir da verbessern?
Wie haben wir „erledigt“ definiert („Definition of Done“)?
Ist das zu viel oder zu wenig herausfordernd oder passt das so?
Sind wir mit dem Ergebnis weiter gekommen?
Sind wir gut in der Zeit, bei diesem Sprint und insgesamt?
Schaffen wir es unser Produkt rechtzeitig zu entwickeln, wenn wir so weitermachen wie jetzt?
Scrum Übersicht
Hier finden Sie eine grafische Übersicht über sämtliche Rollen, Meetings und Artefakte und wie diese zusammenhängen:
Scrum: Wie geht es weiter?
Und was passiert, wenn man Scrum in seinem Unternehmen einführt?
Was sind die Vorteile, welches die Nachteile?
In unserem nächsten Artikel Scrum in der Praxis – Vor-und Nachteile von Scrum berichten wir darüber, wie es unserem Kunden, Herrn M. gelungen ist Scrum in seinem Unternehmen einzuführen, welche Hindernisse er dabei nehmen musste und was sich günstig ausgewirkt hat.
Rund um das Thema Agilität haben wir bereits einige Artikel herausgebracht. Falls Sie tiefer in die Thematik einsteigen wollen, ist hier eine Übersicht für Sie:
Hilft anderen gern über die Schwelle – in agilen Transformationen und anderen Change-Prozessen
Susanne Grätsch weiß aus eigener Erfahrung, dass man an Veränderungen wächst. Seit 1999 ist sie im Mittelstand und für internationale Konzerne unterwegs. Anfangs lag ihr Schwerpunkt noch in Führungskräfteentwicklung und Coaching. Inzwischen sucht und findet sie ihre Herausforderungen in groß angelegten Change-Projekten, die sie begleitet. Sie unterstützt Unternehmen z. B. bei der Veränderung hin zu einem agilen Unternehmen im Rahmen der digitalen Transformation, bei der Überwindung von Wachstumsschwellen oder bei der Etablierung einer attraktiven, motivierenden Unternehmenskultur, die Voraussetzung für die Gewinnung neuer Mitarbeiter als attraktiver Arbeitgeber ist. Als NLP-Master-Practitioner, zertifizierte UXQB-Beraterin (für Usability und User Experience) sowie Consultant in der hypno-systemischen Organisationsberatung kann sie sich schnell in neue Fachgebiete einfuchsen und fühlt sich in der Automobilindustrie ebenso zu Hause wie in der IT-Branche oder der Immobilienwirtschaft. Ihre größte private Herausforderung ist es, beruflichen Erfolg mit einem erfüllten Familienleben zu verbinden. Allerdings ist sie damit nicht allein, sondern kann auf die tatkräftige Unterstützung ihres Mannes, Oliver Grätsch, zählen.
Über die Autorin
Kassandra Knebel
Macht gern Theater – auch als Trainerin in Unternehmen
Seit 15 Jahren macht Kassandra Knebel Unternehmenstheater. Ob Datev, Bombardier, Sparkasse oder Lions-Club – sie bringt Menschen dazu, ihre gewohnten Bahnen zu verlassen, neues Terrain zu erkunden und kreativ zu sein. In ihren Workshops geht es darum, Informationen in Handlung, Text und Spiel umzusetzen, sich und andere dabei zu beobachten und die Hintergründe zu erforschen und zu verstehen. Sie unterstützt Menschen dabei, Gefühl und Verstand zu synchronisieren, sich mit anderen auszutauschen und dadurch im Team enger zusammenzuwachsen. Außerdem schult sie Führungskräfte in überzeugendem Auftreten. Das Theaterspiel, bei dem die Körpersprache eine große Rolle spielt, macht Motivationen menschlichen Handelns ebenso sichtbar wie psychologische Muster. Es ist eine Möglichkeit, miteinander zu kommunizieren und auch Emotionen zum Ausdruck zu bringen. Dabei darf gern viel gelacht werden, denn Rumalbern befreit – eine gute Ausgangslage, um Dinge anders anzugehen.
