Warum wird ein Scrum-Projekt begonnen?

Am Anfang steht eine Produkt-Vision. Das ist eine grobe Vorstellung vom Produkt oder Projektergebnis, die die Geschäftsleitung oder der Product Owner als Auftraggeber hat. Für eine solche Produkt-Vision und Vorstellung gibt es meist einen konkreten Anlass oder Auslöser.

Beispiele dafür sind:

  • Anwender oder Kunden sind mit einem bestehenden Produkt nicht mehr zufrieden, sie haben andere Anforderungen und Wünsche, weil Wettbewerber das auch bieten.
  • Es gibt neue, bessere technische Möglichkeiten für ein bestehendes oder ganz neues Produkt, die man nutzen will.
  • Technik ist fehleranfällig, Prozesse sind schwerfällig und teuer; das soll verbessert werden.
  • Es gibt eine gesetzliche Anforderung oder andere Rahmenbedingungen, die es notwendig machen, dass etwas umgesetzt oder geändert wird.

Letztlich wollen Geschäftsleitung und Product Owner ein Produkt oder ein Projektergebnis, das einen größeren Nutzen bringt oder Schaden für das Unternehmen abwendet. Mit solchen Auslösern und Anlässen startet ein Scrum-Projekt.

Das läuft dann aber anders ab als ein klassisches Projekt; es gelten die Regeln des agilen Projektmanagements. Der Scrum-Prozess ist darauf ausgerichtet, die Anforderungen der Auftraggeber, der Nutzer, der Kunden und des Product Owners, möglichst korrekt zu erfassen, dann ohne großen Planungsaufwand zu bearbeiten und am Ende funktionierende Ergebnisse zu liefern. Im Einzelnen werden dazu folgende Schritte durchgeführt.

1. Anforderungen für das Scrum-Projekt ermitteln und in User Storys und Story Cards festhalten

Aus der ersten, aber möglichst schon anschaulichen und verständlichen Produkt-Vision und der groben Produkt-Vorstellung lassen sich einzelne Funktionen und Merkmale des Produkts oder der Lösung ableiten, die im Projekt zu entwickeln sind. Die Kunden und Nutzer beschreiben ihre Anforderungen und Erwartungen dazu als User Story aus ihrer Anwenderperspektive und in ihren Worten – nicht im Jargon der Techniker.

Daraus werden die Funktionen und Merkmale abgleitet, die das Produkt haben soll. Sie werden auf einer Story Card formuliert. Die Story Card ist das Medium, auf dem die User Story möglichst exakt erfasst und dargestellt wird. Die User Storys und Story Cards können im Gespräch oder in einem Workshop mit dem Product Owner und gegebenenfalls mit ausgewählten Nutzern oder Kunden ermittelt und formuliert werden.

Mit diesen Anforderungen wird bereits deutlich, welche Ressourcen das Projekt braucht. Das betrifft zum einen die Art der Qualifikationen und des Know-hows im Projektteam und zum anderen eine grobe Schätzung des Aufwands für die Entwicklung des Produkts oder der Lösung.

2. Product-Backlog und Backlog-Items erarbeiten

Aus den Anforderungen des Product Owners und der Nutzer oder Kunden und aus den User Storys wird ein Product Backlog zusammengestellt. Das ist eine Sammlung sämtlicher Funktionen und Merkmale, die das Produkt oder die Lösung für das Projekt haben soll.

Im Product Backlog können außer Merkmalen und Funktionen auch Aufgaben oder Arbeitspakete für das Scrum-Projekt zusammengestellt sein. Eine einzelne Aufgabe, eine Funktion oder ein Merkmal wird als Backlog-Item bezeichnet.

Am Anfang ist die Beschreibung der einzelnen Backlog-Items noch grob. Denn im Projektteam ist noch nicht genau geklärt, welche Teilaufgaben mit einer Lösung verknüpft sind oder welche Eigenschaften die Funktion im Detail haben soll. Das ergibt sich, wenn das jeweilige Backlog-Item entwickelt oder ausgearbeitet wird.

Dazu müssen gegebenenfalls weitere Gespräche mit dem Nutzer, Kunden oder Project Owner geführt werden. Im Projektverlauf werden die einzelnen Aufgaben, Funktionen und Merkmale deshalb immer detaillierter formuliert und entsprechend beschrieben.

