Scrum ist unter den agilen Projektmanagement-Methoden – verzeih’ mein Französisch – der heiße Scheiß!

Laut einer Studie von 2022 nutzen über 80 % aller agilen Teams entweder Scrum oder eine Hybrid-Variante. Hauptgrund für zwei Drittel der Befragten: Projekte werden einfach schneller fertig. Produkte können schneller eingeführt werden, die Qualität steigt, das Projektrisiko sinkt.

Erstes Fazit: Der Nutzen von Scrum für dich und dein Team übersteigt den Aufwand der Implementierung erheblich!

Höchste Zeit, diesen Effekt zu nutzen; nur wie ist die Frage?

Die Antwort liefert dir mein ultimativer Scrum-Guide. Als Experte für Projektmanagement und PM-Software von trusted zeige ich dir hier alles, was es über Scrum zu wissen gibt – von der Zusammenstellung deines Projektteams, über das Aufsetzen von Backlogs und To-dos, über die berüchtigten “Sprints” bis hin zum (erfolgreichen) Projektabschluss. Plus aussagekräftige Beispiele und praktische Tipps.

Startklar? Dann auf in die Scrum-Schlacht!

Definition: Was ist Scrum?

Scrum ist eine Projektmanagement-Methode, mit der komplexe Projekte schnell und günstig umgesetzt werden sollen.

Wichtige Eckpfeiler dafür sind:

• kurze Planungs- und Projektzyklen (“Sprints”, maximal 4 Wochen)
• kleine Teams (max. 10 Personen, mit “Product Owner”, “Scrum Master” und “Team”)
• der tägliche Austausch (“Daily Scrum”)
• und flexibles Reagieren auf geänderte Anforderungen.

Anstatt Projekte von Anfang an voll bis zum Ende durchzuplanen, setzt Scrum auf ständige Anpassung (Iteration). Wichtig ist nicht die Planung, sondern das fertige Projekt. Zum Beispiel ein Produkt, eine Software oder App, eine Marketing-Strategie, etc.

Die Scrum Methode im Schema

Quelle: trusted.de

Aber aufgepasst! Scrum ist keine exakte Wissenschaft, sondern eher ein Framework. Du kannst dich daran orientieren; aber es wird dir nichts bringen, wenn dein Team nicht zu 100% dahinter steht und die Werte verinnerlicht, die für agiles Projektmanagement wichtig sind:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
2. Funktionierende Projekte sind wichtiger als eine umfassende Dokumentation
3. Zusammenarbeit mit Kund:innen/dem Management ist wichtiger als Verhandlungen
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Oder anders gesagt: Schneller, effizienter, flexibler und viel weniger Bullshit.

Klingt grundsätzlich gut für dich? Perfekt! Mein Ratgeber soll dir helfen, herauszufinden, ob Scrum dir und deinem Team helfen kann, Projekte schneller, effizienter und günstiger umzusetzen. Als Leitfaden und Schritt-für-Schritt-Anleitung zeigt er dir alles, was du brauchst, um Scrum erfolgreich einzuführen.

Unnützes Wissen: Der Begriff “Scrum” kommt eigentlich aus dem Rugby und bedeutet “Gedränge”. In einem “Scrum” prallen Spieler:innen beider Mannschaften aufeinander und müssen durch kluges Teamwork den Ball an sich bringen. Auch beim Rugby müssen Teams flexibel auf Veränderungen reagieren. Und genau wie beim Rugby ist Scrum auch im Management eine Frage von Training und Teamgeist.

Wann ist Scrum für mich geeignet?

Scrum kommt oft – aber nicht nur – in der Produkt- und Softwareentwicklung zum Einsatz.

Scrum ist für dich geeignet, wenn dein Team oft auf wechselnde Marktbedingungen, neue Technologien und viele Wettbewerber reagieren muss. Wenn dein Team komplexe Problemstellungen schnell, günstig und selbstorganisiert lösen will – oder wenn langwierige Entscheidungsprozesse und festgefahren Strukturen deinen Projekterfolg hemmen – kann Scrum die Lösung sein!

Super beliebt ist Scrum zum Beispiel in diesen Branchen:

• IT
• Software- und App-Entwicklung
• Produktentwicklung
• Consulting
• Agiles Marketing
• Automobilbranche
• Medizintechnik
• Kreativagenturen

bzw. für diese Art von Projekten:

• Innovationsprojekte
• Software oder Produkte
• Webdesign
• Marketing-Strategien
• Erschließung neuer Geschäftsfelder
• Kundenorientierte Projekte
• Dringende Projekte mit einer gewissen Komplexität

Grundsätzlich gilt: Scrum hat zwar seinen Ursprung in Software-Entwicklungsteams, kann aber so gut wie überall zum Einsatz kommen, wo es komplexe Problemstellungen gibt.

Wann ist Scrum nicht für mich geeignet?

Wenn dein Projekt ein hohes Maß an Genauigkeit und Wiederholbarkeit verlangt, ist Scrum definitiv der falsche Weg. Auch Arbeiten, die ad-hoc erledigt werden müssen, lassen sich nicht scrummen.

Zwei Beispiele dafür:

Die Industrieproduktion und das produzierende Gewerbe haben mit Scrum wenig am Hut. Hier gibt es bestimmte Produktionsprozesse, die sich bewährt haben und immer nach dem gleichen Muster ablaufen. Eine gleichbleibende Qualität ist essenziell; Iteration im großen Stil sind erstens fehl am Platz und zweitens zu teuer.

Ein großer Hersteller von Reifen z.B. wird in der Produktion niemals mit Scrum arbeiten – sein Design-Team aber ggf. schon!

Zweites Beispiel ist der Service- und Dienstleistungssektor. Auch da gibt es bewährte Prozesse. Vor allem müssen Service-Teams jeden Tag ad-hoc auf Anfragen und Anforderungen reagieren, während Scrum in zwar kurzen, aber fixen Zyklen abläuft. Dein IT-Support-Team kann dem Kunden nicht sagen, dass es sich gerne im nächsten Scrum-Zyklus in 2 Wochen um den Serverausfall kümmert. Das muss sofort passieren!

Kurz und knapp: Scrum eignet sich für komplexe, aber nicht für komplizierte Prozesse; da sind dann eher klassische Projektmanagement-Methoden das Werkzeug der Wahl.

Wie führe ich Scrum ein? Der Scrum-Prozess in 7 Schritten

So, nachdem wir das geklärt haben: Lass uns einmal gemeinsam anschauen, wie Scrum im Detail funktioniert und wie du die Methode in deinem Team einführen kannst.

Keine Sorge, wir gehen Schritt für Schritt vor und ich zeige dir alles an einem einfachen Beispiel. Dafür habe ich mir ein fiktives Projekt überlegt, zu dem Scrum als Methode super passt:

Auftritt: trusted Webdesignz. Das Start-up entwickelt und betreut die Internetauftritte von Unternehmen und hat sich auf Online-Shops spezialisiert. Ein Kunde ist der Shop Anime24, ein Versandhändler für Comics, Animes und Merchandise. Anime24 wünscht sich neue Komfortfunktionen für den Shop; z.B. neue Warenkorb-Features, Produktvorschläge und Aktionen wie Rabatte und Co. Das Team von trusted Webdesignz macht sich an die Arbeit!

Ein solches Projekt würde in Scrum grob in 7 Schritten ablaufen:

Danach geht alles wieder von vorne los, mit dem nächsten Sprint. Im Grunde in simpler Prozess – der aber auch einige Stolpersteine und Tücken birgt und nach mehr oder weniger festen Regeln abläuft.

Bereit, selbst damit durchzustarten?

Damit du einen Einblick bekommst, zeige ich dir im Folgenden die Projektplanung in Scrum anhand des obigen Beispielprojekts, das ich für meinen Guide in unserem PM-Tool monday angelegt habe. monday eignet sich aufgrund seiner Flexibilität prima für die Arbeit mit Scrum; es gibt aber noch viele andere sehr gute Tools, die ich dir später noch im Detail vorstelle.

1. Team zusammenstellen und Rollen verteilen

Als Erstes musst du dein Projektteam zusammenstellen. Ein “klassisches” Scrum-Team besteht aus nicht mehr als 10 Personen mit festen Rollen:

• 1 Product Owner
• 1 Scrum Master
• 3 - 8 Developer (Entwickler:innen)

Also: ein Mitglied ist für die Vision des fertigen Produkts verantwortlich, eines für die Scrum-Prozesse und der Rest des Teams für die operative Projektarbeit.

Die Rollen in einem Scrum-Team im Überblick

Quelle: trusted.de

In unserem Beispiel besteht das Team aus 5 Personen: Robert als Product Owner, Naomi als Scrum Master und Steve, Mattis und Wiebke als Developer. Ich stelle sie dir unten näher vor.

Das ist die erste wichtige Hürde im Scrum-Prozess: Scrum kann nur funktionieren, wenn alle Mitglieder des Teams ihre Rolle kennen und ausfüllen. Überschneiden sich Aufgabenbereiche, führt das fast immer zu Missverständnissen und Chaos. Darum ist die feste Rollenverteilung in Scrum so wichtig!

Schauen wir uns die Rollen im Detail an:

Product Owner

Der Product Owner (oder Produkteigentümer:in) ist quasi der Produktmanager.

Er ist verantwortlich für die Entwicklung und den wirtschaftlichen Erfolg des Projekts. Und er tauscht sich mit den “Stakeholdern” aus. Das sind Kund:innen, Auftraggeber:innen oder auch die Geschäftsleitung – also diejenigen, die das Projekt angestoßen haben.

In kleinen Teams kann es sein, dass Stakeholder und Product Owner ein und dieselbe Person sind. In den meisten projektbasierten Teams (Agenturen und Co.) sind die Stakeholder aber eher “Externe”, also eben Kund:innen.

Der Product Owner nimmt die Anforderungen der Auftraggeber:innen mit ins Team, ist für die Erstellung des Product Backlogs zuständig und verteilt die Aufgaben.

In unserem Beispiel übernimmt Robert als Geschäftsführer von trusted Webdesignz die Rolle des Product Owners. Er steht im engen Austausch mit den Auftraggeber:innen von Anime24 und hat von ihnen den Auftrag zum Website-Relaunch bekommen, mit allen Wunschfunktionen und Anpassungen. Jetzt stellt er dafür sein Team zusammen.

Die konkreten Aufgaben des Product Owners sind:

Wichtig: Der Product Owner ist immer eine Einzelperson und niemals ein Gremium oder eine Gruppe!

Scrum Master

Scrum Master sind nichts anderes als Projektmanager:innen. Sie sind zugleich Coaches, Moderator:innen und Planer:innen. Scrum Master …

• … planen und kommunizieren alle Meeting-Termine (wie Sprint-Planung, Daily Scrums, Reviews, Retrospectives und Co.; siehe unten)
• … sorgen dafür, dass alle im Team ihre Rolle einhalten (und sich keiner als Chef aufspielt)
• … kümmern sich darum, dass die Prinzipien agilen Arbeitens und die Werte von Scrum (siehe unten) verstanden und gelebt werden.

Bei Problemen im Team vermittelt der Scrum Master zwischen den Gruppen. Er begleitet das Team durch Meetings und ist die zentrale Anlaufstelle für Prozessfragen.

Wohlgemerkt: Nicht zu Fragen, die direkt die Projektinhalte betreffen! Denn dafür gibt es ja den Product Owner.

Im fiktiven Projekt-Team von trusted Webdesignz übernimmt Naomi als Kommunikationstalent und Kundenservice-Expertin diesen Posten. Sie hat bereits mit Scrum gearbeitet und ihre Kompetenzen sind in der eigentlichen Projektarbeit nicht gefragt, sodass sie den Posten des Scrum-Masters gut ausfüllen kann. Am Anfang des Projekts verschafft sie sich einen Überblick und plant den Termin für den ersten Sprint.

Die Aufgaben des Scrum Masters im Überblick:

Oder kurz: Alles, was mit Prozessen und Abläufen zu tun hat, liegt in der Verantwortung des Scrum Masters. An der eigentlichen Projektarbeit ist der Scrum Master nicht bzw. kaum beteiligt.

Es ist wichtig, den Unterschied zwischen Scrum Master und Product Owner zu verstehen. Beide haben eine “leitende” Funktion, aber ihre Aufgabenbereiche sind grundverschieden. Einfach gesagt: Während du den Product Owner fragen würdest: “Was sind die Ziele des aktuellen Sprints?”, würdest du den Scrum Master fragen: “Wie lange dauert der aktuelle Sprint noch?”. Inhalte vs. Prozesse. Soweit klar?

Team/Developer

Die Developer oder “Entwickler:innen” sind schließlich der Kern eines Scrum-Teams. Sie kümmern sich um die operative Arbeit und “schrauben” am Projekt.

Obwohl sie “Entwickler:innen” heißen, müssen sie nicht zwangsläufig etwas mit Software am Hut haben. Auch Mitarbeiter:innen aus dem Marketing, dem Design oder aus anderen Bereichen gehören in ein Scrum-Team – sofern ihre Kompetenzen für den Projekterfolg gebraucht werden.

In unserem Beispiel übernehmen die beiden Entwickler:innen Steve und Mattis sowie die Grafikerin Wiebke die Rolle der Developer. Sie werden dafür zuständig sein, die neuen Features für den Online-Shop zu programmieren und ggf. Anpassungen am Design der Page vorzunehmen, wo nötig. Sie arbeiten also direkt am Projekt.

