The Business Development Way
| Nr. | Lieferobjekt | Kurzbeschreibung |
|---|---|---|
| 1 | Produktvision | Eine Produktvision ist ein klares, deutliches, attraktives und emotionalisierendes Bild des angestrebten Produkts – zum Beispiel eine voll digitalisierte Mitgliederverwaltung. Die Produktvision motiviert und inspiriert das Entwicklungsteam. Sie begeistert aber auch die übrigen Beteiligten (z.B. den Auftraggeber, Kundenvertreter, das Marketing und den Vertrieb), für das Produkt einzustehen und schafft die Grundlage für eine wirkungsvolle Produktstrategie. |
| 2 | Canvas | Ein Project Canvas ist ein vorstrukturiertes Plakat, mit dessen Hilfe Produkteteams die wichtigsten Inhalte einer Projektvision im Sinne eines Vor-habenssteckbriefs definieren und dokumentieren. |
| 3 | Story Map | Story Maps ermöglichen Teams, das Product Backlog in Form eines Big Pictures zu visualisieren. Darin werden die zentralen Features des Produkts zunächst als dessen Backbone herausgearbeitet. Dann wird diese Funktionalität in die für das Backbone wichtigsten User Stories aufgeteilt, die als Walking Skeleton bezeichnet werden. Die ersten Sprints sollten sich darauf konzentrieren, vom Walking Skeleton so viel wie möglich auszuliefern [Ste 2019], so dass dem Kunden möglichst schnell ein Minimal Marketable Product (MMP = ist die einfachste marktfähige Konfiguration eines Produkts) ausgeliefert werden kann. |
| 4 | Release Backlog | Das Release Backlog ist das gleiche Instrument wie das Product Backlog. Enthält aber schon Epics für weitere Sprints definiert/priorisiert/selektiert für ein geplantes Releasedatum. |
| 4.a | Epic | Ein Epic ist eine sehr grosse oder nicht detailliert beschriebene User Story respektive Backlog Item. Ein Epic ist zu komplex oder zu umfangreich, um es zu schätzen oder in einem Sprint umzusetzen. |
| 5 | Releaseplan | Der Releaseplan zeigt auf, in welchen Sprints welche User Stories ungefähr umgesetzt werden sollen. Der Product Owner benötigt eine Vorstellung davon, wie viele Sprints es dauern wird, um relevante User Stories umzusetzen. Wichtig dabei ist, dass die geschätzte Grösse, die Priorität und der Mehrwert pro User Story aufgeführt werden. Ein Release kann sich aus drei bis fünf Sprints zusammensetzen. Die Praxis hat gezeigt, dass der letzte Sprint idealerweise ein Stabilisierungssprint ist. |
| 6 | Product Backlog | Priorisierte Liste sämtlicher Produktanforderungen (z.B. in Form von User Stories) mit zeitlichen Schätzwerten (Estimates) für deren Umsetzung. Die Priorisierung erfolgt basierend auf dem Mehrwert, den die User Stories für das Unternehmen bringen. Das Product Backlog ist ein dynamisches Dokument. |
| 6.a | User Story | Eine User Story ist die einfache, in der Alltagssprache formulierte Beschreibung einer umzusetzenden Anforderung aus der Sicht eines konkreten Benutzers (User), welcher das System benutzen wird. Die Beschreibung einer User Story dient als Grundlage für Kommunikation und als Ausgangspunkt für die Umsetzung von Produktfunktionalitäten. Eine User Story besteht aus einem Hauptsatz, allenfalls ergänzt um eine Motivation, eine Frage-Antwort-Sektion, in welcher die wesentliche Kommunikation zwischen Ingenieuren und Kunden festgehalten wird sowie einer Liste von Akzeptanzkriterien. Sie wird ergänzt durch das Festhalten der wichtigsten Fragen/Antworten zwischen dem Entwicklungsteam und den Kundenvertretern sowie den Akzeptanzkriterien. |
| 7 | Sprint Backlog | Sprint Backlog: für den nächsten Sprint aus dem Product Backlog abgeleitete User Stories (Anforderungen) und die daraus definierten konkreten Tätigkeiten (Sie werden bei Scrum als Tasks bezeichnet.). Es definiert die Menge der Arbeit des nächsten Sprints, die das Team akzeptiert hat. |
| 7.a | Sprint Backlog Task | Im Sprint Backlog Task werden für den aktuellen Sprint aus dem Sprint Backlog abgeleitete, konkrete Tätigkeiten (Sie werden bei Scrum als Tasks bezeichnet.) dokumentiert. Die Liste präzisiert sich während des Sprints und wird täglich von allen Team Members gepflegt. |
| 8 | Task- / Kanban-Board | Das Kanban Board / Taskboard ist ein einfaches und übersichtliches Planungs-, Status- und Open-Task-Tool. Ideal ist, wenn das Entwicklungsteam das Board stets aktuell hält und im Daily Scrum Meeting bespricht. Dabei werden die Tasks in priorisierter Reihenfolge aufgeführt. Auf einem einzelnen Haftnotiz-Zettel wird ein einzelner Task aufgeführt (Task kann innerhalb eines Tagesaufwandes bearbeitet werden.). Die Teammitarbeiter ergreifen sich selbständig einen Zettel respektive einen Task und notieren darauf ihren Namen. |
| 9 | Sprint Burndown Chart | Sprint Burndown Chart: Darstellung, die tagesaktuell den Arbeitsfortschritt des Sprints aufzeigt. Zeigt auch den Aufwand für den ursprünglich geschätzten Restwert auf. Neben den entsprechenden Kurven macht es Sinn, auch die Erledigungsmenge pro Tag grafisch festzuhalten. |
| 10 | Impediment Backlog | Impediment Backlog: eine priorisierte Auflistung aller Hindernisse, denen das Sprint Team begegnet. Es wird vor allem in der Retrospektive und teilweise im Daily Stand-up Meeting gepflegt. Mit gezielten Aktionen versucht das Team, diese Hindernisse während des Sprints aus dem Weg zu räumen bzw. räumen zu lassen. |
| 11 | Sprint Inkremente | Ein Inkrement ist in sich eigenständig lauffähig und umfasst immer auch die zuvor ausgelieferten Inkremente um sicherzustellen, dass die neuen Funktionen nicht bereits erstellte und womöglich auch ausgelieferte Software beeinträchtigen. Inkremente sind (Weiter-)Entwicklungen eines Produkts und eines Sprintziels. Sie umfassen die zugehörigen, getesteten, ausreichend dokumentierten, einsatzfähigen Anforderungen und akzeptierten (Teil)-Ergebnisse eines Projektes (Projektprodukt), z.B. in Form von umgesetzten User Stories. |
| 12 | Release Burndown Chart | Der Release Burndown Chart ist eine Darstellung, die tagesaktuell den Arbeitsfortschritt eines gesamten Releases aufzeigt. Zeigt auch den Aufwand für den ursprünglich geschätzten Restwert auf. Der Chart kann mit verschiedenen Kurven wie einzelnen Sprints PLAN/IST etc. ergänzt werden. |
| 13 | Valuebericht | Zeitnah nach einem ausgelieferten Release wird die Wirkung geprüft, so gilt es, die gleichen Faktoren wie bei der Value-Bewertung des Releasestarts noch einmal, aber nun mit dem effektiven Erreichten, zu bewerten. Die zeitlich unterschiedlich berechneten Werte werden gegenübergestellt und deren Abweichung wird analysiert. Dabei muss versucht werden, die Ursachen der Abweichungen genau herauszufinden, damit entsprechende Massnahmen eingeleitet und im Rahmen des nächsten Releases berücksichtigt werden können. All dies wird in einem kurzen Valuebericht zusammengefasst. |
| Nr. | Aufgabe | Kurzbeschreibung |
|---|---|---|
| 1 | Vorbereitungs-Sprint (Sprint Zero) | Der Vorbereitungs-Sprint oder Sprint Zero wird hauptsächlich dann eingesetzt, wenn bestimmte Dinge vor der eigentlichen agilen Entwicklung erledigt werden müssen. Vielleicht muss erst noch ein Team zusammengestellt, der Architekt- oder Designrahmen erstellt oder Hardware besorgt, installiert und ausprobiert werden. Da am Ende für den Kunden nicht etwas potenziell Auslieferbares erstellt wird, macht es Sinn, die dafür notwendigen Product Backlog-Items speziell zu markieren. Das Ziel des Sprint Zeros ist, sich im Team transparent zu begegnen und über die unterschiedlichen Fragestellungen und Bedürfnisse gemeinsam klar zu werden, so dass nach dem Sprint 0 die Basis für eine effiziente Entwicklungs-Konfiguration vorliegt. |
| 2 | Release umsetzen |
Gemäss Release- oder PI-Planning werden die geplanten Sprints so umgesetzt, dass am Ende ein Release-Inkrement (Zusammensetzung aller Sprint-Inkremente) existiert, welches in Betrieb genommen werden kann. Ein Release umfasst alle technischen und organisatorischen Ergebnisse, die nötig sind, damit das System oder Teile davon in Betrieb gesetzt werden können. Ziel: Am Ende eines Release-Zyklus‘ wird das Produkt beziehungsweise das System produktiv gesetzt. |
| 3 | Stabilisierungs-Sprint |
Der Stabilisierungssprint – auch QM-Sprint oder Release-Sprint genannt – soll keine schlechte Code-Qualität während der Sprints erlauben, sondern im Sinne der Qualitätssicherung ist es besonders bei komplexen Konfigurationen und ICT-Infrastrukturen sinnvoll und angebracht, alles nochmals durchzuchecken und mit etwelchen Ungereimtheiten aufzuräumen. Das bedeutet, dass nach mehreren Sprints mit freigegebenen Inkrementen das im Releaseplan definierte Potentially Shippable Product Increment (PSPI) nochmals als Ganzes kritisch geprüft und sauber abgegrenzt werden muss. Das Ziel des Stabilisierungssprints ist, alles Richtige und Wichtige eines Releases «sauber» aufzuräumen – von den technischen Schulden, den Testdaten über Testfälle, Dokumentationen bis hin zu den Entwicklungsinstrumenten. Ebenso bieten Stabilisierungs-Sprints die Möglichkeit, Integrationstests zu nur zeitweise verfügbaren Umsystemen einzuplanen und durchzuführen. |
| 4 | Release ausliefern |
Bei dieser Aktivität wird die Auslieferung und Inbetriebnahme des erstellten Produkts bzw. Produktinkrements mit allen vorbereitenden und unterstützenden Tätigkeiten durchgeführt, damit das Produkt effizient genutzt werden kann. Die dabei eingesetzten Verfahren / Techniken / Werkzeuge sind je nach Entwicklungsart sehr unterschiedlich. Parallel wird die Übergabe an die für den Betrieb verantwortliche Organisation vorbereitet und durchgeführt. Ziel: geordnetes Ausliefern des Systems respektive geordnete Übergabe des Produkts an den Betrieb |
| Nr. | Aufgabe | Kurzbeschreibung |
|---|---|---|
| 1 | Produktvision erstellen | Bevor eine Produktvision in einem Initiativensteckbrief beschrieben werden kann, muss – ausgehend vom Impuls «Vision Statement» – mithilfe einer Strategie- und Business-Design-Technik ein entsprechendes Geschäfts-«Gedankenmodell» erstellt werden. Dieses wird, wie im Punkt 01 beschrieben, gemäss der Canvas-Technik strukturiert und validiert. Bei der Erstellung der Produktvision gilt es, z.B. in Abstimmung zu Canvas, folgende Fragen zu beantworten [Arq 2015]:
Teilnehmende: Entwicklungsteam (sofern schon bekannt), aber auch Auftraggeber, Kundenvertreter, das Marketing und der Vertrieb Ziel: eine Produktvision erstellen, welche das Entwicklungsteam motiviert und inspiriert. Sie soll aber auch die übrigen Beteiligten begeistern und für das Produkt einstehen. |
| 2 | Canvas-Workshop durchführen | Im Product Canvas werden die Eckpfeiler des Vorhabens und des Produkts definiert. Neben dem Produktnutzen (Wert) kann es sich um technische Fragestellungen (z.B. zugrundeliegende Architektur etc.) wie auch um produktspezifische Fragestellungen (umzusetzende Elemente, Anzahl Releases etc.) handeln.
|
| 3 | Scope festlegen | Ziel: Klar definieren, was aus Sicht Produkt / Projekt betroffen ist (in scope) und was nicht (out of scope).
|
| 4 | Business Value & Finanzierung | Im Business Case wird die wirtschaftliche Rechtfertigung des Vorhabens resp. Produkts beschrieben. Nicht für jedes Produkt wird ein Business Case verlangt - bei solchen Vorhaben sollte aber zumindest der Business Value festgelegt werden. Dieser Business Value kann auch in Form von Enablern (Grundlage bilden, dass andere Vorhaben davon profitieren können, z.B. Architektur aufbauen) oder in Form des Abbaus von Unternehmensrisiken oder dem Umsetzen von gesetzlichen Vorschriften bewertet werden. |
| 5 | Stakeholder-Verständnis einholen | Wer ein Vorhaben erfolgreich umsetzen möchte, sollte sich bewusst werden, welche Personen (neben dem eigenen Team) noch an dieser Initiative beteiligt sind. Dabei gilt es zu erkennen, welche internen und externen Personen auf das Vorhaben einwirken könnten und an diesem aktiv mitarbeiten. Zu Vorhabensbeginn ist es daher entscheidend, von diesen wichtigen Stakeholdern das Einverständnis für das Vorhaben abzuholen. |
| 6 | Initial Product Backlog zusammenstellen | Basierend auf einem Story Mapping wird das PI Product Backlog respektive Initial Product Backlog zusammengestellt. Gemäss dem Scope werden die Anforderungen bzw. Leistungsmerkmale beschrieben und im Anforderungskatalog (im Initial Product Backlog) festgehalten.
|
| 7 | Estimation Meeting | Den Aufwand für die Realisierung der Product Backlog-Elemente («alle» User Stories schätzen) bestimmen und die Anzahl der notwendigen Iterationen (Sprints) festlegen. Die Velocity (Teamgeschwindigkeit, die aufzeigt wie viele Anforderungen ein Scrum Team pro Sprint umsetzen kann) abschätzen und bestimmen.
|
| 8 | Backlog-Priorisierung | Die Priorisierung erfolgt mehrheitlich aufgrund des Nutzens (Mehrwert/Value), welcher ein PI-Inkrement ausweist. |
| 9 | Release Planning | Im Release Planning geht es, wie der Name schon verrät, darum, das nächste Release zu planen. Ein Release umfasst typischerweise 4 - 6 Sprints. Bei der Release-Planung werden durch den PO die Release Ziele formuliert, und es findet eine erste Diskussion, z.B. mit dem Solution Architekt und dem Entwicklungsteam, statt, welche Epics (siehe Release Epic) und ggf. bereits davon abgeleitete Stories im Rahmen des nächsten Releases umgesetzt werden sollen.
|
| 10 | Produkt-Workshop | Im Produkt-Workshop werden gemeinsam und fachlich übergreifend das Wissen und Verständnis über ein bestimmtes abgegrenztes Wissensgebiet (einer Fachdomäne) zwischen den Fachpersonen und dem Entwicklungsteam erschlossen und visualisiert. Dabei werden kommunikative Methoden wie Event Storming eingesetzt, welche diese Wissenstranformation unterstützen.
|
| 11 | Sprint Planning Meeting 1 | Sprint-Planung, Teil 1: Im Sprint Planning Meeting (Teil 1) stellt der Product Owner die User Stories vor, welche im anstehenden Sprint realisiert werden sollen. Zusammen mit dem Team werden das Ziel und der Inhalt „WAS?“ des nächsten Sprints bestimmt. Das Team gibt das Commitment für die Inhalte des anstehenden Sprints. Das Ergebnis ist ein entsprechender Auszug aus dem Product Backlog; genannt Sprint Backlog.
|
| 12 | Sprint Planning Meeting 2 | Sprint-Planung, Teil 2: Im Sprint Planning Meeting (Teil 2) erarbeiten der Scrum Master und das Team zusammen die entsprechende Architektur und / oder das Design „WIE?“. Dabei werden die User Stories in einzelne Tasks heruntergebrochen und im Sprint Backlog Task festgehalten.
|
| 13 | Analysieren & spezifizieren | Ein Sprint „Entwicklungsphase“ enthält immer alle Entwicklungsschritte. Das heisst: Analyse / Spezifikation & Entwurf, die Entwicklung (z.B. Programmierung), die Dokumentation sowie den Modul- und Integrationstest eines Inkrements. Das Analysieren und Spezifizieren bezieht sich somit immer nur auf die zu erarbeitenden User Stories. Das heisst, die im Sprint Planning 2 analysierten User Stories müssen in diesem ersten Arbeitsschritt so spezifiziert werden, dass anschliessend ein lückenloses Verständnis beim Entwickler oder Entwicklungsteam vorliegt, wie (Design) eine Anforderung im Detail umgesetzt wird, um damit die definierten Akzeptanzkriterien zu erfüllen. |
| 14 | Architektur anpassen | Aufgrund von neuen speziellen Anforderungen müssen die Architektur respektive der Architekturrahmen angepasst werden. Das heisst, der Entwickler muss eventuell technische Tasks (z.B. Architektur anpassen) definieren und dann entsprechend umsetzen. |
| 15 | Inkrement erstellen | Der spezifizierte Task wird nun je nach Werkzeug automatisch oder maschinell codiert, so dass daraus ein lauffähiges Inkrement ergibt. |
| 16 | Inkrement testen | Das neu erstellte Inkrement wird laufend in sich, aber auch immer mit dem gesamten System getestet, so dass am Ende jedes Sprints ein lauffähiges, fehlerfreies Produktinkrement bereitsteht. |
| 17 | Daily Stand-up Meeting | |
| 18 | Sprint Review Meeting | Das Team präsentiert dem Produktverantwortlichen und interessierten Stakeholdern in Form einer Demo der neuen Features live am System, was während des letzten Sprints erreicht worden ist. Dabei werden Verbesserungsvorschläge, Lob und Kritik entgegengenommen und anschliessend wird der Sprint abgenommen.
|
| 19 | Sprint-Retrospektiven | Nach jedem Sprint kommen das Team, der Scrum Master und auch der Product Owner zusammen, um das eigene Arbeitsverhalten zu prüfen und gegebenenfalls zu optimieren. Diese Erkenntnisse / Ergebnisse fliessen direkt in die Arbeitsweisen vom nächsten Sprint ein.
|
| 20 | Product Backlog Refinement Meetings | Das Backlog Refinement Meeting (BRM) ist ein regelmässiges Treffen des Entwicklungsteams mit dem Product Owner während und zwischen den Sprints. Darin werden die Product Backlog Items diskutiert und das nächste Sprint Planning vorbereitet. Das heisst, es geht darum zu klären, ob jedes Backlog Item klar genug formuliert und tief genug aufgesplittet ist, um es zu schätzen und in einen Sprint zu implementieren. Backlog Refinement ist kein Prozessschritt.
Schritt 1: Das Entwicklungsteam identifiziert, welche Product Backlog Items aus der Liste der vom PO vorgegebenen Items noch spezifiziert werden müssen. Schritt 2: Der Product Owner erklärt, was das Product Item ist und warum es gebraucht wird. Schritt 3: Das Entwicklungsteam versteht das WAS und WARUM. Ist dies nicht der Fall, so wird das Item ins Product Backlog zurückgestellt oder der Produkt Owner muss das Backlog Item besser aufbereiten, damit es doch noch in den nächsten Sprint passt. Schritt 4: Das Entwicklungsteam weiss, WIE es das Item umsetzen muss. Ist dies nicht der Fall, sind weitere Diskussionen oder die Erstellung einer Spike Story erforderlich. Schritt 5: Das Entwicklungsteam schätzt den Aufwand. Schritt 6: Der PO prüft, ob Nutzen und Aufwand bei den aktualisierten Product Backlog Items weiterhin im richtigen Wertverhältnis sind; anderenfalls werden sie gelöscht. |
| 21 | Integrations- & Systemtests durchführen | Bei einem auslieferbaren Produkteinkrement (Release) wurde das Produkt in mehreren Iterationen (Sprint) umgesetzt. Am Ende jedes Sprints steht ein Produktinkrement zur Verfügung, welches getestet und dokumentiert ist. Diese Inkremente werden, wenn nicht schon bereits auf einer Life-Umgebung umgesetzt, nochmals in einem umfassenden Integrations- und Systemtest geprüft. Existiert in der Entwicklung eine qualifizierte continuous integration (CI) Pipeline, so entfällt dieser Testzyklus. |
| 22 | Produkt ausliefern | Bei grösseren Vorhaben kann allenfalls aufgrund von Abhängigkeiten nicht jedes Inkrement sofort zur Nutzung freigegeben werden. Die Inkremente der Sprints werden sozusagen zwischengelagert, bis ein für den Kunden sinnvolles Produkt in Form eines Releases ausgeliefert werden kann. So wird das getestete und dokumentierte Produktinkrement zur Abnahme und Implementierung übergeben. Die Praxis zeigt, dass insbesondere bei grossen Entwicklungen vor dem Ausliefern eines Releases ein „Stabilisierungssprint“ durchgeführt werden sollte, in welchem die in den vorhegenden Sprints «liegengebliebenen» Tätigkeiten (meist Kleinkorrekturen im Produktinkrement, unfertige Dokumentation fertigstellen etc.) finalisiert werden. Der Auftraggeber hat am Ende eines Releases stets einen Mehrwert und kann allenfalls das Vorhaben aufgrund seiner Zufriedenheit vorzeitig beenden. |
| 23 | Release-Retrospektive | Das Team reflektiert den soeben zu Ende gegangenen Release. Die Ergebnisse der Analysen von positiven und negativen Erfahrungen der Zusammenarbeit als auch allfällige Optimierungen der Arbeitsweisen werden bereits im nächsten Release Anwendung finden. |
| 24 | Release Backlog Refinement | Vierzehntägliches oder monatliches Überarbeiten und Pflegen des PI Product Backlogs, sodass in den PI Planning Meetings entschieden werden kann, welche Anforderungen in den nächsten «festen» Releases umgesetzt werden müssen. Entscheidend ist, dass ein iteratives Backlog Refinement und anschliessend eine im Sinne der Wave Planning optimierte Release- und Sprintplanung gemacht wird.
|
|
+41 41 747 30 60 |