3. Definition of Done festlegen

Dann ist es notwendig, bei der Beschreibung des Backlog-Items genau zu klären und festzulegen, was zeigt, dass das Item fertig ist. Dies wird mit der Beschreibung einer „Definition of Done“ erfüllt. Dazu werden Indikatoren, Funktionen oder Tests benannt, die nach der Entwicklung des Ergebnisses durchgeführt werden und bestätigen, dass die Lösung funktioniert oder ein Produktmerkmal vorhanden ist.

4. Entwicklungsaufwand mit Story Points darstellen

Wenn die Anforderungen der Nutzer, Kunden oder des Product Owners geklärt sind, muss das Projektteam abschätzen, wie komplex eine Aufgabe, Funktion oder Merkmal, also das einzelne Backlog-Item, ist. Die Komplexität ist meistens ein Indikator für den (zeitlichen) Aufwand für die Realisierung. Diese Schätzung wird bei Scrum in Story Points ausgedrückt.

Ein Backlog-Item mit 10 Story Points ist doppelt so komplex und aufwendig wie ein Backlog-Item mit 5 Story Points. Wie viele Stunden Entwicklungsaufwand mit einem Story Point verbunden sind, ergibt sich aus der Erfahrung oder aus dem Projektverlauf. Für eine Zeit- und Kostenkalkulation kann ein Story Point mit einem Zeit- oder Geldfaktor verknüpft werden.

5. Prioritäten für Backlog-Items vergeben

Im nächsten Schritt werden Prioritäten vergeben. Eine hohe Priorität erhalten die Aufgaben, Merkmale und Funktionen, die zur Zufriedenheit der Anwender besonders viel beitragen, indem sie deren besonders wichtigen Anforderungen erfüllen. Maßgeblich ist auch, dass das Produkt und das Projektergebnis insgesamt am Ende des Projekts „funktionieren“ und eine Lösung sind, die für den Anwender brauchbar ist und einen Vorteil bringt.

Eine geringere Priorität erhalten solche Aufgaben, Merkmale und Funktionen, die mit Anforderungen verbunden sind, die für den Anwender nicht so wichtig sind. Sie werden mit anderen zusammengelegt, werden verschoben, zurückgestellt oder gar nicht entwickelt, weil sie nicht in den Zeitrahmen und ins Budget passen.

Möglich ist, dass diese weniger wichtigen Aufgaben, Merkmale und Funktionen bei einer Überarbeitung oder bei der Erweiterung des Produkts oder der Lösung entwickelt werden. Im Bereich der Software-Entwicklung spricht man von einem Release-Wechsel.

6. Ablauf des Projekts besprechen

In einer ersten Besprechung des Scrum-Masters mit seinem Projektteam zum Projektablauf werden die Rahmenbedingungen abgesteckt und ein gemeinsames Verständnis vom Produkt und den wichtigen Aufgaben sowie vom zeitlichen Ablauf entwickelt. Diese Fragen werden dazu besprochen:

  • Wie soll der allgemeine Aufbau des Produkts oder der Lösung aussehen?
  • Was sind die Meilensteine?
  • Welche Funktionen und Aufgaben müssen bis zu welchem Zeitpunkt in jedem Fall erledigt sein?
  • Was sind die Teilziele für eine einzelne Funktion oder Aufgabe?
  • In welche Teilschritte, Sprints, lässt sich das Projekt untergliedern?
  • Auf welche Details oder Besonderheiten ist zu achten?
  • Welche Konventionen und Schnittstellen sind einzuhalten?
  • Wo und wann kann sich das Team regelmäßig für den Daily Scrum (täglich!) treffen?

Ein wesentliches Merkmal von Scrum-Projekten ist, dass die Ablaufplanung nur grob ist und kein großer Aufwand in die Detailplanung investiert wird; denn im Laufe des Projekts wird sich ohnehin vieles wieder ändern. Wichtiger ist, dass ein gemeinsames Verständnis im Projektteam dazu entsteht, was die K.-o.-Kriterien sind, welche Ziele besonders wichtig sind und welche Meilensteine beachtet werden müssen.

7. Sprint Planning: Einzelne Aufgaben bestimmen