Ein Scrum-Team ist immer unabhängig und selbstorganisiert!

Input und Beratung von außen sind zwar nicht unerwünscht – sollten aber nicht Voraussetzung für eine erfolgreiche Projektarbeit sein.

Eine mehr oder weniger lose Regel: Bei der Auswahl eines Scrum-Teams sind Teammitglieder mit breitgefächerten Kenntnissen Spezialist:innen vorzuziehen. Wer zu stark spezialisiert ist, kann nur in seinem Bereich etwas beitragen. Aber das ist natürlich von Projekt zu Projekt unterschiedlich und oft ist Spezialwissen ja auch nötig. Dann muss bei der Teamzusammenstellung geschaut werden, wie man dieses Wissen einbringt.

2. Projektanforderungen definieren und Product Backlog anlegen

Das Product-Backlog ist eine Liste mit allen Punkten, die für das Projekt erfüllt sein müssen.

Sehr vereinfacht gesagt, kannst du dir das Product Backlog wie eine Art Must-have-Liste vorstellen. Hier stehen also alle Anforderungen, die das Management oder deine Kund:innen an das fertige Produkt, die Software oder App oder ganze einfach den Outcome des Projekts setzen.

Jede dieser Anforderungen ist ein “Item” im Product Backlog. Das kann vielleicht ein Feature sein, das die Software unbedingt haben soll.

Alles, was im Product Backlog steht, ist wichtig. Aber einige “Items” sind wichtiger als andere. Gewisse “must haves” sind nicht verhandelbar, bei einigen “nice to haves” hast du mehr Spielraum. Relevant ist nur, dass das Product Backlog definiert, wann das Projekt abgeschlossen ist – nämlich, wenn alle Anforderungen erfüllt sind und die Stakeholder mit dem Outcome zufrieden sind.

Schauen wir uns das im Detail an:

Wer erstellt das Product Backlog? Grundsätzlich fällt das Product Backlog in die Zuständigkeit des Product Owners. In Abstimmung mit den Stakeholdern definiert er, welche Items im Product Backlog stehen und welche Priorität sie haben. Bei Bedarf kann der Product Owner aber Teile des Teams zur Beratung hinzuziehen – z.B. bei technischen Fragen, die eine weitere Einschätzung benötigen.

Was steht im Product Backlog? Ein Product Backlog ist eine priorisierte Liste von Anforderungen, die das Projektergebnis erfüllen muss. Jeder Eintrag im Product Backlog steht also für eine zu erfüllende Anforderung. Wie diese genau hinterlegt wird, ist dir überlassen. Es kann bereits eine konkrete Aufgabe sein, oder ein grober Wunsch der Stakeholder. Wichtig ist nur, dass das Entwicklerteam alle “Items” verstehen und umsetzen kann.

Bezogen auf unser Beispiel könnte ein Product Backlog Item also beispielsweise ein neues Warenkorb-Feature sein, das es Shop-Besucher:innen ermöglicht, gefundene Artikel zunächst abzuspeichern. Aufgabe des Teams ist es dann, im Sprint Planning eine eigene Schätzung abzugeben, wie viel Aufwand die Umsetzung des Items erfordert. Was ein Sprint Planning genau ist und wie es abläuft, erfährst du im nächsten Schritt.

Was ist das Ergebnis? Eine klare Vision des fertigen Produkts bzw. des Projekt-Outcomes. So gesehen eine Liste von Anforderungen, die erfüllt werden müssen, priorisiert von oben nach unten. Ganz oben stehen die wichtigsten “must haves”, weiter unten die Punkte, die ggf. noch verhandelbar sind. Ziel: Das Team muss durch einen einzigen Blick auf das Product Backlog verstehen, wie das Ergebnis aussehen soll.

In unserem Beispiel-Projekt ist der Relaunch eines Onlineshops für den Anbieter Anime24 geplant. Ziel des Projektes ist die Implementierung der erwähnten Warenkorb-Features und neuer Komfortfunktionen für Kund:innen. Dazu gehören hinterlegte Zahlungsdaten, Express- sowie Gast-Checkouts und Userprofile. Weil die Warenkorbfunktion die wichtigste Neuerung darstellt, steht sie ganz oben im Produkt Backlog. Danach folgen die Zahlungsdaten, während der Gast-Checkout nur eine nachgeordnete Priorität hat und ganz zum Schluss umgesetzt werden soll.

Wie ein Product Backlog für unser konkretes Beispiel aussehen könnte, siehst du hier:

So könnte das Product Backlog für die Überarbeitung eines Onlineshops aussehen

Screenshot: trusted.de

Quelle: monday.com

Können Einträge im Product Backlog geändert werden? Ja. Das Product Backlog ist “lebendig” und kann jederzeit durch den Product Owner angepasst werden. Wichtig ist, dass die Veränderungen verständlich und transparent sind. Außerdem kann der Product Owner die Priorisierung einzelner Items verändern, beispielsweise wenn die Stakeholder ein entsprechendes Feedback geben.

Es kann immer vorkommen, dass sich die Anforderungen an ein Produkt verändern, hier muss dann der Product Owner natürlich entsprechend reagieren. Das Product Backlog bietet diesen Spielraum.

Ist das Product Backlog fertig, kann es mit der Projektarbeit losgehen. Der erste “Sprint” wird geplant!

Vorher aber noch kurz ein paar wichtige Begriffe im Zusammenhang mit dem Product Backlog:

3. Sprint Planning durchführen

Im Sprint Planning legt das Team fest, welche Anforderungen des Product Backlogs im nächsten “Sprint” – also in den nächsten 1 bis 4 Wochen – erledigt werden sollen. Dabei legst du im Meeting mit dem Team konkrete Ziele fest und definierst, wie diese Ziele erreicht werden können. Digital oder persönlich ist dabei eigentlich egal. Wichtig ist nur, dass alle Projektbeteiligten am Start sind.

Das Ergebnis der Planung ist das Sprint Backlog; eine To-do-Liste für die nächsten Schritte.

Das klingt komplexer, als es eigentlich ist. Schauen wir uns mal an, wie so eine Sprint-Planung konkret abläuft:

Wer ist beteiligt? Alle; das heißt: der Product Owner, der Scrum Master und alle Mitglieder des Development-Teams. Der Product Owner definiert das gewünschte Ergebnis des nächsten Sprints, das Team diskutiert die dazu nötigen Aufgaben und der Scrum Master hält alles in geordneten Bahnen.

