Scrum ist ein Projektmanagement-Framework, das Teamarbeit, Verantwortung und schrittweise Fortschritte hin zu klar definierten Zielen betont. Es beginnt mit einer einfachen Voraussetzung: beginnen Sie mit dem, was Sie sehen oder wissen. Verfolgen Sie dann den Fortschritt und passen Sie bei Bedarf an.
Die drei Säulen des Scrum
Scrum basiert auf Empirizismus, der besagt, dass Wissen aus Erfahrung stammt und Entscheidungen auf dem basieren sollten, was bekannt ist. Diese drei Säulen verbinden Scrum miteinander.
Warum Scrum?
Scrum liefert Funktionen schrittweise, während Waterfall nur in Phasen liefert. Die traditionelle Waterfall-Entwicklung ist ein sequenzieller, phasenbasierter Prozess, bei dem Wert erst am Ende des Projekts geliefert wird. Scrum transformiert dieses Modell, indem neue Funktionen in jedem Sprint – typischerweise alle 2–4 Wochen – geliefert werden, anstatt sich auf eine große zukünftige Freigabe zu konzentrieren.
Scrum zerlegt komplexe Aufgaben in handhabbare Teile, teilt große Organisationen in kleine Teams auf und transformiert bedeutende Projekte in eine Reihe kurzer, zeitlich begrenzterSprints.
Durch iterative und inkrementelle Entwicklung können Unternehmen Produkte und Dienstleistungen, die Kunden wirklich benötigen, schneller und effizienter liefern. Mit Scrum können Sie am Ende jedes Sprints Kundenfeedback erhalten und integrieren, was bedeutet, dass Ihre Ergebnisse durch den tatsächlichen Einsatz in der Realität geprägt werden und nicht durch Annahmen. Dadurch ist es einfacher, Kunden und Schlüsselinteressenten aktiv einzubeziehen.
Agil gegenüber Scrum
Agil ist eine Praxis, die kontinuierliche Iteration in Entwicklung und Test während des gesamten SDLC ermöglicht. Agil zerlegt Produkte in kleinere, handhabbare Komponenten.Scrum ist nur eines von vielen iterativen und inkrementellen agilen Softwareentwicklungsprozessen die es uns ermöglichen, uns darauf zu konzentrieren, geschäftlichen Wert in kürzester Zeit zu liefern.
Scrum befasst sich typischerweise mit Anforderungen, die sich ändern oder zu Beginn eines Projekts unbekannt sind. Scrum zeichnet sich durch folgendes aus:
- Leichtgewichtig
- Einfach zu verstehen
- Schwer zu meistern
Vorteile von Scrum
Hier sind die Vorteile, die Scrum für Organisationen, Teams, Produkte und Einzelpersonen bringt:
- Bessere Qualität: Es gibt ein Framework zur Erreichung von Vision oder Zielen. Scrum bietet kontinuierliches Feedback und Transparenz, um sicherzustellen, dass die Qualität so hoch wie möglich ist. Scrum hilft, Qualität durch Praktiken wie
- Verkürzte Time-to-Market-Zeit: Scrum hat gezeigt, dass Wert für Endnutzer 30 %–40 % schneller geliefert wird als mit traditionellen Methoden.
- Höherer Return on Investment (ROI): Kurzere Time-to-Market-Zeit ist ein entscheidender Grund dafür, dass Scrum-Projekte einen höheren ROI erzielen. Frühes Einkommen und die Ansammlung von Nutzen bedeuten höhere Gesamterträge. Dies basiert auf dem grundlegenden Prinzip der Berechnung des Netto-Barwerts (NPV).
- Höhere Team-Moral: Zusammenarbeit mit glücklichen, engagierten Personen ist erfüllend und produktiv. Selbstmanagement überträgt Entscheidungen, die normalerweise von Managern oder Organisationen getroffen werden, in die Hände derScrum-Team Mitglieder.
- Stärkere Teamzusammenarbeit: Wenn Scrum-Teams das Projekt und das Produkt übernehmen, können sie hervorragende Ergebnisse erzielen. Scrum-Teams arbeiten zusammen und verbessern Qualität und Projektleistung durch gesteigerte Beteiligung und Kommunikation.
Scrum-Framework
Scrum ist einfach. Es ist kein Satz starren, miteinander verflochtener Vorgaben. Scrum ist keine Methode. Scrum verkörpert die wissenschaftliche Methode des Empirismus. Es ersetzt prozedurale algorithmische Ansätze durch heuristische Methoden, respektiert Menschen und Selbstorganisation, um Unvorhersehbarkeit zu bewältigen und komplexe Probleme zu lösen. Das Diagramm unten zeigt Scrum in Aktion, wie es von Ken Schwaber und Jeff Sutherland in ihrem Buch „Scrum: Die Kunst, die doppelte Arbeit in der halben Zeit zu erledigen“ beschrieben wird, und veranschaulicht die Reise von der Planung bis zur Softwarebereitstellung.
Bestandteile des Scrum-Prozesses
Das Scrum-Framework selbst ist einfach. Es definiert nur einige allgemeine Richtlinien mit einer geringen Anzahl von Regeln, Rollen, Produkte, und Ereignisse. Jedoch sind diese Komponenten für bestimmte Zwecke von entscheidender Bedeutung und unerlässlich für den erfolgreichen Einsatz des Frameworks.
Die wichtigsten Bestandteile des Scrum-Frameworks sind:
- Scrum-Rollen: Scrum Master, Product Owner, und das Scrum-Team
- Produkte: Sprint-Backlog, Produkt-Backlog, Burndown-Diagramm, Protokolle usw.
- Scrum-Ereignisse: Sprint-Planung, Sprint-Review, Daily Scrum, Sprint-Retrospektive, usw.
- Sprints
Das Diagramm unten zeigt die wichtigsten Elemente des Scrum-Frameworks. Der Prozess wurde mithilfe des Scrum-Prozess-Canvas aus den Agile-Softwaretools von Visual Paradigm.
Scrum-Rollen
Wenn eine Organisation Scrum übernimmt, ist das Erste, was verstanden werden muss, wie sich Scrum-Rollen von traditionellen Projektmanagement-Rollen unterscheiden. Obwohl es in Scrum nur drei Hauptrollen gibt, entsprechen sie nicht automatisch vertrauten Berufsbezeichnungen. Lassen Sie uns mit kurzen Definitionen jeder Rolle beginnen:
Product Owner
Der Product Owner ist die Scrum-Rolle, die für die Vertretung der Geschäftswelt oder der Nutzercommunity verantwortlich ist. Er arbeitet eng mit den Nutzern zusammen, um Funktionen im Produkt-Backlog zu definieren. Zu den Hauptverantwortlichkeiten gehören:
- Definieren der Produktvision und -strategie, einschließlich kurz- und langfristiger Ziele;
- Bereitstellen oder Sammeln von Wissen über das Produkt oder den Service;
- Verstehen und Vermitteln der Kundenbedürfnisse an das Entwicklungsteam;
- Erfassen, Priorisieren und Verwalten von Produkt- oder Serviceanforderungen;
- Verantwortung für die Budgetierung des Produkts oder des Services, einschließlich Rentabilität;
- Bestimmung der Veröffentlichungsdaten für das Produkt oder den Service;
- Täglich Fragen beantworten und Entscheidungen gemeinsam mit dem Entwicklungsteam treffen;
- Akzeptieren oder Ablehnen der abgeschlossenen Arbeit aus dem Sprint;
- Präsentieren der wichtigsten Ergebnisse des Teams am Ende jedes Sprints;
- Verwalten des Produkt-Backlogs.
Scrum Master
Der Scrum Master ist der Facilitator des agilen Entwicklungsteams. Scrum ermöglicht es Teams, sich selbst zu organisieren und schnell anhand agiler Prinzipien anzupassen. Der Scrum Master verwaltet den Informationsfluss. Hauptverantwortlichkeiten:
- Als Coach zu dienen, um das Team bei der Einhaltung von Scrum-Werten und -Praktiken zu unterstützen;
- Hilfe beim Beseitigen von Hindernissen und Schutz des Teams vor externen Ablenkungen;
- Förderung einer guten Zusammenarbeit zwischen dem Team und den Stakeholdern;
- Förderung von Sachlichkeit und Transparenz innerhalb des Teams;
- Schutz des Teams vor organisatorischen Störungen.
Scrum-Team
Der Scrum-Team (auch bekannt als Entwicklungsteam) besteht aus 3 bis 9 Mitgliedern, die gemeinsam alle technischen Fähigkeiten besitzen müssen, die zur Lieferung des Produkts oder der Dienstleistung erforderlich sind. Sie werden direkt vom Scrum Master geleitet, aber nicht im klassischen Sinne verwaltet. Sie müssen sich selbst organisieren, überfachlich arbeiten und für die vollständige Erfüllung aller erforderlichen Aufgaben verantwortlich sein.
Das Entwicklungsteam ist verantwortlich dafür, am Ende jedes Sprints einen potenziell lieferbaren Produkt-Teilabschluss zu liefern – einschließlich Analyse, Design, Entwicklung, Test und technischer Dokumentation. Wichtige Merkmale eines Scrum-Teams sind:
- Selbstorganisation: Alle Teammitglieder verwalten ihre eigene Arbeit, um die zugewiesenen Aufgaben abzuschließen. Im agilen Scrum gibt es keinen Teamleiter oder Vorgesetzten. Jeder muss ausreichend engagiert sein, um seine eigenen Aktivitäten voranzutreiben und zum Erfolg des Teams beizutragen. Wenn einer scheitert, scheitert das ganze Team.
- Überfachlich: Alle Teammitglieder müssen über alle notwendigen Kenntnisse und Fähigkeiten verfügen, um ein qualitativ hochwertiges, lieferbares Produkt zu liefern. Experten können hinzugezogen werden, um Anleitung zu geben, aber nur, um Wissen an das Team weiterzugeben, um Fähigkeitslücken zu schließen.
- Der Product Owner benötigt eine Geschäftsvision: Der Product Owner vertritt die Stimme des Kunden und muss deren Bedürfnisse in handlungsorientierte Aufgaben für den Scrum Master und das Entwicklungsteam übersetzen. Dies ist in der Regel eine Vollzeitposition.
- Der Scrum Master ist kein Linienmanager: Sie unterstützen die Entwicklung des Teams und beseitigen Hindernisse, die den Fortschritt behindern.
Scrum-Artefakte
Scrum-Artefakte helfen dabei, die Arbeit zu definieren, die in das Team eingeht und derzeit bearbeitet wird. Obwohl es weitere Artefakte gibt – wie Benutzerstories, Release-Backlogs, Burndown-Charts – konzentrieren wir uns hier auf die drei zentralen:
Produkt-Backlog
Der Produkt-Backlog ist eine priorisierte Liste von Benutzerstories, die die Funktionen darstellen, die das Produktteam benötigt oder erwartet. Typischerweise pflegt der Product Owner diese Liste.
Sprint-Backlog
Das Sprint-Backlog enthält eine Reihe ausgewählter Aufgaben, die während des aktuellen Sprints abgeschlossen werden sollen. Zwei wichtige Punkte zur Beziehung zwischen dem Sprint-Backlog und dem Produkt-Backlog:
1. Das Team entscheidet, was in den Sprint aufgenommen wird. Daher besitzt das Team die Verantwortung und ist für die Lieferung dieser Aufgaben verantwortlich.
2. Bevor ein Element vom Produkt-Backlog in das Sprint-Backlog übertragen wird, muss das Team sicherstellen, dass alle erforderlichen Informationen vorliegen. Das Team legt typischerweise eine Checkliste mit Kriterien fest, die erfüllt sein müssen, bevor ein Element hinzugefügt werden kann.
Produkt-Backlog im Vergleich zum Sprint-Backlog
Der Sprint-Backlog ist die Liste der Aufgaben, die das Scrum-Team während des Sprints abschließen möchte. In der Sprint-Planungssitzung wählt das Team typischerweise einige Produkt-Backlog-Aufgaben in Form von Benutzerstories aus und bestimmt die Aufgaben, die zur Abschluss jeder einzelnen Aufgabe erforderlich sind, wie unten dargestellt:
Burndown-Diagramm
Ein Burndown-Diagramm ist eine grafische Darstellung der verbleibenden Arbeit über die Zeit. Die verbleibende Arbeit (oder Backlog-Arbeit) wird auf der vertikalen Achse dargestellt, während die Zeit auf der horizontalen Achse angezeigt wird. Es handelt sich um ein laufendes Diagramm der noch zu erledigenden Arbeit. Es kann verwendet werden, um vorherzusagen, wann die gesamte Arbeit abgeschlossen sein wird. Es wird häufig in agilen Softwareentwicklungsmethoden wie Scrum eingesetzt, kann aber auf jedes Projekt angewendet werden, das eine messbare Fortschrittsentwicklung über die Zeit aufweist. Die verbleibende Arbeit kann in Zeit oder Story-Punkten.
Scrum-Veranstaltungen
Kommunikation ist entscheidend! Scrum basiert auf Transparenz in allen Bereichen (Scrum-Säule #1). Angesichts dieses zentralen Prinzips ist das Framework um eine Reihe von Schlüsselevents aufgebaut, um die anderen beiden Säulen – Inspektion und Anpassung – sicherzustellen, wie in der folgenden Tabelle gezeigt:
| Ereignis | Inspektion | Anpassung |
|---|---|---|
| Sprint-Planung |
|
|
| Daily Scrum |
|
|
| Sprint-Review |
|
|
| Sprint-Retrospektive |
|
|
Hinweis: Während jedes Sprints gibt es fünf Schlüsselveranstaltungen im Scrum, wie unten gezeigt:
Sprint-Planung
Jeder Sprint beginnt mit der Planung. Das Team muss festlegen und verpflichten, was es im Rahmen des Sprints liefern wird. Mögliche Aufgaben werden immer aus dem Sprint-Backlog entnommen, wie unten gezeigt:
Hier kann der Scrum Master glänzen. Der Product Owner definiert, was aus geschäftlicher/kundenspezifischer Sicht benötigt wird, das Scrum-Team bestimmt, was es nach seiner Einschätzung liefern kann, und der Scrum Master sorgt dafür, dass beide Seiten optimal zusammenpassen.
Daily-Scrum-Meeting
Sobald das Team sich verpflichtet, was es im Rahmen des Sprints liefern wird, findet ein Daily Stand-up statt. Das zentrale Ziel ist es, sicherzustellen, dass jedes Teammitglied (und möglicherweise Beobachter) den Status und den Fortschritt der Arbeit vollständig versteht:
- Was habe ich gestern gemacht?
- Was werde ich heute tun?
- Was blockiert mich?
Diese tägliche Aktualisierung liefert dem Team unmittelbares Feedback. Die Meetings sind kurz – maximal drei Minuten pro Person.
Hinweis:Beobachter sind zur Beobachtung da. Der Scrum Master muss externe und interne Ablenkungen minimieren.
Sprint-Review-Meeting
Das Sprint-Review oder die Demo findet am Ende des Sprints statt, um das Increment zu überprüfen. Das Team demonstriert das Increment anhand der Definition von Fertigstellung und konzentriert sich dabei auf das Sprint-Ziel. Der Product Owner überprüft und akzeptiert das gelieferte Increment.
Sprint-Retrospektive
Die Sprint-Retrospektive ist typischerweise die letzte Aktivität im Sprint. Viele Teams führen sie unmittelbar nach dem Sprint-Review durch. Das gesamte Team – einschließlich des Scrum Masters und des Product Owners – sollte daran teilnehmen. Eine einstündige Retrospektive ist in der Regel ausreichend. Diese Sitzung ermöglicht dem Team, über Folgendes nachzudenken:
- Was sollten wir beginnen zu tun?
- Was sollten wir aufhören zu tun?
- Was sollten wir weiterhin tun?
Das Ziel ist es, die Team-Effizienz kontinuierlich zu verbessern.
Backlog-Refinement
Stellen Sie sich das Product Backlog als die Projekt-Roadmap vor. Während das Team zusammenarbeitet, erstellen und aktualisieren sie eine Liste aller Aufgaben, die benötigt werden, um das Projekt abzuschließen, und stellen sicher, dass alle notwendigen Anforderungen erfüllt sind.
Sprints
Im Scrum-Framework werden alle Aktivitäten, die zur Umsetzung einer Aufgabe aus dem Scrum-Product-Backlog erforderlich sind, innerhalb eines Sprints durchgeführt (auch „Iterationen“ genannt). Sprints sind immer kurz – typischerweise 2 bis 4 Wochen. Jeder Sprint folgt einem definierten Prozess, wie unten gezeigt:
Wie bereits erwähnt, werden Aufgaben im Product Backlog priorisiert und für das Sprint-Backlog ausgewählt. Ein Sprint enthält nur wenige Hauptaufgaben – eine Unterschätzung der Arbeit für eine einzelne Aufgabe kann den Sprint erheblich beeinträchtigen. Da größere Aufgaben oft schwieriger einzuschätzen und zu verstehen sind, steigt das Risiko eines Sprint-Fehlschlags. Erfahrene Scrum-Teams investieren Zeit und Mühe, um komplexe oder große Aufgaben (z. B. Benutzerfunktionen oder Epics) in kleinere Benutzerstories (oder weiter in Aufgaben oder Unteraufgaben) zu zerlegen.
Epic
Ein Epic fasst eine große Menge an Arbeit zusammen. Es ist im Wesentlichen eine „große Benutzerstory“, die in viele kleinere Stories aufgeteilt werden kann. Die Vollendung eines Epics kann mehrere Sprints in Anspruch nehmen. Daher müssen Epics bei der Entwicklung in kleinere Benutzerstories zerlegt werden.
Epics werden früh im Projektzyklus eingeführt. Sie sind hochgradig abstrakt und fast marktorientiert funktionale Punkte.
Wir nennen große Stories „Epics“, um ihre Größe zu verdeutlichen. Denken Sie daran wie einen Film. Wenn ich Ihnen sage, ein Film sei ein „Action-Abenteuer“, bekommen Sie eine Vorstellung davon, was Sie erwarten können – möglicherweise Autorennen, Schießereien usw. Ähnlich kann die Bezeichnung einer Story als „Epic“ manchmal zusätzlichen Kontext vermitteln.
Benutzerstory
Eine Benutzerstory ist eine kurze Aussage über eine Produktanforderung oder ein Geschäftsfall. Sie wird normalerweise in einfacher Sprache verfasst, um dem Leser zu helfen, zu verstehen, was die Software tun soll. Der Product Owner erstellt die Story. Danach zerlegen die Scrum-Teammitglieder die Story in eine oder mehrere Scrum-Aufgaben.
Benutzerstories sind typischerweise Funktionen, die für den Endbenutzer sichtbar sind. Sie folgen dem Format: „Ich möchte [etwas tun], damit ich [ein Ziel erreichen kann].“ Sie liefern Wert für den Kunden/Anwender. Dies ist die Produktanforderung des Kunden.
Beispiel: „Als Kunde möchte ich ein Konto erstellen, damit ich meine Einkäufe aus dem letzten Jahr einsehen kann, um meine Budgetplanung für das nächste Jahr zu unterstützen.“
Aufgabe
Im Gegensatz dazu ist eine Aufgabe technischer in der Ausrichtung. Aufgaben beinhalten oft Code, Design, Erstellung von Testdaten, Automatisierung usw. Sie sind typischerweise individuelle Verantwortlichkeiten. Aufgaben werden nicht im Format von Benutzerstories formuliert. Sie sind technischer in der Ausrichtung.
Beispiel: „Beurteile den UI-Aspekt mit Material Design“ oder „Stelle die Anwendung im App Store ein.“
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish