Scrum

Was ist Scrum, wie funktioniert es, welche Haltung und Werte sind wichtig und wo liegen Vorteile?

Wissen kompakt: Scrum ist ein Framework, das Organisationen bei der Wertschöpfung durch adaptive Lösungen bei komplexen Problemen unterstützt.

Scrum Definition

Scrum ist ein Framework für die Entwicklung und Instandhaltung komplexer Produkte und Dienstleistungen. Ursprünglich für die Softwareentwicklung konzipiert, wird das Framework seit vielen Jahren in unterschiedlichen Bereichen und Industrien für die Produktentwicklung und im Projektmanagement verwendet. Definiert ist das Framework im sogenannten Scrum Guide. Dieser nennt

  • fünf Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive)
  • drei Verantwortlichkeiten (Product Owner, Scrum Master und Entwickler) sowie
  • drei Artefakte (Product Backlog, Sprint Backlog und Product Increment)

als zentrale Elemente.

Scrum - ein Framework mit Events, Verantwortlichkeiten und Artefakten

Scrum kompakt

Scrum adressiert die gemeinschaftliche Entwicklung von komplexen Produkten und Services. Es basiert auf Empirie (Wissen entsteht aus Erfahrung und das Treffen von Entscheidungen erfolgt auf der Grundlage von Beobachtungen) und Lean Thinking (Verschwendung wird vermieden und der Fokus liegt auf dem Wesentlichen). Das Vorgehen ist inkrementell und iterativ. Es folgt der Überlegung, dass Entwicklungsprojekte häufig zu komplex für eine exakte Planung und Beschreibung sind, da viele Anforderungen und Lösungen zu Projektbeginn unklar sind. Diese Unklarheiten werden durch ein schrittweises Iterieren beseitigt.

In Scrum organisiert sich das Team – ausgestattet mit benötigten Kompetenzen – innerhalb fester Zeitspannen selbst, wobei es sich verpflichtet, regelmäßig und so früh wie möglich, fertige Funktionalität zu liefern.

Das Herz des Frameworks ist der sogenannte Sprint.¹ Er umfasst alle anderen Events.

  • Das Sprint Planning ist das erste Event innerhalb des Sprints. Im Planning wird festgelegt, „warum“ der aktuelle Sprint einen Wert besitzt, „was“ aus dem Product Backlog in den Sprint Backlog übernommen und „wie“ es realisiert wird. Ziel ist auf dem Weg zum Product Goal ein Inkrement zu erzeugen, dass einen Wert liefert, funktionsfähig ist und potenziell lieferfähig sein soll.
  • Im Zuge der Implementierung gibt es ein täglich stattfindendes Standup Meeting zur gemeinschaftlichen Synchronisation.
  • Im Sprint Review wird die erledigte Arbeit am Ende des Sprints präsentiert und das weitere Vorgehen thematisiert.
  • Und in der Retrospektive wird das Miteinander im zurückliegenden Sprint mit dem Ziel erörtert, die zukünftige Zusammenarbeit zu verbessern.

Und schon beginnt der Ablauf von vorne.

Scrum Events

Der Scrum Guide definiert fünf Events – alternativ auch Meetings, Rituale, Aktivitäten oder Zeremonien genannt:

Sprint

Ein Leitmotiv des Frameworks ist die Entwicklung von Produkten in kurzen Zyklen bzw. Inkrementen. Diese kurzen Zyklen werden Sprint genannt. Sie sind das Herz von Scrum. Wichtig ist, dass Sprints im gesamten Entwicklungsablauf eine konsistente Dauer haben. Beim Arbeiten mit parallelen Teams sollten Organisationen darauf achten, dass Sprints synchron verlaufen, so dass es nicht zu unnötigen Wartezeiten zwischen den Teams kommt.

Trotz aller Offenheit für Neues, gilt es Änderungen innerhalb eines Sprints zu vermeiden, die das vereinbarte Sprint-Ziel gefährden. Das vereinbarte Sprint-Ziel ist eine Prämisse, die es gemeinsam zu erreichen gilt, so dass ein potenziell lieferfähiges Inkrement entsteht, das funktioniert und Kunden zur Verfügung gestellt werden könnte. Werden einzelne User Storys nicht umgesetzt, so wird der Sprint nicht verlängert, sondern die entsprechenden User Storys gegebenenfalls für einen der nächsten Sprints eingeplant. Die Anpassung von Qualitätszielen und Akzeptanzkriterien ist nicht vorgesehen, sollte jedoch das Sprint-Ziel obsolet werden, kann der Product Owner einen Sprint auch abbrechen.