Was wird geplant? Für den Sprint nimmst du dir die Punkte aus dem Product Backlog vor, die du in den nächsten 1 bis 4 Wochen mit deinem Team erreichen willst bzw. erreichen kannst. Das kann ein konkretes Teilergebnis des Projekts sein; es können aber auch Aufgaben sein, die vorbereitend für spätere Tasks erledigt werden müssen.

Während des Sprints arbeitet das Projektteam nur an diesen Tasks, nicht an anderen Punkten des Product Backlogs. Deswegen sind Sprints auch so kurz angelegt; meistens sind es 2 Wochen. Das erlaubt es deinem Team, mit “Laser Focus” an den Zielen zu arbeiten.

In der ersten Sprint-Planung eines neuen Projekts geht es auch darum, dem Team das fertige Product Backlog vorzustellen und sie auf die “Vision” des fertigen Projekts einzuschwören.

Wie wird geplant? Im Grunde ist eine Sprint-Planung eine Verhandlung. Der Product Owner kann zwar – auf Basis des Product Backlog – vorgeben, welches Ziel erreicht werden soll. Aber letztlich muss das Team beurteilen, ob das Ziel realistisch ist und was dafür nötig ist. Dabei kann (und soll) jedes Teammitglied Input geben. Auch die Ergebnisse des letzten Sprints und das bisherige Feedback der Stakeholder sind wichtig!

Bei der Planung von Zielen hältst du dich am besten an die SMART-Regel. Das heißt, deine einzelnen Ziele sind “specific” (spezifisch), “measurable” (messbar), “achievable” (erreichbar), “relevant” und “time-bound” – also zeitlich umrissen, mit klaren Deadlines.

Eine meiner Lieblingsmethoden für die Sprint-Planung ist das “Planning Poker”. Das zeige ich dir später noch im Detail, aber im Grunde läuft das so, dass alle im Team unabhängig voneinander einschätzen, wie schwierig eine Aufgabe umzusetzen ist. Das kann helfen, Diskussionen in Gang zu bringen und Input aus dem Team “herauszukitzeln”. Oder mögliche Stolpersteine zu erkennen. So etwas zu nutzen ist aber kein Muss.

Was ist das Ergebnis? Der fertige Sprint Backlog enthält die Aufgaben und Ziele der kommenden Wochen und ist die Basis für das Scrum-Board. Ab jetzt kann dein Team anfangen, am Projekt zu arbeiten.

Ergebnisse und Probleme während des Sprints werden festgehalten und am Ende in der Sprint Review (siehe unten) diskutiert. So kannst du, wenn dein Team während des Sprints auf Probleme stößt, im nächsten Sprint darauf reagieren. Oder hast (wenn alles glattläuft) ein Teilergebnis, das du an deine Stakeholder kommunizieren kannst.

Wie sieht ein Sprint Backlog aus? Ein Sprint Backlog kann so ziemlich alles sein; handschriftliche Notizen, ein Word-Dokument, eine Mindmap oder ein Whiteboard. Für die bessere Übersicht sollte der Scrum Master das Backlog nach der Planung trotzdem in eine saubere Form gießen. Dafür kann eine Excel-Tabelle herhalten; noch besser ist ein Projektmanagement-Tool mit Kanban-Board.

Immer noch zu abstrakt? Kein Problem; hier mal ein beispielhaftes Sprint Backlog, wie wir es für unser Beispiel-Projekt “Website-Relaunch” hätten anlegen können:

Für den ersten Sprint bei trusted Webdesignz stet das Warenkorb-Feature im Vordergrund. Die Anforderungen sind klar und stammen aus dem Product Backlog: Kund:innen von Anime24 sollen in Zukunft einzelne Artikel dem Warenkorb hinzufügen und wieder entnehmen können. Das erfordert ein passendes Design für die Checkout-Seiten, die Planung der Datenbank-Tabelle, die Entwicklung des nötigen Codes, die Implementierung und eine Testphase des neuen Features. All diese Tasks bilden zusammen den Sprint Backlog des ersten Sprints.

Ein wichtiger Begriff, den du im Zusammenhang mit den Sprints kennen solltest:

4. Aufgaben verteilen und Scrum-Board aufsetzen

Das Scrum-Board (oder Scrum-Taskboard) ist eines der wichtigsten Instrumente des Scrum-Teams. Es gibt Auskunft über den aktuellen Stand eines Sprints und listet alle Sprint-Backlogs nach Arbeitsstand und Status.

In der ersten Spalte stehen die User Storys, also konkrete Anforderungen an das Produkt, aus denen Aufgaben für das Entwicklerteam abgeleitet werden. Diese To-dos stehen in der zweiten Spalte und werden (analog zu Kanban-Boards) je nach Status weiter nach rechts verschoben:

• In Planung (To do)
• In Arbeit (Doing)
• Im Test (Verify)
• Abgeschlossen (Done)

Erst, nachdem ein Task getestet bzw. geprüft oder abgesegnet wurde, landet er in der Spalte “done” – und gilt damit als abgeschlossen.

Wichtig: Jedes Scrum-Team muss den Status “done” exakt definieren. Ziel sollte es sein, dass jede erledigte Aufgabe als Teilprodukt (oder “Increment”) den Stakeholdern präsentiert und ausgeliefert werden kann. Das bedeutet: Jedes “Increment” soll voll einsatzfähig und kundentauglich sein.

Wie ein Scrum-Board für unser Beispielprojekt aussehen könnte, siehst du hier:

So könnte ein Sprint Backlog für unser Beispiel-Projekt aussehen

Screenshot: trusted.de

Quelle: monday.com

Im Beispiel siehst du die Userstory “Artikel im Warenkorb hinterlegen”. In der Sprint-Planung wurden für diese Anforderung schon alle nötigen Tasks geplant, die nun als einzelne “Tickets” oder “Karten” auf dem Board verteilt werden. Gleichzeitig wird definiert, wer für welche Aufgabe zuständig ist. So sehen alle im Team, wo die Verantwortlichkeiten liegen und was jeder einzelne zu tun hat.

Übrigens: Viele Scrum-Teams arbeiten mit einer Art “Informationszentrale”. Das kann beispielsweise ein Meetingraum sein, der genügend Platz für Whiteboards und Pinnwände bietet. Hier lassen sich dann problemlos Mindmaps und Scrum-Boards aufstellen und anpinnen. Jedes Teammitglied kann sich selbstständig auf einen Blick informieren.

Diese Infozentrale lässt sich natürlich auch durch eine digitale PM-Software aufsetzen, was sich für Remote-Teams besser eignet und platzsparender ist. Hier hat jedes Team seine ganz eigenen Ansprüche und Vorlieben.

Ein paar wichtige Begriffe, die du zum Kanban-Board kennen solltest:

Ist das Scrum-Board aufgesetzt, geht es an die Projektarbeit. Das heißt: Jetzt endlich verlässt das Team die graue Theorie und macht sich an die Arbeit, die geplanten Aufgaben umzusetzen. Der Sprint beginnt. Innerhalb der nächsten Wochen wird das Team fokussiert an den geplanten Tasks arbeiten und sich in “Daily Scrums” regelmäßig dazu austauschen.

5. Tägliche Abstimmung im Daily Scrum

Wie der Name schon verrät, ist der Daily Scrum ein täglich stattfindendes Meeting des Scrum-Teams. Es dient der Team-Synchronisation, dem allgemeinen Austausch und der Koordination von Aufgaben.

Wer nimmt am Daily Scrum teil? Am Meeting nehmen das gesamte Developer-Team und der Scrum Master teil. Je nach Möglichkeit und Bedarf kann auch der Product Owner hinzugezogen werden – er muss aber nicht täglich erscheinen.

Was wird besprochen? Der Daily Scrum funktioniert wie eine tägliche Besprechung der anstehenden Aufgaben. Aktuelle Fortschritte können so verfolgt und etwaige Probleme frühzeitig erkannt werden. So kann jedes Teammitglied seine Arbeit mit dem gesamten Team abstimmen und ist auf dem aktuellen Stand. Insgesamt soll das tägliche Meeting die Selbstorganisation des Teams stärken und die Zusammenarbeit verbessern.

Während der Daily Scrums können z.B. Tasks im Scrum Board verschoben werden. Außerdem kannst du hier in deinem Team Probleme besprechen, die während der Projektarbeit aufgetreten sind. Wenn sich ein Task verzögert, mehr Ressourcen verbraucht, als vorgesehen oder komplett blockiert wird, hat das ganze Team die Probleme auf dem Schirm. Es kann sie dann ausräumen oder auf die Agenda für den nächsten Sprint setzen.

Wie lange dauert ein Daily Scrum? Die vorgesehene Timebox für das Daily Scrum liegt bei 15 Minuten und sollte die angesetzte Zeit nicht überschreiten.

Im ersten Daily Scrum sind Steve, Mattis und Wiebke anwesend, um die anstehenden Aufgaben zu besprechen und sich abzustimmen. Naomi moderiert das Meeting. Steve und Mattis sind mit ihren Aufgaben on track; sie sind gut gelaunt und scherzen. Naomi ruft die beiden höflich zur Ordnung, damit auch Wiebke ihre Ergebnisse noch teilen kann, ohne die Timebox zu sprengen. Tatsächlich hat Wiebke ein Problem. Ihr Mockup der Checkout-Page dauert länger, als geplant, da eine Anforderung an das Design unklar formuliert war. Das könnte Steve und Mattis später im Sprint in ihren Aufgaben blockieren; noch ist das Sprintziel aber nicht ernsthaft gefährdet. Nach 15 Minuten endet das Meeting und das Team macht sich wieder an die Arbeit. Naomi wird sich nun mit dem Product Owner Robert abstimmen und ihn zum nächsten Daily Scrum einladen, damit er sich einen Überblick verschaffen kann. Er wird dann ggf. die Anforderungen im Backlog präzisieren – oder im Zweifel noch einmal Rücksprache mit Anime24 halten.

6. Ergebnisse im Sprint Review prüfen

Am Ende eines Sprints – also nach 1 bis 4 Wochen Arbeit – endet der Sprint und die Sprint Review findet statt.

Im Grunde ist das eine Abnahme für alles, was während des Sprints passiert ist. Die Developer stellen ihre Ergebnisse dem Product Owner vor, der sie begutachtet und anhand der Anforderungen überprüft.

Wie läuft das konkret ab?

Wer ist bei der Sprint Review dabei? Auch hier ist wieder das gesamte Team anwesend, damit sich alle zu den Ergebnissen austauschen können. Stakeholder müssen nicht unbedingt dabei sein; im Sinne der Kundenzufriedenheit und Transparenz sind sie aber stets willkommen und werden bei Bedarf vom Product Owner rechtzeitig eingeladen.

Was wird in der Sprint Review besprochen? Hier werden nur Ergebnisse vorgestellt und Feedback eingeholt – vom Product Owner und/oder von den Stakeholdern. Sollten die Ergebnisse nicht den Anforderungen entsprechen, bekommt das Team eine entsprechende Rückmeldung und kann im nächsten Sprint die Fehler beseitigen oder Korrekturen vornehmen.

Diese kurze Iteration ist der große Vorteil von Scrum, denn: Durch die kurzen Zyklen und die ständige Möglichkeit zur Anpassung ist ein Projekt niemals in Gänze in Gefahr. Das ständige Hamsterrad aus Entwicklung, Prüfung und Abnahme ermöglicht es deinem Team, blitzschnell auf neue Bedingungen zu reagieren.

Die Sprint Review kann – muss aber nicht – den Abschluss eines Projekts markieren. Wenn alle Items des Backlogs umgesetzt wurden und das Ergebnis den Anforderungen entspricht, ist das Projekt an dieser Stelle abgeschlossen. Die Stakeholder erhalten den Outcome, dein Team kann sich auf das nächste Projekt stürzen.

Falls noch nicht alle Anforderungen umgesetzt wurden, folgt nach dem ersten der zweite Sprint und dann der dritte und vierte … solange, bis das Projektergebnis alle Anforderungen erfüllt.

In unserem Beispiel:

Das fertige und intern bereits geprüfte Warenkorb-Feature wird während der Sprint-Review dem Product Owner Robert vorgestellt. Auch Ayla, eine Vertreterin von Anime24, ist mit dabei, um sich die Funktion vorführen zu lassen und sich die neue Checkout-Page anzuschauen. Alles läuft glatt; das neue Feature funktioniert und kann ausgespielt werden. Ayla macht noch ein paar Verbesserungsvorschläge am Aufbau und der Farbgebung der neuen Page, die das Team in den nächsten Sprint mitnehmen kann. Wiebke wird sich dann um die nötigen Änderungen kümmern.

Du siehst, Scrum funktioniert nur dank ständiger Kommunikation, Transparenz und Anpassungsfähigkeit. Das Ende eines Sprints markiert immer den Anfang des nächsten und alle Erfahrungen des ersten Zyklus gehen in den zweiten ein. Eigentlich easy, oder?

Bevor du allerdings komplett die Waffen niederlegen kannst, gibt es noch einen fixen Termin, den du beachten solltest: Die Sprint Retrospective.

7. Prozesse durch die Sprint Retrospective optimieren

Nach der Sprint Review folgt die “Sprint Retrospective”. Auch das ist ein festes Meeting in jedem Scrum-Prozess und quasi eine Art “Nachbesprechung”; gleichzeitig aber auch der Startschuss für den nächsten Sprint. Sprint Retrospective und Sprint Planning werden deshalb oft auch direkt “hintereinander” geplant.

