Sprint Planning

English
Sprint Planning, Sprint Planning Meeting, Sprint Negotiation

Sprint Planning ist ein Element ("Event") von Scrum. Scrum ist ein Managementsystem des Agilen Projektmanagements, mit dessen Hilfe Scrum-Teams komplexe, von Veränderung geprägte Entwicklungsaufgaben bearbeiten. Das Sprint Planning steht am Beginn jedes einzelnen Sprints (zeitlich fest definierter Abarbeitungszeitraum für ein Team). Es dient zur Festlegung der in diesem Sprint zu bearbeitenden Inhalten.

Sprint Planning
★★★★★
★★★★★
4
Kommentare 4
Zuletzt aktualisiert am
Download PDFDownload PDF
Download PDF (English)Download PDF (English)

Themen

Alle Themen

Sprint Planning

English
Sprint Planning, Sprint Planning Meeting, Sprint Negotiation

Sprint Planning ist ein Element ("Event") von Scrum. Scrum ist ein Managementsystem des Agilen Projektmanagements, mit dessen Hilfe Scrum-Teams komplexe, von Veränderung geprägte Entwicklungsaufgaben bearbeiten. Das Sprint Planning steht am Beginn jedes einzelnen Sprints (zeitlich fest definierter Abarbeitungszeitraum für ein Team). Es dient zur Festlegung der in diesem Sprint zu bearbeitenden Inhalten.

Sprint Planning

Einsatzmöglichkeiten

  • Planen der im kommenden Sprint zu erstellenden, in sich geschlossenen Teilprodukte oder Teilergebnisse (sog. "Produktinkremente")
  • Planen der Tätigkeiten, um diese Ergebnisse zu realisieren

 

Ergebnisse
  • Das vom Scrum-Team gemeinsam formulierte Sprint-Ziel ("Sprint Goal"). Das Sprint-Ziel beschreibt übergeordnet in ca. ein bis zwei Sätzen die im Sprint durch das Scrum-Team zu erbringende Leistung.
  • Das Sprint Backlog: eine vollständige Liste der zur Abarbeitung vereinbarten Backlog Items mit weiteren Informationen zur Bearbeitung.
  • Die Liste der Sprint Tasks, die zur Bearbeitung der einzelnen Backlog Items notwendig sind.
Vorteile
Kontinuität: Sprint Planning findet in einem definierten Rhythmus statt und gibt dadurch dem Entwicklungsprozess einen stabilen Rahmen.
Einvernehmlich und kollektiv: Das gesamte Scrum-Team plant die zu erstellenden Ergebnisse, die dafür erforderlichen Tätigkeiten und schätzt gemeinsam den Aufwand.
"Time-Boxed": Das Sprint-Planning hat eine festgelegte, stets gleiche Dauer von in der Regel mindestens vier, höchstens acht Stunden, abhängig von Teamgröße und Erfahrung der Mitarbeiter. Es wird dadurch für alle Verantwortlichen planbar.
Grenzen, Risiken, Nachteile
Die strenge zeitliche Einteilung kann einen starken Einschnitt in die gewohnten Arbeitsabläufe des Projektteams darstellen.
Die iterative Abschätzung der Sprints lässt keine (sinnvolle) Abarbeitung des Projekts zu fixierter Dauer (terminierte Deadline) und fixiertem Aufwand (Festpreis) zu.
Der Fokus auf Teamarbeit kann, in Verbindung mit dem hohen Anspruch an die Kommunikation, Einzelkämpfer ausgrenzen.
Voraussetzungen
  • Einsatz von Scrum oder einer angepassten Variation von Scrum
  • hohe Disziplin bei allen Teilnehmern hinsichtlich regelmäßiger Teilnahme und aktiver Mitarbeit
  • Die einzelnen Scrum-Events finden regelmäßig statt (Daily Srum, Sprint Review, Sprint Retrospective und Sprint Planning). Der Zeitrahmen eines Sprints, sowie die Zeitpunkte der einzelnen Events wurden vorab festgelegt.
  • Das Unternehmen muss die jeweils benötigten Mitarbeiter (z.B. Experten für bestimmte Fragestellungen) für das Sprint Planning zur Verfügung stellen.
Qualifizierung

