AGILES FRAMEWORK: SCRUM¶

Im Scrum wird auf eine umfangreiche und vollständige Planungsdokumentation wie im traditionellen Projektmanagement weitgehend verzichtet. Zu Beginn des Projektes steht ein Product Goal, welches versucht wird umzusetzen. Anhand dessen wird eine Sammlung von Anforderungen an das Produkt in Form eines eindimensionalen, priorisierten Kataloges, dem Product Backlog, erstellt – dann geht es direkt in die schrittweise Umsetzung. Im Zentrum stehen kurze Entwicklungszyklen, sogenannte Sprints. In ihnen werden vollständige Teilergebnisse erarbeitet, die dann nach ihrer Fertigstellung eine qualifizierte Rückmeldung durch den Kunden bzw. einen verantwortlichen Vertreter sowie durch die Stakeholder erlauben. Hierdurch ist es möglich, bereits im frühen Stadium des Projektes kostspielige Fehlentwicklungen zu korrigieren und damit ausufernde Zeitverluste und Zusatzkosten zu vermeiden. Um einen reibungslosen Arbeitsablauf zu gewährleisten, existieren im Scrum gewisse Regeln (die Scrum Säulen Transparenz, Überprüfung und Anpassung) und Werte (Commitment, Fokus, Offenheit, Respekt und Mut), zu deren Einhaltung sich alle Beteiligten verpflichten.

Projektatlas Scrum¶

Rollen bei Scrum¶

Die drei Hauptrollen¶

Anders als im traditionellem Projektmanagement gibt es keinen Projektleiter – die Scrum Welt ist dreigeteilt. Ein Scrum Team besteht aus einem Product Owner, einem Scrum Master und den Developern. Sie arbeiten zusammen, um ein möglichst optimales Produkt zu erzeugen.

Der Product Owner ist der Kunde oder sein voll umfänglicher Repräsentant im Projekt (Stellvertreter, bzw. Proxy). Er stellt sicher, dass dessen Vorstellungen in das Projekt eingearbeitet werden und verantwortet den „Return on Investment“ (ROI).

Die Developer kommen aus verschiedenen Fachrichtungen (cross-functional), arbeiten selbstständig und fällen Entscheidungen bei der Produkterstellung in eigener Verantwortung. Sie haben sich der Aufgabe verschrieben, in jedem Sprint einen Mehrwert zu generieren.

Ihnen ist der Scrum Master als Coach und Teamentwickler beigestellt, der sich unter anderem darum kümmert, dass die Arbeitsumgebung optimiert wird und Scrum (wie im Scrum Guide definiert) im Unternehmen gefördert wird. Er ist ergebnisverantwortlich für die Effektivität des Scrum Teams, indem er organisatorische Behinderungen und Störungen des Arbeitsablaufes ausräumt [14][15][16].

Dabei kann das Einsatzgebiet von Scrum im Projektmanagement recht unterschiedlich aussehen, wie etwa:

• Eine Firma benötigt eine neue Software bzw. ein neues Programm und beauftragt dafür ein Entwicklungshaus.
• Innerhalb eines Unternehmens benötigen die Fachabteilungen Anpassungen ihrer Arbeitssoftware und beauftragen die IT-Abteilung.
• Ein Unternehmen installiert ein neues ERP-System (Enterprise Ressource Planning) und beauftragt mehrere Scrum Teams mit der Entwicklung von Applikationen.

Mitglieder des Scrum Teams können auch über große Entfernungen verteilt sein, daher sind die Rollen Product Owner, Scrum Master und Developer nicht immer im selben Unternehmen. Dadurch sind die im Scrum Framework beschriebenen Bedingungen nicht immer einzuhalten, sodass die Rollen, Zuständigkeiten und Abläufe variieren können. Unter Umständen kann dies aber die Arbeitsergebnisse negativ beeinträchtigen.

Ziel von Scrum ist, durch sogenannte Increments nutzbare und auch potenziell auslieferbare Ergebnisse (z. B. Software, etc.) zu erarbeiten.

Product Owner¶

Der Product Owner hat das Ziel, den Wert des Arbeitsergebnisses zu steigern und steht dafür auch allein in der Verantwortung. Er ist immer eine ansprechbare Person, weder eine Abteilung noch ein Ausschuss. Als Manager des Product Backlogs erfüllt er folgende Funktionen:

• Verantwortlich für den (potenziell auslieferbaren) Mehrwert des Produktes
  (Return on Investment – ROI)
• Entwickelt und kommuniziert das Product Goal
• Zuständig für die Erstellung der Einträge des Product Backlogs, gegebenenfalls in der Form von User Stories
• Priorisierung und klare Kommunikation dieser Einträge
• Repräsentiert seine Stakeholder in unterschiedlichen Szenarien (beispielsweise die Kunden und Anwender) und verantwortet das Stakeholdermanagement
• Entwickelt mit den Developern zusammen das Sprint Goal
• Steht idealerweise während des Sprints den Developern zur Verfügung, um etwaige Fragen zu beantworten
• Verantwortlich für die Abnahme der Increments
• Hat die Entscheidungshoheit, ob der Sprint weitergeführt oder beendet wird

TIPP: Der Product Owner darf die Umsetzung der Aufgaben rund um das Product Goal und den Product Backlog selbst erledigen oder aber an andere delegieren. Dennoch ist er allein verantwortlich für die Ergebnisse.

Developer¶

Die Developer sind die Personen im Scrum Team, welche in jedem Sprint nutzbare Increments erschaffen. Sie sind selbstorganisiert und alle technischen Kompetenzen sollten möglichst vertreten sein. Die Aufgaben der Developer umfassen:

• Erstellung des Sprint Backlogs (Planungsgrundlage für jeden Sprint) und Verhandlung des Aufgabenumfangs mit dem Product Owner
• Gemeinschaftliche Verantwortung der Ergebnisse jedes Sprints
• Mehrwert und Qualität durch die Einhaltung einer „Definition of Done“ (DoD) zu erbringen

