Die Scrum Methode als Framework

Dieser Beitrag gibt Ihnen einen einfachen Einstieg und Überblick über ein vielverwendetes Wort im Projektgeschäft: SCRUM – aber was ist das eigentlich?

Was ist Scrum und welche Vorteile bietet die Scrum Methode für die Durchführung von Projekten?

1. Scrum: Ein schneller Einstieg

Scrum ist eine Form des agilen Projektmanagements, die in den 90er Jahren von Jeff Sutherland und Ken Schwaber entwickelt wurde, um Projekte flexibel und anpassungsfähig zu halten.

Der Begriff „Scrum“ ist aus dem Rugby entlehnt und bedeutet soviel wie „Gedränge“. Hierbei streben die Spieler, oder in unserem Fall das Scrum Team, auf ein gemeinsames Ziel hin.

Ein weiterer Begriff, der im Zusammenhang mit Scrum verwendet wird und ebenfalls aus dem sportlichen Bereich stammt, ist der „Sprint“.

Sprints bezeichnen bei der Scrum Methode die einzelnen Entwicklungszeiträume, in der das Scrum Team das jeweilige Projekt-(Teil)ziel erreicht haben soll.

Ein Scrum Sprint ist zwischen 2 – 4 Wochen lang und bietet den Vorteil einer effizienten und ergebnisorientierten Arbeitsweise, bei der die Teammitglieder selbstorganisiert handeln.

Im Gegensatz zu herkömmlichen Projektmanagementmethoden übernimmt der Manager nicht die Verantwortung für das Scrum Projekt, sondern das Scrum Team selbst.

Bei der Scrum Methode gibt es unterschiedliche Scrum Rollen, die durch ein hohes Maß an Eigenverantwortung, Transparenz, kontinuierliche Verbesserung und flache Hierarchien gekennzeichnet sind.

Mit Scrum können Projekte effizient und kundenorientiert realisiert werden. Der Product Owner (dazu weiter unten mehr) stellt dabei den Kunden dar. Die Methode zeichnet sich prinzipiell durch drei Säulen aus: Transparenz, Adaption und Überprüfung.

Durch regelmäßige, klar strukturierte Meetings werden mögliche Problemquellen leichter identifiziert und behoben und ein Prozess der kontinuierlichen Verbesserung entsteht.

Diese Methode eignet sich hervorragend für komplexe Projekte, die im Vorfeld nur schwer planbar sind und daher maximale Flexibilität erfordern.

2. Was ist Scrum?

Scrum definiert ein flexibles Rahmenwerk zur Erstellung iterativer Produkte beziehungsweise Projekte.

Auch wenn Scrum für Flexibilität steht, ist das Framework in sich sehr klar definiert.

Scrum hat seinen Ursprung in der Softwareindustrie, ist mittlerweile allerdings auch in anderen Branchen eine etablierte Entwicklungs- und Managementmethode.

Scrum ist eine Methode mit breit gefächerten Einsatzgebieten, sei es in der Produktentwicklung, im Dienstleistungsbereich, im Marketing oder im Management von komplexen Organisationen.

3. Mögliche Anwendungsbereiche der Scrum Methode

• Automobilbranche
• Militär
• IT-Branche
• Universitäten
• Schulen
• Regierungsprojekte
• Online Marketing

Bei einem Scrum Projekt werden komplizierte und flexible Aufgabenstellungen durch das Scrum Team kreativ und mit Fokus bearbeitet, um am Ende ein innovatives Produkt mit optimalem Mehrwert für den Kunden zu liefern.

Die Eigenschaften des Produkts stellt und verantwortet der Product Owner.

Scrum ist im Wesentlichen dafür da, die Arbeitsmethoden und Resultate innerhalb des Prozesses transparent zu machen und bestmöglich zu optimieren.

4. Einige Vorteile von Scrum im Überblick:

• Hohes Maß an Flexibilität, Effizienz und Transparenz;
• simple Methode, die leicht einführbar und umsetzbar ist (Achtung: Struktur beachten!);
• Probleme können schnell erkannt und verbessert werden (durch die regelmäßigen Sprint-Retrospektiven);
• hochwertige Produktqualität in enger Kooperation mit dem Product Owner;
• gesteigerte Kundenzufriedenheit durch enge kooperative Zusammenarbeit;
• hohes Maß an Eigenverantwortung des Teams führt zu besseren Ergebnissen;
• wenig Dokumentations- und Administrationsaufwand.

