Du bist auf der Suche nach einer effektiven Methode, um dein Projektmanagement zu verbessern?
Scrum könnte genau das sein, was du brauchst!
Aber, was ist Scrum genau und wie funktioniert das Scrum Framework?
In unserer ultimativen Anleitung führen wir dich durch die Welt von Scrum, einer bewährten agilen Methode, die Teams dabei hilft, komplexe Projekte effizient zu handhaben.
Du lernst die zentralen Rollen von Scrum kennen – den Product Owner, den Scrum Master und das Entwicklungsteam bilden das Scrum Team.
Wir zeigen dir, wie du Sprints planst, Backlogs verwaltest und mit den verschiedenen Scrum Artefakten und Events umgehst.
Wir sprechen über Scrum Events, Scrum Rollen, Scrum Methoden und den Scrum Prozess im Scrum Framework.
Egal ob du ein Neuling in der agilen Welt bist oder dein Scrum-Wissen vertiefen möchtest – diese Anleitung wird dir helfen, deine Projekte effektiver und effizienter zu gestalten.
Bist du bereit uns auf dieser spannenden Reise zu begleiten?
11 Nuggets für
noch mehr Agilität
Mehr Agilität, bietet dieses E-Book für dich und dein Team.
Du wirst damit Teil der exklusiven E-Mail Liste und erhältst Gratis dieses E-Book.
Abmeldung jederzeit möglich.
Dieses Beispiel zu Scrum ist noch nicht fertig und wird weiter ausgearbeitet und ergänzt.
Schritt 1: Der Auftrag
Stell dir vor, Herr Müller, ein Restaurantbesitzer, möchte eine App entwickeln lassen, mit der seine Kunden Tische reservieren können.
Er hat jedoch noch nicht alle Details dazu im Kopf. Er geht zu einer Softwareentwicklungsagentur und präsentiert seine Idee:
„Ich möchte eine intuitive und benutzerfreundliche mobile App für mein Restaurant, die es unseren Kunden ermöglicht, Tische bequem von ihrem Smartphone aus zu reservieren.
Die App sollte eine klare und aktuelle Übersicht über die Verfügbarkeit der Tische in Echtzeit anzeigen.
Die Kunden sollten in der Lage sein, die Anzahl der Personen, das Datum und die Uhrzeit für ihre Reservierung anzugeben.
Außerdem würde ich gerne ein Bewertungssystem in die App integrieren, damit die Kunden ihr Erlebnis im Restaurant teilen können.
Eine Funktion, um die Speisekarte anzusehen und möglicherweise sogar vorab zu bestellen, wäre auch sehr wünschenswert.
Ich möchte auch, dass die App ein attraktives Design hat, das zum Ambiente des Restaurants passt, und dass sie sowohl für iOS- als auch für Android-Nutzer verfügbar ist.
Darüber hinaus sollte die App eine einfache Registrierung und Anmeldung für die Kunden ermöglichen, eventuell durch die Integration mit Social Media Konten.
Unsere primäre Zielgruppe sind Menschen zwischen 20 und 50 Jahren, die technikaffin sind und die Bequemlichkeit von Online-Reservierungen schätzen.
Dazu gehören sowohl Einheimische als auch Touristen, die in der Stadt sind und nach einem Ort suchen, um zu essen.“
Dann formuliert Herr Müller noch ein paar Rahmenparameter:
Was wichtig ist:
- Benutzerfreundlichkeit und einfache Bedienung
- Real-time Tischreservierungen
- Integration eines Bewertungssystems
- Ansicht der Speisekarte und möglicherweise Vorbestellung
- Attraktives Design
- Verfügbarkeit auf iOS und Android
- Einfache Registrierung und Anmeldung
Was weniger wichtig ist, aber dennoch in Betracht gezogen werden könnte:
- Integration mit Social Media Konten
- Personalisierte Empfehlungen basierend auf vorherigen Bestellungen oder Vorlieben
- Push-Benachrichtigungen für spezielle Angebote oder Events
- Kundenbindungsprogramm oder Treuepunktesystem.
Schritt 2: Scrum vs Kanban vs. Klassisch Die Entscheidung
Die Agentur bewertet Herr Müllers Projekt und entscheidet, dass wegen der Unklarheit und Änderbarkeit der Anforderungen ein agiler Ansatz am besten geeignet ist.
Wären die Anforderungen schon fest und es wäre klar welche Teile hergestellt werden müssen, käme auch ein auf Output orientiertes Kanban infrage.
Da in diesem Fall viel Ungewissheit über das endgültige Produkt besteht und das Team auch Neuland bei seinen Erfahrungen betritt, fällt die Entscheidung auf Scrum.
Denn bei Scrum können Anforderungen während des Entwicklungsprozesses weiterentwickelt und verändert werden, was perfekt für Herr Müllers Situation ist.
Hier sind die Überlegugen, warum die Agentur sich für Scrum entschieden hat:
1. Flexibilität
Da Herr Müller noch nicht alle Details zu seiner App kennt, ermöglicht Scrum eine flexible Anpassung an neue Anforderungen, die während des Entwicklungsprozesses auftauchen.
2. Kontinuierliche Verbesserung
Durch regelmäßige Feedbackschleifen, wie das Sprint Review und die Retrospektive, hat das Team die Möglichkeit, das Produkt und den Prozess kontinuierlich zu verbessern und zu verfeinern.
3. Transparenz
Scrum fördert eine hohe Transparenz des Projektstatus. Durch tägliche Scrum-Meetings und regelmäßige Reviews kann Herr Müller den Fortschritt leicht verfolgen und sich aktiv beteiligen.
4. Risikominimierung
Da in kurzen Sprints gearbeitet wird und nach jedem Sprint ein potenziell auslieferbares Produkt vorhanden ist, minimiert Scrum das Risiko, dass viel Arbeit in Funktionen gesteckt wird, die am Ende nicht benötigt werden.
5. Teamkollaboration
Scrum fördert eine intensive Zusammenarbeit und Eigenverantwortung im Team. Das kann besonders hilfreich sein, wenn das Team Neuland betritt und zusammen Lösungen finden muss.
Fazit
Die Entscheidung zwischen Scrum und Kanban (oder einer anderen Methode) basiert auf einer Bewertung der spezifischen Anforderungen des Projekts, der Erfahrung des Teams und der Risikobereitschaft des Kunden.
Bei einem festgelegten und gut verstandenen Prozess mit klar definierten Aufgaben könnte Kanban besser geeignet sein, da es eine kontinuierliche Flow-Produktion fördert.
In diesem speziellen Fall hat das Scrum-Modell jedoch den Vorteil, dass es dem Team ermöglicht, auf die unklaren und sich ändernden Anforderungen von Herrn Müller zu reagieren und dennoch ein hochwertiges Produkt zu liefern.
Schritt 3: Der agile Scrum Kick-off
Es findet ein Kick-off-Meeting nach Lean Inception statt, bei dem das Scrum-Team, der Scrum Master und der Product Owner und der Kunde (in diesem Fall Herr Müller) zusammenkommen, um das Projekt zu starten und die allgemeinen Anforderungen und Ziele zu besprechen.
Lean Inception startet das Projekt und klärt die Erwartungen und Ziele aller Beteiligten.
Dieses Meeting ist eine Kollaborationsübung, die dazu dient, das gesamte Team auf dasselbe Verständnis zu bringen, was das Produkt ist und wer die Benutzer sind.
Die Lean Inception kann eine Woche oder länger dauern, je nach Größe und Komplexität des Projekts.
Sie umfasst verschiedene Aktivitäten, wie die Definition der Produktvision, das Identifizieren der Stakeholder, das Erstellen von Personas und die Erstellung einer User Story Map und eines initialen Product Backlogs.
In diesem Fall ist die Lean Inception – stark vereinfacht, so abgelaufen:
1. Produktvision: Peter, der Scrum Master, beginnt das Meeting mit einer Diskussion über die Produktvision. Herr Müller erklärt, was er sich von der App erhofft und welche Probleme sie für seine Kunden lösen soll.
2. Stakeholder und Personas: Danach identifiziert das Team die Stakeholder des Projekts und erstellt Personas für die verschiedenen Benutzertypen der App.
3. User Journey: Das Team entwirft eine User Journey Map, um die verschiedenen Schritte zu visualisieren, die ein Benutzer beim Interagieren mit der App durchläuft.
4. User Story Mapping: Anschließend erstellt das Team eine User Story Map. Sie identifizieren die wichtigsten Funktionen (Epics) der App und zerlegen sie in kleinere User Stories.
5. Backlog Erstellung: Die User Stories werden in ein initiales Product Backlog übertragen, das die Grundlage für die zukünftige Entwicklung bildet.
Fazit
In dieser Lean Inception waren keine Führungskräfte der Agentur oder Key User des Kunden anwesend.
Führungskräfte können anwesend sein, um das Engagement der Agentur zu zeigen und strategische Perspektiven einzubringen.
Es könnte auch sehr hilfreich sein, einen oder mehrere Key User oder repräsentative Endnutzer einzubeziehen, um sicherzustellen, dass das Team ein tiefes Verständnis der Benutzerbedürfnisse hat.
Jedoch ist zu beachten, das die Gruppengröße gut zu moderieren ist, um sicherzustellen, dass das Meeting produktiv bleibt.
Die Lean Inception endet mit einem gemeinsamen Verständnis des MVP (Minimum Viable Product) – der kleinsten, funktionsfähigen Version der App, deren Nutzen vermarktet werden kann, um das Interesse und das Feedback der Kunden zu testen.
Schritt 4: Der Scrum Sprint
Nun beginnt der erste Sprint, eine Zeitperiode von normalerweise 2-4 Wochen, in der das Team eine ausgewählte Menge an User Stories aus dem Product Backlog in funktionsfähige Software umwandelt.
Ein Sprint im Scrum beginnt mit der Sprint-Planung und endet mit der Sprint-Retrospektive.
In diesem Fall wurde die Dauer eines Sprints auf zwei Wochen festgelegt.
So läuft ein Sprint in der Regel ab:
1. Sprint Planung (Sprint Planning)
In dieser Sitzung entscheidet das Team, welche User Stories aus dem Product Backlog im kommenden Sprint umgesetzt werden sollen. Diese Auswahl wird als Sprint Backlog bezeichnet. Dabei wird nicht nur festgelegt, was umgesetzt wird, sondern auch wie das passieren soll. Jedes Teammitglied bringt seinen Beitrag dazu bei, welche technischen Schritte notwendig sind, um die User Stories umzusetzen.
2. Daily Scrum (auch Daily Standup)
Während des Sprints trifft sich das Team jeden Tag für ein kurzes Meeting (Timebox – in der Regel nicht länger als 15 Minuten).
In diesem Meeting berichtet jedes Teammitglied über die Arbeit, die es seit dem letzten Meeting erledigt hat, was es bis zum nächsten Meeting tun will und ob es dabei irgendwelche Hindernisse gibt.
Das Ziel ist es, den Fortschritt zu überprüfen und zu sehen, ob das Team auf dem richtigen Weg ist, um die im Sprint Backlog festgelegten Ziele zu erreichen.
Das Daily muss nicht vom Scrum Master moderiert werden und ist auch kein Status Meeting indem an den Scrum Master, Produkt Owner oder Stakeholder berichtet wird.
3. Arbeit am Sprint Backlog
Zwischen den Daily Scrums arbeitet das Team an der Umsetzung der User Stories aus dem Sprint Backlog.
Dabei hält es sich an die im Sprint Planning vereinbarte Arbeitsweise und nutzt agile Entwicklungstechniken, wie beispielsweise Pair Programming oder Test-Driven Development.
4. Backlog Refinement
5. Sprint Review
Am Ende des Sprints hält das Team ein Sprint Review.
Hier präsentiert das Team die während des Sprints entwickelten Funktionen. Der Kunde Herr Müller und möglicherweise andere Stakeholder sind anwesend und geben ihr Feedback.
Dieses Feedback kann zu Anpassungen im Product Backlog führen, und es können neue User Stories hinzugefügt werden.
Das Sprint Review ist keine Abnahme der Arbeiten sondern ein informelles Meeting.
6. Sprint Retrospektive
Nach dem Sprint Review findet die Sprint Retrospektive statt.
Hier reflektiert das Team, was im vergangenen Sprint gut lief und was verbessert werden könnte.
Das Ziel ist es, den Entwicklungsprozess kontinuierlich zu verbessern.
Mögliche Verbesserungen werden im nächsten Sprint umgesetzt.
Sobald die Sprint Retrospektive abgeschlossen ist, beginnt der nächste Sprint mit einem neuen Sprint Planning.
So geht der Prozess immer weiter, bis das Produkt fertig, oder das Budget verbraucht ist.
11 Nuggets für
noch mehr Agilität
Mehr Agilität, bietet dieses E-Book für dich und dein Team.
Du wirst damit Teil der exklusiven E-Mail Liste und erhältst Gratis dieses E-Book.
Abmeldung jederzeit möglich.
Schritt 5: Das Scrum Sprint Review und die Backlog-Anpassung
Am Ende des Sprints findet ein Sprint Review statt. Hier stellt das Team Herrn Müller die Arbeitsergebnisse vor. Vielleicht haben sie die Funktion für die Tischreservierung fertiggestellt.
Der Sprint Review dient dazu, das vom Team erstellte Produktinkrement zu überprüfen und das Product Backlog gegebenenfalls anzupassen.
Hier ist ein typischer Ablauf eines Sprint Reviews:
1. Vorbereitung
Vor dem Sprint Review bereitet das Entwicklungsteam die im Sprint erstellten Funktionen vor, um sie präsentieren zu können.
Im Fall von Herrn Müller ist dies die fertiggestellte Funktion für die Tischreservierung.
Der Product Owner überprüft das Product Backlog und bereitet sich auf mögliche Anpassungen vor.
2. Teilnehmer
An der Sprint Review nehmen in der Regel der Product Owner, das Entwicklungsteam, Stakeholder und der Scrum Master teil.
Es ist durchaus hilfreich, Stakeholder wie Herrn Müller und möglicherweise sogar Endbenutzer einzuladen, um Feedback aus erster Hand zu erhalten.
3. Präsentation
Die Präsentation wird in der Regel vom Entwicklungsteam durchgeführt.
Sie zeigen die Funktionen, die sie im Sprint entwickelt haben, in ihrer tatsächlichen Umgebung. Das heißt, sie zeigen beispielsweise, wie die Tischreservierungsfunktion in der App funktioniert.
Auch das selbst ausprobieren durch die Stakeholder ist gestattet und hilfreich für die Review.
4. Diskussion und Feedback
Nach der Präsentation gibt es eine Diskussion und ein Feedback.
Der Product Owner und die Stakeholder haben die Möglichkeit, Fragen zu stellen und ihre Gedanken zu den präsentierten Funktionen zu äußern.
Dies ist ein sehr wichtiger Teil des Reviews, da hier oft neue Ideen und Anforderungen entstehen können.
5. Anpassung des Product Backlogs
Auf Grundlage des Feedbacks und der Diskussion wird der Product Owner entscheiden, ob und wie das Product Backlog anzupassen ist.
Er kann die Priorität von User Stories ändern oder neue User Stories hinzufügen, die auf dem Feedback basieren.
Zum Beispiel könnte Herr Müller auf der Grundlage der vorgestellten Tischreservierungsfunktion neue Ideen für zusätzliche Funktionen haben.
Artefakte
Das Hauptergebnis des Sprint Reviews ist das überarbeitete Product Backlog.
Es enthält nun alle Änderungen, die aufgrund des Feedbacks und der Diskussionen während des Reviews vorgenommen wurden.
Auf Basis des Outcomes für den nächsten Sprint, wird die priorisierung der User Storys im Product Backlog angepasst.
Ein weiteres Ergebnis ist das potenziell auslieferbare Produktinkrement selbst, das in diesem Sprint entwickelt wurde – in diesem Fall die Tischreservierungsfunktion.
Darüber hinaus dient das Sprint Review als Gelegenheit, das Commitment des Teams gegenüber den Stakeholdern zu demonstrieren und die zukünftige Ausrichtung der Arbeiten zu bestimmen.
Es fördert die Transparenz und das Verständnis für die Arbeit des Scrum Teams.
Schritt 6: Das Backlog Refinement
Das Backlog Refinement (früher oft als „Backlog Grooming“ bezeichnet) ist ein kontinuierlicher Prozess während des Sprints, bei dem der Product Owner und das Entwicklungsteam das Product Backlog durchgehen und verbessern.
So läuft normalerweise das Backlog Refinement ab:
Vorbereitung
Der Product Owner geht das Product Backlog durch und identifiziert die User Stories, die klärungsbedürftig sind oder weiter ausgearbeitet werden müssen.
Er kann auch neue User Stories erstellen oder erstellen lassen, die in das Backlog aufgenommen werden sollen.
Teilnehmer
An dem Backlog Refinement nehmen in der Regel der Product Owner, das Entwicklungsteam und der Scrum Master teil.
Der Product Owner präsentiert die User Stories und erklärt das gewünschte Verhalten und die Business-Anforderungen.
Das Entwicklungsteam stellt Fragen und diskutiert technische Details und Lösungsansätze.
Der Scrum Master moderiert das Meeting und stellt sicher, dass es produktiv verläuft und in der Timebox bleibt.
Detaillierung und Schätzung von User Stories
Im Laufe des Meetings werden die User Stories detaillierter beschrieben und die Akzeptanzkriterien klar definiert.
Das Team schätzt dann die User Stories hinsichtlich der benötigten Arbeit.
Sie verwenden oft Techniken wie Planning Poker oder Relatives schätzen, um eine Bewertung zu erreichen.
Hinzufügen neuer User Stories
Falls neue User Stories während des Refinements entstehen oder vom Product Owner vorgeschlagen werden, werden diese ins Backlog aufgenommen und ebenfalls detailliert und geschätzt.
Ein User Story Writing Workshop ist eine spezielle Art von Backlog Refinement. Es ist ein dedizierter Workshop, der darauf abzielt, gemeinsam als Team neue User Stories zu erstellen und zu formulieren.
Das ist nützlich, wenn das Product Backlog sehr klein ist oder wenn ein neues Feature oder eine neues Epic beginnt, die neue User Stories erfordern.
Während eines solchen Workshops können Techniken wie User Story Mapping oder Persona-Analysen verwendet werden, um die Erstellung von User Stories zu unterstützen.
Fazit
Das Hauptergebnis des Backlog Refinements und des User Story Writing Workshops ist ein verbessertes und aktualisiertes Product Backlog, das klarere, besser geschätzte und besser priorisierte User Stories enthält.
Dies erleichtert die zukünftige Sprint-Planung und hilft dabei, das Entwicklungsteam und den Product Owner zu gemeinsamen Verständnis zu bringen.
Schritt 7: Die Scrum Retrospektive und kontinuierliche Verbesserung
Die letzte Aktivität eines Sprints ist die Sprint Retrospektive. Hier reflektiert das Team, was gut lief und was verbessert werden könnte. Vielleicht beschließen sie, mehr Kommunikation mit Herrn Müller zu haben oder die User Stories klarer zu formulieren. Diese Verbesserungen werden im nächsten Sprint angewendet.
Und dann beginnt der Prozess von Neuem, bis das Produkt vollständig entwickelt ist und Herr Müller eine funktionierende App für sein Restaurant hat.
Durch Scrum kann das Team flexibel auf Änderungen reagieren und ständig Verbesserungen vornehmen, um ein Produkt zu liefern, das Herr Müllers Erwartungen erfüllt und seinen Kunden den besten Service bietet.