Der Scrum Master muss mit Scrum im Detail vertraut sein. Eine Zertifizierung als Scrum Master ist sinnvoll. Darüber hinaus sollte er über Moderationserfahrung verfügen; Kenntnisse im Konfliktmanagement können hilfreich sein.

Der Product Owner muss mit seiner Rollenbeschreibung gemäß Scrum vertraut sein. Eine Zertifizierung als Product Owner ist sinnvoll.

Die am Sprint Planning beteiligten Mitglieder des Entwicklungsteams sollten die Grundzüge von Scrum und die Regeln des Sprint Plannings kennen.

Benötigte Informationen
  • Das Product Backlog bzw. die nach Priorität sortierte Liste der für den Sprint möglichen Product Backlog Items. Ein Backlog Item stellt eine qualifizierte Anforderung bzw. eine User Story dar.
  • Der aktuelle Wert der Velocity des Entwicklungsteams. Velocitiy ist der von einem Entwicklungsteam in einem Sprint durchschnittlich erbrachte Leistungsumfang (z.B. in Story Points oder Task Points angegeben). Zu Beginn eines Projekts ist der Velocity-Wert ungenau und basiert auf Erfahrungen, sofern es sich um ein neu zusammengesetztes Team handelt. Ein verlässlicher, für das aktuelle Team spezifischer Wert, ergibt sich erst nach mehreren Sprints.
  • Vorläufige, relative Aufwandsschätzungen der Product Backlog Items (z.B. in Story-Points oder Task-Points)
  • Das letzte Produktinkrement (sofern es sich nicht um den ersten Sprint handelt). Ein "Produktinkrement" oder kurz: "Inkrement" beschreibt die innerhalb eines Sprints erstellte Software. Diese Software muss die vorab festgelegten Anforderungen des Product Backlogs erfüllen und darüber hinaus laufähig, getestet und dokumentiert sein.
  • Die Arbeitskapazität des Entwicklungsteams (unter Berücksichtigung geplanter Fehlzeiten). Das Entwicklungsteam umfasst alle Personen, welche für die Bearbeitung der einzelnen Sprint Tasks zuständig sind. Dabei handelt es sich meist um Teammitglieder unterschiedlicher Fachrichtungen und Spezialisierungen, nicht nur um die reinen Software-Entwickler.
  • "Definition of Done": Allgemeine Qualitätskriterien / Abnahmekriterien, die für einzelne Sprint Tasks und das Produktinkrement am Ende des Sprints gelten.
Benötigte Hilfsmittel

Zur Besprechung der Backlog Items und der Sprint Tasks:

  • Whiteboard und Board-Marker
  • Alternativ: Flipchart und Marker
  • Alternativ: Haftnotizen und Pinn-Nadeln, bzw. Klebestreifen zur Befestigung

 

Für die Arbeit mit verteilten Teams in Verbindung mit digitalen Kommunikationslösungen:

  • Arbeitsplatz mit Internetanbindung – inklusive entsprechender Software und Lizenzen
  • Headset bzw. Mikrofon und Lautsprecher zur gegenseitigen Verständigung
  • Optional: Webcam zur Bildübertragung

 

Herkunft

Scrum wurde in den frühen 1990er Jahren durch Ken Sutherland und Ken Schwaber erdacht (veröffentlicht unter dem Namen: "SCRUM Software Development Process"). Die Ausarbeitung der Idee basiert auf der Publikation "New New Product Development Game", in der Hirotaka Takeuchi und Ikujiro Nonaka 1986 die Entwicklung eines gemeinsamen Ziels durch Iterationen beschrieben. Besondere Schwerpunkte waren hierbei Geschwindigkeit und Flexibilität. Die aktuell gültige Version von Scrum ist im sogenannten "Scrum Guide" dokumentiert, der in mehreren Sprachen frei zum Download auf der Website www.scrumguides.org zur Verfügung steht.

  1. Durchführung: Schritt für Schritt
  2. Schritt 1: Bereiten Sie das Sprint Planning Meeting vor!
  3. Schritt 2: Wählen Sie die Backlog Items aus und formulieren Sie das Sprint-Ziel!
  4. Schritt 3: Erstellen Sie das vollständige Sprint Backlog!

Durchführung: Schritt für Schritt