Sprint Planning

Zu Beginn eines Sprints findet die Spint Planung – auf Englisch: das Sprint Planning – statt. Es ist ein Treffen zur Planung der Anforderungen und Arbeitspakete, die im aktuellen Sprint umgesetzt werden sollen. Die Teilnahme ist für die Entwickler  verpflichtend. Organisiert wird das Meeting vom Product Owner, moderiert vom Scrum Master.

Das Sprint Planning teilt sich in zwei Phasen auf:  Beim Sprint Planning 1 wird über das „Warum“ und „Was“ gesprochen, also warum ist Sprint wertvoll und was soll im realisiert werden. Ein Sprint-Ziel wird vereinbart und die Entwickler verpflichten sich, die vereinbarten Anforderungen im nächsten Sprint umzusetzen. Beim Sprint Planning 2 einigen sich die Entwickler auf das „Wie“, also wie das Team die Anforderungen realisieren wird. Dazu definieren Sie Tasks und visualisieren diese häufig mit einem Taskboard. Am Ende von Phase 2 sollten die Entwickler in der Lage sein, dem Product Owner und dem Scrum Master zu erklären, wie sie als selbst-managendes Team arbeiten wollen, um das Sprint-Ziel zu erreichen und das erwartete Inkrement zu erstellen.

Daily Scrum

Das Daily Scrum ist ein täglich stattfindendes Standup Meeting, zu dem sich die Entwickler treffen, um sich gegenseitig zu synchronisieren und über den Fortschritt, die anstehenden Tätigkeiten und mögliche Probleme auszutauschen. Die Teilnahme an dem Meeting ist für die Entwickler verpflichtend, zusätzlich sollte der Scrum Master und könnte der Product Owner teilnehmen. In der Praxis hat es sich bewährt, dass jedes Teammitglied drei Fragen – immer mit Bezug auf das Sprint-Ziel – beantwortet:

  • Was habe ich seit gestern getan, um dem Team zu helfen, dass Sprint-Ziel zu erreichen?
  • Was mache ich bis morgen, um das Team beim Erreichen des Sprint-Ziels zu unterstützen?
  • Was hindert mich oder das Team daran, das Sprint-Ziel zu erreichen?

Durch den Austausch werden Redundanzen vermieden.

Sprint Review

Das Sprint Review ist ein Treffen am Ende eines Sprints zur Inspektion der erledigten Arbeit in Bezug auf das gesteckte Sprint-Ziel und zur Besprechung zukünftiger Anpassungen. Am Sprint Review nehmen das Scrum Team und alle beteiligten Mitarbeiter teil. Auch ausgewählte Stakeholder – Personen oder Gruppen mit einem Interesse an den Sprintergebnissen – also bspw. Anwender, Manager, Vertreter aus Bereichen wie Marketing, Vertrieb oder IT können teilnehmen.

Beim Sprint Review wird sichtbar, was im Sprint erarbeitet und welche User Storys umgesetzt wurden. Da nur realisierte User Storys und deren Umsetzung live im Produkt präsentiert werden, ist der Fortschritt der Entwicklung für alle Beteiligten direkt ersichtlich. Durch die Teilnahme von Stakeholdern können diese direktes Feedback und somit Kritik, Lob und Verbesserungsvorschläge äußern, die gegebenenfalls vom Product Owner für den nächsten Sprint vorgesehen werden.

Sprint Retrospektive

Eine Retrospektive ist ein regelmäßiges Treffen, zu dem sich das Srcum Team trifft, um die jüngere Vergangenheit – also den zurückliegenden Sprint – zu beleuchten und dadurch die zukünftige Zusammenarbeit im Team zu verbessern. Es ist ein Meeting, bei dem Prozesse, Werkzeuge, Fähigkeiten, Beziehungen, Herausforderungen und Erfahrungen reflektiert werden. Das Feedback bietet dabei Chancen sowohl für das Team als Ganzes als auch für jeden einzelnen Teilnehmer.