Bei der Scrum Methode arbeiten die Scrum Teams in unterschiedlichen Scrum Rollen, auf die wir später genauer eingehen werden. Damit die Methode ihre volle Wirksamkeit entfalten kann, sind einige Faktoren zu beachten.

Scrum zeichnet sich durch bestimmte Prinzipien und Werte aus, die als Richtlinien für die Zusammenarbeit im Team verstanden werden sollten. Dazu gehören Mut, Respekt, Fokus sowie die Bereitschaft, selbstverantwortlich und gleichzeitig teamorientiert zu arbeiten.

Durch die Verkörperung der Werte von Scrum übernimmt das Team die gemeinsame Verantwortung für ein erfolgreiches Scrum Projekt.

Diese Werte und Prinzipien sind im Agilen Manifest wie folgt verankert:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

(siehe Agile Manifesto)

Das Ziel des Prozesses ist es, ein einsatzfähiges Ergebnis oder Produkt zu entwickeln, welches schon nach kurzer Zeit als „potenziell releasefähig“ bezeichnet werden und durch den Kunden direkt nach Ablauf der einzelnen Projektphasen (Scrum Sprint) getestet werden kann.

Die Qualitätssicherung erfolgt im Softwareprojekte meist über Code-Reviews und eine separate QA Instanz, welche Bestandteil des Teams sind.

Der Qualitätssicherungsprozess findet meist über ein Projektmanagement Board in Jira, Trello, Asana oder anderen Tools statt.

Unsere Scrum Boards für Softwareentwicklung haben in der Regel die folgenden Phasen:

• OPEN
• NEEDS INFO
• IN DEVELOPMENT
• DEPLOY TO QA
• IN QA / REVIEW
• DEPLOY TO STAGE
• IN STAGE
• DEPLOY TO LIVE
• FINISHED

Ein Scrum Projekt setzt sich aus dem Team und den dementsprechenden Rollen sowie aus sogenannten Artefakten und Ereignissen zusammen. Weiterhin sollen bestimmte Regeln eingehalten werden.

All diese Faktoren dienen einem spezifischen Zweck und sind die Voraussetzung für den erfolgreichen Einsatz von Scrum.

5. Der typische Ablauf in der Scrum Methode

Jeder Sprint hat ein klar definiertes Ziel, das dem strategischen Ziel Ihres Marketings und Vertriebs zuträglich ist.

Bei einer Website könnte so ein kleines Ziel z.B. „Backend zur Eingabe von Inhalten fertigstellen“). Dieses Ziel kann mit einem Meilenstein identisch sein.

Oft ist ein Meilenstein jedoch weiter gefasst und kann mit einem einzigen Sprint (meist von 2 Wochen) in der Regel nicht erreicht werden.

In Scrum werden sogenannte Ereignisse in Form von regelmäßigen und klar strukturierten Meetings definiert, die zeitlich befristet sind. Damit wird sichergestellt, dass die Arbeitsprozesse effizient und fokussiert ablaufen. Alle nicht definierten Abläufe werden in diesem Prozess strategisch ausgeschlossen.

Ein Ereignis gilt als abgeschlossen, wenn das jeweilige Ziel erreicht ist (“Definition of Done”).

Mit Hilfe der Ereignisse können die Arbeitsprozesse überprüft und die einzelnen Abläufe angepasst werden.

6. Die fünf Scrum Ereignisse im Überblick

Das Scrum-Framework ist durch fünf Ereignisse gekennzeichnet.

Dies sind der Sprint, das Sprint Planning, das Daily Scrum, der Sprint Review und die Sprint Retrospektive.

1. Ein Sprint ist ein bestimmter Zeitraum, in dem das Scrum Team ein Produktinkrement erstellt.

Dies kann beispielsweise ein großes Projekt, mehrere kleinere Projekte, eine Reihe von Berichten oder eine Version einer App sein. Jeder Sprint hat ein klar definiertes Ziel.

2. Die Sprint-Planung wird auch als Sprint Planning Workshop bezeichnet und beschreibt ein Meeting, in dem die während eines Sprints zu erledigende Arbeit festgelegt wird.