Aber halt, wirst du jetzt sagen: Ein zweites Meetings für den Abschluss? Hätte nicht auch eines gereicht?

Schauen wir’s uns an:

Wer ist an der Sprint Retrospective beteiligt? Hier kommen das Entwicklerteam und der Scrum Master zusammen und besprechen den Ablauf des letzten Sprints. Der Product Owner und die Stakeholder sind (in der Regel) nicht mit dabei – was schon einmal einen Unterschied zur “Sprint Review” markiert. Denn hier geht es primär um die Arbeit der Developer. Der Scrum Master leitet und moderiert das Ganze.

Was wird in der Retrospective besprochen? Das Team bespricht den letzten Sprint, besondere Vorkommnisse und positive sowie negative Aspekte der Projektarbeit. Während die Sprint Review also vor allem den Outcome des Projekts an sich im Blick hat, geht es in der Retrospective primär um die Verbesserung von Prozessen, Abläufen und Kommunikation.

Was ist das Ergebnis der Retrospective? Ziel soll es sein, Probleme zu ermitteln und den kommenden Sprint anhand der gewonnenen Erkenntnisse zu optimieren.

Im ersten Sprint gab es einige Erkenntnisse, die für die Planung des nächsten Sprints ausschlaggebend sein könnten. In einem der späteren Dailys hat sich herausgestellt, dass Steve und Mattis sich trotz Scrum-Board nicht richtig abgestimmt hatten, und parallel an der gleichen Aufgabe gearbeitet haben. Das Feature konnte zwar umgesetzt werden; trotzdem hat die Doppelbearbeitung Zeit gekostet. Unter anderen Bedingungen hätte das die Gefährdung des Sprint-Ziels bedeutet. Naomi erinnert die beiden daran, das Board als Instrument ernstzunehmen und zu nutzen und zeigt ihnen noch einmal, wie sie Verantwortlichkeiten im Board einstellen können. So hat das Team für den nächsten Sprint eine wertvolle Lektion gelernt. Alle gehen voller Elan in die weitere Planung.

So; jetzt weißt du, wie die Planung eines Scrum-Zyklus funktioniert und wie du Projekte in deinem Team mit Scrum planen kannst.

Eigentlich hättest du damit schon alles, um loszulegen. Trotzdem solltest du hier noch nicht Schluss machen, denn ich habe noch einige coole Tipps und Hintergrundinfos für dich, die dir auf deiner Scrum-Reise mit Sicherheit nützlich sein werden:

Was brauche ich für Scrum? Wichtige Werkzeuge und Hilfsmittel

Das passende Projektmanagement-Tool

Nicht unbedingt essenziell, aber super hilfreich für Scrum ist eine smarte PM-Software.

Die hilft dir, eine digitale Einsatzzentrale für dein Team zu schaffen und ist in der Regel bequemer, als analoge Whiteboards. Außerdem ist es vor allem für Remote-Teams – die nicht einfach “eben schnell einen Blick an die Bürowand werfen können” – toll, um über alles auf dem Laufenden zu bleiben.

monday ist flexibel einsetzbar und eignet sich optimal für agile und hybride Teams

Screenshot: trusted.de

Quelle: monday.com

Der Scrum-Prozess fällt in das Themengebiet “Agiles Projektmanagement” und benötigt besondere Funktionen und Tools, die in klassischen PM-Lösungen nicht oder nur teilweise vorhanden sind.

Daher ist es wichtig, ein Tool zu finden, das alle für Scrum wichtigen Eigenschaften mitbringt – zum Beispiel die Möglichkeit, ein Scrum-Board aufzusetzen, Aufgaben zu planen und zuzuweisen, Kommentare zu hinterlassen oder Ergebnisse in Dokumenten festzuhalten.

Ein paar meiner persönlichen Favoriten für den Scrum-Prozess habe ich dir hier einmal übersichtlich aufgelistet:

monday.com

Zum Anbieter

monday.com ist ein großartiges Tool für agiles Projektmanagement und zu Recht Sieger im aktuellen trusted-Test. Ein Vorteil von monday.com ist der flexible Einsatz im Projekt-, Aufgaben- und Workload-Management. Zusätzlich musst du dich nicht sklavisch an Scrum halten, weil monday.com auch klassische bzw. hybride PM-Praktiken unterstützt. In monday ist auch unser Beispielprojekt entstanden!

Asana

Zum Profil

Asana ähnelt in vielen Belangen monday.com und ist ähnlich vielfältig einsetzbar. In Sachen Bedienung und Benutzerfreundlichkeit ist Asana sogar die etwas dankbare Lösung und benötigt nur eine geringe Einarbeitungszeit. Außerdem glänzt Asana mit zahlreichen, sehr einfach zu nutzenden Automatisierungen.

awork

Zum Anbieter

awork ist eine PM-Lösung aus Deutschland und zeichnet sich neben der modernen Optik durch eine hohe Benutzerfreundlichkeit aus. Kleine Lücken hat das Tool lediglich im Bereich der Ressourcenplanung. Im Vergleich zu monday.com ist Awork die etwas schlankere Lösung, für kleine Teams aber definitiv eine gute Wahl.

MeisterTask

Zum Anbieter

MeisterTask stammt ebenso wie Awork aus Deutschland und hat seine große Stärke im agilen Aufgabenmanagement. Außerdem glänzt MeisterTask durch sein modernes und übersichtliches Design: Hier finden sich neue User sofort zurecht. Lediglich im Multiprojektmanagement zeigt die Anwendung Schwächen. Kleine und mittlere Teams finden in MeisterTask eine vielseitige Lösung für hybrides oder agiles Projektmanagement.

Jira

Zum Profil

Jira stammt ursprünglich aus der Software-Entwicklung und bringt einen vergleichsweise großen Funktionsumfang mit. Das erhöht natürlich die Einarbeitungszeit, bietet Usern aber auch zahlreiche Möglichkeiten für den Einsatz.

Wenn du dich ausführlich über passende Software informieren möchtest, findest du im trusted-Test der besten Projektmanagement-Software weitere nützliche Informationen.

Die 3 Artefakte von Scrum

Zu den wichtigsten Werkzeugen für jedes Scrum-Team gehören auch die 3 “Artefakte” von Scrum: Das Product Backlog, Sprint Backlog und das Product Increment.

Die habe ich dir oben schon “in der Praxis” vorgestellt; hier gebe ich dir noch einmal eine kleine Zusammenfassung und alle wichtigen Infos:

Weitere Werkzeuge für den Scrum-Prozess

Weitere Werkzeuge, Methoden und Tools, die dich beim “Scrummen” unterstützen können, zeige ich dir hier:

Planning Poker