Ziele sind die Verbesserung der Zusammenarbeit im Team und somit die Verbesserung von Abläufen und Inhalten, sowie die Festlegung von Maßnahmen, von Dos und Don’ts, basierend auf  den gemeinsam gewonnen Erkenntnissen. Darüber hinaus bietet die Retrospektive Raum für offenes Feedback im Team und zur Überprüfung der vereinbarten Maßnahmen der vergangenen Retrospektive. In der Praxis gibt es eine große Anzahl von Möglichkeiten, die Retrospektiven abzuhalten und es empfiehlt sich, immer mal wieder die Vorgehensweise anzupassen, um so das Interesse am Austausch untereinander hoch zu halten.

Scrum Verantwortlichkeiten

Der Scrum Guide definiert ein Team mit drei Verantwortlichkeiten²:

Product Owner

Der Product Owner ist eine der drei Verantwortlichkeiten in Scrum. Er repräsentiert die Vorstellungen der Stakeholder, erstellt und pflegt das Product Backlog, und arbeitet eng mit den Entwicklern zusammen. Er ist verantwortlich für die Definition des Produkt-Ziels und in vielen Organisationen auch für den Erfolg der Entwicklung. Er nimmt aktiv Einfluss auf die Entwicklung über die Formulierung und Priorisierung von Backlog Items (die jedoch allesamt auch von Kollegen erfasst werden können). In der Praxis  verantwortet er oftmals Releases und Release-Pläne, pflegt einen Kapazitätsplan und betreibt Risikomanagement. Er vereint somit Produkt- und Projektmanagementaufgaben.

Trotz seiner Verantwortung und seinen zahlreichen Aufgaben ist er aber nicht der Vorgesetzte der Entwickler oder des Scrum Teams. Er sollte sich weder in technische Lösungsdiskussionen oder die Schätzung von Aufwänden einmischen. Damit der Product Owner seine Tätigkeit gut ausführen kann, muss er vom Management bevollmächtigt sein, um bspw. Entscheidungen bzgl. Anforderungen und Funktionsumfang treffen zu können. Darüber hinaus ist es wichtig, dass er sowohl fachlich als auch kommunikativ qualifiziert und stets verfügbar ist.

Scrum Master

Der Scrum Master ist für die Umsetzung des Frameworks verantwortlich. Als Mitglied des Teams agiert er als Moderator, Vermittler, Prozessbegleiter, Unterstützer und Coach. Einfach ausgedrückt: er hilft Entwicklern und dem Product Owner dabei, Ziele gemeinsam zu erreichen, indem er die Arbeit der Kollegen erleichtert und die Zusammenarbeit fördert.

Der Scrum Master versucht eine vertrauensvolle, offene Arbeitsatmosphäre zu schaffen und die Werte des Frameworks zu leben. Dabei wirkt er aber nicht nur in Richtung des Teams, sondern auch in Richtung der Stakeholder und der Organisation. Und bei Bedarf spricht er unproduktives Verhalten oder bietet angemessenes Feedback an.

Die Tätigkeiten des Scrum Masters sollten nicht mit denen eines Projektleiters verwechselt werden. Er besitzt keine Weisungsbefugnis und damit auch keine Entscheidungsgewalt. In Scrum organisieren bzw. managen sich die Entwickler selbst. Im Rahmen der Retrospektive erhält er die Gelegenheit, Feedback zu seiner eigenen Tätigkeit zu erfragen.

Entwickler

Der Scrum Guide 2020 definiert eine weitere Verantwortlichkeit: die Entwickler. In der Vorgängerversion des Guides wurde noch von einem Entwicklungsteam gesprochen.

Entwickler sind diejenigen im Team, die sich in einem Sprint dazu verpflichtet haben, jegliche Aspekte eines Inkrements zu erstellen. In der Praxis bedeutet dies, dass sich fortan bspw. nicht nur Softwareentwickler angesprochen fühlen dürfen, sondern alle Beteiligten – z.B. auch Manager in der Linie, UX Designer oder Marketingmitarbeiter, die aktiv in einem Sprint mitwirken. 

Da das Scrum Team aus 10 oder weniger Personen bestehen soll, sollten maximal 8 Entwickler in einem Team mitwirken. Idealerweise arbeiten sie funktionsübergreifend und besitzen gemeinsam alle erforderlichen Fähigkeiten, um ein Inkrement am Ende des Sprints zu erstellen. Unabhängig von den Fähigkeiten der einzelnen Mitglieder definiert das Framework keine zusätzlichen Verantwortlichkeiten, Rollen oder Titel für das Team. Betont wird die gemeinsame Verantwortung, ein potenziell lieferfähiges Inkrement zu erstellen. Grundsätzlich gilt, dass sich die Entwickler selbst managen und weder Product Owner noch Scrum Master ihnen vorgesetzt sind. 