Schritt 1: Bereiten Sie das Sprint Planning Meeting vor!

Aufgaben des Scrum Masters

Der Scrum Master ist für die Organisation aller Scrum Events verantwortlich. Dazu gehört auch das Sprint Planning Meeting, das am Beginn jedes einzelnen Sprints steht. Der Scrum Master sorgt für die Räumlichkeiten und klärt Fragen der Teammitglieder zu den Themen "Scrum" sowie "Sprint Planning". Eine spätere Delegation an andere Mitglieder des Scrum-Teams ist möglich. Falls zur Klärung von Detailfragen erforderlich, lädt der Organisator zusätzliche Spezialisten ein.

Handelt es sich um den ersten Sprint des Projekts, stimmt der Scrum Master die Taktung der Events mit dem gesamten Team ab. Die Standardtaktung der Sprints beträgt einen Monat. Für das Sprint Planning Meeting gibt der Scrum Guide acht Stunden (einen Arbeitstag) vor. Wird eine kürzere Sprint-Dauer vereinbart, reduziert sich direkt proportional die Zeit des Sprint Planning Meetings (z.B.: Halbierung der Sprint-Dauer auf zwei Wochen führt zu einer Dauer des Sprint Planning von vier Stunden). Der Scrum Guide sieht acht Stunden als maximale Dauer für das Sprint Planning Meeting vor, dementsprechend sind auch keine Sprints von mehr als einem Monat vorgesehen.

Aufgaben des Product Owners

Der Product Owner priorisiert die abzuarbeitenden Product Backlog Items. Er wählt eigenständig die aus seiner Sicht notwendigen Backlog Items anhand von Abhängigkeiten und der fachlichen Priorität aus. Hierzu stimmt der Product Owner die Priorisierung einzeln abzuliefernder Features mit entsprechenden Stakeholdern ab.

Als Faustregel gilt, dass doppelt so viele Backlog Items vorbereitet werden sollten wie während eines Sprints in etwa abgearbeitet werden können. Dies hat zwei Gründe:

  1. Das einzelne Product Backlog Item wurde noch nicht genau geschätzt. Daher können einzelne Product Backlog Items evtl. weniger aufwendig als erwartet sein. Durch den Puffer zusätzlicher Backlog Items wird gewährleistet, dass auf jeden Fall ein vollständiges Sprint Backlog zusammengestellt werden kann.
  2. Die Vorbesprechung weiterer Product Backlog Items für den auf den aktuellen Sprint folgenden Sprint dient der Orientierung des Scrum-Teams und der Information weiterer Stakeholder.

Bild 1 zeigt die Beziehungen der einzelnen Elemente: Product (Backlog), Sprint (Backlog) und Sprint Task aus Sicht des Sprint Planning.

>Bild 1: Zusammenhang von Product Backlog, Sprint Backlog, Backlog Item und Sprint Task.
Bild vergrößern

Da das Team im Sprint Planning entscheidet, wie viele Product Backlog Items in einem Sprint abgearbeitet werden können, benötigt es hierfür alle Informationen zur möglichst genauen Schätzung von Aufwand und Abhängigkeiten. Der Product Owner stimmt deshalb die zur Abarbeitung notwendigen Details für die ausgewählten Backlog Items (z.B. Schnittstellen-Informationen, rechtlicher Rahmen) mit den Stakeholdern ab. Am Ende der Vorbereitung hält der Product Owner die priorisierte Liste der Product Backlog Items bereit und ist in der Lage, diese im Scrum Planning Meeting fachlich zu erläutern.

Bei Bedarf klärt er gemeinsam mit dem Scrum Master die Gegebenheiten und die Art des Austauschs (z.B. Kommunikationsmedium, Methoden, zeitlicher Umfang und Ort) für das Sprint Planning ab.

Praxistipps ...

Varianten ...

Ergänzende Methoden

Stakeholdermanagement

Berücksichtigen Sie die Ziele und Interessen der Stakeholder und identifizieren Sie mögliche Projektgegner! Definieren Sie gezielte Maßnahmen, um Schaden vom Projekt abzuwenden. Binden Sie Befürworter so ein, dass sie positiv auf den Projektfortschritt einwirken.

Mind Mapping

