BLOG

BLOG

Schriftgröße: + –
4 Minuten Lesezeit (825 Worte)

Scrum in a Nutshell

C37E8874-929C-4D1B-B754-F9048C994D81 SCRUM in a Nutshell

Hier erhalten Sie einen schnellen, aber detaillierten Überblick über das Scrum Framework. Dieses Whitepaper "Scrum in a Nutshell" beschreibt die wichtigsten Scrum-Rollen, Scrum-Artefakte und Scrum-Zeremonien.

Scrum - Das Agile Framework
Scrum ist ein Framework, das eine iterative und inkrementelle Produktentwicklung ermöglicht, die es erlaubt, Dinge zur richtigen Zeit zu erledigen und den Wert des Gelieferten zu maximieren. Aufgaben werden von selbstorganisierenden Teams schneller und mit höherer Qualität ausgeführt. Es wird ein hohes Maß an Selbstmotivation erreicht und ist der Grund dafür, dass Teams mit Scrum schneller eine höhere Produktivität erreichen können. Kundenanforderungen werden ständig nach dem Geschäftswert priorisiert und in regelmäßigen Abständen in das Produkt integriert, so dass der Kunde dem Team umgehend Feedback geben kann und somit die Qualität des Produkts rechtzeitig verbessert wird.

Ein Scrum-Projekt beginnt meist mit einer Vision des zu entwickelnden Produkts oder Systems. Die Vision mag anfangs vage sein und sicherlich eher auf Marktfragen als auf technische Begriffe bezogen sein. Im weiteren Verlauf des Projekts wird sie klarer. Aus dieser Vision heraus schreibt der Product Owner das Product Backlog.

Zu Beginn einer Iteration (Sprint) legt der Produkteigentümer dem Team das priorisierte Product Backlog vor, das auswählt, was seiner Meinung nach bis zum Ende des Sprints in einen Zuwachs an potenziell lieferbaren Funktionen umgewandelt werden kann. Auf diese Weise wird das Sprint Backlog erstellt. Danach wird das Team mit der Entwicklung der von ihm gewählten Funktionen allein gelassen. Das Team befasst sich nun eingehender mit den Anforderungen, betrachtet die verfügbare Technologie und bewertet seine eigenen Fähigkeiten und Fertigkeiten. Dann legt es gemeinsam fest, wie die Funktionalität aufgebaut werden soll, wobei es seinen Ansatz täglich modifiziert, um neue Komplexitäten oder Schwierigkeiten herauszufinden. Das Team findet heraus, was zu tun ist, und wählt den besten Weg dazu aus. Dieser kreative Prozess ist der Kern der Scrum-Produktivität. Am Ende des Sprints präsentiert das Team dem Product Owner das Inkrement der Funktionalität, damit er einerseits die Funktionalität überprüfen und andererseits rechtzeitig Anpassungen am Projekt vornehmen kann.

Scrum-Rollen - Scrum kennt 3 Rollen:

  • Produkt-Owner
  • Scrum Team
  • Scrum-Master

Alle Verantwortlichkeiten für die Leitung des Projekts sind auf diese drei Rollen verteilt.

Product Ownwer
Der Product Owner vertritt die Interessen aller am Projekt Beteiligten (Stakeholder) und ist für das Endprodukt verantwortlich. Er eruiert die Produktanforderungen vom Stakeholder, erstellt das Product Backlog (Anforderungen aufgeschlüsselt in User Stories), ist verantwortlich für den Return on Investment (ROI) und erstellt den Release-Plan. Der Product Owner priorisiert das Product Backlog anhand von Business Value Points, um sicherzustellen, dass die wertvollste Funktionalität zuerst entwickelt wird.
Die Spannung zwischen dem, was das Unternehmen will, und dem, was das Team tun kann, macht Scrum zu einem so effektiven Mittel für eine qualitativ hochwertige Produktion.

Das Scrum Team
Das Team findet heraus, wie man das Product Backlog in eine Erweiterung der Funktionalität innerhalb eines Sprints verwandeln kann. Jedes Teammitglied ist für den Erfolg jeder Iteration und des Projekts als Ganzes mitverantwortlich. Das Team ist verantwortlich für/an:

  • Software-Qualität
  • technische Implementierung von Benutzergeschichten
  • Lieferung eines funktionalen Software-Inkrements
  • sich selbst organisieren

Der Scrum-Master
Der Scrum Master ist für den Scrum-Prozess verantwortlich. Er stellt sicher, dass sich alle an die Regeln halten. Er beseitigt auch Hindernisse für das Team. Der Scrum Master ist nicht Teil des Teams.