Während dieses Meetings definiert das gesamte Team klar die Ergebnisse für den Sprint und weist die notwendigen Arbeiten zur Erreichung des Sprintziels zu. Dazu ist eine klare Priorisierung der einzelnen Elemente im Backlog essentiell.

Die Priorisierung von Epics und User Stories wird durch den Product Owner vorgenommen. Hierbei werden alle wichtigen Informationen im sogenannten Product Backlog festgehalten.

Der Product Backlog dient im Scrum Prozess als wichtigstes Werkzeug.

Im Sprint Planning Workshop sind alle Scrum Rollen anwesend und planen den Ablauf des ersten Scrum Sprint. Nach dem Sprint Planning Workshop geht das Entwicklerteam in die Umsetzung und arbeitet an allen Items, die im Sprint Planning in vom Product Backlog in den Sprint Backlog geschoben wurden.

Im Planning Workshop wird eine erste Aufwandseinschätzung für die erste Arbeitsphase mit Hilfe von Planning Poker durchgeführt. Dabei schätzt das Team mit einem Punktesystem den voraussichtlichen Aufwand des kommenden Sprints ein.

Jede User Story beziehungsweise Anforderung wird geschätzt und mit entsprechenden Komplexitätspunkten bewertet. Dieser Wert wird dann in den Sprint Backlog übertragen.

Im Nachgang wird gemessen, wie viel Zeit für die Umsetzung eines Punkts benötigt wurde. Im Laufe der Zeit bekommt man eine Vorstellung davon, wie viele Einheiten pro Scrum Sprint machbar sind (diese Metrik wird “Velocity” des Teams genannt). Auf der Basis dieser Erfahrungswerte wird der nächste Sprint geplant.

Das könnte Sie dazu ebenfalls interessieren: Umfassende Anleitung für Strategie, Umsetzung & Vermarktung von Web-, Mobile-& Cloud-Anwendungen.

Beispiel Sprint Planning Agenda

In Scrum ist keine feste Agenda vorgegeben, sondern ein Ziel des Meetings.

Das Ziel ist es, den Scope (Umfang) des nächsten Sprints zu definieren, sodass sich das Team auf diesen Umfang einigen kann.

Unsere Sprint Planning Agenda sieht meist wie folgt aus:

• Der Product Owner definiert das Sprint-Ziel und wählt folgend alle Sprint Items aus, die das Team liefern soll.
• Der Product Owner geht die Backlog Items der Reihenfolge nach durch (Wichtigstes zuerst!) und stellt sie dem Team vor – mit der Information, warum das wichtig ist.
• Das Scrum Team stellt Fragen, um das Verständnis zu schärfen.
• Das Scrum Team identifiziert Abhängigkeiten und schreibt diese als Links zu den abhängigen Anforderungen an das besprochene Backlog Item.
• Das Scrum Team gibt für das besprochene Backlog Item eine Schätzung ab (jeder im Team unabhängig voneinander!). Dann werden die Schätzungen diskutiert und das Team committed sich auf einen Schätzung als Ergebnis.
• Das Team identifiziert Risiken, die sich aus dem Sprint Ziel und dem Scope ergeben und definiert Maßnahmen, um diese Risiken abzufangen. Es geht dabei nur um die drei wirklich wichtigsten Risiken, nicht um jedes einzelne kleine Risiko.
• Das Team einigt sich auf die in der letzten Sprint Retrospektive festgestellten Verbesserungen.
• Für jedes Element, das in den Sprint Backlog geschoben werden soll, muss die „Definition of Ready“ (siehe unten) erfüllt sein. Ist dies für manche Backlog Items nicht erfüllt, startet das Team anschließend ein Backlog Grooming (auch Refinement genannt), sodass alle fehlenden Informationen zum Start der Umsetzung vorhanden sind. Das Backlog Grooming sollte immer dann stattfinden, wenn sich Items im Product Backlog verändert haben.

3. Der Daily Scrum wird manchmal auch als Stand-Up oder Daily bezeichnet und beschreibt ein 15-minütiges Meeting, welches täglich stattfindet.

Hierbei hat das Team die Möglichkeit, sich auszutauschen und das, was bis zum nächsten Weekly umgesetzt werden soll, zu definieren, als auch Ziel-Blocker zu identifizieren.

Die Arbeit des Vortages wird analysiert, während Aktualisierungen für die an diesem Tag stattfindende Arbeit festgelegt werden.