Wenn die Ziele und Rahmenbedingungen geklärt sind, erfolgt das Sprint Planning. Dazu bespricht das Projektteam, wie die Backlog-Items aus dem Product Backlog in Einzel- oder Teilaufgaben zerlegt werden. Diese werden dann innerhalb sogenannter Sprints geplant und bearbeitet.

Ein Sprint ist ein Arbeitszyklus (Teilschritt oder Phase) im Projekt, in dem jeder Projektmitarbeiter die von ihm ausgewählte Teilaufgabe (Sprint-Task) bearbeitet und eine fertige Teillösung dafür liefert. Die Zeit für einen Sprint hängt vom Umfang und von der Komplexität der jeweils bearbeiteten Aufgaben ab. Sie wird als sogenannte Time Box festgelegt und kann ein bis vier Wochen umfassen.

Abbildung 1 zeigt im Überblick, wie dieser Kernprozess im Scrum-Projekt, der Sprint, funktioniert.

Abbildung 1: Scrum-Prozess und Sprint im Überblick

Das Ergebnis des Sprint Planning sind die Sprint-Tasks oder Tickets. Diese Teilaufgaben werden im Sprint Backlog (Maßnahmenplan) aufgeführt und am Sprint-Taskboard visualisiert. Das Sprint Backlog und das Taskboard sind gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwicklerteam für den nächsten Arbeitszyklus (Sprint). Jedes Teammitglied übernimmt eigenverantwortlich eine Teilaufgabe beziehungsweise ein Ticket und verpflichtet sich damit, dafür eine Lösung zu entwickeln oder zu finden.

8. Aufgabendurchlauf mit dem Sprint Taskboard oder Kanban-Board steuern

Die Planung und der Durchlauf der einzelnen Aufgaben (Sprint-Tasks) wird mit einem Sprint-Taskboard für alle Projektmitglieder sichtbar. Das Taskboard kann in Form eines Kanban-Boards stärker untergliedert und verbessert werden. Das Kanban-Board macht anschaulich, in welcher Phase sich eine Sprint-Task oder ein Ticket gerade befindet. Es bildet die Wertschöpfungskette des Projekts ab.

Wichtig ist: Es werden nur so viele Tickets für die Bearbeitung freigegeben, wie vom Projektteam bearbeitet werden können. Geht es an einer Stelle nicht voran, stauen sich dort die Tickets. Es wird schnell sichtbar, wo der Engpass liegt und was getan werden kann. Eilige Tickets können beispielsweise vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig.

Abbildung 2 zeigt den Aufbau eines Kanban-Boards im Scrum-Projekt. An einer Wandtafel sind alle einzelnen Aufgaben bis zum nächsten Meilenstein auf Karten formuliert. Engpässe oder eilige Tickets können farblich markiert werden. So sind der Arbeitsablauf, der Stand der Arbeiten und die Engpässe für alle immer sichtbar.

Abbildung 2: Kanban-Board als detailliertes Sprint-Taskboard

9. Aufgaben erledigen

Im Sprint arbeiten die Teammitglieder an ihren Aufgaben (Sprint-Tasks). Die Projektmitarbeiter und Entwickler orientieren sich dabei an den Story Cards, mit deren Hilfe sie prüfen und testen können, ob sie eine gute Lösung entwickelt haben. Sie haben dafür den mit der Time Box definierten Zeitrahmen.

Die Teammitglieder haben deshalb den Zeitplan, den Aufwand und die Meilensteine im Blick, um im vereinbarten Zeitrahmen und Kostenrahmen zu bleiben. Die Story Points zeigen, wie viel Budget zur Verfügung steht.

10. Daily Scrum: Lösungen regelmäßig besprechen

Während eines täglichen, 15-minütigen Treffens, dem eigentlichen Daily Scrum (Gedränge), berichtet jeder der Reihe nach:

  • Was wurde seit dem letzten Scrum gemacht?
  • Was ist bis zum nächsten Scrum zu tun?
  • Was behindert bei der Arbeit oder was verhindert die weitere Bearbeitung?

Die Probleme werden im Impediment Backlog festgehalten. Der Scrum-Master muss diese Hindernisse aufgreifen und helfen, dass sie beseitigt werden. Die Projektmitglieder können mit dem Arbeitsfortschritt erkennen, ob der geplante Zeitaufwand, wie er in den Story Points dargestellt ist, dem tatsächlichen Aufwand entspricht. Ungeplanter Aufwand und seine Ursachen werden beim Daily Scrum besprochen.