Die drei beschriebenen Rollen haben sich dem Projekt verpflichtet. Andere sind vielleicht nur an dem Projekt interessiert (beteiligt), aber sie sind nicht am Haken. Scrum macht eine klare Trennung zwischen diesen beiden Gruppen. Engagiert: Die Rollen, die für das Projekt verantwortlich sind, haben die Autorität, das zu tun, was für den Erfolg des Projekts notwendig ist. Beteiligt: Die anderen Stakeholder, die nicht für den direkten Erfolg verantwortlich sind, können sich nicht unnötig einmischen. Es sollte immer klar sein, wer zum Beispiel für den ROI verantwortlich ist und wer einen Anteil am ROI hat, aber nicht rechenschaftspflichtig ist.

Scrum-Artefakte - Scrum kennt 3 Hauptartefakte:

  • Produkt-Backlog
  • Diagramm zum Abbrand
  • Sprint-Backlog

Produkt-Backlog
Die Anforderungen an das Produkt sind im Product Backlog aufgeführt. Es handelt sich dabei um eine sich ständig ändernde, dynamisch priorisierte Liste von Anforderungen, geordnet nach Geschäftswert. Die Anforderungen werden nach dem Bestellwert in User Stories aufgeschlüsselt.

Burndown-Chart
Das Burndown-Chart zeigt den verbleibenden Arbeitsaufwand pro Sprint. Es ist ein sehr nützliches Mittel, um die Korrelation zwischen der zu einem beliebigen Zeitpunkt verbleibenden Arbeit und dem Fortschritt der Mannschaft(en) zu visualisieren. Mit Hilfe des Burndown-Charts wird der Fortschritt der Mannschaft(en) in Bezug auf die Planung überprüft und bei Bedarf Anpassungen vorgenommen.

Sprint-Backlog
Das Sprint Backlog enthält alle engagierten User Stories für den aktuellen Sprint, aufgeschlüsselt nach Aufgaben des Teams. Alle Punkte des Sprint Backlogs sollten entwickelt, getestet, dokumentiert und integriert werden, um die Verpflichtung zu erfüllen.

Potentially Shippable Product Functionality
Scrum erfordert von den Teams, bei jedem Sprint eine Erweiterung der Produktfunktionalität zu erstellen. Dieses Inkrement muss potenziell lieferbar sein, da der Product Owner sich möglicherweise dafür entscheidet, die Funktionalität sofort zu implementieren. Dies setzt voraus, dass das Inkrement lieferbar ist:

  • gründlich getestet
  • gut strukturiert
  • gut geschriebener Code
  • die Bedienung der Funktionalität durch den Benutzer ist dokumentiert
Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken.
15
×
Blog-Beitrag abonnieren

Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Die COBIT Evolution
KAIT kommt: IT-Regeln für Asset Manager ohne Umweg...

Ähnliche Beiträge

 

Kommentare 23

Gäste - Franziska Schmitt am Sonntag, 17. Mai 2020 13:35

Zu „Scrum in a Nutshell“: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?

Zu „Scrum in a Nutshell“: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Gäste - Britta Sander am Dienstag, 19. Mai 2020 07:17

Mein Vorschlag wäre: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.

Mein Vorschlag wäre: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Gäste - Christian Brandt am Mittwoch, 20. Mai 2020 14:43

Guter Punkt. Ich würde zusätzlich fragen, was passieren soll, wenn sich die Voraussetzungen während des Betriebs ändern. Meine Ausgangsfrage bleibt: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?

Guter Punkt. Ich würde zusätzlich fragen, was passieren soll, wenn sich die Voraussetzungen während des Betriebs ändern. Meine Ausgangsfrage bleibt: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Markus Groß am Mittwoch, 20. Mai 2020 15:55

Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Auf die Ausgangsfrage bezogen: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.

Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Auf die Ausgangsfrage bezogen: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Gäste - Holger Böttcher am Donnerstag, 21. Mai 2020 09:53

Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Das bezieht sich für mich auf den hier beschriebenen Ansatz. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.

Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Das bezieht sich für mich auf den hier beschriebenen Ansatz. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.
Gäste - Kai Klein am Sonntag, 17. Mai 2020 18:43

Zum Beitrag „Scrum in a Nutshell“: Mein Vorschlag wäre, die Übergabe erst mit benanntem Verantwortlichen und nachvollziehbaren Abnahmekriterien abschließen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Verbindlichkeit von Qualitätskriterien sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.

Zum Beitrag „Scrum in a Nutshell“: Mein Vorschlag wäre, die Übergabe erst mit benanntem Verantwortlichen und nachvollziehbaren Abnahmekriterien abschließen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Verbindlichkeit von Qualitätskriterien sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Gäste - Britta Sander am Freitag, 22. Mai 2020 13:26

Wie geht man mit Vorgaben um, die den Handlungsspielraum des Teams tatsächlich begrenzen?

Wie geht man mit Vorgaben um, die den Handlungsspielraum des Teams tatsächlich begrenzen?
Gäste - Christian Brandt am Samstag, 23. Mai 2020 11:52