Scrum Artefakte

Der Scrum Guide definiert drei Artefakte:

Product Backlog

Ein Backlog ist eine Sammlung von Dingen, insbesondere unvollständiger Arbeit oder Angelegenheiten, die erledigt werden müssen. Oder einfach ausgedrückt: Ein Backlog ist eine Liste von Aufgaben bzw. Anforderungen, die abgearbeitet bzw. realisiert werden sollen.

Ein Product Backlog beinhaltet Elemente, mit denen ein vom Product Owner definiertes Product Goal – das Produkt-Ziel – erreicht werden. Das Product Goal sorgt also dafür, dass „lediglich“ Items festgehalten werden, die auf das Ziel der Entwicklung einzahlen. Verantwortlich für das Product Backlog als auch das Product Goal ist der Product Owner. Im Zuge der kontinuierlichen Verfeinerung und Priorisierung der Items, nutzt er die Meinungen von Stakeholdern und die Expertise der Entwickler. Er kommuniziert die Product Backlog Items, sorgt für Transparenz und Verständnis und geht mit einer Vorauswahl von Items – auch bekannt als Selected Backlog – in das Sprint Planning.

Interessanterweise spricht der Scrum Guide immer nur von Product Backlog Items, ohne diese genauer zu benennen. User Storys, Epics, Features, Anforderungen etc. werden nicht explizit erwähnt. 

Sprint Backlog

Das Sprint Backlog ist der Plan für den aktuellen Sprint. Er wird im Sprint Planning vereinbart und beinhaltet alle Product Backlog Items, die durch die Entwickler für den aktuellen Sprint ausgewählt und im Sprint umgesetzt werden. Zusätzlich beinhaltet das Sprint Backlog das Sprint-Ziel, auf das sich die Entwickler gemeinsam committen und die Tasks bzw. Aufgaben, die nötig sind, um die Items zu realisieren und das Ziel zu erreichen.

Nachdem der Product Owner das „Warum“ des Sprints und die aus seiner Sicht wichtigsten Items erläutert hat, entscheiden die Entwickler, „was“ „wie“ im Sprint umgesetzt wird. Sie tragen damit die Verantwortung für den Sprint, das Sprint-Ziel und das Sprint Backlog. Idealerweise selektieren sie die Items mit den höchsten Prioritäten, die der Product Owner im Zuge des Backlog Refinements gemeinsam mit ihnen und in Vertretung der wichtigsten Stakeholder festgelegt hat. Die Aufgaben zur Realisierung der einzelnen Items sollten dabei nicht mehr als einen Tag in Anspruch nehmen, so dass jeden Tag Aufgaben abgeschlossen werden können. Der Fortschritt innerhalb des Sprints lässt sich bspw. mit Taskboards oder Burn-Down-Charts visualisieren. 

Product Increment

Ein Product Increment – auf deutsch ein Produkt-Inkrement oder einfach Inkrement – umfasst alle während eines Sprints abgeschlossenen Backlog Items und beinhaltet die Inkremente aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement „Done“ sein, d.h. es muss sich in einem brauchbaren Zustand befinden und der Definition of Done entsprechen. Darüber hinaus muss das Inkrement „potenziell lieferfähig“ sein, d.h. es muss funktionieren, es muss getestet sein, es muss sich in Betrieb nehmen lassen, es sollte dokumentiert sein und den Anwendern einen Mehrwert bieten.

In der Praxis wird nicht jedes fertige Inkrement den Kunden zur Verfügung gestellt, da dies viele Kunden-Organisationen überfordern könnte. Bei einer App, die sich automatisch im Hintergrund auf einem Handy aktualisiert, ist eine Lieferung pro Monat durchaus denkbar, bei einer Anwendung, die unternehmensweit mit mehreren 1000 Anwendern betrieben wird, würde das ggf. zu viel Aufwand erzeugen. Hier sind Marketing und Vertrieb gefordert, gemeinsam mit dem Product Owner eine sinnvolle Release-Strategie zu definieren.

Scrum Whitepaper als Download

Wollen Sie das Scrum Whitepaper kostenlos downloaden?

Alles Wichtige über das Framework auf einen Blick.

  • Events
  • Verantwortlichkeiten
  • Artefakte
  • Werte
  • Vorteile
  • Tipps

Wissen auf 13 Seiten zum Mitnehmen.