Der Scrum Master sollte bei diesen täglichen Treffen idealerweise dabei sein. Teilweise ist auch der Product Owner bei den Daily Scrums anwesend – allerdings ist dieser nicht aktiv am Meeting beteiligt. Er hört nur zu und entscheidet, ob irgendwelche Nachbesserungen im Backlog vorgenommen werden müssen.

Das Ziel des Daily Scrum ist es, Klarheit über den aktuellen Fortschritt zu bekommen und zu sehen, ob jemand eventuell Hilfe braucht oder ob es gegebenenfalls irgendwelche Stolpersteine im Prozess gibt. Es dient der Feinjustierung und stellt die Frage ins Zentrum, wie die Zusammenarbeit sinnvoller gestaltet werden kann.

Das Ziel ist nicht, einen Projekt-Statusbericht abzugeben. Dies geschieht erst beim Sprint Review.

Daily Scrum Agenda als Beispiel

Unsere Agenda für das Daily Scrum Meeting sieht wie folgt aus, wobei sich jeder im Team an diese Agenda hält (das Meeting darf 15 Min nicht überschreiten):

• Was habe ich gestern erreicht, das das Sprint-Ziel voranbringt?
• Was werde ich heute tun, damit wir das Sprint-Ziel erreichen?
• Gibt es Blocker, die ich sehe, die verhindern können, dass wir unser Sprint Ziel erreichen?
• Welche Verbesserungen aus der letzten Retrospektive sind bereits umgesetzt?
• Welche Verbesserungen aus der letzten Retrospektive sind noch nicht umgesetzt?

4. Der Sprint Review findet nach dem Ende eines Sprints statt.

Während der Überprüfung der Ergebnisse erklärt der Product Owner, welche geplanten Arbeiten während des Sprints entweder durchgeführt wurden oder nicht.

Das Team präsentiert die abgeschlossenen Arbeiten und tauscht sich darüber aus, was gut gelaufen ist und wie Probleme gelöst wurden. Es kann auch sein, dass die Stakeholder beim Sprint Review dabei sind.

Der Product Owner gibt Feedback und entscheidet, ob die Aufgabe als erfolgreich abgeschlossen gilt (Definition of „Done“). Die Ergebnisse des Sprint Review werden im Backlog festgehalten.

Sprint Review Agenda als Beispiel

• Wir nehmen jedes Sprint Review Meeting auf und legen das Video in unserem Dokumentation Tool ab. Das hat den Zweck, dass neue Team-Mitglieder durch das Anschauen der letzten Sprint-Review-Videos ein gutes und effizientes Onboarding bekommen, auf dem dann individuell aufgebaut werden kann. So bleibt Know-how digital erhalten.
• Das Team geht durch jedes Backlog Item und präsentiert das Ergebnis (nicht nur besprechen, sondern zeigen).
• Sollte es abhängige Backlog Items geben, werden diese ebenfalls als „Re-Test“ nochmal präsentiert.
• Das präsentierende Team-Mitglied geht die Definition of Done-Checkliste (Siehe unten „Definition of Done“) durch und zeigt, dass diese erfüllt ist.

5. Die Sprint Retrospektive findet nach einem Sprint statt und bietet dem Team die Möglichkeit, die Arbeitsprozesse während des vorherigen Sprints zu analysieren und bei Bedarf Anpassungen vorzunehmen.

Der gesamte Prozess wird hierbei evaluiert und im Backlog festgehalten.

Beispiel Agenda Sprint Retrospektive

• Jedes Teammitglied hat mindestens einen Punkt zu „Was hat im Sprint gut funktioniert?“.
• Jedes Teammitglied hat mindestens einen Punkt zu „Was hat im Sprint nicht gut funktioniert und muss verbessert werden?“.
• Im Team wird beschlossen und für das nächste Sprint Review dokumentiert, was im nächsten Sprint verbessert werden soll. Das gesamte Team muss sich darauf einigen.
• Wie können Verbesserungen in Tools und Workflows systematisiert werden?
• Der Projektreport wird präsentiert (Time, Budget, Scope, Quality).
• Der Product Owner akzeptiert den Report und gibt Ihn frei

7. Was ist ein Sprint?

Den äußeren Rahmen der einzelnen Ereignisse geben die Sprints vor. Sie bilden das Herzstück von Scrum und somit einen klar definierten Rhythmus im Projekt.

Der Entwicklungszeitraum eines Projekts wird in Sprints unterteilt. Der erste Sprint ist der „Setup Sprint“ und der letzte Sprint ist „Final Sprint“. Während jedes Sprints entwickelt das Team bestimmte Features sowie User Stories und behebt Fehler, basierend auf den Prioritäten des Product Owners, die als „das Ziel“ bezeichnet werden.

Ziel eines Sprints sollte immer sein, ein auslieferbares Produktinkrement bereitzustellen um Tests in der Zielgruppe des Produkts zu starten.

In der Regel ist das vorgegebene Zeitfenster für einen Sprint 1-2 Wochen. Je nach Komplexität des Projekts kann es allerdings auf 3 bis maximal 4 Wochen verlängert werden.

Ein einwöchiger Sprint wird beispielsweise für Wartungsprojekte, Fehlerbehebungen von Releases oder bei Projekten mit häufig wechselnden Anforderungen empfohlen, um damit einer besonders hohen Dynamik gerecht zu werden. Es hängt also vom Projekt und der Teamorganisation ab, welche Dauer am besten passt.

Ein Sprint stellt den ausschlaggebende Faktor dar, warum der Scrum Prozess als agile Projektmanagementmethode gilt.

Zwischen den einzelnen Sprints werden immer wieder Verbesserungen und Anpassungen vorgenommen.

Am Anfang steht die Produktplanung, beziehungsweise die Sprintplanung. Hier werden die groben Richtungsziele festgelegt. Außerdem wird entschieden, wie viele Sprints voraussichtlich benötigt werden und was die Zwischenziele der einzelnen Sprints Sprints sein könnten.

Wenn es sich beispielsweise um 10 Sprintphasen á 2 Wochen handelt, steht am Anfang noch nicht fest, was genau während des 6. oder 7. Sprints passiert. Das ist der Unterschied zum klassischen Projektmanagement, denn hier ist der gesamte Prozess bereits am Anfang klar durchgeplant.

Die Details werden immer am Anfang des jeweiligen Sprints aufgrund der Ergebnisse des vorangegangenen Sprints geplant.

8. Was ist das Ziel eines Sprints?

Jeder Sprint muss ein klares Ziel haben. Es ist dafür da, dem Team eine Orientierung über die Arbeitsprozesse zu geben und Klarheit über das betreffende Produktinkrement zu verschaffen.

Das Ziel wird während der Sprint-Planung festgelegt und dient als verbindendes Element der einzelnen Teammitglieder.

Das Sprintziel ist während des gesamten Prozesses der ausschlaggebende Faktor für Priorisierungen und Maßnahmen im Sprint.

Wenn sich im Laufe des Prozesses herausstellt, dass der Arbeitsaufwand dem im Backlog festgelegten Erwartungen nicht gerecht wird, tritt das Team mit dem Product Owner in Kontakt und kann ein neues Ziel aushandeln.

Das könnte Sie dazu ebenfalls interessieren: Umfassende Anleitung für Strategie, Umsetzung & Vermarktung von Web-, Mobile-& Cloud-Anwendungen.

Parallele Sprints in Scrum

Sprints können sich überlappen, wenn in getrennten Teams beispielsweise für Design, Konzeption, Back End und Front End gearbeitet wird. Hierbei kann die Arbeit an dem nächsten geplanten Sprint bereits beginnen und Entwicklungsausfälle können somit vermieden werden.

Während der Kunde (oder der Product Owner) die Ergebnisse des aktuellen Sprints überprüft oder akzeptiert, arbeitet das Team im nächsten Sprint weiter an den Themen.

Ein weiteres Beispiel ist die Arbeit am Backend im CMS. Die Arbeit daran kann in einem eigenen Sprint erfolgen, während gleichzeitig das Frontend von einem anderen Team bearbeitet wird. Die beiden Sprints laufen parallel zueinander ab.

Dies ist ein komplexeres Modell und schwieriger zu verwalten, da hier meist ein Integrations-Sprint nötig wird, um die Ergebnisse zusammen zu führen. Es gibt den Teams jedoch die Möglichkeit, die Ergebnisse schneller und mit weniger Ausfallzeiten zu liefern.