Daneben ist das Team von Developern

• interdisziplinär (cross-functional),
• (eigen-)verantwortlich für die Umsetzung der Aufgaben und
• idealerweise aus 10 Mitgliedern oder weniger bestehend.

Scrum Master¶

Der Scrum Master ist verantwortlich, dass Scrum als Framework gefördert und gelebt wird. Er sorgt dafür, dass alle Beteiligten die Theorie, Handlungsweisen, Regeln und Werte verstehen und befolgen können. Die Aufgabe des Scrum Masters besteht darin, seine agile Führungsrolle als „Servant Leader“ wahrzunehmen [17]. Dies bedeutet, dass sein Fokus drauf liegt, andere zu moderieren, zu befähigen und so zu coachen, damit diese erfolgreich im Sinne von Scrum agieren können. Sein Erfolg ist von deren Erfolg abhängig. Seine Ansprechpartner sind neben dem Product Owner und den Developern auch das Unternehmen. Er ist integraler Bestandteil des Scrum Teams.

In Bezug auf den Product Owner stellt er sicher, dass jeder Beteiligte innerhalb des Scrum Teams den Aufgabenhorizont des Product Owners auch versteht. Dazu gehören die Ziele und auch die Produktdomäne. Weiter umfasst sein Aufgabengebiet:

• Assistenz des Product Owners bei der Formulierung des Product Goals, der Definition von Product-Backlog-Einträgen und gegebenenfalls auch den User Stories.
• Unterstützung bei allen Scrum Meetings.
• Assistenz bei der Priorisierung von Einträgen.
• Unterstützung und gegebenenfalls Coaching bei der Frage, wie Agilität und empirisches Vorgehen praktiziert und gelebt werden kann.
• Förderung der Zusammenarbeit mit den Stakeholdern (faciliate), falls gewünscht.

In Hinblick auf die Developer besteht seine Aufgabe darin, das Team bei allen Belangen zu fördern und zu einem erfolgreichen Team (siehe Performing Team) zu entwickeln. Darunter fallen folgende Aufgaben:

• Coaching des Teams, um ein „Performing Team” zu werden.
• Unterstützung beim Selbstmanagement der Developer, sodass diese eigenständig Entscheidungen fällen und durchführen können.
• Förderung der (interdisziplinären) Zusammenarbeit.
• Sicherstellung des ordentlichen Ablaufs aller Scrum Events (Einhaltung des Zeitrahmens, positive und produktive Arbeitsumgebung).
• Identifikation von Störungen (impediments) sowie Sicherstellung von deren Beseitigung.
• Falls notwendig: Vermittlung zwischen Developern und Product Owner.

Im Bezug auf die Organisation kommt es auch darauf an, zu welchem Grad Scrum als Rahmenvorgabe mit seinen Anforderungen und Abläufen im Unternehmen bereits etabliert ist. Wie hierarchisch ist das Unternehmen organisiert, und inwieweit kann Verantwortung auch effektiv delegiert werden? Besteht bereits Verständnis dafür und ist somit auch die Möglichkeit gegeben, agiles, empirisches und inkrementelles Vorgehen zu ermöglichen? Insbesondere bei der Einführung von Scrum kann das bedeuten, auf Widerstände und Vorbehalte zu stoßen. Auch spielt die Unternehmenskultur eine entscheidende Rolle. Hauptsächlich ermöglicht der Scrum Master folgendes im Unternehmen:

• Vermittlung der Vorgehensweise, Ziele, Inhalte und des Mindsets agilen Vorgehens.
• Er ist Organisationsentwickler und sorgt für die Implementierung von Scrum im Unternehmen, sodass die Rahmenbedingungen gegeben sind oder, wenn nötig, verbessert werden.
• Information und Coaching von Mitarbeitern, Linienvorgesetzten, Verantwortungsträgern.
• Assistenz aller Mitarbeiter und Stakeholder beim Verständnis von Agilität sowie empirischer Vorgehensweise (agile Führungsrolle).
• Reduzierung von Barrieren zwischen Stakeholdern und Scrum Team.

Rollenverteilung bei großen Scrum Projekten (Scrum of Scrums)¶

Bei größeren Scrum Projekten kann sich gegebenenfalls die Notwendigkeit oder Möglichkeit ergeben, mehrere Teams von Developern parallel arbeiten zu lassen [18][19]. In diesem Fall kann ein Scrum Master unter Umständen mehrere Teams gleichzeitig betreuen. Anders ist es beim Product Owner, denn hier wird jedem Team ein spezifischer, für dieses „Teilprojekt“ benannter, Product Owner beigestellt. In dieser Konstellation ist es jedoch wichtig, einen Chief Product Owner zu identifizieren, der dann die Gesamtverantwortung und endgültige Entscheidungsvollmacht gegenüber den anderen Product Ownern hat.

Verantwortlichkeiten¶

Product Vision¶

Das große Ziel der Entwicklung¶

Mit der Product Vision wird das große Ziel für die Entwicklung neuer Produkte abgesteckt. Dabei geht der Zeitraum oder Horizont weit über den Abschluss des Projektes hinaus und schließt den Produktlebenszyklus mit ein [20]. Es geht darum, den gewünschten wirtschaftlichen Erfolg als Vision zu formulieren und der Frage nachzugehen, wie er erreicht werden kann. Sie muss jedoch nicht unbedingt in allen Fällen erarbeitet werden, etwa, wenn innerhalb eines Unternehmens Scrum Projekte durchgeführt werden (z. B. die IT-Abteilung entwickelt Anwendungen für Fachabteilungen). Die Verantwortung liegt beim Product Owner.

Es ist jedoch zu beachten, dass seit 2020 die Product Vision nicht mehr als solche existiert. Stattdessen ist das Product Goal an deren Platz getreten [21]. Die Product Vision kann als großes Product Goal verstanden und auch dazu genutzt werden, ein übergeordnetes Ziel zu definieren.

Commitment: Das Product Goal¶