Scrum in der Praxis

Das agile Manifest und Scrum

Im Jahr 2001 formulierten 17 Autoren, u. a. Ken Schwaber und Jeff Sutherland, die Erfinder von Scrum, und Ken Beck, einem der drei Begründer von Extreme Programming, das agile Manifest. Es definiert folgende Leitsätze und Prinzipien:

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Software ist wichtiger als eine umfassende Dokumentation.
  • Die Zusammenarbeit mit Kunden ist wichtiger als die Vertragsverhandlung.
  • Das Reagieren auf Veränderung ist wichtiger als das Festhalten an Plänen.

Diese Leitsätze – häufig als Werte deklariert oder als Werte-Paare verstanden – beinhalten immer zwei Seiten. Die linke Seite (bspw. „Individuen und Interaktionen“) ist dabei wertvoller als die rechte (bspw. „Prozesse und Werkzeuge“). Natürlich darf die rechte Seite nicht zu weit in den Hintergrund rücken; bspw. lassen sich nicht alle Funktionen einer Software ohne Dokumentation nachvollziehen. Bei der Entwicklung von Lösungen ist also auch auf eine Ausgewogenheit der Werte-Paare zu achten.

In gewisser Weise beschreibt das Agile Manifest einen Verhaltenskodex, um Handlungen einer Entwicklung zu reflektieren und an definierten Prinzipien auszurichten. Darauf aufbauend liefert Scrum einen Rahmen, um die Arbeit gemeinschaftlich zu organisieren und erledigen.

Haltung und Werte in Scrum

Die Anzahl der Organisationen, die Scrum nutzen, wächst kontinuierlich. Unternehmen erhoffen sich mehr Flexibilität, schnellere Entwicklungszyklen oder niedrigere Kosten. Durch die Sprints, die Kommunikation zwischen Product Owner und Stakeholder und die gemeinsame Sprint Planung lässt sich die Flexibilität häufig steigern. Doch diese Flexibilität ist nicht kostenlos. Das Framework erfordert regelmäßige Kommunikation zwischen den Beteiligten in Form von Daily Standups, Sprint Planungen, Sprint Reviews, Retrospektiven und gegebenenfalls Skalierungen. Hinzu kommt der Aufwand, Backlogs zu pflegen, Arbeitspakete zu definieren, Aufwände zu schätzen und den Fortschritt zu dokumentieren. In anderen Worten: Scrum ist keine Abkürzung zu Unternehmenserfolg. Technische Herausforderungen bleiben bestehen, sie lassen sich aber vermutlich im Laufe einer Entwicklung mit neuem Wissen besser beurteilen als zu Projektbeginn. Damit sinkt das Risiko falscher Projektpläne und Versprechungen.

Damit das Vorgehen funktioniert, müssen Organisationen aber nicht nur lernen, die Regeln des Frameworks anzuwenden, und die Verantwortlichkeiten an geeignete Mitarbeiter zu übertragen. Es ist notwendig, ein agiles Mindset und eine offene Haltung zu entwickeln, und die Werte mit Leben zu füllen. Das Management muss sich von einem Command-and-Control-Führungsstil lösen. Das Team muss lernen, mit Verantwortung umzugehen und sie bewusst in Anspruch zu nehmen. Der Product Owner muss verstehen, dass er nicht der Vorgesetzte der Entwickler ist. Und der Scrum Master darf sich nicht als Projektleiter verstehen. Es geht also um

  • Selbstverpflichtung bzw. Commitment,
  • Mut,
  • Offenheit,
  • Fokus und
  • Respekt.

Das Commitment des Teams, das vereinbarte Sprint-Ziel zu erreichen, die Verpflichtung zu Qualität, Lernen und gemeinsam das Beste zu tun, ist wesentlich für die Zusammenarbeit und den Aufbau einer agilen Kultur.

Mut ist wichtig für den Erfolg des Teams, denn es geht darum, neue Dinge auszuprobieren, Fehler zuzugeben, bei Bedarf um Hilfe zu bitten, zu manchen Forderungen „nein“ zu sagen und ggf. den Status quo zu hinterfragen. Natürlich müssen auch der Scrum Master – bspw. bei der Beseitigung von Impediments – und der Product Owner – bspw. im Dialog mit Stakeholdern, die permanent und kurzfristig neue Dinge fordern – mutig sein.