Lassen Sie Ihren Assoziationen freien Lauf und bringen Sie zugleich Ihre Ideen strukturiert aufs Papier! Ob allein oder im Team - Mind Mapping ist die Methode erster Wahl für alle Aufgaben im Projekt.

Kanban Light

Sorgen Sie für hohe Transparenz bei der Aufgabenplanung für das Projektteam und verkürzen Sie die Durchlaufzeit einzelner Aufgaben durch die Überwachung und Steuerung entsprechender Verantwortlichkeiten. Regeltermine fördern den teaminternen Austausch.

Team Estimation Game

Mittels kollektiver Betrachtung schätzen Sie mit hoher Genauigkeit und dank des kurzen und intuitiv verständlichen Regelwerks mit geringem Aufwand. Die Gestaltung als Spiel fördert die aktive Mitarbeit in der Gruppe.

Planning Poker

Schätzen Sie spielend einfach die relativen Aufwände für die User Storys oder anderen Aufgaben zusammen mit dem Umsetzungsteam!

Sprint Review

Halten Sie Ihr agiles Projekt auf Kurs und beschließen Sie notwendige Maßnahmen zur Steuerung, in dem Sie nach jedem Sprint das Feedback der Stakeholder zum Produktinkrement einholen!

Fachartikel zur Methode

Scrum – eine Einführung

Viele Software-Produkte entsprechen nach Fertigstellung nicht den Vorstellungen des Kunden.
Zum Artikel

Scrum-Projekte planen mit System

Teil 1:
Besonderheiten und Voraussetzungen

Genau wie in traditionellen Projekten nimmt auch in Scrum die Planung eine zentrale Rolle ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt.

Zum Artikel

Scrum-Projekte planen mit System

Teil 2:
Vorgehen in der Praxis
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden.
Zum Artikel

Häufige Stolperfallen in Scrum

Scrum schreibt als agile Projektmanagement-Methode nur wenige Rollen, eine überschaubare Menge an Regeln und wenige Dokumente vor. So wirkt die Anwendung von Scrum auf den ersten Blick bestechend einfach.

Zum Artikel

Agile Softwareentwicklung mit Scrum und User Stories

Das agile Vorgehensmodell Scrum erfreut sich in der Softwareentwicklung zunehmender Beliebtheit, da es ein einfaches und flexibles Vorgehen erlaubt. Allerdings gibt es in Scrum keine Vorgaben, wie Anforderungen von Anwendern erfasst und …

Zum Artikel

Scrum in SAP-Projekten einsetzen

Teil 1:
Projektinitiierung und Planung
Für IT-Projekte bringt die Scrum-Methodik viele Vorteile, der Einsatz in SAP-Entwicklungsprojekten scheint daher naheliegend. Doch in der Praxis bestehen hier einige Herausforderungen. So birgt z.B.
Zum Artikel

Scrum in SAP-Projekten einsetzen

Teil 2:
Projektdurchführung und Ausblick
Im ersten Teil haben Sie erfahren, was es bei der Vorbereitung und Planung von Scrum in SAP-Projekten zu berücksichtigen gilt.
Zum Artikel
Vorschaubild

Scrum und Kanban sinnvoll kombinieren

Scrum und Kanban kommen in der Softwareentwicklung immer häufiger zum Einsatz und haben in der Familie der Agilen Methoden inzwischen ihren festen Platz eingenommen. Doch sind diese beiden Ansätze überhaupt miteinander vereinbar?

Zum Artikel

Scrum + Critical Chain = Reliable Scrum

Scrum ist bei Software-Entwicklungen zwar weit verbreitet und bewährt, allerdings garantiert es weder Termintreue noch einen bestimmten Leistungsumfang.

Zum Artikel
Vorschaubild

Der Agile Projektleiter – Bindeglied zwischen Scrum und klassischem Umfeld

Während die Entwicklungsabteilungen in vielen Unternehmen mittlerweile Scrum verwenden, erfolgt die Projektabwicklung im restlichen Unternehmen weiterhin nach einem klassischen Vorgehen. Diese beiden Welten lassen sich mithilfe der Rolle des …

Zum Artikel
Vorschaubild

Wie führe ich als Scrum Master? Führungsstile für die Praxis