Das ist ein wichtiger Punkt. Die Grenzen würde ich transparent machen. Innerhalb dieser Grenzen sollte das Team aber echte Entscheidungsmöglichkeiten behalten.

Das ist ein wichtiger Punkt. Die Grenzen würde ich transparent machen. Innerhalb dieser Grenzen sollte das Team aber echte Entscheidungsmöglichkeiten behalten.
Gäste - Christian Brandt am Montag, 25. Mai 2020 14:36

Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.

Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Gäste - Holger Böttcher am Mittwoch, 27. Mai 2020 11:00

Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.

Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.
Markus Groß am Donnerstag, 28. Mai 2020 14:38

Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.

Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.
Gäste - Uwe Baumann am Freitag, 29. Mai 2020 10:11

Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Die Ausgangsfrage „Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team?“ ist damit für mich noch nicht vollständig beantwortet.

Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Die Ausgangsfrage „Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team?“ ist damit für mich noch nicht vollständig beantwortet.
Gäste - Franziska Schmitt am Samstag, 30. Mai 2020 10:50

Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.

Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren. Bei diesem Beitrag zu „Scrum in a Nutshell“ würde ich diese Frage ausdrücklich mitprüfen.
Gäste - Uwe Baumann am Montag, 25. Mai 2020 19:13

Welche Entscheidung müsste zu Nachvollziehbarkeit von Priorisierungsentscheidungen zuerst fallen, wenn ein Dienstleister einen Teil der Umsetzung übernimmt? Ich beziehe mich auf den Schwerpunkt „Scrum in a Nutshell“.

Welche Entscheidung müsste zu Nachvollziehbarkeit von Priorisierungsentscheidungen zuerst fallen, wenn ein Dienstleister einen Teil der Umsetzung übernimmt? Ich beziehe mich auf den Schwerpunkt „Scrum in a Nutshell“.
Gäste - Laura Keller am Montag, 25. Mai 2020 20:58

Zum Beitrag „Scrum in a Nutshell“: Ich würde die erwarteten Ergebnisse und Übergaben konkret vereinbaren; ein Vertrag allein belegt noch keine Umsetzung. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Nachvollziehbarkeit von Priorisierungsentscheidungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.

Zum Beitrag „Scrum in a Nutshell“: Ich würde die erwarteten Ergebnisse und Übergaben konkret vereinbaren; ein Vertrag allein belegt noch keine Umsetzung. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Nachvollziehbarkeit von Priorisierungsentscheidungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Gäste - Holger Böttcher am Dienstag, 26. Mai 2020 16:47

Wie würdet ihr bei Verbindlichkeit von Qualitätskriterien erkennen, dass eine Maßnahme im Alltag wirklich trägt und nicht nur formal erledigt ist? Die Frage bezieht sich auf „Scrum in a Nutshell“.

Wie würdet ihr bei Verbindlichkeit von Qualitätskriterien erkennen, dass eine Maßnahme im Alltag wirklich trägt und nicht nur formal erledigt ist? Die Frage bezieht sich auf „Scrum in a Nutshell“.
Markus Groß am Dienstag, 26. Mai 2020 17:36

Ich würde dafür einen konkreten Prüffall festlegen: erwartetes Ergebnis, beobachtetes Ergebnis und benannter Prüfer. Wenn die Abweichung sichtbar bleibt, lässt sich auch sinnvoll über die nächste Maßnahme entscheiden. Bezogen auf Verbindlichkeit von Qualitätskriterien im Beitrag „Scrum in a Nutshell“ würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.

Ich würde dafür einen konkreten Prüffall festlegen: erwartetes Ergebnis, beobachtetes Ergebnis und benannter Prüfer. Wenn die Abweichung sichtbar bleibt, lässt sich auch sinnvoll über die nächste Maßnahme entscheiden. Bezogen auf Verbindlichkeit von Qualitätskriterien im Beitrag „Scrum in a Nutshell“ würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Gäste - Holger Böttcher am Montag, 01. Juni 2020 09:26

Für mich liegt der Schwerpunkt hier: Die Entscheidung sollte ausdrücklich besprochen werden. Wenn der Konflikt nur still in das Team verlagert wird, verschwindet er nicht.

Für mich liegt der Schwerpunkt hier: Die Entscheidung sollte ausdrücklich besprochen werden. Wenn der Konflikt nur still in das Team verlagert wird, verschwindet er nicht.
Gäste - Holger Böttcher am Dienstag, 02. Juni 2020 09:11

Dazu eine Rückfrage: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?

Dazu eine Rückfrage: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Gäste - Nora Sommer am Mittwoch, 03. Juni 2020 07:41

Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.

Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Bereits registriert? Hier einloggen
Mittwoch, 07. Oktober 2026

Sicherheitscode (Captcha)

Image

Wir benutzen Cookies

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern. Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.

CookieHint and Consent by reDim GmbH (Öffnet in neuem Fenster)