11. Plan- und Ist-Aufwand im Burn-Down-Chart darstellen

In einem Sprint-Burn-Down-Chart wird sichtbar gemacht, wie das Projekt voranschreitet. Dazu wird festgehalten, welche Ressourcen oder Arbeitszeiten bereits verbraucht wurden. Dieser Ist-Aufwand wird mit dem Plan-Aufwand verglichen und in einem Diagramm, dem Burn-Down-Chart bei Scrum, dargestellt.

Das Burn-Down-Chart ist eine einfache Abbildung, die sichtbar macht, ob das Projekt im ursprünglich vereinbarten Zeit- und Kostenrahmen bleibt. Oder ob Budget oder Zeitplan angepasst werden müssen. Durch die täglichen Treffen können diese sehr aktuell geführt und Korrekturmaßnahmen sehr schnell eingeleitet werden. Abbildung 3 zeigt, wie ein Burn-Down-Chart für einen Sprint aussehen kann.

Abbildung 3: Burn-Down-Chart für das Controlling im Scrum-Sprint

12. Lösungen im Sprint-Review-Meeting als fertig abnehmen – nächste Schritte

Jeder Sprint wird durch ein Sprint-Review-Meeting abgeschlossen. Das Team stellt die Ergebnisse, das sogenannte Product Increment, dem Product Owner oder den Kunden und Anwendern vor. Sie müssen die Lösungen akzeptieren und abnehmen.

Dazu wird geprüft, ob das Teilergebnis aus diesem Sprint (Product Increment) der mit dem Product Backlog festgelegten Definition of Done entspricht. Falls der Product Owner nicht zufrieden ist, muss das Produkt verbessert werden. Es wird festgehalten, was nachbearbeitet werden muss.

Ist das Teilprodukt, das in diesem Sprint erstellt wurde, in Ordnung und vom Product Owner und den Anwendern oder Kunden abgenommen, werden die nächsten Aufgaben aus dem Product Backlog bearbeitet. Dabei wird wieder die grobe Beschreibung im Product Backlog geprüft und detailliert und für den nächsten Sprint eingeplant. Im Rahmen dieses Product-Backlog-Refinements kann sich auch herausstellen, dass einzelne Backlog-Items nicht mehr oder erst später gebraucht werden.

13. Scrum Velocity ermitteln

Mit jedem Sprint wird klar, wie schnell das Team im Projekt insgesamt vorankommt. Um diese Geschwindigkeit zu ermitteln, wird ein sogenanntes Velocity-Chart erstellt und nach jedem Sprint aktualisiert. Das hat zwei Zwecke:

  • Das Team lernt, ob seine Einschätzungen zum Aufwand und zum Zeitablauf realistisch waren und ob Änderungen im Arbeitsablauf geholfen haben; damit wird das Sprint Planning (Schritt 7) genauer.
  • Der Product Owner kann aus dem Velocity-Chart auch erkennen, bis wann er mit dem Projektabschluss und dem fertigen Produkt rechnen kann.

Im Velocity-Chart werden die Aufgaben aus dem Product Backlog, die komplett fertiggestellt sind, dem Sprint zugeordnet, in dem sie erledigt wurden. Die dazugehörenden Story Points werden addiert und kumuliert. So ergibt sich ein ähnliches Bild wie beim Burn-Down-Chart. Abbildung 4 zeigt ein Beispiel für ein Velocity-Chart.

Abbildung 4: Velocity-Chart als Darstellung der Sprint-Geschwindigkeit und des Arbeitsfortschritts bei Scrum

14. Sprint-Retrospective durchführen

In gesonderten Treffen, der Sprint-Retrospective, können die Projektmitarbeiter ihre Zusammenarbeit im Team überprüfen. Sie besprechen und festhalten, was intern verbessert werden sollte, um die Projektziele gemäß Anforderung, Zeitplan und Kostenplan zu erreichen.

Anlässe für ein Sprint-Retrospective ergeben sich insbesondere dann, wenn Konflikte zwischen den Teammitgliedern oder auch zwischen Team und Product Owner entstanden sind oder wenn das Projekt nicht vorankommt. Im Rahmen dieser Meetings wird dann nach einer gemeinsamen und tragfähigen Lösung gesucht, sodass das Team weiterarbeiten kann und die Projektziele erreicht werden.