Der Scrum Master hat zwar innerhalb seines Teams eine hervorgehobene Stellung, in der Regel verfügt er aber über keine Weisungsbefugnis und muss immer mit den Teammitgliedern auf Augenhöhe agieren.

Zum Artikel
Vorschaubild

Scrum mit Scrum im Unternehmen einführen

Scrum liegt im Trend, die vielen Erfolge in der IT-Entwicklung mit dieser Methode lassen sich nicht mehr von der Hand weisen. Doch die Scrum-Einführung scheitert in der Praxis häufig an einem unzureichenden Change Management – u.a.

Zum Artikel

Aufgabengebiete

Planen & Kalkulieren
Überwachen & Steuern
Scrum-Methoden
Agile

Keywords

Scrum
Planen
Agile
Leistungsumfang
Moderieren
Agile Methoden
Projektstart

Links

Download der offiziellen Scrum Guide Versionen in verschiedenen Sprachen
Entstehungsgeschichte von Scrum
SAFe – Scaled Agile Framework V3.0
Download PDFDownload PDF
Download PDF (English)Download PDF (English)

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
4 Kommentare anzeigen & selbst mitreden!
Gesamt
★★★★★
★★★★★
Bewertungen 4
Kommentare 4

Themen

Alle Themen

Mehr zum Thema

Excel-Vorlage Ressourcenauslastung

Excel-Vorlage Ressourcenauslastung

Ressourcenengpässe zählen zu den typischen Problemen in einer Multiprojektumgebung. Abhilfe schafft eine Ressourcenplanung auf Basis klarer Projektprioritäten. Dazu ist keine Spezialsoftware nötig – die hier vorgestellte Excel-Lösung reicht in vielen Fällen völlig aus.
Zum Tool
Ja zum Projekt! Zustimmung und Begeisterung wecken

Ja zum Projekt! Zustimmung und Begeisterung wecken

E-Book mit 119 Seiten und 2 Arbeitshilfen
Ein Projekt ohne Akzeptanz hat wenig Aussicht auf Erfolg. Erfahren Sie in diesem Spotlight, wie Sie Ihre Projektidee von Beginn an erfolgreich vermarkten.
Zum E-Book

Artikel

Mit Datenbalken Projektdaten besser vergleichen

So holen Sie sich Rückendeckung vom Topmanagement

Mit Diagrammvorlagen in Excel und PowerPoint für einheitliche Optik sorgen

Mit einer starken Positionierung zum Wunschjob

Projektmanagement der Zukunft: Wie steht es um die Transformation?

Eine agile Transition mit Design Thinking

Mit Excel-Datenschnitten in nur 2 Schritten zum interaktiven Info-Cockpit

Frauen im Projekt: 3 Tipps für ein starkes Auftreten

Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Pünktlich zum 25. Geburtstag von Scrum und drei Jahre nach der jüngsten Aktualisierung des Scrum Guide haben die Erfinder dieses wohl verbreitetsten agilen Rahmenwerks, Jeff Sutherland und Ken Schwaber, am 18. November eine …

Zum Blog
©️ VIAR PRO studio - stock.adobe.com | Scrum Master und Product Owner Zertifizierungskurs

Zertifizierter Product Owner und Scrum Master

Lassen Sie sich in einem nur 3-tägigen, kombinierten Praxistraining zum Product Owner und zum Scrum Master zertifizieren.

Datum:

-
Zur Weiterbildung

Mehr zum Thema

LeistungsumfangPlanenTeamführung

Alle Kommentare (4)

Peter
Jetter

03.12.2015

"Die iterative Abschätzung der Sprints lässt keine (sinnvolle) Abarbeitung des Projekts zu fixierter Dauer (terminierte Deadline) und fixiertem Aufwand (Festpreis) zu." Wie kommen Sie zu dieser Aussage? Nach meinem Verständnis sind in Scrum Qulalitä, time(date) und budget(HC, stabile Teams!) in der Regel fest. Variabel ist der Scope. Ziel ist den gelieferten Business Value innerhalb des time und budget Rahmens zu maximieren. Der scope wird dazu stets neu priorisiert, damit stets das Produktinkrement mit dem höchsten Business Value realisiert wird. Problem- und Lösungsverständnis entwickeln sich -in gegenseitiger Wechselwirkung- über die Zeit.

 