Der Kompass der Entwicklung¶

Das Product Goal ist die Verpflichtung (commitment) des Scrum Teams zum Product Backlog und dient als Kompass für die Entwicklung des aktuellen Projektes. Es beschreibt, anders als (vormals) die Product Vision, ein konkretes Ziel, welches mit dem Scrum Projekt verfolgt und durch die Sprints erzeugt wird [22].

Bei der Erarbeitung des Product Goals sollten möglichst Kunden und Anwender miteinbezogen werden. Der Product Owner entwickelt für die Stakeholder des Projektes ein gemeinsames Verständnis der Zielvorstellung und legt die Rahmenbedingungen fest, die der Vermarktung des Produktes und dessen wirtschaftlichem Erfolg dienen.

Dabei geht es um folgende Fragen:

• Wieso wird das Projekt durchgeführt?
• Welche Zielgruppe soll angesprochen werden?
• Worin besteht das Bedürfnis oder der Nutzen des Kunden / der Verbraucher?
• Worum handelt es sich? Was genau wird angeboten?
• Welche Alleinstellungsmerkmale hat die Anwendung oder das Produkt gegenüber Mitbewerbern?
• Wie ist das Geschäftsmodell aufgebaut?
• Auf welche Weise soll Gewinn erwirtschaftet werden?

Scrum Artefakt: Das Product Backlog¶

Produktanforderungen¶

Zu Beginn des Projektes wird das Product Backlog erstellt. Es ist die zentrale Sammelstelle für die Anforderungen an das Produkt und unterliegt der Verantwortung des Product Owners.

Es enthält jedweden Eintrag, der zur Erarbeitung des Endproduktes notwendig ist. Diese Einträge werden auch als Product Backlog Items bezeichnet. Dazu gehören Merkmale, Funktionen, Anforderungen, aber auch Korrekturen, Darstellungen, oder auch Benutzeroberflächen (Graphical User Interface) [23].

Eine häufig verwendete Eintragsform sind User Stories [24]. User Stories sind Wünsche und Anforderungen an ein Endprodukt, die vom Product Owner oder seinen Stakeholdern in „Prosa“ festgehalten werden. Die technische Umsetzung der User Stories wird zu diesem Zeitpunkt noch nicht thematisiert – das erfolgt später im Sprint Backlog.

Sobald der erste Pool von Anforderungen ermittelt wurde, werden die Einträge im Product Backlog im nächsten Schritt priorisiert, das heißt, nach ihrer Wichtigkeit geordnet. Einträge, die weiter oben im Product Backlog aufgelistet sind, sind klarer und detaillierter als weiter unten gelistete Einträge [25]. Die obersten Einträge sind demnach die, die der Product Owner zuerst umgesetzt haben möchte. Das Kriterium für die Priorisierung ist üblicherweise der Geschäftswertbeitrag, den die Umsetzung der jeweiligen User Story liefert. Aber auch andere Kriterien können eine Rolle spielen, wie etwa Entwicklungskosten oder Risiken [26]. In jedem Sprint (Entwicklungszyklus) wird eine von den Developern festgelegte Anzahl der obersten Einträge aus dem Product Backlog in ein Increment umgesetzt.

Damit dies möglich ist, müssen die Einträge oder User Stories im oberen Bereich vom Arbeitsaufwand her so gestaltet sein, dass ihre Umsetzung in den kurzen Sprintzyklen möglich ist.

Weiter unten im Product Backlog gibt es Einträge unterschiedlichster Größe: Weitere Einträge, User Stories, Epics (sehr umfangreiche User Stories) und Themes (User Stories, die zu einem gemeinsamen Themenbereich zusammengefasst sind).

Sobald diese Einträge in den oberen Bereich des Product Backlog verschoben werden, müssen sie in feingranulare Einträge oder User Stories zerteilt werden, um ihre Umsetzbarkeit sicherzustellen.

Sobald ein Eintrag in die technische Umsetzung überführt wird, wird dieser aus dem Product Backlog entfernt und die weiter unten aufgeführten Einträge rutschen nach. Tasks, welche die „Definition of Ready“ erfüllen und zum Sprint Goal passen, sind zur Verschiebung in das Sprint Backlog bereit [27].

Das Product Backlog ändert sich dabei fortlaufend.

Backlog-Einträge haben eine Beschreibung, werden eingeordnet und auf ihren Aufwand hin abgeschätzt. Gegebenenfalls kommen Testbeschreibungen hinzu, diese gehören zu den Akzeptanzkriterien, welche wiederum Bestandteil der „Definition of Done“ sind.

Das Product Backlog

• unterliegt der Verantwortung des Product Owners.
• enthält eine Liste der gewünschten Funktionalitäten.
• kann als wesentlichen Bestandteil User Stories enthalten.
• enthält Einträge, die nach Wichtigkeit (z. B. Geschäftswertbeitrag) priorisiert und abgeschätzt werden. Höchstpriore Einträge werden im kommenden Sprint bearbeitet.
• wird, wenn Anlass dazu besteht, nach Maßgabe des Product Owners während der Projektlaufzeit gewartet (refinement).
• unterliegt einer konstanten Veränderung und ist das Zentrum agiler Anpassung.
• soll den DEEP-Kriterien (detailed appropriately, estimated, emergent, prioritised) genügen.

Backlog Refinement¶

Backlog Refinement Meeting¶

Im Backlog Refinement Meeting, welches manchmal noch unter dem Begriff Backlog Grooming zu finden ist, aber hier keine Verwendung mehr findet, werden vorhandene Einträge des Product Backlogs gesichtet sowie priorisiert. Während dieses Meetings werden zudem die Inhalte weiter spezifiziert und deren Aufwand abgeschätzt.

Neue Einträge ergeben sich aus den vorhergehenden Ergebnissen der Umsetzung. Die Priorisierung wird aufgrund sich ändernder Randbedingungen aktualisiert und Einträge oder User Stories, welche für das Produkt als unwichtig identifiziert wurden, werden aus dem Product Backlog entfernt [28].