15. Projekt abschließen und Project-Review durchführen

Sind alle Sprints durchlaufen, wird das fertige Produkt an den Product Owner geliefert. Oder allgemein: Das Projekt kann abgeschlossen werden.

Der Product Owner prüft das Produkt und das Projektergebnis insgesamt vor dem Hintergrund der Anforderungen der Nutzer und der Kunden, wie sie mit den Story Cards formuliert wurden. Dabei werden Änderungen beachtet, die sich während der Projektlaufzeit ergeben haben. Außerdem wird berücksichtigt, welche Prioritäten zu Beginn das Projekts vereinbart und vergeben wurden.

Mit der Prüfung wird geklärt, welche Anforderungen, Merkmale und Funktionen des Produkts in diesem Projekt (doch nicht) bearbeitet wurden und welche Gründe das hatte. Sie werden gegebenenfalls erst in einem anschließenden Projekt bearbeitet.

Mit dem Projektabschluss kann ein Project-Review erfolgen. Hier werden alle Aspekte angesprochen, die die Zusammenarbeit erschwert oder den Prozess behindert haben. Daraus ergeben sich meistens Möglichkeiten, das nächste Scrum-Projekt besser zu machen.

Praxis

Anforderungen ermitteln, Story Cards schreiben

Stellen Sie die Anforderungen des Produkteigners und der Anwender und Kunden zusammen.

  • Führen Sie Gespräche mit den Kunden und Anwendern, in denen diese ihre Anforderungen an das Produkt, das von Ihnen entwickelt werden soll, oder an das Projektergebnis, das Sie herbeiführen sollen, benennen und erläutern.
  • Lassen Sie die Anwender oder Kunden für Ihr Produkt oder Projekt Story Cards schreiben. Das sind kurze Beschreibungen dessen, was das Produkt oder Projekt – aus Sicht der Anwender – leisten und können soll.
  • Diskutieren und reflektieren Sie die Anforderungen auf den Story Cards. Fragen Sie nach.

Die Story Cards sind immer in den Worten der Anwender und in ihren Bildern formuliert. Nutzen Sie das folgende Formular, um Ihre Anwender-Anforderungen zu ermitteln und in der Story Card zu beschreiben.

Product Backlog mit Backlog-Items erstellen

Leiten Sie aus den User Storys auf den Story Cards und den einzelnen Anforderungen die Aufgaben für das Projekt oder die Funktionen und Merkmale des Produkts und der Lösung ab, die Sie entwickeln sollen.

  • Beschreiben Sie kurz die Backlog-Items; zum Beispiel auf der Grundlage von Use Cases.
  • Stellen Sie den Zusammenhang dar zwischen dem Backlog-Item (Aufgabe, Funktion, Merkmal) und der Anforderung der Kunden oder Anwender (User Story).
  • Legen Sie fest, woran Sie die Definition of Done festmachen.
  • Welche Merkmale, Indikatoren oder Funktionen drücken aus, dass dieses Backlog-Item „fertig“ ist und die Anforderungen erfüllt werden?
  • Was muss dazu getestet werden?

Wie Sie aus einer User Story einen Use Case oder ein Backlog-Item erstellen, zeigt das Beispiel im Beitrag zu User Story und Use Case.

Komplexität und Aufwand schätzen und Story Points vergeben

Vergeben Sie für jedes Backlog-Item Story Points. Schätzen Sie dazu grob den Aufwand, der mit der Realisierung einer Funktion oder eines Merkmals verbunden ist.

Prioritäten klären

Klären Sie, welche Priorität eine Anforderung der Anwender oder Kunden sowie die damit verknüpften Aufgaben, Funktionen und Merkmale (Backlog-Items) haben soll. Diese Prioritäten haben Sie gegebenenfalls schon bei der Ermittlung der Anforderungen mit den Anwendern festgelegt und in der Story Card dokumentiert.

Sie können diese Einschätzung nun im Projektteam überprüfen. Fassen Sie diese Informationen in der folgenden Vorlage zusammen.

Things-That-Matter-Matrix für die Aufwandsschätzung und Prioritätensetzung

