Was ist Scrum

 

Wie funktioniert Scrum Projektmanagement

 

In der heutigen agilen Softwareentwicklungsumgebung wenden zu 85% der Unternehmen weltweit Scrum an. Scrum ist ein agiles Vorgehensmodell im Projektmanagement, mit welchem die Teams interdisziplinär kooperieren. Selbstorganisation wird in der Scrum Methodik gross geschrieben, weil die Interdisziplinarität und Agilität ihnen die Möglichkeit gibt, Herausforderungen flexibel und selbst oder im Team anzugehen. Agilität ist Beweglichkeit bzw. Flexibilität von Organisationen, Strukturen und Prozessen sowie Personen. Die Scrum Methodik zeichnet sich dadurch aus, dass das Ziel vom Management oder Auftragsgeber vorgegeben wird, jedoch die Teams die Freiheit haben, den Weg zum Ziel im vorgegebenen Zeitraum selbst zu gestalten. Die Teams die Scrum anwenden, passen sich jeweils den zeitlichen und technologischen Wandel an. (Komus A, 2016/17)

 

 

 

 

Auf dieser Abbildung zwei sieht man den Grobdurchlauf, wie die Prozesse im Scrum aufgebaut sind und zeigt den Ablauf der Scrum Methode. Dieser Durchlauf zieht sich durch den ganzen Transferbericht durch.

 

Scrum Artefakten Im Vergleich zu anderen Projektmanagementmethoden, gibt es in der Scrum Methodik drei bedeutende Begriffe die nach dem Leistungsumfang des Produktes oder der Dienstleistung orientieren. In der Fachsprache werden sie Artefakten genannt. (Scrum Alliance, 2017)

 

Artefakt 1: Produktinkrement (PI) Ein Produktinkrement, auch PI genannt ist ein fertiges Stück des Gesamtprodukts. Das Endergebnis eines Sprints ist ein Teil des Produktinkrementes. Der Funktionsumfang des Endproduktes wir mit jedem PI erweitert und optimiert.

Artefakt 2: Produkt Backlog In einem Produkt Backlog sind neue potentielle Funktionalitäten in der Pipeline, die im nächsten Sprint eingeplant werden können. Im Fachjargon werden diese Features genannt und AnwenManagement Product Owner Product Backlog Sprint Backlog Kunden und User Sprint Planning Product Increment Scrum Master und Scrum Team Daily Scrum Sprint Sprint Review Refinement

 

Artefakt 3: Sprint Backlog Gestützt auf das priorisierte Produkt Backlog können Features im Sprint unter Berücksichtigung der Ressourcenkapazität der Entwicklung eingeplant werden.

 

Teams & Rollen

Das Scrum Entwicklungsteam besteht aus 3 Teammitglieder. Jedoch sind im Projekt selbst noch weitere Stakeholder involviert, die anschliessend näher beschrieben werden. Product Owner (PO) Der Product Owner ist die Person zwischen dem Auftraggeber und dem Entwicklungsteam. Die Anforderungen werden vom Product Owner entgegengenommen und mit dem Auftraggeber gemeinsam priorisiert. Die Priorisierung ist einer der wichtigen Aufgabe, weil es zu keiner widersprüchlichen Planung kommen darf

 

Der Product Owner ist für folgende Punkte zuständig:

• für die Wertmaximierung des Produktes und die Arbeit der Entwickler

• Priorisierung des Backlogs

• Überblick der Releases und wenn möglich das Implementieren auf der produktiv ähnlichen Instanz nach jedem Sprint

• Im Projekt sind viele Stakeholders involviert und der Product Owner ist häufig mit ihnen in Kontakt und versucht, alle Rückmeldungen, die einen Mehrwert für das Produkt bieten, zu berücksichtigen

 

Scrum Master (SM)

Scrum Master ist eine Person, die zuständig dafür ist, dass die Scrum Regeln eingehalten werden. Die Zusammenarbeit im Team und die Organisation der Meetings werden durch den Scrum Master koordiniert und überwacht. Ausserdem hat der Scrum Master einen Überblick auf die Kapazitätsplanung der Entwickler, damit kein Engpass entsteht. (Atlassian Agile Coach, 2020)

 

Entwickler (Dev)

Die Entwickler liefern am Ende das Produkt, dass den Anforderungen des Product Owners entspricht. Sie schreiben die Codes und testen am Ende ihren Code. (Scaled Agile Framework and SAFe, 2020) Bei den Entwicklern unterscheidet man in der Regel je nach Technologien. Nicht jeder Entwickler hat das gleiche Potential, die gleichen Handlungen durchzuführen, weil es je nach benötigter Wissenschaft unterschiedliche Code-Sprachen vorhanden sind. Es gibt einen grossen Unterschied zwischen Frontend- und Backend Entwickler. Frontendentwickler sind verantwortlich für das vordere Ende der Entwicklung. Das heisst, das was der User am Ende des PI zu sehen bekommt. Der Backendentwickler entwickelt die Struktur der Logik im hinteren Teil des PI und klärt die Logik und deren Schnittstellen zu den weiteren Systemen im Unternehmen auf. (Atlassian Agile Coach, 2020).

 

Designer (UX)

In der Scrum Methodik wird der Designer nicht im Detail oder zum Teil nicht erläutert. Aber die User Experience Designer tragen eine wichtige Rolle. Sie liefern Designs und Prototypen, die den Entwicklern das Verständnis des User Flows (Bsp. User Journeys) um die Anforderungen einfacher zu verstehen. Damit die Designs entwickelt werden können, kooperiert der Product Owner vor dem Sprint Planning eng mit dem Designer zusammen. Die Designs werden anhand der Anforderungen des Auftraggebers erstellt.

 

Solution Architekt

Der Solution Architekt ist dafür verantwortlich, die allgemeine technische und architektonische Vision zu definieren und um sicherzustellen, dass das zu entwickelnde System oder die zu entwickelnde Lösung für den beabsichtigten Zweck geeignet ist. Der Solution Architekt spielt eine wichtige Rolle beim Entwerfen der Lösung an ein gemeinsames Vorhaben und sind an der Entwicklung von Lösungen, der Überprüfung der Hypothesen und der Schaffung kontinuierlicher Bereitstellungskanäle beteiligt.

 

Auftraggeber

Bei allen Projekten gibt es einen Auftraggeber. Der Auftraggeber beauftragt den Product Owner, um ein Produkt oder eine Dienstleistung zu erstellen, bzw. bereitzustellen. Als nächstes erarbeitet der Product Owner die detaillierten Anforderungen gemeinsam mit dem Auftraggeber. Die Anforderungen werden durch den Product Owner entgegengenommen und dokumentiert. Damit die Wichtig- und Dringlichkeit der Anforderungen eingeordnet werden können, sollten die Anforderungen nach Muss- oder Kann-Kriterien gruppiert werden.

 

Anwender (User)

Die Anwender werden schlussendlich das gelieferte Inkrement anwenden. Sie können grundsätzlich gute Anforderungen bringen, weil sie die Prozesse durch den Auftraggeber bereits kennen. Deshalb ist es von grossem Vorteil, wenn die Anwender frühzeitig in das Projekt miteinbezogen werden, damit das Projektteam herausgefordert wird und das Produkt oder die Dienstleistung eine gewisse Qualitätsnorm annimmt.

 

Manager

Der Manager ist verantwortlich für den Gesamtüberblick über das Projekt. Er unterstützt das Scrum Team, um die Herausforderungen zu meistern und das Team zu entlasten. Zudem können Investitionsfragen können durch den Manager geklärt werden.

 

Produktmanager

Der Produktmanager ist in der agilen Scrum Methode verantwortlich für die Zielerreichung des Unternehmens oder dem Auftraggeber. Sie müssen mit dem Produkt vertraut sein und bei Teamerweiterungen in jedem Fall folgende Aspekte berücksichtigen. Dabei müssen alle Eindrücke des Nutzers berücksichtigt werden, zusätzlich jederzeit den Überblick haben über den Stand der Entwicklung und das Ziel im Vordergrund haben. Der Produktmanager ist eng mit dem Product Owner in Abstimmung, weil die Ziele vor dem PI vom Produktmanager validiert werden müssen. Die Vorgehensweise bzw. Roadmap der Projekte wird zudem auch in Abstimmung mit dem Product Owners festgelegt.

 

Release Train Engineer (RTE)

Der Einsatz eines Release Train Engineers ist abhängig der Projektgrösse. Besteht das Projekt aus mehreren Teams, ist es durchaus sinnvoll, einen Release Train Engineer einzusetzen. (Safe Scaled Agile, 2020) Verantwortlichkeit Release Train

• Erstellung und Kommunikation der Jahreskalender der Iterationen und Produktinkrements (PI) • Unterstützung bei der PI-Planungsveranstaltung

• Behilflich sein bei der PI-Planungsbereitschaft durch die Förderung eines kontinuierlichen Explorationsprozesses, der die Synthese einer Vision, einer Vorgehensweise bzw. Roadmap und von Rückständen vorantreibt, sowie durch Pre- und PostPI-Planungssitzungen

• Zusammenfassung der PI-Ziele des Teams zu PI-Programmzielen (die RTE) und Veröffentlichung dieser Ziele im Interesse der Sichtbarkeit und Transparenz

• Etwas eskalieren zu lassen und die Herausforderungen zu verfolgen.

• Unterstützung beim Verfolgen von projektübergreifenden Risiken und Abhängigkeiten

• Verwaltung und Optimierung des Wertflusses

 

Definition von Feature

Je nach Bedürfnissen des Auftraggebers müssen die Anforderungen im zusätzlichen Feature festgehalten werden. Ein Feature ist eine Aufgabeneinheit, die in verschiedene User Stories unterteilt wird. Bei den User Stories stehen die Endbenutzer im Mittelpunkt. Jedes Feature stellt die Gesamtaufgabe dar. (Atlassian Agile Coach) So könnte eine Gesamtaufgabe aussehen: Kunden können Mobiltelefone in einem neuen Online-Shop bestellen. Die User Story kann ein Feature sein und der Titel könnte wie folgt benannt werden: Mobiltelefonbestellung. Diese Funktion Mobiltelefonbestellung enthält jedoch auch mehr Anforderungen. Dieser Titel des Features alleine würde für die Entwickler nicht ausreichen, weil einige offene Punkte noch nicht deklariert sind. Diese Punkte können anhand der Akzeptanzkriterien gelöst werden. Akzeptanzkriterien sind ein Teil des Features. Akzeptanzkriterien Akzeptanzkriterien leiten sich aus einer User Story ab. Akzeptanzkriterien geben vor, wann eine User Story als akzeptiert bzw. angenommen gilt. Beim bereits erwähnten Beispiel können folgende Akzeptanzkriterien im Feature aufgenommen werden:

 

Akzeptanzkriterium 1 Der Kunde gelangt über die Navigationsleiste auf die Produktauflistungsseite

Akzeptanzkriterium 2 Der Kunde kann über die Produktauflistungsseite ein Mobiletelefon aussuchen

Akzeptanzkriterium 3 Klickt der Kunde auf ein Gerät, gelangt er auf die Produktdetailseite Akzeptanzkriterium 4 In der Produktdetailseite, kann der Kunde das Mobiletelefon nach Farbe, Speichergrösse konfigurieren

Akzeptanzkriterium 5 Ist das Mobiletelefon konfiguriert, kann es der Kunde in den Warenkorb legen.

 

Diese Akzeptanzkriterien dienen als Beispiel und können je nach Bedarf erweitert werden. Es gibt zahlreiche Methoden, wie die Akzeptanzkriterien definiert werden können. Eine effiziente Methode ist die Gherkin Methode und wäre für das Unternehmen InnoSoft GmbH eine Unterstützung. Somit kann die Firma das Bedürfnis des Auftraggebers verständlicher für die Entwickler darstellen. Somit erhält auch der Auftraggeber das gewünschte Produkt oder die gewünschte Dienstleistung. (Agile For Growth, 2020) Wenn das erste Akzeptanzkriterium in der oberen Tabelle drei auf die Gherkin angewendet wird, sieht die Gherkin Methode folgendermassen aus:

 

Szenario Der Kunde gelangt über die Navigationsleiste auf die Produktauflistungsseite

Gegeben Kunde befindet sich auf dem Online Shop Landingpage

Wenn Kunde klickt in der Navigationsleiste auf Mobiletelefone

Dann Kunde landet auf die Produktauflistungsseite der Mobiltelefone

 

Sind die User Story und Akzeptanzkriterien erstellt, können im Feature zusätzlich noch die beteiligten Stakeholder festgehalten werden. In der Tabelle fünf sind mögliche Stakeholder des Features abgebildet. Somit sehen die Entwickler auch welche Stakeholder in diesem Projekt involviert sind. (Drei Methoden, ein Ziel:, 2020)

 

Zusätzlich können Prototypen im Feature abgelegt werden, sowie offene Punkte können vermerkt werden. Der Aufwand für das Feature wird durch die Arbeitsleistung einer Arbeitskraft pro Tag und sowie die Verantwortlichkeiten können auch bei Bedarf vermerkt werden.

 

2.4 Definition of Done (DoD)

Damit alle Teammitglieder über das gleiche Wissen verfügen, wann eine Story fertig ist, sollte beim Projektbeginn über die „Definition von Done" besprochen werden. Entscheidungspunkte

 

Definition of Done

• Deckt die Entwicklung der Entwickler die geforderten Akzeptanzkriterien

• Wurde die Funktionalität durch den Entwickler getestet

• Wurde der Code von einem weiteren Entwickler überprüft

• Erfüllt die Entwicklung der Unternehmung die vorgegebenen Security Richtlinien

• Wurde die Entwicklung auf der Entwicklungsumgebung bereitgestellt

 

Weitere Punkte können je nach Erfahrung im PI dazustossen und die Liste kann dementsprechend erweitert werden.

 

2.5 Visualisierung der Features

In der Praxis wird ein Feature Board verwendet. Das Feature Board dient dazu, den Überblick der verschiedenen Features zu behalten und Transparenz in den Prozess zu bringen Das Board ist wie folgt aufgebaut und basiert auf die Grundlage des Kanban-Boards:

Die Features im Backlog werden vom Product Owner erstellt. Darin werden die genauen Anforderungen für die Zielerreichung des Produktinkrements beschrieben. Die Anforderungen sind möglichst einfach, präzis und verständlich zu formulieren, damit sie am Ende von alle Teammitgliedern verstanden werden. Dort werden dann die genauen Anforderungen am Produktinkrement beschrieben. Falls einige erstellte Designs vorhanden sind, können sie bereits als Prototypen des Designers eingefügt werden. Wenn der Product Owner die Einladung an die Entwickler sendet, um das Feature zu analysieren, wird das bearbeitende Feature in die Spalte Analysis verschoben, wie in Tabelle 7 dargestellt. Es ist wichtig zu verstehen, dass das Board dynamisch ist und die Features in unterschiedlichen Status befinden können.

 

Priorisierung der Features

Wie bereits erwähnt, müssen die Features priorisiert werden. Es gibt in der Theorie viele Methoden, wie die Features priorisiert werden können. Anbei wird ein Beispiel erklärt: Priorisierung nach Business Value. Der Auftraggeber gibt dem Product Owner vor, welche Feature die höchste Priorität haben. Die Bewertungsskala ist zwischen eins und zehn, wobei zehn die höchste Priorität aufweist. Befinden sich mehr als zehn Features im Backlog, kann die Skala entsprechend ergänzt werden. Mit dieser Methode können die Features priorisiert werden.

 

2.6 Visualisierung des Sprints

Am Tag der Einladung wird nun das Feature im Team besprochen und verfeinert. Der Produkt Owner eröffnet das Meeting mit der Vorstellung des Features und stellt die Einzelheiten vor. Im Idealfall sollte nicht nur der Inhalt des Features präsentiert werden, sondern auch der Prototyp, somit haben alle Teammitglieder die gleiche Wahrnehmung. Wurde das Feature präsentiert, kann die Diskussionsrunde starten. Die Entwickler können nun erwähnen, welche Entwicklungsfunktionalitäten benötigt werden. So könnte eine Visualisierung aussehen:

Für jede Funktion und Technologie sollte im Feature eine Story erstellt werden. Diese Stories werden anschliessend im Team nach Personentagen geschätzt. Personentagen sind in der Firma InnoSoft GmbH bereits vordefiniert. Sie entspricht Anzahl Mitarbeitenden in Stunden umgerechnet. Somit weiss der PO wie viele Stunden an Ressourcen zur Verfügung stehen. Die einfachste Methode für die Schätzung der Stories ist die Fibonacci Methode. (Atlassian Agile Coach, 2020) In der Fibonacci Methode können die Stories in folgenden Personentage geschätzt werden: 0.5; 1; 2; 3; 5; 8; 13; 20; 40; 100. Diese Zahl bedeutet so viele Personentage benötig eine Story. Je höher die Zahl, desto aufwändiger die Story.

 

2.7 Ereignisse & Zeremonien

Feature Refinement (Feature Verfeinerung) Ein häufig angewendetes Ereignis ist, ist das Feature Refinement. Features Refinement dienen dazu, das geplante Feature für das nächste PI im Team zu analysieren. Der Product Owner lädt die beteiligten Entwickler zu diesem Event ein. Am Anfang dieses Meetings stellt der Product Owner das Feature, den Prozess und den Ablauf des Nutzers den Entwicklern vor. Danach wird eine Diskussion zwischen den Entwicklern und dem Product Owner eröffnet. Das Ziel der Diskussion ist, dass alle teilnehmenden Entwickler den gleichen Wissenstand haben. Ausserdem sollen die Entwickler sich auf einen gemeinsamen Lösungsweg einigen und interne wie auch externe Abhängigkeiten erkennen und diese auch melden. Alle Informationen werden entsprechend dokumentiert. Dieses Ereignis wird für alle Features, die für das nächste PI geplant sind, durchgeführt. Das Ziel einer Zeremonie ist es, dass Stories erstellt werden.

 

PI (Produktinkrement) Planning

Das PI Planning ist in der Regel das grösste und längste Ereignis in der Scrum Methodik und dauert je nach grösse der Teams ca. zwei Tage. An diesem Event wird über die Produktvision, PI-Ziele und die Agenda kommuniziert und diskutiert. Das PI Planning wird grundsächlich vom Release Train Engineer moderiert und findet im letzten Sprint statt. (Safe Scaled Agile, 2020) Am Ende des PI Plannings sollten folgende Themen klar sein:

 

Feature Board

Alle Features, welche bereits verfeinert wurden, sind im Feature Board mit ihrer Abhängigkeit zu anderen Teams ersichtlich.

Stories Alle Stories sind im Sprint Board ersichtlich, sind nach Personentage geschätzt worden und vom Product Owner in der richtigen Reihenfolge priorisiert.

Risiken Mögliche Risiken wurden dokumentiert und den Teammitgliedern zur Erledigung zugewiesen.

Abhängigkeiten zu externen und internen Teams wurden identifiziert und diskutiert.

Ziel ist es, dass die Abhängigkeiten im nächsten PI gelöst werden. Ziele Für das gesamte PI wurde durch den Product Owner Ziele vorgegeben, welche nach SMART definiert sind. Die Ziele sollten im Team besprochen werden, damit sich die Mitarbeiter damit identifizieren können. Das heisst, die Ziele sind spezifisch, messbar, akzeptiert, realisierbar und terminiert. Bsp.: Bis am Ende des PI ist der Endnutzer in der Lage, ein Handy im neuen Onlineshop zu bestellen.

 

Für die Unternehmen ist folgendes zu empfehlen:

Kapazitätsplanung Um das gesamte PI optimal planen zu können, um nicht in Verzug zu geraten, ist es empfehlenswert für die Firma InnoSoft GmbH, wenn die Absenzen der Teammitglieder bereits im vorneherein transparent sind. Somit werden unangenehmen Überraschungen vermieden und die Planung hat ihre Verbindlichkeit.

Confidence Vote (Zufriedenheitsabstimmung) Es ist empfohlen am Ende des PI eine Zufriedenheitsumfrage zu starten, um die Zuversichtlichkeit der Teammitglieder in Erfahrung zu bringen. Die Skala ist in der Regel von eins bis fünf. Bei negativen Meldungen (eins bis drei) können die Sorgen oder Herausforderungen der Teammitglieder noch vor Ort diskutiert werden.

 

Sprint Planning

Bevor ein Sprint startet, treffen sich die Teammitglieder. Das wird im Fachjargon Sprint Planning genannt. Die im PI Planning bereits erstellten Stories werden im Team diskutiert und den Entwicklern zugewiesen. Die Prioritäten der Stories werden vom Product Owner vorgegeben. Mit Blick auf die Kapazitätsplanung, wird verhindert, dass das Team nicht überlastet wird.

Sprint

Der Hauptvorteil der Scrum Methodik ist grundsächlich ihre Flexibilität, sprich Agilität. Die Agilität wird in den Sprints widerspiegelt. Mit den Iterationen, sprich wiederholenden Zyklen, ist ein Sprint eine Iteration in der Scrum Methodik. Die Iterationsdauer können je nach Team individuell zwischen zwei bis vier Wochen sein. Falls sich das Team für eine Iterationsdauer von zwei Wochen einigt, muss diese Iterationsdauer bis zum Ende des PI durchgezogen werden. Während des PI ist es nicht erlaubt, eine Iterationsdauer zu ändern. Nachdem die Iteration beendet ist startet wiederum ein neuer Sprint.

Daily Scrum

Im Daily Scrum treffen sich alle Teammitglieder einmal am Tag und die Sitzung dauert in der Regel ungefähr 15 Minuten. Dabei stellt sich jedes Teammitglied die Frage, ob das Ziel vom letzten Daily Scrum erreicht wurde, was muss noch für das nächste Daily Scrum gemacht werden und zum Schluss, ob es noch Herausforderungen gibt, die den Arbeitsalltag verhindern. Allgemeine Diskussionen haben im Daily Scrum keinen Platz und sollten danach besprochen werden.

 

Sprint Review (Sprint Rückblick)

Das Sprint Review dient dazu, dass jedes Teammitglied seine erreichten Fortschritte präsentiert. Das dient dem Team, wie auch dem Product Owner dazu, einen Überblick des Fortschrittes zu sehen damit bei mangelhafter Entwicklung rechtzeitig eingegriffen werden kann. Somit würden Verspätungen frühzeitig erkannt und können mit dem Auftraggeber besprochen werden. Das Sprint Review wird meistens am vorletzten Tag, bevor der neue Sprint startet, durchgeführt.

 

Sprint Retrospective (Sprint Rückblick)

Am Ende des Sprints wird eine Retrospective durchgeführt. Auch ein Retrospective ist ein Rückblick. Im Retrospective wird im Team besprochen, was im Sprint allgemein gut und weniger gut lief und welche Punkte dringend belassen sollen.

  • Lief gut

  • Lief weniger gut

  • Nicht weiterführen

System Demo

Am Tag der System Demo werden allen beteiligten Stakeholder der Stand der Entwicklung vorgeführt. Es wird präsentiert, was das Team im jeweiligen Sprint erreicht hat. Im besten Fall wird nach jedem Sprint ein System Demo durch den Release Train Engineer organisiert.

 

Unterstützende Tools

Um die Scrum-Methode einführen zu können, werden einige wichtige Anwendungen benötigt, die das Team von Beginn an unterstützen. Hier werden einige Tools kurz erläutert die alle unterstützend sein können

  • JIRA

  • WIKI

  • Excel

  • Mural Board

  • InVision

  • Pokerli

©2020 FRANK & PARTNER