Die Vorbereitung des kommenden Sprints dient der Festlegung derjenigen Einträge aus dem Product Backlog, die bearbeitet werden sollen, sowie der Maßnahmenplanung zur technischen Umsetzung. Diese Vorbereitung wird üblicherweise im Sprint Planning durchgeführt.

Die folgenden Punkte können als Agenda für ein Backlog Refinement Meeting dienen:

• Ordnen und Priorisieren der Product-Backlog-Einträge
• Löschen von Product-Backlog-Einträgen, welche nicht mehr wichtig sind
• Hinzufügen von neuen Product-Backlog-Einträgen
• Ausformulieren und Hinzufügen von Details zu den Product-Backlog-Einträgen
• Zusammenfassen von Product-Backlog-Einträgen
• Schätzen von Product-Backlog-Einträgen (Aufwand)
• Eventuell Planung von Releases

User Stories¶

Einträge im Product Backlog¶

Ein wichtiges Kriterium bei der Erstellung und Gestaltung des Product Backlog ist die Sichtweise des Kunden oder Endnutzers des Produktes. User Stories geben dem Anwender die Möglichkeit in seiner Sprache auszudrücken, was er sich wünscht. Daher werden die Einträge in Form von User Stories erstellt und in das Product Backlog eingetragen. Während bei der Einführung von Scrum die technische Umsetzung der Anforderungen noch in das Product Backlog eingetragen wurde, wird mittlerweile weitestgehend darauf verzichtet. Technische Aspekte und Fragen der Umsetzung werden im Sprint Backlog eingetragen (siehe Sprint Backlog).

Eine User Story wird aus der Sicht des Anwenders geschildert und beinhaltet Informationen bezüglich „Rolle“, „Funktionalität“ und „Geschäftswertbeitrag“, also worin der Nutzen oder Mehrwert besteht [29]. Dadurch ist sichergestellt, dass jeder Teilnehmer am Projekt – etwa Kunden, Endnutzer oder auch andere Stakeholder – ihre Wünsche ausdrücken können, ohne technische Kenntnisse zu besitzen oder sich fachlich ausdrücken zu müssen.

Um eine User Story umsetzbar zu machen (wenn diese der „Definition of Ready“ entsprechen), sollte sie den INVEST-Kriterien genügen [30]:

Independent – Unabhängig
Negotiable – Verhandelbar
Valuable – Wertvoll
Estimable – Abschätzbar
Short – Kurz
Testable – Testfähig

Außerdem sollten beim Einfügen von User Stories in das Product Backlog die drei Cs für gute User Stories beachtet werden. Die Cs stehen dabei für Card, Conversation und Confirmation [31].

Card:
Die wichtigsten Daten einer User Story werden auf einer Karte festgehalten. Dazu gehören die Priorität der User Story, ihre Akzeptanzkriterien und auch der Arbeitsaufwand für die Umsetzung einer User Story, der in einer Schätzklausur ermittelt wurde.

Conversation:
Product Owner und Developer haben sich ausführlich über die User Story ausgetauscht und das Ziel der User Story wurde von allen verstanden.

Confirmation:
Es wurden Akzeptanzkriterien (acceptance criteria) festgehalten, unter deren Einhaltung der Product Owner die Umsetzung der User Story im Increment durch entsprechenden Akzeptanztests abnimmt.

Aktualisierung des Product Backlog¶

Das Product Backlog sollte in regelmäßigen Abständen einer Bewertung und Überprüfung unterzogen werden. Diese Bewertung und Überprüfung erlaubt es die Einträge im Product Backlog durchzusehen und dahingehend zu überprüfen, ob sie noch aktuell sind und ob sie die Interessen des Kunden korrekt wiedergeben. Zur Aktualisierung des Product Backlogs eignet sich das Backlog Refinement Meeting.

Es ist wichtig, immer eine ausreichende Anzahl von User Stories im Zustand „Ready“ zu haben. Der Status „Definition of Ready“ bezeichnet Product Backlog Items, die den drei Cs und den INVEST-Kriterien genügen und für eine Umsetzung in Aufgaben (Tasks) hinreichend klein und detailliert sind. Damit können sie jederzeit in das Sprint Planning übernommen und in Folge dem Sprint zugeführt werden (siehe Definition of Ready).

Definition of Ready (DoR)¶

Die „Definition of Ready“ (DoR) bedeutet, dass ganz oben im Product Backlog gelistete Aufgaben oder User Stories so formuliert sein müssen, dass diese für die Developer verständlich sind und beim nächsten Sprint bearbeitet werden können.

Wenn Product Backlog Items (PBI) nicht der DoR entsprechen und die Entwickler diese auch nicht exakt verstanden haben, kann der Entwicklungsaufwand steigen und die Bearbeitung der Items den zeitlichen Rahmen des Sprints sprengen. Dies führt im schlimmsten Fall dazu, dass das Sprint-Ziel verfehlt oder ein Increment nicht rechtzeitig geliefert wird [32].

Anders ausgedrückt, eine Aufgabe ist dann als „ready“ zu betrachten, wenn die Developer sagen, sie haben sie verstanden. Erst wenn die PBIs der DoR sowie den INVEST-Kriterien und den drei Cs entsprechen, sind diese für das Sprint Backlog bereit und können bearbeitet werden.

Eigenschaften von PBIs, welche einer „Definition of Ready“ entsprechen, können sein [33]:

• Für jeden Developer klar verständlich
• Feingranular (möglichst klein)
• Geschätzt und bieten einen Mehrwert
• Mindestens ein Akzeptanzkriterium (von allen Beteiligten verstanden)

Agiles Schätzen¶

Aufwandsbewertung¶

Eine wichtige Grundlage für jede weitere Planung ist das Abschätzen des Arbeitsaufwandes, der sich hinter den Einträgen im Product Backlog verbirgt. Damit lässt sich ein erster Eindruck vermitteln, welchen Umfang die Arbeiten im Projektverlauf haben könnten.