Eine Things-That-Matter-Matrix kann bei der Einschätzung des Aufwands und der Prioritäten hilfreich sein. Hier zeigen Sie den Zusammenhang zwischen Aufgabe, Funktion, Merkmal (Backlog-Item) einerseits und Anforderung der Kunden oder Anwender andererseits.

Dabei wird deutlich, welche Anforderung besonders aufwendig wird und mit welchem Backlog-Item Sie unterschiedliche Anforderungen gleichzeitig erfüllen können (Mehrfachverwendung).

In der folgenden Matrix können Sie zusätzlich den groben Aufwand zur Realisierung der Funktion angeben. Zur Schätzung des Aufwands wird einfach nach Größenklassen unterschieden – wie bei Kleidung: S, M, L für einen geringen, mittleren oder hohen Aufwand. So ergeben sich die Story Points und Prioritäten.

Backlog-Items in Teilaufgaben, Sprint-Tasks zerlegen und Maßnahmenplan erarbeiten

Zerlegen Sie die Backlog-Items in Teilaufgaben. Gehen Sie dabei nach Prioritäten vor; die wichtigsten zuerst. Die Teilaufgaben sind die Sprint-Tasks. Stellen Sie alle Sprint-Tasks im Sprint-Backlog zusammen. Das ist der Maßnahmenplan für Ihr Projektteam.

Halten Sie diesen Maßnahmenplan immer auf dem Laufenden. Planen Sie die gerade anstehenden Aufgaben und überprüfen Sie täglich, welche Aufgaben noch anstehen, welche gerade bearbeitet werden und welche abgeschlossen sind. Überprüfen Sie den Aufwand, der noch notwendig ist und vergleichen Sie ihn mit dem ursprünglich geplanten Aufwand.

Projekt über tägliche Besprechungen – Daily Scrum – steuern

Visualisieren Sie den Arbeitsablauf und den Fortschritt im Projekt mithilfe eines Sprint-Taskboards. Nutzen Sie dazu die folgende Vorlage. Sie können die Projektphasen auch feiner gliedern und unterscheiden. Dies ist dann ein Kanban-Board für Ihr Scrum-Projekt.

Klären Sie im täglichen Scrum den Stand des Projekts. Alle Teammitglieder berichten:

  • was sie erreicht haben,
  • was nun ansteht und
  • was Probleme bereitet hat.

Burn-Down-Chart pflegen

  • Halten Sie bei den täglichen Sprint-Meetings (Scrum) den Projektaufwand im Burn-Down-Chart fest.
  • Identifizieren Sie Abweichungen.
  • Besprechen Sie, welche Gegenmaßnahmen eingeleitet werden können.

Die folgenden einfachen Diagramme machen für alle sichtbar, ob das Projekt im Zeit- und Kostenplan liegt. Im Diagramm wird „rückwärts gezählt“; nicht das verbrauchte Budget steht im Vordergrund, sondern das noch verfügbare. Das fördert die Motivation.

Wenn ein Sprint abgeschlossen und das Ergebnis vom Produkteigner (Product Owner) abgenommen ist, dann führen Sie Ihr Velocity-Chart fort. Sie dokumentieren den Arbeitsfortschritt und die Projektgeschwindigkeit für die Teammitglieder und den Produkteigner. Nutzen Sie dazu eine der beiden Vorlagen.

Sprint-Retrospective durchführen

  • Welche Hindernisse sind im Arbeitsablauf aufgetaucht?
  • Wie können diese beseitigt werden?

Halten Sie das Problem fest und sorgen Sie mit den Teammitgliedern dafür, dass es beseitigt wird. Wie kann das geschehen? Halten Sie Ihre Verbesserungsmaßnahmen in der folgenden Vorlage fest.

In der folgenden Vorlage ist der Ablauf eines Sprints mit den einzelnen Schritten und Elementen noch einmal in der Übersicht dargestellt.

Im folgenden Abschnitt werden spezielle Probleme und Hindernisse erläutert, die bei Scrum-Projekten auftauchen oder die sich im Vorfeld ergeben können. Denn: die besonderen Regeln und Prinzipien von Scrum und agilem Projektmanagement setzen viel Transparenz, Verantwortungsbewusstsein und Vertrauen voraus, die nicht immer in der notwendigen Form gegeben sind. Außerdem muss die Projektaufgabe passen, damit Scrum funktioniert.

Dazu im Management-Handbuch

Weitere Kapitel zum Thema