Was ist Scrum? – Eine kompakte Einführung in die Scrum Methode

Was ist Scrum? – Eine kompakte Einführung in die Scrum Methode 600 315 Andreas Diehl (#DNO)

Die Scrum Methode ist ein Framework für agiles Projektmanagement. Auch wenn Scrum seine Ursprünge in der Softwareentwicklung hat, erfreut sich die Methode zunehmend auch in Nicht-Softwareprojekten großer Beliebtheit. 

Dieser Beitrag bietet einen kompakten Einstieg in die Scrum Methode. Dabei konzentriere ich mich vor allem auf die Aspekte des Scrum Modells, die für das Projektmanagement im Kontext von Nicht-Softwareprojekten in traditionellen Projekt- und Organisationsstrukturen wichtig sind. 

Was ist Scrum ? – Scrum Definition, Historie und Prinzipien  

Scrum (engl.) ist ein Begriff aus dem Rugby und bedeutet “angeordnetes Gedränge”. Jeff Sutherland und Ken Schwaber haben die Scrum Methode entwickelt und 1995 erstmals auf einer Konferenz öffentlich vorgestellt. Die beiden Scrum-Väter waren auch maßgeblich an der Formulierung des agilen Manifestes in 2001 beteiligt. Seitdem wurde die Scrum Methode permanent weiterentwickelt und hat maßgeblich zu einem heutigen Verständnis agiler Arbeitsweisen beigetragen.

Scrum Definition 

Wenn Du die Frage “Was ist Scrum” kurz und knapp beantworten möchtest, dann biete ich Dir folgende Definition an:

Scrum ist ein formales Regelwerk für die Zusammenarbeit von Teams. Dabei definiert das Scrum Modell Rollen, Meetings und verschiedene Artefakte, die Teams unterstützen nach agilen Prinzipien zu arbeiten.

Dabei ist die Scrum Methode keine dogmatische Projektmanagement-Methode, sondern ein Framework, das einem Team und beteiligten Stakeholdern Leitplanken und Orientierungspunkte bietet. Das Scrum Framework wird durch www.scrum.org permanent weiterentwickelt und ist im jeweils aktuellen Scrum Guide dokumentiert. 

Dabei fokussiert sich das Scrum Modell auf die Definition von Rollen, Meetings und Artefakten, die Du in der folgenden Übersicht findest.

Scrum Rollen

  1. Product / Project Owner
  2. Projekt- bzw. Produkt Team
  3. Scrum Master

Scrum Meetings und Aktivitäten:

  1. Sprint
  2. Sprint Planning
  3. Daily
  4. Sprint Review
  5. Sprint Retrospektive
  6. Refinement Meetings

Scrum Artefakte

  1. Product Backlog
  2. Product Backlog Items (User Stories)
  3. Sprint Backlog
  4. Definition of Done
  5. Definition of Ready
  6. Produkt Inkrement
  7. Planning Poker und Schätzungen

Die wesentlichen Prinzipien der Scrum Methode

Damit das Scrum Modell Wirkung zeigt, braucht es einen bestimmten Kontext. Ohne ein Verständnis dieser wesentlichen Prinzipien ist die Gefahr zu groß, dass Mitarbeiter sich zwar wie in einem Scrum Team verhalten, aber die Scrum Methode keine Wirkung entfaltet.. Die Prinzipien sind Werte und Verhaltensnormen, die es erst ermöglichen, dass das Scrum Modell überhaupt wirksam sein kann.

  • Vision: Das heißt, jedes Scrum Team folgt einem langfristigen Ziel, das als übergreifender Orientierungspunkt dient.
  • Wertorientierung: Scrum Teams messen ihre Ergebnisse am erzielten Wert für Kunden und Unternehmen.
  • Transparenz: Damit sind Ziele, Entscheidungen und anstehende Aufgaben allen Beteiligten und Stakeholdern frei zugänglich und bekannt.
  • Fokussierung: Eine konsequente Priorisierung der zu erledigenden Aufgaben sorgt für einen hohen Fokus.
  • Rollenklarheit: Alle am Projekt beteiligten Personen haben eine klare Rolle.
  • Autonomie: Das heißt, dass das umsetzende Team sich eigenständig und autonom auf die zu erledigenden Aufgaben committet, ohne dass ihnen Arbeitspakete und Aufträge zugeteilt werden
  • Prozesstreue: Der Scrum Prozess ist nicht verhandelbar. Denn der Prozess gibt einem Team Sicherheit, senkt durch eine hohe Standardisierung die Overhead-Kosten und trägt gleichzeitig zu hoher Transparenz bei.
  • Feedback: Der Scrum Prozess ist nicht verhandelbar. Denn der Prozess gibt einem Team Sicherheit, senkt durch eine hohe Standardisierung die Overhead-Kosten und trägt gleichzeitig zu hoher Transparenz bei.

Scrum Team – Product Owner, Development Team, Scrum Master

Product Owner (PO) – 1 Person

Der Product Owner (PO) oder auch Project Owner hat die wichtige Aufgabe die Interessen des Unternehmens (Business Value) und der Anwender / Kunden (User Value) in Einklang zu bringen und den Wert aus dem Produkt oder Projekt zu maximieren. Dabei formuliert und kommuniziert der PO auch eine langfristige Vision für das Vorhaben. Damit das gelingt, braucht der PO ein tiefgreifendes Verständnis der Kundenbedürfnisse und der strategischen Rahmenbedingungen aus Sicht des Unternehmens. 

Das wichtigste Werkzeug des Product Owners ist das Backlog und die Priorisierung der darin enthaltenen Themen. Damit stellt der PO sicher, dass das Team an den richtigen Aufgaben arbeitet und jeder im Team seine Zeit gewinnbringend im Sinne des Unternehmens einsetzt. Zudem formuliert der Product Owner für jeden Sprint ein Sprint-Ziel.

Entwicklungs- oder Projektteam – 3 bis 8 Personen  

Das Entwicklungs- oder Projektteam arbeitet autonom und selbstorganisiert an der Umsetzung der verabredeten Aufgaben. Dazu committet sich das Team auf die in einem Sprint zu erledigenden Aufgaben. Das heißt, es werden keine Arbeitspakete zugeteilt. Stattdessen entscheidet das Team während des Plannings welche der priorisierten Aufgaben im Rahmen des Sprints erledigt werden können. Damit Teams selbstwirksam auftreten und sich committen können, ist eine wichtige Voraussetzung, dass Entwicklungs- oder Projektteams interdisziplinär besetzt sind. Das heißt, dass alle notwendigen Kompetenzen und Fähigkeiten im Team vorhanden sind, um die verabredeten Aufgaben zu lösen und die Ziele des Sprints zu erreichen.

Scrum Master – 1 Person

Der Scrum Master ist der Coach des Teams und des Product Owners. Seine wichtigste Aufgabe ist das Team und den Product Owner darin zu befähigen, ihre Aufgaben bestmöglich zu erledigen. Dazu beseitigt er Hindernisse, trägt zu einer effizienten Umsetzung bei und unterstützt das Team in der Einhaltung des Scrum Prozesses. Zudem schützt der Scrum Master das Team vor ungewollter Einflussnahme. Dazu coacht er auch beteiligte Stakeholder und stellt sicher, dass agile Prinzipien von allen Beteiligten gelebt werden. 

Scrum Prozess – Sprints und Scrum Meetings 

Der Scrum Prozess besteht in einer wiederkehrenden Abfolge von Sprints. Dabei ist jeder  Sprint durch fest definierte Meetings gekennzeichnet, deren Intention, Dauer und Ziele klar definiert sind.

Der Scrum Prozess ist eine Abfolge von Sprints, die wiederum durch fest definierte Meetings gekennzeichnet sind.
Der Scrum Prozess ist eine Abfolge von Sprints, die wiederum durch fest definierte Meetings gekennzeichnet sind. – © Andreas Diehl

Im Folgenden gehe ich näher auf die jeweiligen Aktivitäten und Meetings des Scrum Prozesses ein. Dabei solltest Du berücksichtigen, dass das Scrum Framework von der idealen Voraussetzung ausgeht, dass Teams Vollzeit an der Umsetzung eines Vorhabens arbeiten. 

Der Sprint – Herzstück des Scrum Prozesses

Der Sprint ist das oberste zentrale Ordnungsprinzip im Scrum Framework. Dabei ist ein Sprint ein ein fest definiertes Zeitintervall, in dem das Team an der Erledigung der vereinbarten Aufgaben und der Erreichung des Sprint-Ziels arbeitet. Sprints geben sich die Klinke in die Hand. Das heißt, das Ende des einen Sprints ist der Anfang des nächsten Sprints. Die Dauer eines Sprints beträgt typischerweise 1-4 Wochen und wird in Abhängigkeit des Produktes / Projektes festgelegt. Bei der Festlegung der Sprintdauer zu Beginn eines Vorhabens  solltest Du folgende Rahmenbedingungen berücksichtigen:

  • Die Sprintdauer ist fix, d.h. alle Sprints haben die gleiche Dauer. Das gilt solange, bis Du möglicherweise feststellst, dass eine andere Sprintdauer für dein Vorhaben angemessener wäre. Dann änderst Du die Sprintdauer und bleibst dabei.
  • Sprints dauern max. vier Wochen. Der relativ kurze Zyklus von vier Wochen ist der Einsicht geschuldet, dass mit zunehmender Länge eines Zyklus die Qualität der Planung sinkt. Diese Erkenntnis ist auch als “Cone of uncertainty” bekannt. 

Was macht der PO während des Sprints?

Da der Product Owner nicht direkt an der Umsetzung des Projektes oder Produktes arbeitet, stellt sich die Frage, was der PO eigentlich während des Sprints macht. Der PO hat die wichtige Aufgabe das Backlog weiter zu pflegen und zu priorisieren und damit schon wieder den nächsten Sprint vorzubereiten. Dazu stimmt er sich in Refinement Meetings auch mit dem Team ab, damit Aufgaben im nächsten Planning bereits einmal durchdacht und nicht völlig neu sind. Zudem steht er dem Team auch während der Umsetzung für Rückfragen zur Verfügung bzw. priorisiert Aufgaben neu, sofern sich im Laufe der Umsetzung neue Erkenntnisse ergeben, die die ursprüngliche Planung durcheinander bringen.

Abbruch eines Sprints

Wenn das ursprünglich formulierte Sprint Ziel keine Relevanz mehr hat bzw. keinen Wert mehr verspricht, kann das Team entscheiden den Sprint abzubrechen. Alternativ greift das Team in Absprache mit dem PO auf das priorisierte Backlog zurück.

Scrum Meetings

Damit das Arbeiten in Sprints nicht zu einer sinnlosen Aneinanderreihung von Zeitintervallen wird, hat das Scrum Framework feste Meeting definiert. Das heißt, die Scrum Meetings sind das zweite wichtige Ordnungsprinzip und geben dem Sprint eine Struktur.

Dabei startet jeder Sprint mit einer gemeinsamen Planung (Planning), endet mit einer Präsentation der erzielten Arbeitsergebnisse (Review) und der Frage, wie die Zusammenarbeit weiter verbessert werden kann (Retrospektive). Zur Vorbereitung des Planning finden sog. Refinements statt und während des Sprints synchronisieren sich Teammitglieder täglich (Dailys). Die Dauer der einzelnen Meetings ist dabei relativ zur Länge des Sprints. 

Im Folgenden skizziere ich die Scrum Meetings, ihre Intention und die idealtypische Dauer ausgehend von einem Team, das Vollzeit in einem 4-Wochen Sprint an der Umsetzung des Vorhabens arbeitet. Diese Empfehlungen orientieren sich am offiziellen Scrum Guide. 

Sprint Planning – Start des Sprints, 8 Stunden

Jeder Sprint startet mit einem gemeinsamen Planning, an dem das gesamte Scrum Team (PO, Projektteam, Scrum Master) teilnimmt. Während des Plannings werden anstehende Aufgaben diskutiert und der erwartete Aufwand geschätzt. Mit der Schätzung über den erwarteten Aufwand wird der PO befähigt, um auf Basis des erwarteten Nutzens und der Kosten eine Entscheidung bzgl. der Priorisierung zu treffen. Das umsetzende Team committet sich auf die Aufgaben, übernimmt die priorisierten Aufgaben in sein Sprint Backlog und der PO formuliert abschließend ein Sprint Ziel. Bei einem vierwöchigen Sprint werden für ein Planning 8 Stunden angesetzt.

Daily – täglich, 15 Minuten

Das Daily ist eine tägliche Synchronisation des umsetzenden Teams. Da die Dauer auf 15 Minuten begrenzt ist, findet es oft im Stehen statt. Deswegen wird es mitunter auch “Stand Up” genannt. Dabei haben das Stehen und die enge Timebox einen ganz einfachen Hintergrund. Denn statt sich in epischer Breite auszulassen, ist jedes Teammitglied eingeladen ein kurzes Update zu geben, um sich mit den Kollegen zu synchronisieren. Wo stehe ich gerade, brauche ich Hilfe, habe ich sonstige Fragen? Sollte sich daraus weiterer Gesprächsbedarf ergeben, finden im Anschluss an das Daily weiterführende Gespräche statt, anstatt das gesamte Team während des Dailys damit zu behelligen. Das Daily ist ein Meeting das Projektteams, das jeden Tag zu gleicher Zeit am gleichen Ort stattfindet. Das heißt, der Scrum Master und der Product Owner nehmen nur optional teil. 

Review bzw. Demos – Ende des Sprints, 4 Stunden 

Zum Ende des Sprints präsentiert das Projekt- bzw. Produktteam die Arbeitsergebnisse des Sprints. Zu der Review werden neben dem Product Owner, vor allem interessierte Stakeholder, und ggf. auch ausgewählte Kunden eingeladen. Zum einen bietet die Review dem Projekt- bzw. Produktteam eine Bühne für das was es im zurückliegenden Sprint geschafft hat. Zum anderen erhalten Stakeholder und eingeladene Personen die Möglichkeit Feedback zu geben und Fragen zu stellen, um damit auch auf künftige Planungen Einfluss zu nehmen. Die Entscheidung, was davon wie priorisiert wird, obliegt jedoch alleine dem Product Owner. Das heißt, die Review ist keine Abnahme und auch ausdrücklich nicht mit einem Lenkungsausschuss zu vergleichen. Denn hier präsentiert ein autonomes Team, das auf Basis einer gemeinsamen Planung mit dem Product Owner sein bestmögliches getan hat. Nicht fertiggestellte Arbeitspakete und Aufgaben wandern direkt in das nächste Planning. 

Retrospektive – Ende des Sprints, 3 Stunden

Schließlich endet der Sprint mit einer Retrospektive des Scrum Teams. Dazu treffen sich das Projektteam, der Product Owner und der Scrum Master, um die Zusammenarbeit zu reflektieren und basierend auf diesen Einsichten Vereinbarungen für künftige Sprints zu treffen. Das heißt, in der Retrospektive geht es ausschließlich um den Arbeitsprozess, gar nicht um Inhalte bzw. Arbeitsergebnisse. Der Scrum Master moderiert die Retro z.B. nach folgendem beispielhaften Muster.

  • Willkommen (“Set the stage”)
  • Informationen und Eindrücke sammeln (“Gather data”)
    • Was ist gut gelaufen? (Keep)
    • Was sollten wir einstellen? (Drop) 
    • Was könnten wir ausprobieren? (Try)
  • Erkenntnisse verdichten (“Generate insights”) 
  • ToDos für den folgenden Sprint formulieren (“Decide what to do”)
  • Abschluss (“Closing”) – Wem möchte ich Danke sagen?

Dabei sind Retrospektiven dann besonders wirksam, wenn Teilnehmer den Wunsch nach ständiger Verbesserung und eine gesunde Portion Selbstreflexion mitbringen. In der japanischen Lean Philosophie wird diese Haltung mit den Prinzipien Kaizen und Hansei bestens beschrieben. Die Retrospektive schließt mit konkreten Vereinbarungen, die im nächsten Sprint umgesetzt werden und unter Umständen auch einen eigenen Eintrag im Sprint Backlog erhalten.

Refinement

Das einzige Meeting, das keiner definierten Struktur folgt, sind Refinement Meetings. Die Ziel von Refinements ist, dass sich Product Owner und das umsetzende Team im Vorfeld zu einem Planning über den Umfang und den Outcome von anstehenden Aufgaben unterhalten. Das gibt dem PO die Möglichkeit seine Anforderungen zu schärfen und den beteiligten Teammitgliedern die Chance schon einmal über Anforderungen nachzudenken. Dabei ist die grundlegende Idee , dass das umsetzende Team nicht im Planning erstmalig von einer Anforderung erfährt. Diese vorherige Synchronisation und ein gemeinsames Refinement der Aufgaben sind gerade bei sehr komplexen und umfangreichen Aufgaben wichtig, um die effiziente Durchführung des Plannings zu gewährleisten. Wenn Du also merkst, dass ihr während des Plannings nicht auf den Punkt oder zu einem guten Abschluss kommt, dann könnte ein unzureichendes Refinement eine mögliche Ursache sein. 

Zusammenfassung der Scrum Meetings

Diese hohe Standardisierung der Scrum Meetings trägt zu einer hohen Effizienz und sehr guten Meetingkultur bei. Jedes Meeting hat ein definiertes Ziel, einen klaren Platz im Sprint und eine feste Timebox. Damit reduzierst Du den organisatorischen Overhead auf ein absolutes Minimum. 

Die folgende Übersicht gibt dir eine Zusammenfassung der Scrum Meetings.

EventZielDauer / Sprint (4 Wochen)Teilnehmer
Sprint PlanningDiskussion der anstehenden Aufgaben, Aufstellen des Sprint Backlogs, Definition des Sprint Goals1 mal zu Beginn des Sprints, max. 8 Stunden (bei  einem 4 Wochen Sprint)Alle

Product Owner, Produkt- bzw. Projektteam, Scrum Master
DailySynchronisation der Teammitglieder, was plane ich heute, wo brauche ich ggf. Hilfe etc.Täglich, max.15 MinutenProdukt- bzw. Projektteam

Optional: PO, Scrum Master
Sprint ReviewDas Projektteam stellt Arbeitsergebnisse vor, PO und Stakeholder geben Feedback.4h Alle

Zusätzlich: Stakeholder ggf. Kunden
Sprint RetrospektiveOptimierung der Zusammenarbeit, Anpassung der Definition of Done 3h Alle

Optional: Stakeholder, um Impulse zu setzen
Product Backlog RefinementKlärung und Schätzung der Backlog Items2-4 Stunden pro WocheProduct Owner, Produkt- bzw. Projektteam,

Optional: Scrum Master

Scrum Artefakte und Werkzeuge

Neben Rollen und den Aktivitäten sind die Scrum Artefakte und Werkzeuge der dritte zentrale Baustein des Scrum Frameworks. Im Folgenden werde ich die die folgenden Scrum Artefakte kurz erläutern.

Product Backlog

Das Backlog ist die Summe aller anstehenden Aufgaben, eine angemessene deutsche Übersetzung wäre z.B. “Themenspeicher”. Das heißt, im Backlog findest Du alle Aufgabenstellungen und Ideen, von denen Du als PO annimmst, dass sie Wert für das Projekt oder das Produkt schaffen. Das können auch Aufgaben sein, die vielleicht nur aus formalen Anforderungen erledigt werden müssen. Das Product Backlog wird vom Product Owner z.B. in einem Kanban Board gepflegt und priorisiert. Mit einem jederzeit priorisierten Backlog arbeitet der Product Owner vor. Das heißt, sollte das Team konservativ geplant haben und deutlich früher mit den, für den Sprint vereinbarten, Aufgaben fertig sein, kann das Team jederzeit auf das priorisierte Backlog zurückgreifen. Im Optimalfall ist das Product Backlog auch online für das Team und die beteiligten Stakeholder einsehbar.  

Product Backlog Items (User Stories)

Einzelne Einträge und Aufgaben innerhalb des Backlogs sind “Product Backlog Items”. Das können kleine sehr konkrete ToDos sein, Ausweitungen bestehender Leistungsmerkmale, neue Features oder auch neue Epics. Von einem Epic sprichst Du immer dann, wenn neue Leistungsmerkmale eine “epische” Breite bzw. Tiefe haben und nicht mehr innerhalb eines einzelnen Sprints umgesetzt werden können. Diese Epics werden dann in bearbeitbare Product Backlogs Items aufgebrochen.

Jedes Product Backlog Item enthält den erwarteten Kundennutzen, ggf. den Mehrwert für das Unternehmen und Messgrößen zur Beurteilung der Wirksamkeit der Maßnahmen oder des Features. Zudem enthält der Backlog Eintrag bzw. Akzeptanzkriterien, die für die Erfüllung der Aufgabe notwendig sind. Auch wenn es kein offizielles  Format für Product Backlog Items gibt, haben sich User Stories als defacto Standard etabliert. 

Sprint Backlog

Das Sprint Backlog enthält alle Aufgaben, die im laufenden Sprint durch das Team bearbeitet werden. Während das Backlog unter der Hoheit des PO steht, gehört das Sprint Backlog einzig und allein dem umsetzenden Team. Dabei ist das Sprint Backlog ein Ergebnis der Sprint Planung. Denn hier entscheiden der PO und das Projektteam gemeinsam, welche Backlog Items im kommenden Sprint bearbeitet werden.

Backlog, Sprint Backlog und Sprint Planning in einem Kanban Board
Backlog, Sprint Backlog und Sprint Planning in einem Kanban Board – ©Andreas Diehl

Definition of Ready

Die Definition of Ready (DoR) spiegelt das Verständnis des Teams wider, welchen Reifegrad eine Aufgabe im Backlog erfüllen darf, um überhaupt bearbeitet werden zu können. Zum Beispiel können der erwartete Nutzen oder auch Messgrößen zur Beurteilung der Wirksamkeit Bestandteil der Definition of Ready sein. Erfüllt eine Aufgabe die Definition of Ready nicht, ist der PO gefordert das Product Backlog Item weiter auszuarbeiten. Die Definition of Done (DoD) wird wie die Definition of Ready (DoR) einer ständigen Anpassung und kritischen Überprüfung unterzogen. So kann das Team z.B. im Rahmen der Retrospektive entscheiden die Definition of Done (DoD) oder auch die Definition of Ready (DoR) anzupassen.

Definition of Ready (DoR) und Definition of Done (DoD) sind wichtige Artefakte der Scrum Methode
Definition of Ready (DoR) und Definition of Done (DoD) sind wichtige Artefakte der Scrum Methode -@Andreas Diehl

Definition of Done

Die Definition of Done (DoD) ist eine Vereinbarung und das gemeinsame Verständnis des Teams, wann Arbeit erledigt ist. Das heißt, allgemeingültige Akzeptanzkriterien für die erfolgreiche Erledigung einer Aufgabe in Form von allgemeine Anforderungen und Qualitätskriterien. So könnte ein Team z.B. vereinbaren, dass Arbeitsergebnisse für alle zugänglich und besprochen sein müssen, damit eine Aufgabe wirklich “done” ist. Entsprechend kann eine Aufgabe in deinem Kanban Board erst auf  “Done” verschoben werden, wenn sie die Bedingungen der “Definition of Done” erfüllt. 

Produkt Inkrement

Wenn Du den Scrum Guide liest oder hörst, wird dir der Begriff “Produkt Inkrement” ganz sicher auffallen. Das Produkt Inkrement beschreibt die während eines Sprints erzielten Arbeitsergebnisse. Also das “Delta” zum Arbeitsstand vor dem letzten Sprint bzw. die neuen Leistungsaspekte, die das Team in diesem Sprint fertig gestellt hat. 

Schätzungen – Story Points und Planning Poker

Während des Sprint Plannings schätzt das umsetzende Team den Aufwand einzelner Aufgaben. Damit gibt das Team dem PO ein wichtiges Feedback über den erwarteten Aufwand der Umsetzung. Der PO kann also seinen erwarteten Nutzen und den Aufwand direkt gegenüberstellen, sein Backlog und die für den Sprint wichtigen Aufgaben besser priorisieren. Der Wert den eine Aufgabe erhält wird in Anlehnung an User Stories auch “Story Points” genannt. Wenn Du die Story Points aller Aufgaben im Sprint addierst, erhälst Du eine Maßzahl für die Leistungsfähigkeit des Teams. Damit hast Du eine Orientierung, die dir auf lange Sicht hilft besser zu planen. 

Planning Poker

Für das Schätzen hat sich als Methode “Planning Poker” etabliert. Dabei bekommt jedes Teammitglied einen Satz Karten, die je einen Wert aus der Fibonacci Reihe (1, 2, 3, 5, 8, 13, 21 …) enthalten. Nach Vorstellung einer Aufgabe spielen alle Teammitglieder ihre Karte gleichzeitig aus. Damit soll vermieden werden, dass sich Teammitglieder zu stark gegenseitig beeinflussen. Mit ihrer ausgespielten Karte schätzt jedes Teammitglied den erwarteten relativen Aufwand. Dabei handelt es sich um keine absolute Aufwandsschätzung, sondern den erwarteten Aufwand in Relation zu einer Referenzaufgabe. Denn wichtiger als der absolute Aufwand sind die mit der Schätzung verbundenen Informationen. Weichen die Schätzungen zu weit voneinander ab, dann hat das Team scheinbar ein unterschiedliches Verständnis über den Umfang einer Aufgabe. Das heißt, Planning Poker und Schätzen fördern eine konstruktive Auseinandersetzung, werfen wichtige Fragen auf und helfen dem Team ein besseres Verständnis der zu erledigenden Aufgabe zu gewinnen.

Fazit – Die Scrum Methode als Vater des agilen Projektmanagements

Mittlerweile hat das Scrum Modell über 25 Jahre Reifeprüfung und ständige Anpassung hinter sich. Damit ist Scrum vor allem in Verbindung mit Kanban ein defacto Standard für die agile Umsetzung auch von Nicht-Softwareprojekten. Dabei sind nach meinem Verständnis die wesentlichen Prinzipien und Ideen der Scrum Methode deutlich wichtiger als eine Scrum Guide konforme Implementierung des Scrum Frameworks. Denn schon ein selbstbewusster und autonomer PO, ein selbstorganisiertes Team, klare Spielregeln und Meetingstrukturen werden die meisten Projektorganisationen in eher hierarchischen aufgestellten Unternehmen zügig an die Belastungsgrenzen ihrer heutigen Kultur führen. 

Für mich als Berater ist Scrum ein unverzichtbarer Baustein beim Aufbau agiler Projektstrukturen und Governance für die Umsetzung der digitalen Transformation. Und ein gutes und sehr einfaches Mittel, um mal ein wenig an den Grundfesten der heutigen Organisation zu rütteln. Schließlich werde ich ja nicht gebucht, damit alles so bleibt wie es ist. Sofern auch Du mal ein wenig rütteln willst, findest Du in diesem Artikel ein paar Überlegungen, wie Du Scrum in deiner Organisation einführen kannst

Ich hoffe, es ist mir gelungen die Frage “Was ist Scrum?” fürs Erste ausreichend beantwortet zu haben. Du bist jedoch herzlich eingeladen weiterführende Fragen in den Kommentaren zu hinterlassen. 

Viel Erfolg.

Artikel zum Download:

Weiterführende Artikel:

Hinterlasse eine Antwort

Ihre Email-Adresse wird nicht veröffentlicht.