Dabei wird darauf verzichtet, konkrete Vorhersagen zu machen, wie hoch beispielsweise etwa der Aufwand in Arbeitsstunden sein könnte. Vielmehr geht es darum, relative Größen zu ermitteln, das heißt, die Komplexität der einzelnen Einträge wird im Verhältnis zueinander geschätzt. Durch die relativen Aufwandsgrößen ist es einfacher, die Release-Pläne an geänderte Randbedingungen, die die Velocity (Entwicklungsgeschwindigkeit) verändern, anzupassen, und die Auswirkungen der Veränderungen zu bewerten.

Ablauf der Schätzklausur

• Die Schätzklausur erfolgt im Team zum Beispiel in Form eines „Planning Poker“.
• Jeder Eintrag des Produkt Backlogs wird abgeschätzt. Man beginnt mit der User Story, die den geringsten Arbeitsumfang erwarten lässt.
• Anschließend werden alle weiteren Einträge mit dem ersten Eintrag verglichen und relativ dazu bewertet.
• Der Aufwand wird üblicherweise in Story Points geschätzt.
• Für die Story-Points-Abschätzung empfiehlt sich die Skala nach Fibonacci:
  Die Zahlenfolge von Fibonacci ergibt sich, wenn die vorausgehende Zahl jeweils zur nachfolgenden Zahl addiert wird (1, 2, 3, 5, 8, 13, 21, 34). Einträge am oberen Ende der Skala haben bereits den Charakter von Epics und müssen im weiteren Verlauf in User Stories geteilt werden.
• Eine weitere Möglichkeit neben den Story Points besteht darin, die Einträge mit Kleidergrößen zu vergleichen. Diese lauten: XXS, XS, S, M, L, XL und XXL. Einträge am unteren Ende der Skala haben bereits den Charakter von Epics und müssen im weiteren Verlauf geteilt werden.

Sprint¶

Die Erzeugung des Projektgegenstandes¶

Sprints sind Entwicklungsintervalle, in denen das Projektergebnis erarbeitet wird. Sie werden in festen Zeiträumen von maximal vier Wochen oder weniger durchgeführt [34][35]. Die Zeiträume können gegebenenfalls verändert werden, wenn das Scrum Team dies so entscheidet. Bei komplexen Entwicklungsvorhaben bieten sich kürzere Sprints an, da auf diese Weise schneller gehandelt werden kann, falls das Projekt nicht in die richtige Richtung läuft. Während des Sprints wird ein Sprint Backlog (Scrum-Task-Board) geführt welches täglich aktualisiert wird. Der Sprint Backlog soll an einer gut sichtbaren Stelle – im Büro oder virtuell – angebracht sein. Somit ist jederzeit ersichtlich, wo sich der Sprint gerade befindet.

Scrum Artefakt: Das Increment¶

Ein konkreter Schritt in Richtung Product Goal¶

Das Ziel eines jeden Sprints ist es, an dessen Ende ein (oder mehrere) getestete und nutzbare, möglicherweise sogar verkaufsfähige Increments zu erhalten. Jedes Increment ist ein Schritt zur Erreichung des Product Goals. Jedoch sind alle Arbeiten, die nicht der „Definition of Done“ entsprechen, nicht als Increment zu betrachten.

Die erzeugten Increments werden am Ende des Sprints im Sprint Review vom Product Owner abgenommen und von ihm sowie evtl. anwesenden Stakeholdern mit den Developern begutachtet [36][37]. Es ist auch möglich, ein Increment schon vor Ablauf des Sprints an die Stakeholder auszuliefern.

Letztendlich ergibt die Summe der Increments das finale Produkt, welches durch das Product Goal beschrieben und im Product Backlog spezifiziert wurde.

Commitment: Definition of Done (DoD)¶

Wann ist ein Increment erledigt?¶

Die „Definition of Done“ (DoD) ist das zum Increment zugehörige „commitment“ . Es ist ein wichtiges agiles Werkzeug, das Teams dabei hilft, Arbeit zu planen und durchzuführen. Im Prinzip ist die DoD lediglich eine Reihe von Kriterien, die das Produkt erfüllen muss, um als fertig zu gelten.

Ein wesentlicher Aspekt bei der Bearbeitung der Sprints ist die Forderung, dass ein Sprint nur dann insgesamt erfolgreich ist, wenn alle User Stories vollständig in ein Increment umgesetzt und dann im Sprint Review präsentiert wurden. Auch wenn nicht alles Stories umgesetzt wurden, kann der Sprint Review als „Done“ definiert werden, wenn das Sprint Goal erfüllt wurde [38][39][40].

Die Kriterien der DoD, denen alle umgesetzten User Stories im Increment entsprechen müssen, können folgende Anforderungen erfüllen: Geschäfts-, Funktionalitäts-, Qualitäts- und Nicht-Funktionale Anforderungen [41]. Ebenfalls können sie von den Developern nach Rücksprache mit dem Product Owner festgelegt werden.

Beispiele für „Definition of Done“-Kriterien:

• Das Sprint-Ziel wurde nach Einschätzung des Scrum Teams erreicht (das kann evtl. auch dann der Fall sein, wenn nicht alle User Stories umgesetzt wurden).
• Die Akzeptanzkriterien der umgesetzten User Stories werden erfüllt.
• Die Release-Dokumentation ist fertiggestellt.
• Das Increment ist getestet.
• Bestehende Richtlinien, Standards und Normen wurden eingehalten.

Scrum Artefakt: Sprint Backlog¶

Was wird als nächstes bearbeitet?¶

Zu Beginn jedes Sprints werden die Einträge aus dem Product Backlog ausgewählt, welche im kommenden Sprint bearbeitet und in ein auslieferbares (= getestetes, vorzeigbares) Increment überführt werden sollen. Die Auswahl erfolgt im Sprint Planning Meeting unter Teilnahme des Product Owners, gegebenenfalls des Scrum Masters und der Developer [42][43]. Die Developer entscheiden, wie viele Einträge im kommenden Sprint bearbeitet werden sollen und orientieren sich dabei an der in den vorangegangenen Sprints erzielten Velocity. Der Sprint Backlog besteht, neben den Product-Backlog-Einträgen und den Increments, aus dem Sprint Goal.