Ich hatte es oben schon einmal kurz angesprochen. Das Planning Poker (oder Scrum Poker) ist eine spielerische Methode zur Aufwandsschätzung und eine meiner Lieblingsmethoden für die Planung. Alle Teammitglieder (“Spieler:innen”) bekommen ein Set aus Spielkarten mit Zahlenwerten in der Fibonacci-Folge (also 0, 1, 2, 3, 5, 8,13 usw.; oft sind auch Karten mit “0,5”, “?” oder “∞” mit dabei).

Im Sprint Planning nutzt dein Team diese Karten, um den Aufwand einer bestimmten Aufgabe zu schätzen.

Also: eine konkrete Aufgabe wird vorgestellt, alle legen ihre Schätzung verdeckt auf den Tisch und decken sie auf Kommando auf. Die Spieler:innen mit der höchsten und der niedrigsten Schätzung müssen nun ihre Einschätzungen begründen. Dann darf das ganze Team diskutieren und versuchen, zu einer gemeinsamen Bewertung zu kommen.

Das Planning Poker ist eine spielerische und effektive Methode, um den Arbeitsaufwand zu schätzen

Quelle: trusted.de

Es ist kein Muss, Planning Poker zu spielen, wenn du mit deinem Team Aufgaben planst. Für einige Aufgaben ist die Methode auch einfach nicht geeignet, denn je komplexer der Task, desto ungenauer die Schätzungen. Im Umfang begrenzte Aufgaben lassen sich damit aber schon sehr gut einschätzen.

Roman Voting

Es gibt Fragen, die klärt ein Team am besten durch ein einfaches “Ja” oder “Nein”. Nachdem ein Vorschlag ausführlich diskutiert wurde, stimmt jedes Teammitglied mit einem Handzeichen ab. Daumen nach oben bedeutet “Zustimmung”; Ablehnung wird mit einem Daumen nach unten angezeigt. Eine Enthaltung ist theoretisch auch möglich, indem der Daumen waagerecht gehalten wird. Ob du diese Variante zulässt, ist dir überlassen.

Eine Anwendungsmöglichkeit für Roman Voting ist beispielsweise die Entscheidung über einen Optimierungsvorschlag, der im Zuge einer Sprint Retrospective genannt wird.

Roman Voting spart Zeit, ist demokratisch und effektiv. Du solltest es aber nur nutzen, wenn Demokratie auch wirklich das Gebot der Stunde ist. Flache Hierarchien schön und gut, aber in einigen Fällen muss der Scrum Master das letzte Wort haben, um die Prozesse zu schützen.

Burndown-Chart

Die Burndown-Chart ist eine grafische Darstellung zur Veranschaulichung von verbleibender Arbeit im Verhältnis zur angesetzten Projektdauer. Agil arbeitende Teams erkennen so auf einen Blick, ob Deadlines und Fristen eingehalten werden und ob sich Projekte im Soll befinden. Scrum Teams, die in Sprints arbeiten, können so außerdem prüfen, ob einzelne Sprintziele (siehe “Sprint Goal”) erreicht wurden.

Ein Burndown-Chart ist eine simple Möglichkeit, mit der du prüfen kannst, ob sich dein Projekt im Soll befindet

Quelle: trusted.de

Das Gegenteil ist ein Burnup-Chart, die Auskunft darüber gibt, wie viel Arbeit bereits erledigt worden ist.

Whiteboards und Co.

Whiteboards helfen bei der Visualisierung von Aufgaben, Ideen und Vorschlägen und sollten von Scrum-Teams umfangreich genutzt werden. Office-Teams nutzen hierfür oft einen eigenen Raum (in dem auch die Meetings stattfinden) als “Informationszentrale”. Alle Mitglieder des Teams können sich hier selbstständig informieren und den Fortschritt von Aufgaben einsehen.

Hier ein Beispiel für die Nutzung eines digitalen Whiteboards

Screenshot: trusted.de

Quelle: jamboard.google.com

Remote-Teams haben es naturgemäß nicht ganz so einfach und müssen auf digitale Lösungen ausweichen. Hier gibt es aber viele gute und geprüfte Lösungen, um sich auch über weite Entfernung hinweg auszutauschen. Sowohl Zoom als auch Google Meet und MS Teams integrieren mittlerweile passable Lösungen.

Fazit: Wie nutze ich Scrum für mich und wann stößt es an seine Grenzen?

Wie du siehst, ist Scrum “easy to learn” aber “hard to master”.

Du wirst einiges an Konzeption und Planung brauchen, damit dein Team erfolgreich scrummen kann. Neben den Rollen, Events und Instrumenten spielt vor allem die Mentalität im Team (und im ganzen Unternehmen) eine riesige Rolle.

Gehen wir einmal kurz einen Schritt zurück und werden etwas abstrakter!

Scrum ist eine empirische Arbeitsmethode und basiert auf Erkenntnisgewinn und ständiger Adaption. Das verlangt von allen Beteiligten ein hohes Gespür für Veränderungen, Flexibilität und Mut zur Innovation. Scrum kann nur gelingen, wenn alle Teammitglieder bereits sind, Prozesse zu hinterfragen, selbstständig zu denken und zu handeln. Wenn dein Team das nicht mitbringt, bringt dir leider auch der schönste Guide nichts.

Außerdem solltest du mit den richtigen Erwartungen an die Sache gehen!

Scrum ist kein Wundermittel und nicht für alle Projekte, Branchen, Abteilungen, Teams und Unternehmen geeignet. Wenn du versuchst, die Methode über etwas zu stülpen, für die es einfach nicht gemacht wurde, bringt der Scrum-Prozess mehr Hindernisse als Vorteile.

Sofern die Voraussetzungen in deinem Team gegeben ist, hält dich nun aber nichts mehr davon ab, sofort mit dem “Scrummen” zu beginnen.

Tipps für den Einstieg in die Scrum-Methode

Hier noch ein paar Tipps, die du bei der Einführung von Scrum beherzigen solltest:

Lass nicht den Chef raushängen!

Scrum arbeitet nicht nach einem Top-Down-Prinzip. Es gibt keine “Anweisungen von oben”, die eins zu eins umgesetzt werden müssen. Alle Teammitglieder sind Teil des Organismus; Entscheidungen werden im Team gefällt und Prozesse gemeinsam erarbeitet und angepasst.

Zwar gibt es den Product Owner und den Scrum Master, die eine gesonderte Rolle einnehmen; grundsätzlich sollten sich aber alle Beteiligten dem gemeinsamen Ziel unterordnen und ihre Rolle nicht als “leitend”, sondern als unterstützend verstehen.

Besinne dich auf die Grundwerte von Scrum!

Scrum arbeitet nicht nur nach Prinzipien, sondern verlangt auch einen besonderen Wertekanon, der von allen Teammitgliedern verinnerlicht werden muss. Diese Werte sind für alle verbindlich und die wichtigste Grundlage, auf denen die Scrum-Prinzipien aufbauen:

Achte auf Rollen- und Machtkonflikte!

Scrum basiert einerseits auf flachen Hierarchien, setzt andererseits aber auch auf eine klare Rollenverteilung und definierte Kompetenzen. Das mag auf den ersten Blick paradox wirken, bei genauerer Betrachtung ergeben sich aber etliche Vorteile aus dieser ungleichen Konstellation.

Wichtig ist nur, dass alle Teammitglieder ihre Rolle kennen und auch annehmen.

Scrum-Teams leben von der Zusammenarbeit auf Augenhöhe, dem ständigen Austausch und einer hohen Bereitschaft, Fehler und Hindernisse gemeinsam zu erkennen und zu beseitigen. Dennoch ist es wichtig, dass bestimmte Kompetenzen klar zugeordnet sind.

Egal wie gut geplant: In Projekten kann und wird es immer zu Reibereien und Unstimmigkeiten kommen. Daher ist die Rolle des Scrum Masters so wichtig: Er vermittelt, sorgt für ein positives Arbeitsklima und nimmt Stimmungen auf, um sie im Optimalfall in Produktivität und ein besseres Miteinander umzukehren. Dennoch gilt auch hier wieder die Eigenverantwortung.

Nochmal mit Gefühl: Scrum kann nur erfolgreich sein, wenn alle Beteiligten an einem Strang ziehen!

Lerne aus Fehlern und Erfahrungen!

Wie oben bereits beschrieben, lebt und atmet Scrum die Empirie.

Erfahrungen und Erkenntnisse stehen über Werkzeugen und Methoden. Das ist ein oftmals unterschätzter Faktor und sollte ernst genommen werden. Frei nach dem Motto “Ein Fehler ist es nur, wenn man ihn zweimal macht” funktioniert auch Scrum. Dafür ist es entscheidend, dass alle Beteiligten den Mut aufbringen, Fehler auch als solche anzusprechen.

Denn ihr werdet Fehler machen. Das lässt sich nicht vermeiden und gehört zum Scrum-Prozess dazu.

Setze um, was für dich funktioniert!

Teams merken sehr schnell, welche Scrum-Praktiken und Arbeitsweisen für sie funktionieren. Hier hilft eine ehrliche und offene Analyse der erzielten Ergebnisse und Prozesse. Dafür gibt es die Sprint Retrospective.

Denn nicht alle Scrum-Praktiken eignen sich auch tatsächlich für jedes Team und Projekt gleichermaßen. Es gibt zahlreiche Hybrid-Varianten, die klassische und agile Methoden mischen und so eine optimale Kombination beider Ansätze vereinen.

Wichtig ist nur, dass Elemente, die funktionieren, auch wirklich in den Arbeitsalltag integriert und übernommen werden.

Daraus ergibt sich direkt auch mein nächster Tipp:

Passe an, was für dich nicht funktioniert!

Scrum ist ein Rahmenwerk, schreibt dir aber nicht vor, wie du den Rahmen genau zu füllen hast. Es ist ein Fehler, sich sklavisch an bestimmte Vorgaben zu halten, erst recht, wenn diese Vorgaben für dich und dein Team nicht funktionieren!

Beispiel Sprint: wöchentliche Sprints bedeuten auch einen gewissen Aufwand in der Planung. Sehr kleine Teams können ein Sprint-Intervall je nach Projekt auch ausdehnen und so die Meetingdichte entschlacken.

Es gibt zwar einige Scrum-Expert:innen, die davor warnen, nur Teilaspekte von Scrum umzusetzen.

Aber am Ende ist wichtig, dass die Projektarbeit funktioniert, nicht dass du einen Preis für den besten Scrum-Prozess gewinnst. Wenn also ein Mix aus klassischen und agilen Konzepten in deinem Team funktioniert: go for it!

Plane nicht zu viel parallel!

Ganz oder gar nicht! Gerade große Unternehmen neigen dazu, Mitarbeiter:innen für mehrere Scrum-Teams zu verplanen. Das kann an den Kompetenzen liegen, die benötigt werden, oder weil die einzelnen Projekte nur einen geringen Umfang haben.

Das widerspricht aber den Scrum-Werten, die unter anderem einen vollen Fokus aller Teammitglieder verlangen. Ein weiterer Punkt ist die Arbeitszeit, denn die ist bekanntlich endlich. Mehrere Daily Scrums, Reviews und Abschlussmeetings gehen zulasten der Produktivität und verschleppen Ergebnisse.

Scrum Ressourcen

Du hast in meinem Guide vielleicht festgestellt, dass Scrum seine eigene Sprache hat. Hier ist das Wörterbuch dazu:

Kleines Scrum-Lexikon

Scrum-Checkliste

Diese Checkliste ist eine übersichtliche Zusammenfassung meines Ratgebers. Sie soll dir dabei helfen, Scrum einzuführen und dein erstes Scrum-Projekt erfolgreich durchzuführen. Orientiere dich gerne daran, wenn du dein erstes Projekt mit Scrum planst:

• Agiles Projektmanagement als neue Arbeitsweise etablieren
  • Ziele klar definieren (Was will ich mit Scrum erreichen?)
  • Zeithorizont planen (Wann will ich mit Scrum starten?)
  • Agiles “Mindset” etablieren und ins Team tragen
• Bevor es losgeht
  • Product Owner bestimmen
  • Scrum Master einsetzen
  • Developer-Team zusammenstellen
  • Sprintzyklus festlegen (1 bis 4 Wochen)
  • Meeting-Routine festlegen (Daily Scrum – Wer, wann, wo und wie?)
  • Termine festlegen (Sprint Planning, Sprint Review, Sprint Retrospective)
  • Tools bereitstellen (PM-Software, Videokonferenz-Software und Co.)
  • Ggf. Workshop oder Schulung mit dem Team durchführen
• Projektvorbereitung
  • Stakeholder identifizieren
  • Mit Stakeholdern Projektziele/Vision definieren
  • Budget und Ressourcen planen
  • Product Backlog anlegen
• Sprint Planning
  • Product Backlog Items für Sprint vorbereiten
  • Definition of Ready fixieren
  • Sprintziele im Team festlegen (ggf. diskutieren)
  • Abhängigkeiten, Anforderungen und Risiken definieren
• Taskboard
  • Taskboard/Kanban-Board anlegen
  • Aufgaben aus dem Sprint Planning anlegen
  • Zuständigkeiten verteilen
  • Loslegen!

Scrum Guide 2020 (Download)

Hier findest du den aktuellen Scrum-Guide der Scrum-Erfinder Ken Schwaber und Jeff Sutherland, zuletzt aktualisiert im Jahr 2020.

Scrum FAQ