Daniel
Reinold

04.12.2015

Vielen Dank für Ihren Beitrag. In wie weit die Zielsetzung im Allgemeinen fest oder variabel ist, möchte ich in der Methode „Sprint Planning“ nicht festlegen. Durch ergänzende/verknüpfende Methoden mag eine Bearbeitung zum Festpreis möglich sein (siehe z.B.: https://www.projektmagazin.de/artikel/sechs-schritten-zum-agilen-festpreis_1089027). Die allgemeine Diskussion zum Thema ist immer noch im Gange (z.B.: „Agiler Festpreis“). Da wir hier eine praxisnahe Darstellung liefern möchten, sind die Leser (und ich) dankbar für entsprechende Beispiele.

 

Martin
Rohner

14.12.2015

★★★★★
★★★★★
Ich möchte mich hier Peter Jetter anschliessen. Das ist doch genau der Vorteil von SCRUM: fixe Kosten, da fixe Ressourcen (in der Regel) weil ja der Scope noch nicht ganz klar ist von Anfang an. Und das ist die Hauptaufgabe von PO und SCRUM Master, diesen durch Priorisierung und genaue Schätzung in den Backlog zu bringen. Somit kann genau eine sinnvolle Abarbeitung erzielt warden, indem die dem Endnutzer wichtigen Funktionen möglichst schnell zur Verfügung gestellt werden. Ich habe mittlerweile als externer Projektleiter / SCRUM Master genau aus diesen Gründen (Fixpreis, das Wichtige zuerst) schon mehrere Kundenprojekte erfolgreich geleitet. Ausschlaggebend für den Erfolg war jeweils vor allem dass die entsprechenden Rollen und Verantwortlichkeiten klar waren und die Spielregeln von Anfang an (und immer mal wieder) kommuniziert und eingehalten wurden. Im generellen bin ich sowieso der Meinung, dass die Sprint Planung als solches eigentlich gar keine Methode ist, sondern ein Werkzeug in der Methode SCRUM, resp. agiles Projektmanagement, aber dies ist einfach meine Sicht.

 

Guest

14.04.2016

Auch ich finde die Formulierung "Die iterative Abschätzung der Sprints lässt keine (sinnvolle) Abarbeitung des Projekts zu fixierter Dauer (terminierte Deadline) und fixiertem Aufwand (Festpreis) zu." unglücklich. Es stimmt schon, dass das Sprint Planning auf die Planung des nächsten Sprints fokussiert. Betrachte ich also isoliert nur dieses Event ist natürlich eine Sprint-übergreifende Planung (die dann die "sinnvolle" Abarbeitung eines Projekts ermöglicht) nicht präsent. Das Problem hierbei ist aber die isolierte Betrachtung; und das Vernachlässigen der Aufgaben des Product Owners, der genau diese übergreifenden Themen bei der Pflege des Product Backlogs stets im Auge behält. Der Eindruck, der durch die Äußerung entsteht, ist, dass Scrum für diese Art der Planung nicht geeignet sei (insbesondere durch die Verwendung einer Wertung in Form von "keine (sinnvolle) Abarbeitung". Dies ist schlicht falsch. Es ist gerade der Vorteil der iterativen Abarbeitung insbesondere bei festem Termin und/oder Festpreis dem Kunden das unter diesen Rahmenbedingungen beste Produkt zu liefern. Dies wird -- gerade durch das iterative Vorgehen -- ermöglicht, weil dem Kunden enge Feedbackschleifen angeboten werden. Insofern schließe ich mich den Äußerungen von Peter Jetter und Martin Rohner an. Als weiteres: Den als ersten genannten Punkt unter "Nachteil / Grenzen / Risiken" verstehe ich auch nicht. Schließlich ist agiles Vorgehen nun mal verschieden vom klassischen Projekt. Konsequenterweise müssen sich Personen, die sich hierauf einlassen mit Veränderungen umgehen. Dies allerdings unter der Rubrik "Nachteil / Grenzen / Risiken" zu führen, empfinde ich als unglücklich. Denn dies gilt doch für jedwede anderen Arbeitsweisen, die für ein Projektteam neu sind und die "einen starken Einschnitt in die gewohnten Arbeitsabläufe des Projektteams darstellen".