Offenheit ist die Basis für eine Lernkultur, für Feedback und neue Ideen. Offenheit als Wert ermöglicht fundierte Entscheidungen, erhöht die Effizienz und schafft Vertrauen.

Trotz der Offenheit für neue Ideen ist es für die Arbeit im Team wichtig, sich bspw. im Sprint auf die Realisierung der vereinbarten Backlog Items zu fokussieren. Timeboxing, eine Definition of Ready und eine Definition of Done sind nützliche Hilfsmittel für den Fokus. Unterstützt wird der Fokus durch den Scrum Master, der versucht störende Einflüsse von den Entwicklern fernzuhalten, und dem Product Owner, der sich bspw. im Sprint Planning auf das „Warum“ und „Was“ und nicht auf das „Wie“ fokussiert.

Respekt als Wert ist essenziell für die Zusammenarbeit zwischen den Beteiligten. Es gilt die Ideen, Ansichten und Leistungen von anderen zu respektieren. Respekt ist ein zentraler Baustein für eine erfolgreiche und produktive Entwicklung.

Erst mit einem Mindset, das Commitment, Mut, Offenheit, Fokus und Respekt als Werte lebt, entfaltet das Framework die größten Vorteile.

Vorteile von Scrum

Da Vorhersagen und die Erstellung von realistischen Plänen bei der Entwicklung von Software und Systemen häufig schwierig sind, dreht Scrum den Ansatz um: Wissen entsteht aus Erfahrung und Erfahrung entsteht im Laufe einer Entwicklung.

In Verbindung mit dem iterativen Vorgehen, den Commitments auf das Product Goal, das Sprint Goal und die Definition of Done sowie dem frühzeitigen Erkennen von Hindernissen (den sogenannten Impediments), erhöht sich die Vorhersagbarkeit und das Entwicklungsrisiko sinkt.

Zusammengefasst bietet Scrum folgende Vorteile:

  • Einfaches Set aus Verantwortlichkeiten, Events und Artefakten; leicht zu verstehen und anzuwenden.
  • Hohe Flexibilität beim Arbeiten, dennoch klare Regeln und Prinzipien.
  • Konzentrierte Kommunikation zwischen den Verantwortlichkeiten.
  • Kurze Feedback-Zyklen.
  • Integration von Stakeholdern leicht möglich, bspw. im Sprint Review oder im Vorfeld des Sprint Plannings.
  • Transparenz der Arbeitsschritte und Zwischenergebnisse.
  • Die Fähigkeit, Abweichungen zu erkennen und zu korrigieren.
  • Die Möglichkeit, den gelebten Prozess im laufenden Projekt zu justieren.

 

Fragen im Kontext von Scrum

Es gibt eine Liste an Fragen im Kontext von Scrum. Auf einige der Fragen finden Sie Antworten in unserem Blog:

Sicherlich fallen Ihnen noch weitere Fragen ein. Melden Sie sich gerne bei uns und wir versuchen Ihre Fragen zu beantworten oder entsprechende Beiträge zu publizieren.

Impuls zum Diskutieren:

Glauben Sie der Scrum Guide definiert zu viele oder zu wenige Regeln? Und was wäre der Vorteil, wenn er mehr oder weniger definieren würde?

Hinweise:

[1] Vermissen Sie die „übliche“ grafische Darstellung des Frameworks? Wir haben uns bewusst für eine alternative Darstellung entschieden, denn aus unserer Sicht stimmen „üblicherweise“ die Proportionen nicht. Das Standup-Meeting dauert bspw. maximal 15 Minuten, nimmt aber grafisch häufig 1/4 der Sprintlänge ein, die zwischen einer Woche und einem Monat variiert. Das Inkrement ist meist kleiner als das Sprint Backlog, müsste aber größer sein, da es auch die Inkremente der vorherigen Sprints beinhaltet. Wir haben uns daher entschieden, eine andere Darstellung zu veröffentlichen.

[2] Hier finden Sie weitere Informationen zum Thema Accountability versus Rolle.

Wenn Sie sich für einen guten Podcast interessieren, empfehlen wir Ihnen gerne Scrum meistern.

Hier finden Sie ein Video über agiles Projektmanagement mit Scrum.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Was ist LeSS - Large-Scale Scrum?

Was ist LeSS – Large-Scale Scrum?

Wissen kompakt: Was ist ein Produktziel?

Was ist ein Produktziel?

Wissen kompakt: Was ist eine Projektorganisation?

Was ist eine Projektorganisation?