Mit agilen Teams aus Freelancer-Experten sind lokal limitierte Teams in der Lage, solche Engpässe zu überwinden.

9. Die drei Scrum Artefakte

Scrum Artefakte umfassen den Product Backlog, den Sprint Backlog und die Product Inkremente.

Sie beschreiben die während der Sprints durchgeführten Tätigkeiten.

Der Product Backlog ist eine vollständige, geordnete Liste aller Produktanforderungen und dient als einzigartige Referenz für alle notwendigen Produktänderungen.

Der Product Owner überwacht den Product Backlog, einschließlich der Art und Weise, wie er dem Team zur Verfügung gestellt wird und gibt die Priorisierung der einzelnen Backlog-Items vor.

Der Product Owner und der Rest des Teams arbeiten zusammen, um den Product Backlog zu überprüfen und bei Bedarf Anpassungen bzgl. Inhalt und Prioritäten vorzunehmen, wenn sich die Produktanforderungen ändern und weiterentwickeln (was ja der Sinn von Scrum ist, dieser Flexibilität gerecht zu werden).

Der Produkt Backlog kann beispielsweise ein zentrales System oder eine Exceltabelle sein und dient als wichtigste Informationsquelle während des Scrum Prozesses.

Der Product Backlog ist der langfristige Plan, in dem alle Ziele, Anforderungen und User Stories festgehalten werden. In ihm ist auch der Sprint Backlog und das Produktinkrement enthalten.

Der Sprint Backlog ist eine Liste aller Elemente aus dem Product Backlog, die während eines Sprints bearbeitet werden sollen.

Der Sprint Backlog wird zusammengestellt, indem Elemente aus dem Product Backlog so lange priorisiert werden, bis das Team auf der Basis der Story Punkte pro Anforderung im Backlog sieht, dass es seine Kapazität für die nächste Sprintphase erreicht hat.

Gemäß dem selbstorganisierenden Scrum Framework, basierend auf den Fähigkeiten und Prioritäten, werden die einzelnen Aufgaben im Sprint Backlog festgehalten.

Der Product Owner gibt die Prioritäten vor und der Sprint Backlog wird im Sprint Planning Meeting für den nächsten Sprint gebildet.

Das Produktinkrement ist die Summe der während eines Sprints geleisteten Produktarbeit, kombiniert mit allen in früheren Sprints geleisteten Arbeiten.

Das Ziel eines Sprints ist es, ein “Shippable Product Increment” zu produzieren, wobei es dem Scrum-Team obliegt, sich darüber zu einigen, was den „Done“-Status eines Sprints definiert.

Hierbei müssen sich alle Teammitglieder auf eine Definition einigen und sie nachvollziehen können (die “Definition of Done” einzelner Anforderungen im Backlog müssen erfüllt sein).

Das Wesentliche ist folgendes: Scrum ist ein Framework, welches von den Teams verwenden wird, um die Arbeit gemeinsam zu erledigen.

10. Die drei Kern-Rollen bei Scrum

Das Scrum-Framework wird durch drei Kernrollen definiert: das Entwicklungsteam, den Scrum Master und den Product Owner.

Der Product Owner

Der Product Owner ist eine wesentliche Schlüsselrolle im Scrum Prozess. Er oder sie trägt die Verantwortung dafür, die richtigen Anforderungen an das Produkt zu stellen und sorgt dafür, dass die Anforderungen der Stakeholder optimal erfüllt werden.

Diese Rolle ist für die Kommunikation zwischen den einzelnen Parteien verantwortlich, also mit Interessenten, Anwendern, Kunden, dem Management und dem Entwicklungsteam.

Der Product Owner ist immer eine einzelne Person und kein Komitee. Obwohl die Rolle bei Entscheidungen auf die Empfehlungen der anderen Teammitglieder zurückgreifen kann, fällt der Product Owner die endgültigen Entscheidungen letztlich selbst.

Lesen Sie dazu auch: 8 Product Owner Skills, die Sie für Ihr Projekt brauchen

Das Entwicklerteam

Das Entwicklungsteam besteht aus einer Gruppe von Experten, die selbstorganisiert und durch die Scrum Methode geführt zusammenarbeiten, um die gewünschten Produkte zu liefern beziehungsweise Anforderungen zu erfüllen.

Trotz des Titels „Entwicklung“ und des Software-Hintergrunds von Scrum können diese Produkte alles umfassen und schließen auch Dienstleistungen umfassen oder in Marketing-Teams Anwendung finden.