Es hat sich dabei als hilfreich erwiesen, das Sprint Backlog als sogenanntes Taskboard [44] an einer gut sichtbaren Stelle im Arbeitsbereich zu platzieren. In der linken Spalte sind dabei die zur Umsetzung anstehenden User Stories priorisiert aufgelistet. Rechts daneben in der To-Do-Spalte stehen die Arbeiten (Tasks), welche für die Umsetzung der jeweiligen User Story in ein Increment notwendig sind. Die Tasks sind so angeordnet, wie die Developer sie im Sprint Planning Meeting bestimmt haben. Eine Spalte weiter wird aufgeführt, was gerade getan wird (WIP = Work-in-Progress) und in der letzten Spalte sind die erledigten (= Done) Arbeiten gelistet. So lässt sich jederzeit gut visualisieren, wo die Arbeiten gerade stehen. Spätestens wenn die Developer über verschiedene Standorte verteilt sind, sollte man über den Einsatz eines softwarebasierten Sprint Backlogs nachdenken.

Sprint Backlog:

• Ist die Liste der Einträge, die im laufenden Sprint bearbeitet werden sollen.
• Dessen Einträge werden jeweils aus dem Product Backlog entnommen.
• Ist die Beschreibung der technischen Maßnahmen (Tasks) zur Umsetzung und Implementierung (z. B. Design, Architektur, Programmierung, Testing und Refaktorierung).
• Unterliegt der Verantwortung des Scrum Teams, wobei der Product Owner das Sprint Goal formuliert und die Developer eine Vorhersage der Funktionalitäten treffen, die erarbeitet werden sollen.
• Wird für alle sichtbar im Büro angebracht. Die Wartung und Aktualisierung erfolgt rechtzeitig zum Daily Scrum (Daily Stand-up Meeting).

Commitment: Das Sprint Goal¶

Die Zielsetzung des Sprints¶

Das Sprint Goal ist eine weitere Verpflichtung der Developer zum Sprint Backlog. Es gibt den Developern einen Rahmen und Leitlinien für den kommenden Sprint. Das Sprint Goal wird während des Sprint Plannings erarbeitet und soll das Scrum Team dazu ermutigen an einem Strang zu ziehen. Nach dessen Erstellung wird es in den Sprint Backlog aufgenommen und dient den Developern als Zielvorgabe. Falls während der Bearbeitung des Sprints die Ergebnisse nicht dem Sprint Goal entsprechen, können die Developer mit dem Product Owner den Fokus des Sprints ggf. neu verhandeln. Das Sprint Goal darf jedoch während des Sprints nicht verändert werden.

Sprint Planning¶

Was wird wie im kommenden Sprint erledigt und warum ist dies werthaltig?¶

Das Sprint Planning ist ein Meeting zur Auswahl der Einträge des kommenden Sprints. Bei komplizierteren User Stories bzw. Epics bietet es sich gegebenenfalls an, ein zweiteiliges Sprint Planning Meeting durchzuführen. In diesem wird das Product Backlog geprüft und aktuell priorisiert und die für den nächsten Sprint in Frage kommenden Einträge, falls notwendig, zerteilt und ausführlich besprochen. In diesem Meeting konzentriert sich das Scrum Team auch auf das Sprint Goal, welches im Sprint erreicht werden soll.

Prinzipiell gibt es drei Themen, welche beim Sprint Planning bearbeitet werden:

• Wieso ist dieser Sprint wertvoll?
• Was kann in diesem Sprint erledigt werden?
• Wie sollen die ausgewählten Tasks erledigt werden?

Nach dieser Vorbereitung können sich dann die Developer im Anschlussmeeting auf die Überführung der User Stories in Tasks konzentrieren.

Bei der Anzahl der im Sprint Planning zur Umsetzung ausgewählten User Stories orientieren sich die Developer an zwei Größen:

Einerseits an der zur Verfügung stehenden Nettoarbeitszeit und andererseits an den geschätzten Task-Arbeitsstunden, welche zur Realisierung der User Stories veranschlagt wurden. Hier kann man sich jedoch auch an den beim Schätzworkshop erzielten Story Points orientieren.

Beide Stundenpools sollten in etwa gleich sein, um eine realistische Chance zu haben, die Tätigkeiten zeitgerecht zu erfüllen.

Bei zunehmender Projektdauer und gewonnener Erfahrung können auch anhand der Velocity die User Stories (Points) für den Sprint ausgewählt werden.

Die Auswahl, welche User Stories für den Sprint anstehen, wird final durch den Product Owner bestimmt. Am Ende des Sprint Plannings einigen sich die Developer darauf, das vereinbarte Sprintziel, nämlich die Umsetzung aller gewählten User Stories, möglichst zu erreichen.

• Teilnehmer: Scrum Team und evtl. Vertreter des Kunden oder Anwenders
• Dauer: maximal 2 Stunden pro Sprint-Woche
• Moderation: Scrum Master
• Verantwortlich für die Ziele: Product Owner
• Ergebnis: Zielbeschreibung und Sprint Backlog des kommenden Sprints

Daily Scrum¶

Die tägliche Abstimmung¶

Das Daily Scrum ist ein fixes Stand-up Meeting während des Sprints, bei dem sich die Developer täglich, idealerweise zur gleichen Zeit und am selben Ort, gegenseitig in kurzer Form über ihre Arbeit informieren [45][46]. Gegebenenfalls achtet der Scrum Master auf die Einhaltung des Zeitpunkts, der Zeitdauer und des konstruktiven Ablaufs.

Agenda:

Prinzipiell entscheiden die Developer selbst, wie dieses Meeting jeweils gestaltet werden soll. Es hat sich jedoch als gebräuchlich erwiesen, dass jeder Developer seinen Teamkollegen kurz drei Informationen gibt:

1. Was habe ich gestern gemacht?
2. Was plane ich heute zu machen?
3. Welche Impediments stören meinen Arbeitsablauf?

Der Scrum Master nimmt die Impediments der Developer entgegen und kümmert sich um Lösungen. Eventuell kommt ein „Impediment Backlog“ zur Dokumentation der Impediments und ihrer Aufarbeitung zum Einsatz.

• Dauer: 15 Minuten, stehend
• Ist in Verantwortung der Developer
• Teilnehmer: Developer und gegebenenfalls Scrum Master
• Idealerweise morgens mit unbedingter Anwesenheitspflicht und pünktlichem Erscheinen aller Developer
• Ergebnis: Information über den gegenwärtigen Stand der Umsetzungsarbeiten, verbesserte Kommunikation, schnelle Herbeiführung von Verbesserung, sowie Erhöhung gegenseitigen Wissens aller Developer

Scrum Chart: Sprint Burn-Down-Chart¶

Der Arbeitsfortschritt im Sprint¶

Um den noch verbleibenden Arbeitsaufwand zu visualisieren und um zu zeigen, wo im Sprint sich die Developer gerade befinden, eignet sich ein Sprint Burn-Down-Chart [47]. Die geschätzten Arbeitsstunden der noch offenen Tasks im aktuellen Sprint werden jeden Arbeitstag in das Diagramm eingetragen und mit einer linearen Ideallinie bei gleichmäßiger Abnahme der unfertigen Arbeitspakete verglichen. Sollte sich ergeben, dass das Team das geplante Arbeitspensum bis zum Ende des Sprints nicht erledigen konnte, wird dieses im nächsten Sprint verringert bzw. im umgekehrten Fall erhöht. Eine Alternative zum Sprint Burn-Down-Chart ist das Sprint Burn-Up-Chart bei welchem die Arbeitsstunden der erledigten Tasks aufgetragen werden und somit ein aufwärtsweisendes Diagramm entsteht. Die Sprint Burn-Down-Charts sollten, ebenso wie der Sprint Backlog, gut sichtbar angebracht sein.

Sprint Review¶

Überprüfung der Increments dieses Sprints¶

Das Sprint Review wird am Ende jedes Sprints durchgeführt und hat den Zweck, die Ergebnisse des Sprints zu überprüfen und zukünftige Anpassungen festzulegen.

In diesem Meeting stellt das Scrum Team den Stakeholdern die Ergebnisse vor, die in diesem Sprint erarbeitet wurden. Hier erfolgt die Abnahme der Increments und der Fortschritt in Richtung Product Goal wird diskutiert. Im Anschluss wird das Umfeld auf etwaige Veränderungen hin analysiert und, falls nötig, werden Anpassungen am Product Backlog vorgenommen. Die Ergebnisse des Meetings geben den Developern Feedback zu der bisher erledigten Arbeit und gewährleisten, dass Informationen zu nachfolgenden Tätigkeiten bereitgestellt werden [48].

Bis zum Sprint Review nicht abgeschlossene oder fehlerhaft abgeschlossene Tasks bzw. User Stories und Einträge, welche vom Product Owner nicht akzeptiert werden, wandern zurück ins Product Backlog. Dort werden sie repriorisiert und gegebenenfalls im nächsten Sprint zu Ende geführt. Einträge, die defekt oder als „Technical Debt“ gekennzeichnet sind, werden entweder sofort umgesetzt, oder als Backlog Item identifiziert und entsprechend der Dringlichkeit und des Kritikalitätsgrades bearbeitet.

ACHTUNG: Das Sprint Review ist ein kollaboratives Meeting und keine reine Präsentation.

• Teilnehmer: Scrum Team und Stakeholder, gegebenenfalls Kunden
• Dauer: Maximal 1 Stunde pro Sprint-Woche
• Ergebnis: Product Owner stellt die Erreichung des Sprint Goals fest, Live Demonstration der Increments und Feedback von Stakeholdern und Product Owner

Technical Debt¶

Folgen von schlechter technischer Umsetzung¶

Die „Technical Debt“ oder auch „Technische Schuld“ ist in der Softwareentwicklung eine Metapher für fehlende oder unvollständige Arbeiten bzw. für qualitativ unsaubere technische Umsetzungen. Einträge des Product Backlogs, welche eine Technical Debt aufweisen, zeichnen sich häufig dadurch aus, dass Verbesserungen des fehlerhaften Produktes mehr Zeit- und Planungsaufwand mit sich bringen.

Des Weiteren ist bei der Planung zu berücksichtigen, dass eine stark anwachsende Technical Debt jedes neuen Increments zu einer stark zunehmenden Komplexität des Produktes führt und dadurch, als Konsequenz, die Velocity reduziert wird.

Generell kann zwischen umsichtigen oder rücksichtslosen bzw. überlegten oder versehentlichen Technical Debts unterschieden werden. Diese werden beispielsweise durch Kommunikationsfehler, ungenügendes fachliches Wissen oder mangelhafte Qualitätssicherung der Prozesse hervorgerufen. Sie können aber auch durch Druck des Managements oder bei der parallelen Entwicklung von Features (Mehraufwand an Schnittstellen) auftreten [49].

Beispiele für eine Technical Debt können sein:

• Aufschieben der Dokumentation
• Fehlende Entwicklungsstandards
• Verzicht auf Datensicherung
• Verzögerung oder fehlerhafte Umsetzung automatisierter Tests
• Korrekturversäumnisse
• Missachtung von Programmierstandards (z. B. Anti-Pattern) oder von Warnungen (z. B. Compilerwarnings)
• Fehlerhafte Definition oder Umsetzung der Softwarearchitektur

Sprint Retrospective¶

Lessons-learned und kontinuierlicher Verbesserungsprozess (KVP)¶

Die Sprint Retrospective dient in erster Linie den Developern zur Produktivitäts- und Prozessverbesserung, es kann aber auch das gesamte Scrum Team Ziel dieser Maßnahme sein. Das Meeting wird im Anschluss an das Sprint Review und vor dem nächsten Planning Meeting durchgeführt.

Dabei wird der abgelaufene Sprint daraufhin überprüft, inwieweit der Ablauf störungsfrei war und was für künftige Sprints verbessert werden kann [50][51][52].

• Teilnehmer: Scrum Team
• Moderator: Scrum Master
• Dauer: Maximal 3 Stunden
• Ergebnis: Reflektion des vorangegangenen Sprints und Klärung der Frage, wie es gelaufen ist und wo Verbesserungsmöglichkeiten bestehen.

Dabei bietet sich folgende Agenda an (Plus-Delta-Verfahren):

• Anerkennung der Agenda durch Abstimmung (Handzeichen)
• Erstellung einer Timeline des vergangenen Sprints mit Post-It-Karten
• Anschließende Markierung spezifischer Punkte auf der Timeline mit Plus- und Deltakarten
• Diskussion der Ergebnisse dieser Markierungen
• Identifikation durchzuführender Änderungen und Verbesserungen respektive Abstellung von Impediments für den nächsten Sprint (Infrastruktur, Störungsversuche von außen, Verbesserungen für die Performance der Developer, etc.)
• Benennung von Maßnahmen (action items), verantwortlichen Personen und Zeitpunkten zur Erledigung

Velocity¶

Die Arbeitsgeschwindigkeit¶

Die Velocity summiert die Story Points der User Stories, die ein Team in einem Sprint pro Increment umgesetzt hat [53][54]. Unter der Voraussetzung, dass Teamzusammensetzung und Sprintlänge unverändert bleiben, erhält man nach jedem Sprint einen neuen validen Wert für die Velocity. Gemittelt ergeben diese Werte eine entscheidende Größe, mit deren Hilfe Release Burn-Down-Charts und ein Release Plan angefertigt werden kann. Die Velocity ist abhängig vom Projekt, den bearbeiteten Aufgaben und von den Developern – sie kann daher nur bedingt auf andere Projekte übertragen werden.

Release Planning¶

Product Backlog als Grundlage¶

Zu Beginn des agilen Projektes sind Planungen in vielen Fällen nur eingeschränkt möglich:

• Das Product Backlog besteht aus vielen Einträgen, die subjektiv sind und meist weitgehend angepasst werden müssen.
• Während der Projektlaufzeit kommen neue Einträge hinzu, ältere Einträge erweisen sich möglicherweise als hinfällig und werden gelöscht.
• Die Velocity der Developer, um die Einträge umzusetzen, ist zu Beginn des Projektes nicht bekannt und muss gegebenenfalls abgeschätzt werden.

Die Summe aller abgeschätzten Einträge im Product Backlog lässt ein präzises Release Planning erst zu, sobald die Velocity der Developer bekannt ist. Handelt es sich um ein neu zusammengesetztes Team oder um die erstmalige Durchführung eines Scrum Projektes im Unternehmen, kann die Velocity erst im Verlauf des Projektes festgestellt werden (siehe Velocity).

Scrum Chart: Release Burn-Down-Chart¶

Release Forecasting¶

Mit dem Release Burn-Down-Chart lässt sich der Zeitpunkt eines Release ermitteln, sobald die Velocity der Developer bekannt ist oder gut abgeschätzt werden kann und die Gesamtzahl der für das Release notwendigen Einträge im Product Backlog stabil ist.

Anhand einer Ideallinie kann unter Berücksichtigung der Gesamtsumme der Story Points, die für den gewählten Release abzuarbeiten sind, und der Velocity (Anzahl der Story Points, die voraussichtlich je Sprint umgesetzt werden) ein Schnittpunkt zwischen der Ideallinie und der x-Achse gefunden werden.

Damit kann abgeschätzt werden, nach welchem Sprint ein Release möglich ist. Sollte sich herausstellen, dass der Zeitpunkt aufgrund zu vieler Einträge im Product Backlog (oder wegen geringerer Velocity als geplant) nicht eingehalten werden kann, so muss der Umfang der Einträge gekürzt werden, um den Zeitpunkt halten zu können.

Release Burn-Down-Chart:

• Arbeitsgrundlage sind die zu Beginn des Projektes abgeschätzten Aufwendungen für die Umsetzung der Einträge (User Stories)
• Y-Achse: Summe der Aufwände in Story Points (summierter Punktewert aller für das Release relevanten Einträge im Product Backlog)
• X-Achse: Anzahl der Sprints

Besprechungen & Meetings bei Scrum¶

Besprechungen finden im Scrum in festgesetzter Abfolge statt. Sie sind außerdem zeitlich festgelegt (time boxed), was maßgeblich zur Effizienz des Prozesses beiträgt [55][56]. Dabei darf dieser festgelegte Zeitrahmen nicht überschritten werden. Ergeben sich während der Meetings Punkte, die einer genaueren Diskussion bedürfen, so werden diese in einer speziell dafür angesetzten Besprechung unter der Beteiligung derjenigen Personen geklärt, die davon betroffen sind.

Es gelten strenge Regeln. Die Pünktlichkeit der Beteiligten ist unverzichtbar, ebenso wie die Disziplin während der Meetings (z. B. Ab- oder Stummschalten der Handys und Konzentration auf die zu bearbeitenden Themen).

Time boxed: Effizienz in Scrum Meetings¶

Meetings sind reguläre Bestandteile von Scrum, daher jeweils vor oder nach einer Entwicklung durchzuführen. Alle Angaben beziehen sich auf einen 4-wöchigen Sprint (Sprint-Monat), bei kürzeren Sprints ist die Dauer des jeweiligen Meetings entsprechend kürzer.

ACHTUNG: Das Backlog Refinement Meeting ist kein originäres Scrum Meeting und demnach auch nicht zeitlich festgelegt [57][58].