Der Scrum Master

Der Scrum Master ist der Moderator des Teams und dafür verantwortlich, dass alle Teammitglieder den Theorien, Regeln und Praktiken von Scrum folgen. Diese Rolle sorgt dafür, dass das Scrum Team alles hat, was es braucht, um seine Arbeit abzuschließen.

Der Scrum Master kümmert sich darum, dass die Prozesse einwandfrei ablaufen und arbeitet daran, alle Hindernisse aus dem Weg zu räumen, die den Scrum Prozess behindern oder die Produktentwicklung gefährden könnten.

Er sorgt dafür, dass alle Teammitglieder die Scrum Rollen leben und die Scrum Pozesse eingehalten werden. Der Scrum Master sorgt dafür, dass alle Meetings und Termine stattfinden und findet heraus, welche Probleme es gibt und was verbessert werden kann.

Weitere Rollen im Scrum Prozess sind die sogenannten Stakeholdergruppen, die beispielsweise aus Kunden, Anwendern und/oder dem Management.

11. Anforderungen im Scrum Framework

Anforderungen in Scrum werden im Product Backlog abgelegt.

Dabei gibt es unterschiedliche Backlog Items, die jeweils einem spezifischen Zweck dienen. Im Folgenden möchten wir ihnen diese Anforderungs-Typen kurz vorstellen.

Epics – High Level Anforderungen

Ihre Idee wird in einzelne Anforderungsbereiche gruppiert. Diese nennt man in Scrum „Epics“. Es wird zunächst grob beschrieben, welche Nutzer welche Funktionen in Ihrer Software benötigen und welcher Mehrwert dadurch entsteht. Sie erlangen schnell einen Gesamtüberblick über Ihr Vorhaben.

Eine Epic kann z.B. „Content Management“, „Rechteverwaltung“, „Checkout im E-Commerce“ etc sein. Eine Epic dient als Container für feingranularere User Stories.

User Stories – Für Nutzerinteraktion und Verhalten

User Stories beschreiben einzelne Funktionen eines Nutzers innerhalb einer Epic. Wir nehmen mit Ihnen die Sicht aller Anwender in der jeweiligen Rolle ein und beschreiben die Interaktion des Nutzers mit Ihrer Software. Hier werden Validierungen von Formularen, Workflows und Hintergrundprozesse beschrieben.

Das Ziel einer jeden Interaktion ist es, dem Nutzer das erledigen einer bestimmten Aufgabe so einfach wie möglich zu machen (User Experience) so, dass Ihre Nutzer Spaß im Umgang haben.

Beispiel für eine User Story

As a [WHAT ROLE, PERSONA] I want to [ACTION: CLICK A BUTTON; ENTER TEXT ETC] so that [GOAL: WHY YOU WANT TO DO THE ACTION AND WHAT SHOULD BE THE RESULT]

# Notes
(If any.)

# Pages
Links to frontend or backend page cards this user story provides functionality for.

# Acceptance criteria

12. Definition of Ready einer User Story

Jede User Story kann erst dann mit der Umsetzung begonnen werden, wenn alle Elemente der Definition of Ready erfüllt sind.

Also erst dann, wenn die Anforderungen in der User Story wirklich vollständig sind. Die Definition of Ready einer User Story kann für jedes Team individuell definiert werden.

Unsere Definition of Ready enthält die folgenden Punkte:

• Die User Story ist klar definiert in der Form „As a … I want to … so that …
• Das Frontend als auch die Frontend-Effekte sind definiert und an der User Story verfügbar.
• Anforderungen an die Performance sind in der User Story beschrieben, wenn es welche gibt.
• Die Abhängigkeiten der User Story sind identifiziert und abhängige Backlog Items an der User Story dokumentiert (verlinkt).
• Die Akzeptanzkriterien sind vom Product Owner an der User Story dokumentiert.
• Die User Story hat eine Schätzung, die kleiner als 8 Stunden ist (sonst wird die User Story aufgebrochen in kleiner User Stories).
• Dem Team ist klar, wie das Ergebnis der User Story präsentiert werden soll.

13. Definition of Done einer User Story

Die Definition of Done einer User Story in Scrum ist eine Checkliste aller Punkte, die Erfüllt sein müssen, damit die User Story wirklich als „erledigt“ abgehakt werden kann.

Auch diese Checkliste kann pro Team individuell definiert werden. Sie sollte aber in jedem Fall vorhanden sein, damit keine Mißverständnisse entstehen.

Hier eine kurze Checkliste:

• Alle Akzeptanzkriterien wurden durch die QA getestet und haben den Test bestanden.
• Das Ergebnis entspricht dem Design oder folgt dem Style Guide (falls vorhanden).
• Alle abhängigen Backlog Items wurden ebenfalls getestet und haben den Test bestanden.
• Eine andere Person (als die Person, die die Story umgesetzt hat) hat den Code und die Architektur geprüft.
• Die Dokumentation wurde angepasst und die Dokumentation entspricht den Dokumentations-Guidelines (falls vorhanden).
• Automatisierte Tests wurden erstellt (falls im Projekt automatisierte Tests verwendet werden, siehe dazu auch Software testing).
• Der Product Owner hat in einer persönlichen Präsentation das Ergebnis akzeptiert.

14. Kommunikation in Scrum

Bei der agilen Entwicklung nach Scrum geht es um eine verbesserte Kommunikation und um kontrollierbare Kommunikationskanäle.

Jedes Projekt braucht einen klaren Kommunikationsplan. Hier wird geklärt, wann welche Meetings stattfinden, worum es bei diesen Treffen gehen soll und wer anwesend sein soll.

Außerdem muss feststehen, was das Thema des Meetings ist (siehe Beispiel-Agenda zuvor für jedes Meeting), wie lange es dauert und wo es stattfinden kann.

Hierbei kommt immer weniger das klassische Büro infrage, sondern es werden auch digitale Tools wie Google Hangouts, Skype oder Zoom verwendet. Die Kommunikation ist deshalb von ausschlaggebender Bedeutung, um größtmögliche Transparenz unter den Beteiligten herzustellen.

Außerdem stellt eine glasklare Kommunikation sicher, dass alle Verantwortlichkeiten geklärt sind. Der Kommunikationsplan ist ein Teil Ihres Projektmanagement-Plans. Übliche Meetings sind das Daily Meeting und das Weekly Meeting.

15. Agile Scrum mit agilen Teams aus Freelancer-Experten

Scrum mit agilen, remote-basierten Teams weicht im Prozess, in den Meetings als auch in den Rollen nicht von Scrum in einem lokalen Team ab.

Da „Ad-hoc-Kommunikation“ ohnehin oft stört und diese im virtuellen Team seltener ist, sind die Vorteile von Scrum Prozessen im Remote Work Alltag noch deutlicher zu spüren.

Digitales Arbeiten ist die absolute Voraussetzung. Wird im Agile Scrum Team jedoch konsequent digital gearbeitet, ergibt sich die Chance, Know-how während des Prozesses digital festzuhalten, z.B. indem die Sprint Reviews, in denen jede einzelne Anforderungen präsentiert wird, ggf auch das Sprint-Planning, gefilmt und in einer Mediathek wie Microsoft Stream, Vimeo oder Youtube abgelegt.

So wird Know-how konstant dokumentiert und aufgebaut und kann auch für künftige neue Team-Mitglieder ein einfacheres Onboarding ermöglichen.

16. Unser Fazit

Damit Scrum erfolgreich eingesetzt werden kann, ist ein perfektes Zusammenspiel und die Einhaltung des Regelwerks von ausschlaggebender Bedeutung.

Scrum ist eine Methode, die ein hohes Maß an Offenheit und Selbstverantwortung von allen Beteiligten abverlangt.

Vor allem der Scrum Master muss eine starke Persönlichkeit haben und darauf achten, dass Scrum lebendig bleibt und alle ihre Rollen erfüllen.

Scrum ist eine wunderbare und flexible Methode, um den rasant wachsenden und sich verändernden Anforderungen unserer Zeit gerecht zu werden.

Produkte beziehungsweise Projekte können, mit maximalem Mehrwert, effizient und Kundenorientiert geliefert werden. Scrum bietet somit einige entscheidende Vorteile gegenüber dem klassischen Wasserfallmodell im Projektmanagement.

Dafür ist allerdings die Bereitschaft und Offenheit für agile Vorgehensweisen bei allen Beteiligten ein ausschlaggebender Faktor.