agile-learning.eu · web viewagiles arbeiten im team verlangt von allen beteiligten konzentration...

Output 5 aus dem ALTEF-Projekt, Teil 2

Kompetenzentwicklung am Arbeitsplatz

Der Ansatz „Agiles Lernen“-

Lernkarten zu agilem Projektmanagement(Lerneinheiten für selbstgesteuertes

Lernen)

InhaltAgile Werte und Prinzipien.....................................................................................................................3

Agile Methodologien – Eine Übersicht...................................................................................................9

Backlog.................................................................................................................................................18

Time Boxing..........................................................................................................................................21

Kanban.................................................................................................................................................24

Stand-up Meeting.................................................................................................................................28

Review Meeting....................................................................................................................................30

Retrospektive.......................................................................................................................................33

Planning Poker.....................................................................................................................................35

Burn Down Chart..................................................................................................................................38

Cumulative Flow Chart.........................................................................................................................42

Meilenstein-Trend-Analyse..................................................................................................................44

ALTEFWORKPLACED INTEGRATED LEARNING

Lernkarten zu agilem Projektmanagement

- 2 -


AutorenJörg Longmuß, Manfred Mühlfelderfür Sustainum – Institut für zukunftsfähiges Wirtschaften Berlinwww.sustainum.de

Benjamin Höhnefür das Fernstudieninstitut der Beuth-Hochschule für Technik [email protected]

Dieser Text ist ein Output des ALTEF Projekts: “Arbeitsplatzintegriertes Lernen für qualifizierte technische Fachkräfte”

Berlin, Aalborg, Leiderdorp 2019

Dieses Projekt wurde mit Unterstützung der Europäischen Kommission finanziert. Die Verantwortung für den Inhalt dieser Veröffentlichung trägt allein der Verfasser; die Kommission haftet nicht für die weitere Verwendung der darin enthaltenen Angaben.

Licence:

- 3 -

mailto:[email protected]

http://www.sustainum.de/


Agile Werte und Prinzipien Von Manfred Mühlfelder

AnlässeWie können Sie Begeisterung für agiles Arbeiten schaffen?Wie können Sie die Flexibilität und Agilität in Ihren Projekten erhöhen?Wir können Sie das Mindset Ihrer Mitarbeiter verändern?

ErgebnisseSie können die Werte und wesentliche Prinzipien der agilen Methoden wiedergeben.Sie können den Zusammenhang zwischen agilen Werten, Prinzipien und Methoden erklären.Sie kennen Methoden zur Einstelllungsänderung Ihrer MitarbeiterSie legen die Grundlagen zur Anwendung agiler Methoden in der Arbeitspraxis.

Haben Sie schon einmal überlegt ..

.. welche Voraussetzungen es braucht, damit agile Arbeitsformen wie Scrum in der Praxis funktionieren können?

.... welche Einstellungen und Verhaltensweisen dazu beitragen, dass agile Prinzipien in der Praxis gelebt werden?

- 4 -


.... wie Sie diese Einstellungen bei sich und Ihren Kollegen gezielt beeinflussen und entwickeln können, damit agiles Arbeiten in der Praxis funktioniert?

Das agile Mindset

Was ist ein "agiles" Mindset?

Warum ist ein "agiles" Mindset eine grundlegende Voraussetzung für die erfolgreiche Einführung agiler Methoden im Unternehmen?

Die Experten Svenja Hofert erklärt den Zusammenhang: Hier klicken

Mut zu Neuem

Agilität braucht Mut, um mit Unbekanntem umzugehen. Im Vergleich mit "klassischen" Projektmanagementmethoden, die auf Planbarkeit und Vorhersehbarkeit von Ereignissen abzielen, setzen agile Methoden eher auf das Management von Komplexität, Unvorhersehbarkeit und Innovation. (An)erkennen Sie die Grenzen der Planbarkeit, wenn Sie agil arbeiten wollen.

Offenheit

Offenheit gegenüber neuen und unkonventionellen Ideen ist die Grundlage für Kreativität und Innovation. Offenheit gegenüber anderen Sichtweisen, kulturellen Prägungen und Denkweisen ermöglicht die Schaffung neuer Produkte und Dienstleistungen. Ohne Offenheit sind wir gefangen in alten Denkmustern und Verhaltensweisen.

- 5 -

https://www.youtube.com/watch?v=pH0DfYmxEiI


Fokus und Konzentration auf die Wertschöpfung

Agiles Arbeiten im Team verlangt von allen Beteiligten Konzentration auf gemeinsame Ziele. Im Kern geht es darum, neue (Produkt-) Funktionen und Dienstlesitungen so zu kreieren, dass sich der Nutzen für die Kunden erhöht.... und das schrittweise. Alle im Team müssen eine Feedbackkultur pflegen und sich gegenseitig darin bestärken, immer den Kundennutzen bei der Produktentwicklung im Fokus zu haben.

- 6 -


Respekt im Umgang im Team und mit den Kunden und Lieferanten

Respekt und Wertschätzung im Umgang miteinander sind ein Grundpfeiler für agiles Arbeiten. Ohne Respekt verschließen sich Menschen gegenüber Neuem, haben Angst, sich zu öffnen und reduzieren ihren Beitrag. Ein respektvoller Umgang bedeutet, dem anderen aktiv zuzuhören, andere Sichtweisen zu berücksichtigen und Kompromisse zu schließen. Respekt ist eine Geisteshaltung, die sich im Verhalten und in der Kommunikation zeigt.

Commitment und Zuverlässigkeit

Commitment (deutsch: Selbstverpflichtung) ist eine Einstellung gegenüber Aufgaben und Menschen. Agiles Arbeiten ermöglicht mehr Selbstorganisation und Selbstregulation. Auf der anderen Seite funktionieren selbstorganisierte Teams nur dann, wenn sich die Teamitglieder aufeinander verlassen können. Jede(r) muss sich auf die Erreichung der gemeinsamen Teamziele verpflichten und kommunizieren, wenn er sich nicht dazu commiten kann oder will. In der Psychologie wird noch zwischen einem affektiven ("Ich fühle mich emotional mit der Aufgabe und den anderen Teammitgliedern verbunden."), einem normativen ("Ich fühle mich den anderen gegenüber verpflichtet, meine Aufgaben so gut wie möglich zu erledigen.") und einem kalkulativen ("Ich fühle mich dann verpflichtet, wenn am Ende etwas Positives für mich herausspringt:") Commitment unterschieden.

- 7 -


Agile PrinzipienAgile Prinzipien sind universelle Gesetzmäßigkeiten, die ihre Gültigkeit im Lean Management bereits gezeigt haben. Diese sind u.a.

Inkrementelle Produktentwicklung o Produkte werden in kleinen Schritten entwickelt. Die Produktmerkmale werden

schrittweise erweitert und ergänzt. Anstelle eine "Roll out" der kompletten Produkts werden kleinere Releases geplant.

Iterationen o Das Produkt wird in kleinen Zeitscheiben (Sprints) entwickelt. Am Ende jedes Sprints

werden neue Funktionen begutachtet und entweder akzeptiert oder verworfen. Der Prozess folgt dem PDCA-Zyklus (Plan-Do-Check-Adjust)

Pull" statt "Push" o Nachgelagerte Arbeitsprozesse "ziehen" (pull) ihren Inhalt aus dem vorgelagerten

Prozess. Vorgelagerte Prozesse arbeiten nur so schnell, dass sie keine Arbeitsinhalte auf den nachgelagerten Prozess verlagern (push). So bleibt der Gesamtprozess in der Balance. Es entstehen keine "Senken" oder Überlastungen in einzelnen Arbeitsschritten.

"Just in Time" Produktion o Arbeitsergebnisse werden so fertigstellt, dass sie sofort weiterverarbeitet werden

können. Es werden keine Arbeitsergebnisse "auf Halde" produziert. Dadurch wird eine Verschwendung durch Überproduktion verhindert.

"Time boxing" o Jedes Ereignis im agilen Arbeiten hat eine vorgegebene Dauer. In der

Produktionsarbeit wird diese Dauer durch den Kundentakt festgelegt. Im agilen Arbeiten werden bestimmte Vorgaben gemacht, wie lange einzelne Ereignisse dauern dürfen, z. B:

Sprint Planung 8 h Sprint Review: 2-3 h Retrospektiven: 2-3 h Daily Scrum: 15 Minuten Sprintlänge: 2 bis 4 Wochen

- 8 -


LiteraturempfehlungenLiscia, G., Liscia, J. & Liscia, M. (2018). Workbook Attitude: Eine Frage der inneren Haltung sowie Werte, die gelebt und kommuniziert werden (D.R.E.A.M. of LEADERS® - Workbooks). Norderstedt: Books on Demand

Koschek, H. & Dräther , R. (2018). Neue Geschichten vom Scrum: Von Führung, Lernen und Selbstorganisation in fortschrittlichen Unternehmen. Heidelberg: dpunkt.Verlag

Preußig, J. & Sichart, S. (2018). Agiles Führen: Aktuelle Methoden für moderne Führungskräfte. Freiburg: Haufe

Sauter, R., Sauter, W.& Wolfig, R. (2018). Agile Werte- und Kompetenzentwicklung: Wege in eine neue Arbeitswelt. Berlin: SpringerGabler

- 9 -


Agile Methodologien – Eine Übersicht Von Manfred Mühlfelder

AnlässeOrientierung über agile Methoden gewinnenÜberblick über verschiedene agile Rahmenmodelle gewinnenZusammenhänge zwischen den Methoden erkennen

ErgebnisseSie kennen verschieden Rahmenmodelle für agiles Arbeiten.Sie können einzelne Techniken den jeweiligen Rahmenmodellen zuordnen.Sie können die für Ihre Fragestellung am besten geeigneten Methoden auswählen.Sie können die verschiedenen agilen Methoden miteinander vergleichen und gegenüberstellen.

Was sind "agile" Methoden?

Welche Rahmenmodelle (engl. "frameworks") gibt es für die Beschreibung agiler Methoden?

In dieser Lernkarte lernen Sie die wichtigsten agilen Methoden und Rahmenmodelle kennen.

Lernziele

Beschreiben Sie bitte drei persönliche Lernziele für diese Lernkarte.

- 10 -


Agile Methoden in der Übersicht

Agile Methoden unterscheiden sich hinsichtlich ihres Detailierungsgrades und ihrer Formalisierung.

An der Spitze flexibler Rahmenmodelle für agiles Arbeiten steht SCRUM. Im SCRUM arbeiten die Entwicklerteams selbstorganisiert an der Produktentwicklung. Unter Anleitung eines SCRUM Masters setzen Sie dabei die Vorgaben des PRODUCT OWNERS schrittweise um.

KANBAN, SCRUMBAN und CRYSTAL sind Rahmenwerke für agiles Arbeiten, die vor allem für Effizienz in den Abläufen sorgen. Sie stehen für rel. einfache Methoden zur Steuerung des Arbeitsflusses und erhöhen die Transparenz.

FEATURE DRIVEN DEVELOPMENT (FDD), EXTREME PROGRAMMING (XP) und LEAN SOFTWARE DEVELOPMENT (LDS) fokussieren auf eine schlanke und funktionsorientierte Softwareentwicklung mit integrierten Tests und Feedbackschleifen.

Den höchsten Formalisierungs- und Detaillierungsgrad haben Modelle aus dem Software Engineering wie beispielsweise das V-Modell oder das Rational Unified Process Modell.

SCRUM

SCRUM (deutsch "Gedränge") ist eine Arbeitsweise, in der selbstorganisierte Teams nach bestimmten Regeln miteinander in Interationen neue Produkte bzw. Produktinkremente entwickeln.

- 11 -


Scrum Rollen

Im Scrum gibt es drei zentrale Rollen, die miteinander interagieren.

- 12 -


1. PRODUCT OWNER

Der Product Owner ist derjenige, der die Produkteigenschaften festlegt und die sog. EPICS und USER STORIES formuliert. EIne User Story ist eine Funktionsbeschreibung aus Sicht einer bestimmten Rolle, z. B.

Als [Kunde] möchte ich eine [Visualisierungsfunktion], um eine [dreidimensionale Darstellung eines Produktes zu haben, damit ich mir das Produkt genauer vorstellen kann].

Der Product Owner ist für die Produkt- und Releaseplanung verantwortlich. Er legt den Produktumfang fest und priorisiert die User Strories nach Geschäftswert und Nutzen.

Er hat aber keine disziplinarische Weisungsbefugnis gegenüber dem Entwicklerteam.

Product Owner brauchen vor allem fachliche und unternehmerische Kompetenzen.

2. SCRUM MASTER

Der Scrum Master ist der Team Coach für das Scrum Team. Er achtet auf die Einhaltung der Scrum Regeln und moderiert die Scrum Ereignisse. Auch er hat keine disziplinarische Macht über das Scrum Team, sondern agiert als Coach und Moderator.

Eine seiner zentralen Aufgaben ist die Beseitigung von Hindernissen, die das Entwicklerteam davon abhalten, am Produkt zu arbeiten (z. B. fehlende Lizenzen oder Zugriffe auf andere Systeme).

Scrum Master brauchen vor allem methodische und soziale Kompetenzen.

3. ENTWICKLER TEAM

Das Entwickler Team besteht aus 3 bis 9 Personen, die selbstorganisiert die zu entwickelnden Produktmerkmale und User Stories in Arbeitspakete überführen und in konkrete (Programmier-) Aufgaben überführen. Sie planen im SPRINT PLANNING MEETING die Aufgaben und Ziele für den nächsten Sprint und schätzen die Komplexität jeder User Story.

Alle Aufgaben, die zur Realisierung und Testung einer User Story notwendig sind, werden vom Team selbst geplant und durchgeführt.

Die Teammitglieder benötigen vor allem technische Kompetenzen.

- 13 -


Artefakte im Scrum

Das PRODUCT BACKLOG ist das zentrale Dokument, in dem die Produktanforderungen in Form von EPICS (Leitthemen) und USER STORIES vom Product Owner formuliert und priorisiert werden. Es ist kein starres Lasten- oder Pflichtenheft, sondern kann sich von Sprint zu Sprint verändern. Neue Anforderungen können in das Product Backlog aufgenommmen werden, bereits formulierte User Stories können elimiert oder in ihrer Wichtigkeit nach oben oder unten priorisiert werden. Mithilfe des Product Backlogs steuert der Product Owner den Produktentstehungsprozess.

Beispiel für ein Product Backlog

Das SPRINT BACKLOG umfasst den Arbeitsvorrat für das Entwicklerteam für den nächsten Sprint. Es enthält die am höchsten priorisierten User Stories aus dem Product Backlog. Das Entwicklerteam legt zusammen mit dem Product Owner fest, welche User Stories im nächsten Schritt realisiert werden sollen und schätzt deren Komplexität. Je nach Aufwand und Komplexität der User Stories kann das Sprint Backlog mal mehr oder weniger User Stories beinhalten.

- 14 -

https://www.thinkagile.de/pflege-des-product-backlogs/


Ereignisse im Scrum

Beim SPRINT PLANNING MEETING plant das Entwicklerteam die Arbeitsschritte, die notwendig sind, um die User Stories aus dem SPrint Backlog zu realisieren. Die Teammitglieder diskutieren Abhängigkeiten zwischen den User Stories und legen fest, welche Arbeitsschritte notwendig sind, um das Sprintziel zu erreichen.

Beim ESTIMATION MEETING schätzen die Entwickler die Komplexität jeder User Story und die Aufwände für die Realisierung der Funktionen.

Beim DAILY SCRUM geben sich die Entwickler einen täglichen Statusbericht zum Stand der von ihnen übernommenen Aufgaben. Gegebenenfalls werden Probleme über den Scrum Master an den Product Owner eskaliert, wenn das Sprintziel gefährdet ist.

Beim SPRINT REVIEW präsentiert das Entwicklerteam dem Product Owner die im Sprint entwickelten neuen Funktionen. Der Product Owner akzeptiert die Funktionen oder lehnt sie ab, wenn sie nicht den vereinbarten Akzeptanzkriterien entsprechen ("Definition of Done").

In der RETROSPEKTIVE betrachtet das das Team in der Rückschau den Verlauf des vergangegen Sprints. Ziel der Retrospektive ist die Verbesserung der Zusammenarbeit im Team und die Beseitigung von Hindernissen vor dem Start des nächsten Sprints. Moderiert wird die Retrospektive vom Scrum Master.

Checkliste für die Bewertung eines Sprints (www.retromat.org)

Spezielle Methoden im Scrum

Auf den folgenden Seiten lernen sie einige spezielle Methoden für die Zusammenarbeit in Scrum Teams kennen.

- 15 -

http://www.retromat.org/

http://agilecoach.de/scrum/Scrum-checklist_German_v2016.pdf


Kanban

KANBAN ist ein japanisches Wort und bedeutet soviel wie "SIGNAL" oder "SCHILD". Es wurde ursprünglich im LEAN MANAGEMENT für die Steuerung von Produktionsprozessen nach dem "PULL"-Prinzip eingeführt. Auf einer KANBAN Tafel werden alle Aufgaben, die in einem Sprint zu erledigen sind auf einzelne Karten geschrieben. Danach werden sie nacheinander von links nach rechts durch die einzelnen Spalten der Kanban Tafel gezogen (englisch: pull). Erst wenn ein Platz auf der Tafel leer ist, kann eine nachfolgende Karte auf diese Stelle gezogen werden. So wird ein schneller Arbeitsfluss im System erreicht.

Planning Poker

Beim PLANNING POKER schätzen die Teammitglieder im Scrum Team gemeinsam die Komplexität und den zeitlichen Aufwand für jede User Story. Dabei kommen häufig Planning Poker Karten zum Einsatz. Die Story wird vorgelesen und jedes Teammitglied zieht verdeckt eine Karte aus seinem Kartenset, mit dem der Aufwand für die Realisierung aller Funktionen, die zu einer User Story gehören, geschätzt wird.

Wenn die Schätzungen weit auseinander liegen, müssen diejenigen Teammitglieder mit den höchsten bzw. den niedrigsten Schätzungen dies begründen. Die anderen Teammitglieder hören den Argumenten zu und überdenken ihre eigene Schätzungen.

Danach wird wieder gepokert. Die Schätzungen sollten sich nun einander annähern.

Auf diese Weise werden alle User Stories, die im nächsten Sprint zu realisieren sind, hinsichtich ihrer Komplexität und Aufwänden geschätzt und aufsummiert. Dies ist die Anzahl an STORY POINTS, die im nächsten Sprit vom Team realisiert werden.

- 16 -


Sprint Review

Beim SPRINT REVIEW stellt das Entwicklerteam dem Product Owner die Funktionen vor, die für die Realisierung der User Stories im Sprint entwickelt und getestet worden sind.

Der Product Owner akzeptiert die Funktionen, wenn sie den vereinbarten Akzeptanzkritierien entsprechen.

Die akzeptierten Funktionen können dann in das nächste Release übernommen werden.

Nicht akzeptierte Funktionen müssen im nächsten Sprint nocheinmal gemäß der Akzeptanzkriterien überarbeitet werden.

- 17 -


Retrospektive

Bei einer RETROSPEKTIVE reflektieren die Scrumteammitglieder die Qualität ihrer Zusammenarbeit und der im Sprint erzielten Ergebnisse.

Dabei können die folgenden Leitfragen zur Strukturierung genutzt werden.

1. Was lief gut? Welche positiven Erfahrungen haben wir im letzten Sprint gemacht?

2. Was lief schlecht? Welche negativen Erfahrungen haben wir im letzten Sprint gemacht?

3. Was brauchen wir an Information und besserer Kommunikation, um im nächsten Sprint effektiver als Team zu sein?

4. Welche Scrum Regeln und Prinzipien haben wir in diesem Sprint besonders beachtet bzw. vernachlässigt?

5. Welche Entscheidungen treffen wir für den nächsten Sprint? Was werden wir beibehalten? Was werden wir verändern?

- 18 -


Testen Sie Ihr Wissen.Wer macht was im Scrum Team?

Welche Rollen gibt es im Scrum Team?

LiteraturempfehlungenAndresen, J. (2017). Retrospektiven in agilen Projekten: Ablauf, Regeln und Methodenbausteine. München: Carl Hanser Verlag

Gloger, B. (2016). Scrum: Produkte zuverlässig und schnell entwickeln. München: Carl Hanser Verlag

Häußer, A., Römer, E. & Zeppenfeld, N. (2017). Praxisbuch Agilität. Tools für Personal- und Organisationsentwicklung. Freiburg: Haufe

- 19 -


Backlog Von Jörg Longmuß

Anlässe

Die Arbeit im Vorhaben soll über alle Etappen hinweg übersichtlich strukturiert werden Es sollen jeweils die Aufgaben herausgezogen werden, die in der nächsten Etappe bearbeitet

werden

Aufgabe

Bringen Sie die Aufgaben innerhalb des Vorhabens in eine übersichtliche Struktur, in der sie leicht abgearbeitet werden können

BacklogGenerell wird unter „Backlog“ eine Menge an Arbeit verstanden, die sich im Laufe der Zeit angesammelt hat oder einen Bestand an Aufträgen, die auf ihre Abarbeitung warten.

Ein Backlog ( im ursprünglichen Sinne ein großer Stapel Feuerholz hinter einer Feuerstelle) beschreibt im übertragenen Sinne einen Leistungsrückstand, der sich über einen bestimmten Zeitraum angesammelt hat. Im agilen Projektmanagement steht ein Backlog für projektbezogene Aufgaben, die zu erledigen sind. Dabei wird grundsätzlich zwischen dem Produkt Backlog und dem Sprint Backlog unterschieden. Der Produkt Backlog enthält alle Anforderungen an das Endergebnis, wie z.B. die Anforderungen an die zu erstellende Software in einer Softwareentwicklung. Der Sprint Backlog enthält die Aufgaben, die innerhalb eines Sprints abgearbeitet werden sollen.

Produkt Backlog

Der Produkt Backlog ist eine geordnete Liste aller Punkte, die nach gegenwärtigem Wissensstand für das Produkt benötigt werden. So hat ein Team immer den Überblick, welche Aufgaben es hat, bis ein Vorhaben abgeschlossen ist. Verantwortlich für den Produkt Backlog, einschließlich aller möglicherweise nötigen Änderungen, ist der Product Owner.

Der Produkt Backlog sollte nicht mit dem klassischen Lastenheft verwechselt werden. Er ist nicht notwendigerweise abgeschlossen, sondern in der Regel dynamisch. Die früheste Version legt die zunächst bekannten Anforderungen fest. Es können auch allgemeinere Beschreibungen eingesetzt werden, die erst im Laufe des Vorhaben detailliert werden. Der Produkt Backlog entwickelt sich dann mit der Entwicklung des Produkts. Er kann kontinuierlich verfeinert und ausgearbeitet werden. Auch die Reihenfolge der Produkt Backlog Items in einem Produkt Backlog kann sich ändern, wenn sich Prioritäten verschieben oder neue Anforderungen deutlich werden. Dies ist ein fortlaufender Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam an den Details arbeiten.

Es ist möglich, dass ein Produkt Backlog dabei zu groß wird, um effektiv verwaltet zu werden. Dies geschieht, wenn zu viele Details hinzufügt werden, die zum Ergebnis gehören könnten. Besser sollten zu einem solchen Zeitpunkt im Produkt Backlog nur übergreifende Arbeitspakete bzw. Produktfeatures aufgeführt werden, die erst dann detailliert werden, wenn sie zur Bearbeitung ins Sprint Backlog übernommen werden.

- 20 -


Sprint Backlog

Ein Sprint-Backlog ist die Teilmenge des Produkt-Backlogs, die ein Team während eines Sprints bearbeitet, um das Sprintziel zu erreichen. Der Sprint-Backlog besteht aus Produkt-Backlog-Items, die das Team mit seinem Product Owner bei der Sprint-Planung vereinbart hat. Die meisten Teams schätzen dabei, wie viele Stunden jede Aufgabe jemanden im Team in Anspruch nimmt, um sie zu erledigen (=> Planning Poker). So kann sich das Team auf einen klaren Spielraum für die Dauer des Sprints konzentrieren.

Ein Sprint-Backlog bietet einem Team eine klare Fokussierung auf kurze Sicht, während ein dynamischer Produkt Backlog einen Mechanismus bietet, mit dem das Team Ideen für die Zukunft sammeln und speichern kann. Die Führung einer stabilen Liste von Product Backlog Items in einem Sprint-Backlog schützt das Team vor wechselnden Prioritäten und Unterbrechungen, zumindest für einen überschaubaren Zeitraum.

Beispieldarstellung, Quelle unklar (Pinterest)

Der Sprint Backlog kann sich im Laufe des Sprints ändern, basierend auf dem, was das Team lernt, während es den Sprint Backlog bearbeitet. Für die Bearbeitung empfiehl sich meist ein => Kanban Board, um die Aufgaben zu verfolgen. Der Arbeitsstand kann grafisch mit einem => Burn Don Chart oder einem => Cumulativ Flow Chart aufbereitet werden.

- 21 -


Der Sprint Backlog hält nur für die Dauer eines Sprints an. Jeder neue Sprint beginnt mit einem neuen Sprint Backlog, wobei das Team Elemente aus dem Sprint Backlog des vorherigen Sprints in den neuen Sprint Backlog aufnehmen kann, wenn diese noch nicht ausreichend bearbeitet sind.

Bearbeitung

Eine Aufgabe wird in der Regel einer Person zugeordnet sein. Sie kann aber auch zu Beginn eines Sprints noch frei, d.h. nicht persönlich zugeordnet sein. Hat ein Teammitglied seine aktuellen Aufgaben erledigt oder kommt mit ihnen nicht weiter, wählt es aus seinem persönlichen Sprint Backlog oder aus dem Sprint Backlog des Teams eine andere Aufgabe zur Bearbeitung aus. Sobald ein Teammitglied eine weitere Aufgabe übernimmt, wandert diese auf dem Kanban Board zu "In Bearbeitung". Dieser Prozess wird solange fortgesetzt, bis alle Aufgaben aus dem Backlog erledigt sind – oder bis zur nächsten Review, wo ein neues Sprint Backlog aufgestellt wird.

Weiterführende Links

https://www.agilealliance.org/glossary/backlog

zur Frage, wann eine Aufgabe als abgeschlossen betrachtet werden kann, siehe auch „Definition of Done“ bei Wikipedia: https://de.wikipedia.org/wiki/Scrum#Definition_of_Done

- 22 -

https://de.wikipedia.org/wiki/Scrum#Definition_of_Done

https://www.agilealliance.org/glossary/backlog


Time Boxing Von Benjamin Höhne

AnlässeEin agiles Mindset für die eigene Arbeit entwickeln

Orientierung über agile Methoden gewinnen

Verstehen was die Grundwerte agiler Arbeit sind

ErgebnisseKann ein Meeting in effektive, zeitlich angemessene Blöcke gliedern

Kann Moderationstechniken planen, die ein Meeting ergebnisorientiert begrenzen

Kann wichtige Themen, die nicht Kern eines Meetings sind, aufnehmen und für ein anderes Meetings einplanen

AnwendungRahmenbedingungenWelcher Zeitraum wurde im Vorfeld für das Meeting angesetzt?

Zerlgen Sie den Meetingszeitraum in gleichgroße Timeboxes (z.B. 15 Minuten oder 30 Minuten). Wie lang sind Ihre Timeboxes und wie viele haben Sie zur Vefügung?

ThemenWelche Themen (Agendapunkte) sollen bearbeitet werden.

Themen kategorisierenKategorisieren Sie Ihre Themen nach deren Zeitbedarf.

ImpulseDie Methode des Time-Boxings wird für die Moderation und Planung von Meetings eingesetzt. Kurz gesagt ist das Ziel ein Meeting so kurz und produktiv wie möglich zu gestalten. Dafür wird das Meeting in feste Zeiteinheiten zerlegt (Time-Boxes). Für jedes Thema auf der Agenda kann so einfach festgelegt werden wie viele Time-Boxes dafür benötigt werden. In einer Agenda ist dadurch schnell sichtbar wie viel Raum welchem Thema gegeben wird. Beispielsweise könnte man ein 2 Stunden Meeting so in 10 Minuten Boxen zerlegen und jedes Thema mit einem Ziel belegen.

- 23 -


Jeder Tagesordnungspunkt muss dafür in der Planung mit einem klaren Ziel verbunden werden, welches sowohl dem Moderator als auch dem Team klar ist. Für die Planung der Zeitboxen kann man sich dabei folgende Fragen stellen um zu einer realisitschen und ökonomischen Zeiteinschätzung zu kommen:

Was wollen wir als konkretes Ergebnis aus diesem Tagesordnunspunkt herausziehen? Wer muss dafür was darstellen, berichten oder präsentieren? Muss über das Thema diskutiert werden? Wenn ja, worüber und mit welchen Ziel? Muss eine konkrete Entscheidung getroffen werden oder Verantwortungen vergeben

werden?Je komplexer die Antworten auf diese Fragen sind, desto mehr Zeit muss eingeplant werden. Als generelle Maßgabe sollten jedoch auch notwendige Diskussionen zeitlich begrenzt werden und im Zweifelsfall ein neues Meeting vereinbart werden, wenn das Thema in größeren Umfang und Detail besprochen werden muss. Gerade wenn das Time-Boxing in einem bestehenden Team neu eingeführt wird, kann es sinnvoll sein, einen für alle sichtbaren Timer (Stoppuhr oder Ähnliches) mitlaufen zu lassen.

Ein zusätzlicher Nutzen der oben aufgeführten Leitfragen ist, dass notwendige Inputs von Beteiligten benannt werden können und so bereits im Vorfeld in ihrem Umfang abgesprochen werden können. Gleiches gilt für die Überlegung zu möglichen Diskussionen oder notnwendigen Entscheidungen. Auch hier kann schon im Vorfeld geklärt werden ob eine Unklarheit beispielsweise durch eine Positionierung eines Vorgesetzten oder anderen Stakholders geklärt werden kann.

Um möglichst effektiv mit der Time-Boxing Methode arbeiten zu können, sind folgende Grundsätze hilfreich:

Wir beginnen zum vereinbarten Zeitpunkt Wir konzentrieren uns auf das Wesentliche Wir tauschen nur Informationen aus, die für alle Beteiligten relevant sind Zusätzliche Gesprächsbedarfe werden festgestellt und terminiert Das Time-Boxing Prinzip kann natürlich nicht nur für Meetings genutzt werden, sondern auch

für die eigene Tagesplanung. So können die eigenen Aufgaben in beliebig kleine Zeitboxen eingeplant werden. Gerade für Personen, die in Führungspositionen viele kleine Entscheidungen und Interaktionen in ihren Alltag einplanen müssen, kann sich ein solches Vorgehen für das eigene Zeitmanagement lohnen.

- 24 -


EmpfehlungEin Extrem-Beispiel für die Selbstorganisation mit der Time-Boxing-Methode wird über Elon Musk berichtet. Er soll demnach seinen kompletten Tag in 5 Minuten Slots planen. Wer sich für diese Geschichte und ein paar Tipps zu konkreten Apps interessiert, die einem bei der eigenen Tagesplanung mit der Time-Boxing-Methode helfen können, der kann einige gute Ideen im Video von Thomas Frank finden:

https://youtu.be/fbAYK4KQrso

- 25 -

https://youtu.be/fbAYK4KQrso


Kanban Von Benjamin Höhne

Anlässe Kanban Methode für ein Projekt einsetzen Projekte mit agilen Methoden gestalten.

Ergebnisse Kann ein Kanban Board anlegen Kann ein Projekt mit der Kanban-Methode planen

AnwendungProjekt-KanbanErstellen Sie für ihr aktuelles Projekt ein Kanban-Board mit den Spalten:

Backlog To Do In Progress Check Done

Nutzen Sie dafür entweder eine analoge Variante (Metaplanwand, Whiteboard) mit Post-Its oder eine digitale Repräsentation (Kanboard, Trello, Jira oder MS Project ).

Wenn Sie ihr Kanban gerne mit unserem Kanboard erstellen würden, schreiben Sie uns kurz eine Mail ([email protected]) und wir schalten Sie frei.

AufgabenLegen Sie im Backlog zwei neue Aufgaben an, die aktuell in Ihrem Projekt anstehen und überlegen Sie sich wie Sie folgende Informationen auf ihrem Board abbilden wollen:

Verantwortlichkeiten Deadlines für Aufgaben Zeitspanne eines Sprints (einer Etappe)

ImpulseKanban (jap. Karte) ist eine Möglichkeit, die Arbeit an komplexen Aufgaben in kleinere Tasks aufzuteilen und zu visualisieren. Das Prinzip eignet sich vor allem für agile (Lern)Projekte, da zu Beginn des Projektes nicht alle Aufgaben bereits bekannt sind und sich Priorisierungen häufig ändern können. Ein Kanban-Board besteht in seiner einfachsten Forma aus drei Spalten, in denen die Arbeitspakete organisiert werden (To Do, Doing, Done). Probieren Sie es doch einfach mal aus:

- 26 -


Für die Organisation eines agilen Projekts hat es sich etabliert mit vier Spalten zu arbeiten (To Do, In Progress, Check, Done) und den To Dos direkt Verantwortliche zuzuordnen. Die Check-Spalte wird eingeführt um im Arbeitsprozess signalisieren zu können, dass die Aufgabe aus Sicht des Teams abgeschlossen ist. Wenn das Ergebnis im Review-Meeting abgenommen wurde, kann die Karte auf Done verschoben werden.

Häufig wird für die Projektplanung noch eine weitere Backlog-Spalte eingeführt, in der alle Aufgaben, die im Projekt zu erledigen sind gesammelt werden. Ganz allgemein bezieht sich der Begriff Backlog auf eine Menge an Arbeit, die sich im Laufe der Zeit angesammelt hat oder einen Bestand an Aufträgen, die auf ihre Abarbeitung warten. Das Backlog ist nicht vollständig und erhebt auch nicht diesen Anspruch. Zu Beginn eines Projektes enthält es die bekannten und am besten verstandenen Anforderungen und dient als Quelle für die Bestückung der To Do Spalte des aktuellen Sprints.

Wenn mit einem analogen Kanban-Board gearbeitet wird, sollte dafür Sorge getragen werden, dass dieses allen Teammitgliedern leicht zugänglich ist und dass die Aktualisierung des Boards regelmäßig vorgenommen wird. Wenn man den Status der Aufgaben nicht „im Vorbeigehen“ sehen kann, sollten regelmäßige Stand-Up-Meetings zwischen den Teammitgliedern durchgeführt werden (ca. 15 Minuten) um alle Beteiligten über den Status der Bearbeitung zu informieren. Ein analoges Kanban-Board folgt damit einem Pull-Prinzip, da die Teammitglieder eigenständig dafür Sorgen müssen, dass sie über Statusänderungen informiert bleiben.

- 27 -


Eine Alternative zum analogen Kanban ist die Einführung eines digitalen Kanban-Boards. Der Vorteil eines digitalen Kanboards ist die Möglichkeit eine automatisierte Benachrichtigung bei einem Statuswechsel von Aufgaben zu implementieren, Kommentare zum Status zu erlauben oder Zwischenstände in Form von Dokumenten zu den Karten hochzuladen. Für diesen Zweck eignen sich zum Beispiel Tools wie Kanboard, Jira oder Trello.

Eine einfache Implementierung eines digitalen Kanban-Boards, welche sich auf die wichtigsten Funktionalitäten für agile (Lern)projekte fokussiert, wurde auch für die Agile Learning Academy umgesetzt.

- 28 -


Weiterführende InformationenEine freie und vielfach eingesetzte Kanban Anwendung ist Trello. Trello gibt es für alle gängigen Betriebssysteme und als Smartphone Apps: https://trello.com/

Eine Anleitung wie man in MS Project 2016 ein Kanban-Board einrichtet, finden Sie hier: https://youtu.be/81PvB1zKh-I

Für Ms Project 2010 wird kein natives Kanban unterstützt, mit etwas kreativer Energie kann man aber trotzdem ein Kanban-View erstellen: http://www.cambermast.com/agile-ideas-create-kanban-board-microsoft-project/

- 29 -


Stand-up Meeting Von Benjamin Höhne

Anlässe Durchführung eines Zwischenstopps (Stand-Up) im Agilen Projekt Moderation einer Kleingruppe Projekte mit agilen Methoden gestalten.

Ergebnisse Alle Teammitglieder sind über den Status der Zielerreichung der anderen informiert. Notwendige gemeinsame Arbeiten sind verabredet. Hindernisse sind benannt und Strategien und Verantwortlichkeiten zur Lösung sind

vereinbart.

ChecklisteInformationsstand

Sind alle Teammitglieder ausreichend über den Fortschritt der Aufgaben informiert? Wenn nicht, was wurde vereinbart um alle informiert zu halten?

Verantwortlichkeiten Sind alle notwendigen Arbeiten vereinbart und Verantwortlichkeiten vergeben? Wenn nicht, was wurde vereinbart um die notwendigen Absprachen zu treffen?

Hindernisse Gibt es Hindernisse oder Probleme, die nicht durch das Team aus dem Weg geräumt werden

können? Wenn ja, wer kann dabei helfen und von wem wird diese Person kontaktiert?

ImpulseEin kurzes Meeting (ca. 15 Minuten) mit dem gesamten Projektteam zum Abgleich des Status-Quo der Arbeitspakete, zur Synchronisation der Aktivitäten und bei Bedarf zum Anpassen des Vorgehens. Zeitabstand und Ort können vom Team frei gewählt werden. Folgende Fragestellungen können dabei helfen:

Was habe ich bereits erledigt? Was nehme ich mir bis zum nächsten Zwischenstopp vor? Was brauche ich von anderen Teammitgliedern? Welche Hindernisse/Probleme/Verzögerungen stehen mir im Weg?

o Können diese Hindernisse gelöst werden? Wenn ja wodurch/durch wen?Gerade wenn die Methode der Stand-Up Meetings neu eingeführt wird, kann es auch mal etwas länger dauern. Setzen Sie sich aber trotzdem das Ziel bei jedem Meeting näher an die 15 Miuten zu kommen und nutzen Sie einen Moderator, Coach oder Scrum-Master um die Meetings zu

- 30 -


strukturieren und zu moderieren. Wenn das Team eingespielt ist, können die Stand-Ups auch häufig ohne einen externen Moderator durchgeführt werden.

Vorteile Kürzere Meetings, denn keiner steht gerne lange. Regelmäßigerer Austausch, denn ein 15 Minuten Meeting bekommt man immer noch unter. Klare Aufgaben, denn die eigene Arbeit in Worte zu fassen strukturiert das Denken und eine

fremde Perspektive zu bekommen hilft festgefahren Probleme zu lösen. Mehr Zusammengehörigkeit, denn regelmäßig im Team zu sprechen hilft einem dabei sich

gegenseitig besser zu verstehen.

VorgehenHinstellen und stehen bleiben

Suchen Sie sich einen Tisch oder eine freie Fläche wo Sie sich hinstellen können. Das Stehen hilft dabei sich kurz zu fassen und es sich nicht "gemütlich zu machen".

Übersicht schaffen

Wenn Sie zur Absprache ein Kanban-Board nutzen rollen Sie dieses dort hin oder schließen Sie einen Laptop oder Beamer an um gemeinsam auf die Aufgaben blicken zu können. Es muss allen klar sein worüber geredet wird und wer wofür verantwortlich ist.

Updates geben

Jeder berichtet kurz, welche Fortschritte er seit dem letzten Stand-up gemacht hat, was er bis zum nächsten Stand-Up schaffen will und ob es Hindernisse gibt, die ihn vom Fertigstellen der Aufgaben abhalten. Keine Details berichten, aber konkret und nachvollziehbar die wichtigsten Punkte benennen.

Vereinbarungen

Müssen Aufgaben neu vergeben werden? Braucht es einen Input vom Auftraggeber oder anderen Stakeholdern? Müssen Hindernisse durch ein Teammitglied, den Coach oder andere aus dem Weg geräumt

werden? Wann soll das nächste Stand-Up Meeting stattfinden

EmpfehlungJa, aber... das klappt doch nur mit zwei bis drei Leuten. Weit gefehlt:

- 31 -


https://youtu.be/bNe5Xx42meQ

- 32 -


Review Meeting Von Benjamin Höhne

Anlässe Durchführung eines Etappen-Reviews Moderation einer Kleingruppe Projekte mit agilen Methoden gestalten.

Ergebnisse Die Ergebnisse der letzten Etappe wurden dem Auftraggeber präsentiert und gemeinsam

besprochen. Der Auftraggeber hat eine Entscheidung über die Freigabe der Ergebnisse getroffen.

ChecklisteTeam

Für welches Projektteam wird das Review durchgeführt? Für welche Etappe wird das Review durchgeführt?

EtappenzieleWelche Ziele hatte sich das Team in der letzten Etappe gesetzt?

Zielprüfung In welchem Umfang wurden diese erfüllt? Was genau ist bei den Zielen offen geblieben? Welche Aufgaben ergeben sich daraus für die nächste Etappe?

ImpulseAm Ende jeder Etappe (Sprint) eines Projekts findet ein Review statt. Das Team präsentiert die Ergebnisse seiner Arbeit dem Auftraggeber sowie allen interessierten Stakeholdern und sammelt Feedback (Meinungen, Verbesserungsvorschläge, Lob und Kritik). Der Fortschritt wird überprüft, dann akzeptiert der Auftraggeber entweder die Ergebnisse oder überweist sie zur weiteren Bearbeitung an das Team zurück. Anschließend werden die nächsten Schritte vereinbart und gegebenenfalls das Gesamtziel (siehe auch Product Backlog) angepasst.

VorteileEin regelmäßiges fachliches Review des Projektfortschritt nach jeder Etappe wirkt zunächst aufwendig, hat aber diverse Vorteile:

Zwischen den Projektbeteiligten (Team, Auftraggeber, Stakeholder) findet ein direkter Austausch ohne Umwege statt.

Bei der Überprüfung wird besonders deutlich, was bereits erarbeitet wurde. Der Fortschritt des Projekts lässt sich an konkreten Ergebnissen ablesen.

Die Identifikation des Teams mit den eigenen Arbeitsergebnissen steigt.

- 33 -


Die Motivation zur Erreichung des Gesamtziels steigt, da die Überprüfung immer umgesetzte, greifbare Ergebnisse präsentiert.

Änderungswünsche können direkt gestellt und (nach Entscheidung des Auftraggeber) für einen der nächsten Schritte geplant werden.

Ideen zur weiteren Konkretisierung des Ergebnisses werden von allen Beteiligten gemeinsam diskutiert.

Es gibt ein gemeinsames Bild aller Teilnehmer darüber, welche Aufgaben für die nächste Etappe anstehen.

Ziele Dem Auftraggeber den Status der Arbeit präsentieren Prüfen ob die Etappenziele erreicht wurden: Annahme oder Ablehnung durch den

Auftraggeber. Bestandsaufnahme des Status von allen Aufgaben Zielvereinbarung für die nächste Etappe Backlog überprüfen

Tools und VorbereitungFür eine einmonatige Etappe wird in der Regel eine Obergrenze von maximal zwei Stunden festgelegt. Für kürzere Etappen kann ein kürzerer Zeitrahmen vereinbart werden. Der Coach stellt sicher, dass das Team, der Auftraggeber und andere Stakeholder bei Bedarf eingeladen werden und ein gleiches Verständnis für das Ziel und den Inhalt des Meetings haben. Für die Durchführung eines Review-Meetings können einige Methoden und Tools das Verfahren unterstützen:

Analoges oder digitales Kanban Board (z.B. Kanboard) zur schnellen übersichtlichen Anordung von Aufgaben (Statuswechsel)

Der Produkt-Backlog oder die Liste der Aufgaben, sortiert nach Priorität für das Gesamtziel des Projekts.

Vorläufige, relative Aufwandsschätzungen der anstehenden Aufgaben durch das Team (z.B. Wochenarbeitszeit).

"Definition of Done": Allgemeine Akzeptanzkriterien, die für die einzelnen Aufgaben und das Ergebnis der Etappe gelten.

Computerzugang und Beamer, ggf. weitere Präsentationsmittel (Modelle, Prototypen etc.) sowie Whiteboard oder Flipchart und Marker

EmpfehlungWer sich für einige der vielen Fallstricke und Dos und Dont's in Review-Meetings interessiert, dem sei das Video von Age of Product empfohlen. Das Video vermittelt auch ein gutes Verständnis für das Mindset bzw. die Haltung für ein Review-Meeting, allerdings mit einem Fokus auf die Arbeit von Software-Entwickler Teams.

- 34 -


https://youtu.be/L7OxBy724w4

- 35 -

https://youtu.be/L7OxBy724w4


Retrospektive Von Benjamin Höhne

Anlässe Durchführung einer Etappen-Retrospektive Moderation einer Kleingruppe Projekte mit agilen Methoden gestalten.

Ergebnisse Es wurden konkrete Vereinbarungen getroffen um die gemeinsame Zusammenarbeit zu

optimiere

ChecklisteTeam

Für welches Projektteam wird die Retrospektive durchgeführt? Für welche Etappe (Sprint) wird die Retrospektive durchgeführt?

Das lief gut! Was lief gut in der letzten Etappe?

Das soll besser werden! Was können wir verbessern? Welche konkreten Änderungen vereinbaren wir dazu für die nächste Etappe? Was brauchen wir dazu vom Coach bzw. vom P.O.?

ImpulseZiel der Retrospektive ist es, die unterstützenden und hindernden Faktoren in der individuellen Arbeitsweise und der gemeinsamen Zusammenarbeit konkret zu benennen und daraus Konsequenzen abzuleiten. Folgende Fragestellungen können dabei helfen:

Was lief gut? Welche positiven Erfahrungen haben wir im letzten Sprint gemacht? Was lief schlecht? Welche negativen Erfahrungen haben wir im letzten Sprint gemacht? Was brauchen wir an Information und besserer Kommunikation, um im nächsten Sprint

effektiver als Team zu sein? Welche Entscheidungen treffen wir für den nächsten Sprint? Was werden wir beibehalten?

Was werden wir verändern?

Je nach Dauer der Etappen, der Teamgröße und der bearbeiteten Thema ist der Zeitbedarf für eine Retrospektive sehr unterschiedlich. Der Coach oder Scrum-Master sollte sich im Vorfeld bereits überlegen ob für die Retrospektive viele Diskussionen erwartet werden können und so mehr Zeit für die "Retro" einplanen. Bei längeren Projekten kann es zusätztlich sinnvoll sein in größeren Zeitabständen ein gesondertes Meeting für eine umfangreichere Retrospektive einzuplanen. Hier

- 36 -


können dann festgefahrene, aber möglicherweise ineffektive Gewohnheiten aufgebrochen oder Teams und Verantwortungen neu zugeordnet werden.

Hilfreiche Maßnahmen für eine erfolgreiche Retro:

Moderation durch eine neutrale Person (Coach, Scrum-Master, etc.) Themen sammeln UND Maßnahmen entwickeln (Was machen wir konkret anders?) Time-Boxing für die einzelnen Themen einsetzen Externen Bedarf (Ressourcen, Personen) benennen und Verantwortlichkeiten für die

Beschaffung festlegen (von wem bis wann?)

EmpfehlungGerade für den Coach, Moderator oder Scrum-Master ist die Durchführung einer erfolgreichen Retrospektive eine Herausforderung. Die Teammitglieder sollen sich nicht nur mit den externen Problemen beschäftigen, sondern auch die Verbesserungspotentiale in ihrere eigenen Zusammenarbeit benennen und lösen.

Einige Fallstricke auf diesem Weg tauchen dabei immer wieder auf. Wer sich für einige häufige Fallstricke in der Durchführung von Retrospektiven interessiert, kann in der Podcastreihe der Scrum-Master-Toolbox einige hilfreiche Hinweise finden:

https://scrum-master-toolbox.org/tag/retrospective/

- 37 -

https://scrum-master-toolbox.org/tag/retrospective/


Planning Poker Von Benjamin Höhne

Anlässe Ein agiles Mindset für die eigene Arbeit entwickeln Projekte mit agilen Methoden gestalten. Überblick von einem Projekt gewinnen

Ergebnisse Kann Aufgaben mit der Planning Poker Methode einschätzen Kann einem Team die Planning Poker Methode vermitteln

AnwendungWie Sie das Tool nutzen könnenWenn Sie möchten, können Sie dieses Tool nutzen um im Team ihr Planning Poker durchzuführen. Jedes Teammitglied öffnet dafür diese Seite und gibt die Aufgaben ein, die Sie gemeinsam bewerten möchten. Nachdem jeder für sich den Aufwand der anstehenden Aufgaben eingeschätzt hat, können Sie sich im Team über die Unterschiede austauschen und in eine neue Runde gehen.

ImpulseBeim Planning Poker schätzen die Teammitglieder im Scrum Team gemeinsam die Komplexität und den zeitlichen Aufwand für jede Aufgabe. Dabei kommen häufig Planning Poker Karten zum Einsatz. Die Aufgabe wird vorgelesen und jedes Teammitglied zieht verdeckt eine Karte aus seinem Kartenset, mit dem der Aufwand für die Umsetzung geschätzt wird.

Wenn die Schätzungen weit auseinander liegen, müssen diejenigen Teammitglieder mit den höchsten bzw. den niedrigsten Schätzungen dies begründen. Die anderen Teammitglieder hören den Argumenten zu und überdenken ihre eigene Schätzungen. Danach wird wieder gepokert. Die Schätzungen sollten sich nun einander annähern.

Auf diese Weise werden alle Aufgaben, die im nächsten Sprint zu realisieren sind, hinsichtich ihrer Komplexität und Aufwänden geschätzt und aufsummiert. Dies ist die Anzahl an Story Points, die im nächsten Sprint vom Team realisiert werden.

- 38 -


Eine genaue Schätzung fördert eine effektive Planung, und Sie haben eine Vielzahl von Optionen bei der Wahl einer Schätzmethode. Der Schlüssel liegt darin, diejenige zu finden, die für Ihr Team am besten geeignet ist und es Ihnen ermöglicht, die hilfreichsten Sprintprognosen zu erstellen. Es gibt eine Reihe von bewährten Optionen, aus denen Sie wählen können.

Fibonacci-Sequenz0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

Sie erinnern sich vielleicht an die Fibonacci-Sequenz, eine Reihe von Zahlen, bei der jede Zahl die Summe der beiden vorhergehenden Zahlen ist. Zum Beispiel 1+2=3, 2+3=5, etc. Diese Schätzmethode verfolgt den gleichen Grundansatz, beinhaltet aber optional ½ und rundet dann die höheren Zahlen in der Sequenz ab, um den Anschein einer zu hohen Präzision zu verhindern.

Im Allgemeinen gilt: Je höher der geschätzte Aufwand, desto ungenauer die Schätzung. Eine auf 21 geschätzte Aufgabe ist nicht unbedingt genau und sicherlich weniger genau als eine auf 3 geschätzte Aufgabe. Die Abstraktion der modifizierten Sequenz erinnert sowohl die Teammitglieder als auch Product Owner daran, dass Schätzungen genau das sind, Schätzungen.

T-Shirt GrößenXXS, XS, S, M, L, XL, XXL, XXL

- 39 -


Die Gestaltung der Aufgabe als T-Shirt-Größe eignet sich gut für Projekte, die nicht mit klar zu definierenden Funktionen oder Prototypen für die Aufgaben arbeiten können. Sie erleichtern zudem den Zugang zur Einschätzung und machen einfach deutlich ob man zum Beispiel lieber vier kleinen Aufgaben fertig stellen will oder eine große Aufgabe?

Für Teams, die diese Methode neu einsetzen und ausprobieren wollen hat es zudem den Vorteil, dass die T-Shirt Größen noch nicht direkt mit bestimmten Stunden in Verbindung gebracht werden. Während 5 Aufwandspunkte schnell mit 5 Stunden oder Tagen verknüpft werden können, bietet ein "M" einfach ein relatives Gefühl der Anstrengung im Vergleich zu den anderen Geschichten. Teams können sich schneller durch die Planung bewegen, wenn sie sich auf das Gesamtbild und nicht auf kleine Details konzentrieren.

KapazitätsplanungObwohl es sich nicht unbedingt um eine aufwandsorientierte Skala handelt, kann die Kapazitätsplanung ein großartiges Werkzeug für Teams sein, die neu in der Welt der agilen Zusammenarbeit sind. Anstatt Ihr Team mit unbekannten Zeige-Skalen in das sprichwörtliche Agile Deep End zu werfen, können neue Teams die Kapazität anhand einer konkreten Maßnahme bestimmen, die jeder versteht: der Zeit.

In diesem Modell wird Ihnen die Grundrechenart gut helfen:

Stunden/Tag x Anzahl der Teammitglieder x Tage im Sprint = Sprintkapazität

Wir alle wissen, dass ein typischer Arbeitstag 8 Stunden beträgt, aber wann haben Sie das letzte Mal 8 volle Stunden im Büro gearbeitet? Ihre Berechnungen sollten Zeit für Standups, Brainstorming, Urlaub, Diensteisen und typische "Unterbrechungen" beinhalten. Die Annahme von 6-6,5 effektiven Stunden pro Teammitglied und Tag bietet einen realistischeren Ansatz für eine genaue Planung.

Nehmen wir ein fünfköpfiges Team mit einer vierwöchigen Etappe. Für dieses Projekt ist jedes Teammitglied für 1 Tag pro Woche eingeplant und wir gehen von einer effektiven Arbeitszeit von 5 Stunden pro Arbeitstag aus:

1 Stunde x 5 Personen x 20 Tage = 100 Stunden Kapazität

Ausgerüstet mit Ihrer Kapazität können Sie mit der Planung beginnen. Anstatt relative Aufwandspunkte wie die vorherigen Skalen zu verwenden, schätzt das Team die Anzahl der Stunden, die für jede priorisierte Aufgabe benötigt werden.

Denken Sie daran, dass jede Methode, die Sie wählen, Zeit und Kommunikation braucht, um sie zu beherrschen, und je neuer das Team, desto schwieriger ist es, sie richtig einzuschätzen.

Weiterführende InformationenWeitere Methoden für das Planning Poker finden Sie hier: https://technology.amis.nl/2016/03/23/8-agile-estimation-techniques-beyond-planning-poker/

Ein kurzes Erklärvideo auf englisch finden Sie hier: https://youtu.be/0FbnCWWg_NY

Über die Vorteile, Nachteile und Alternative zu Planning Poker: https://www.extremeuncertainty.com/alternatives-planning-poker/

- 40 -

https://www.extremeuncertainty.com/alternatives-planning-poker/

https://youtu.be/0FbnCWWg_NY

https://technology.amis.nl/2016/03/23/8-agile-estimation-techniques-beyond-planning-poker/

https://technology.amis.nl/2016/03/23/8-agile-estimation-techniques-beyond-planning-poker/


Burn Down Chart Von Jörg Longmuß

AnlässeSie wollen kontinuierlich visualisieren,

wie viel Aufwand für das Erledigen eines Vorhabens noch nötig ist, wie schnell es vorankommt und wann es voraussichtlich abgeschlossen sein wird.

ErgebnisseEs werden deutlich:

Der Aufwand, der für die Erledigung eines Vorhabens noch nötig ist Das Tempo, in dem die Arbeit vorangeht Der Arbeitsstand (vor oder hinter der Planung)

Das Burn Down ChartEin „Burn Down Chart“ visualisiert die noch zu leistende Arbeit zu einem Stichtag und zeigt, was ein Team noch schaffen muss, um das geplante Ziel zu erreichen. Es eignet sich gut für (Teil-) Vorhaben, deren Aufwand relativ gut quantitativ zu bestimmen ist, z.B. in Stunden, Tagen, Storypoints, Menge der offenen Punkte etc. Es ermöglicht, kontinuierlich

abzuschätzen, wie lange die Arbeit bei gleichmäßiger Belastung dauern wird; den erreichten Fortschritt zu jedem Zeitpunkt zu deutlich zu machen; zu sehen, ob ein Team vor dem Zeitplan ist oder dahinter zurückliegt.

Ein Burn Down Chart kann z.B. so aussehen

Quelle: Wikipedia

Auf der senkrechten Achse wird der Umfang der Arbeit eingetragen, der zu Beginn einer Periode geschätzt wird. Die waagerechte Achse ist die Zeitleiste und zeigt Tage an. Der Nullpunkt ist der

- 41 -


Starttag. Der Tag, an dem die Arbeit voraussichtlich erledigt ist, ist der Endpunkt. Es gibt zwei Möglichkeiten, diesen Endpunkt zu bestimmen:

Er kann von außen vorgegeben sein, z.B. ein Liefertermin. Dann können Sie an dem Burn Down Chart ablesen, wieviel Sie jeden Tag schaffen müssen, um zu diesem Zeitpunkt fertig zu sein (termingetreue Planung).

Sie können ihn errechnen, indem Sie den erforderlichen Aufwand durch die pro Tag durchschnittlich zur Verfügung stehende Zeit teilen (ressourcengetreue Planung).

Dann werden der Start- und der Endpunkt mit einer Linie verbunden, die den idealisierten Verlauf der Abarbeitung zeigt.

In Beispiel oben wird am Starttag ein Aufwand von 28 Arbeitstagen für das Vorhaben geschätzt. Wenn 2 Teammitglieder daran jeden Tag mit 70 % ihrer Arbeitszeit arbeiten (also pro Tag Aufgaben im Umfang von 1,4 Arbeitstagen bewältigen), brauchen sie bis zum Ende des Vorhabens 20 Tage – sie haben also ressourcengetreu geplant. Eine idealisierte Abarbeitung würde mit der blauen Linie übereinstimmen.

Nun wird jeden Tag aufgetragen, wieviel Arbeit noch zu tun ist. Dies entspricht dem nach vorne gerichteten Denken bei der => Meilenstein-Trendanalyse: Zu fragen, wieviel Arbeit noch zu erledigen ist und wie lange das voraussichtlich dauern wird. Der Stand der Arbeit wird dabei in aller Regel nicht mit der idealisierten Linie übereinstimmen, sondern darüber hinausgehen oder dahinter zurückbleiben.

Die Abarbeitung wird also gemessen, indem jeden Tag wieder nach der zu leistenden Arbeit bis zur Fertigstellung gefragt wird („Time to Completion“). Im Beispiel liegen die Schätzungen für den Aufwand, der noch zu leisten ist, am Anfang und am Ende der Bearbeitungszeit über und in der Mitte unterhalb der idealisierten Annahme zu Beginn. Das Ende wurde dennoch planmäßig erreicht.

VariantenDas Burn-Down-Chart gibt es in zwei Varianten:

Ein Sprint Burn Down wird zur Verfolgung des Fortschritts innerhalb eines Sprints verwendet. Das Team aktualisiert das Sprint Burn Down im täglichen Stand Up Meeting. Wenn die einzelnen Aufgaben ungefähr die gleiche Größe haben und nicht übermäßig aufwendig sind (nicht länger als ein bis zwei Tage), kann der zu leistende Aufwand statt in Stunden oder Tagen auch direkt in Aufgaben angegeben werden. Das vereinfacht die Verfolgung des Fortschritts.

Ein Release Burn Down wird zur Verfolgung eines Vorhabens über mehrere Sprints hinweg verwendet. Hierbei wird auf der horizontalen Achse der Zeitverlauf in Sprints und auf der vertikalen Achse die Anzahl der noch zu erledigenden Aufgaben aufgetragen. Ändert sich der Umfang des Vorhabens, so springt die Zahl der offenen Aufgaben in diesem Umfang nach oben oder unten. Bei jedem Sprint aktualisiert der Product Owner das Release Burn Down. Mit dessen Hilfe kann der Product Owner Umfang und Abschluss des Vorhabens abschätzen.

- 42 -


Voraussetzungen für ein Burn Down ChartDie Größe und der Detailgrad der Tasks müssen angemessen sein:

Der Umfang der Tasks sollte nicht zu groß sein, damit Entwickler den Restaufwand realistisch schätzen können. Daher müssen Sie Ihre User Storys in einer geeigneten Anzahl an Tasks herunterbrechen. In großen Scrum-Projekten führt dies zu einer hohen Menge an Anforderungen, die verwaltet werden müssen. Um diese Herausforderung zu bewältigen, setzen Sie am besten eine Software ein.

Der Restaufwand ist nicht der bereits erbrachte Aufwand:

Sie müssen jeden Tag den Restaufwand eines Task neu schätzen. Wenn Sie zum Beispiel am Mittwoch feststellen, dass der Aufwand doch noch größer ist, als am Montag geschätzt, dann geben Sie diesen höheren Restaufwand an. Wie viel Aufwand Sie bereits erbracht haben, spielt für die Restaufwandsschätzung im Burn Down Chart keine Rolle.

Der Restaufwand muss täglich erfasst werden

Das Burn Down Chart fordert von den Entwicklern, ihren Restaufwand täglich am Ende des Arbeitstages zu schätzen. Dementsprechend müssen diese diszipliniert dieser Aufgabe nachgehen, damit das Burn Down Chart den tatsächlichen Stand im Sprint wiedergibt.

BesonderheitenDer geleistete Aufwand wird nicht dargestellt! Wenn also der Aufwand für die Aufgaben nicht korrekt abgeschätzt wurde, gibt das Burn Down Chart dies nicht unmittelbar wieder. Dies wird nur indirekt deutlich: Wurde der Aufwand überschätzt, wird das Team dem in der Planung angenommenen Arbeitsstand in der Regel voraus sein. Wurde er deutlich unterschätzt, wird es ständig hinter der Planung herhinken.

Es kann sich also lohnen, parallel den Umfang der geleisteten Arbeit festzuhalten, um zu erkennen, wie realistisch die Schätzung war. Das erlaubt hinterher eine Überprüfung, ob es systematische Abweichungen bei den Schätzungen gab. Wenn ja, muss dies beim Erstellen weiterer Burn Down Charts berücksichtigt werden.

Aufgabe Wählen Sie eines Ihrer aktuellen Vorhaben aus, das Sie vom Umfang her ungefähr

überblicken Schätzen Sie so sorgfältig wie im Augenblick möglich ab, wieviel Aufwand damit verbunden

ist – gemessen in Arbeitsstunden, Arbeitstagen, Aufgabenpaketen o.ä. – und markieren Sie damit den Startpunkt auf der senkrechten Achse.

Entscheiden sie sich für eine termingetreue oder für eine ressourcengetreue Planung und legen Sie den Endtermin fest.

Erstellen Sie ein Burn Down Chart zu diesem Vorhaben und zeichnen den idealisierten Ablauf als eine Gerade zwischen Start- und Endtermin.

Tragen Sie jetzt bei jedem Stand Up-Meeting im Team ein, wieviel Arbeit sie noch vor sich haben.

- 43 -


Haben Sie noch wenig Erfahrung mit Abschätzungen bei dieser Art Vorhaben, halten Sie bitte zusätzlich jeweils fest, wieviel Arbeit Sie seit dem letzten Eintrag im Chart hatten. Vergleichen Sie, ob die Abnahme der noch zu leistenden Arbeit, wie sie im Chart abzulesen ist, jeweils der tatsächlich geleisteten Arbeit entspricht.

Halten Sie zum Ende des Vorhaben fest, wie sehr die ursprüngliche Abschätzung dem tatsächlichen Verlauf entsprochen hat.

Links Eine detaillierte Darstellung von Anforderungen an ein Burn down Chart und Varianten des Einsatzes finden sich unter Wikipedia: https://de.wikipedia.org/wiki/Burn-Down-Chart

Interessant ist auch: https://www.microtool.de/wissen-online/

- 44 -

https://de.wikipedia.org/wiki/Burn-Down-Chart


Cumulative Flow Chart Von Jörg Longmuß

Anlässe

Einen Überblick bekommen, in welchem Status die Aufgaben im Vorhaben sind Abschätzen, zu welchem Zeitpunkt das Vorhaben beendet werden kann

AufgabeFassen Sie in einer Grafik zusammen,

welchen Umfang die Aufgaben der gegenwärtigen Etappe haben welchen Status (offen, in Bearbeitung, in Prüfung, erledigt) sie an jedem Tag haben ob beim gegenwärtigen Tempo das Etappenziel erreicht werden kann

Transparenz in der Arbeit

Bei der Arbeit an einem Vorhaben soll der Stand der Arbeit für alle Beteiligten (Team, Product Owner und sonstige Stakeholder) transparent sein: Was soll getan werden? Wie viel wurde bereits bearbeitet? Wie viel Arbeit ist noch offen? Wann könnte das Vorhaben abgeschlossen sein?

Um die Antwort auf solche Fragen leicht verständlich zu machen, empfiehlt sich eine grafische Darstellung. Als Darstellung des Arbeitsstandes und des voraussichtlichen Endes des Vorhabens gibt es aus dem klassischen Projektmanagement z.B. die => Meilenstein-Trendanalyse und im Scrum das => Burn Down Chart. Diese Grafiken sind relativ einfach zu erstellen und zu lesen. Allerdings geben sie keine Auskunft über das Tempo der Bearbeitung oder den genauen Status der Aufgaben.

Eine aussagekräftige Grafik: Das Cumulative Flow Chart

Besonders in Kombination mit der Arbeit mit einem => Kanban Board gibt es ein weiteres Chart, das hier aussagekräftiger ist, das Cumulative Flow Chart. Es zeigt in einer Übersicht, wie viele Aufgaben noch offen (d.h. im => Backlog) sind, wie viele gerade bearbeitet werden und wie viel noch geprüft bzw. abgenommen werden müssen, außerdem den Umfang der bereits erledigten Arbeiten.

Dazu wird auf der senkrechten Achse die Gesamtheit der Aufgaben aufgetragen, und zwar an jedem Tag (oder einem sonstigen Berichtszeitpunkt) jeweils unterschieden danach, welchen Status die Aufgaben gerade haben (Backlog, in Arbeit, in Prüfung, erledigt). Dabei werden die einzelnen Werte addiert. Die Gesamtsumme kann sich dabei nur ändern, wenn neue Aufgaben hinzukommen (bzw. von der Liste gestrichen werden). Auf der waagerechten Achse tragen Sie die Dauer der Etappe auf, z.B. in Tagen. Zum Ende der Etappe müssen dann

- 45 -


– vorausgesetzt die Arbeit wird vollständig abgeschlossen – alle Aufgaben als „erledigt“ eingetragen sein.

In der Beispielgrafik wurde die Arbeit gestartet, als sich im Backlog Aufgaben im Umfang von zunächst 60 Stunden befanden. Nach einigen Tagen kamen 10 Stunden hinzu, und wenig später noch einmal 10 weitere. Am Tag „0“ waren alle diese Aufgaben im Backlog. Jeden Tag wurden von dort einige Aufgaben in Bearbeitung genommen, später zur Prüfung vorgelegt und endlich als erledigt gekennzeichnet. Das blaue Feld zeigt dabei, was noch nicht begonnen wurde. Das grüne Feld zeigt die Aufgaben in Bearbeitung an, das gelbliche noch zu prüfenden Aufgaben und das rote, was erledigt ist. Am 16. Tag waren schließlich alle Aufgaben abgearbeitet, die ursprünglich im Backlog waren.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 160

10

20

30

40

50

60

70

80

Cumulative Flow Chart

Erledigt In Prüfung In Arbeit Im Backlog

So können Sie erkennen,

wie viele Aufgaben sich in welchem Status befinden: „“Was haben wir noch nicht begonnen, was ist unterwegs, was ist bereits geschafft?“

wie zügig die Arbeit vorangeht: „Wie viele Aufgaben werden jeden Tag begonnen, wie viele erledigt?“

ob das Tempo bleiben kann, wenn zum Ende der Etappe alles fertig sein soll: „Kommen wir bei dieser Geschwindigkeit zum Ziel?“

wo der Ablauf möglicherweise Mängel hat, z.B. „Warum werden nur in größeren Abständen neue Aufgaben begonnen?“, „Warum sind sie so lange in Arbeit?“, „Warum dauert es so lange, bis die Prüfung abgeschlossen ist?“

Links zur Vertiefunghttps://www.microtool.de/wissen-online/was-ist-ein-cumulative-flow-diagram/

… mit ausführlichen Hinweisen, wie ein Cumulative Flow Chart interpretiert und analysiert werden kann.

- 46 -

https://www.microtool.de/wissen-online/was-ist-ein-cumulative-flow-diagram/


http://brodzinski.com/2013/07/cumulative-flow-diagram.html

- 47 -

http://brodzinski.com/2013/07/cumulative-flow-diagram.html


Meilenstein-Trend-Analyse Von Jörg Longmuß

Anlässe Überprüfung, ob ein Vorhaben im Zeitplan liegt Eine Prognose über das Erreichen wichtiger Meilensteine (Konzeptabgabe, Zwischenbericht,

Fertigstellung, …) geben Ein verzögertes oder schwieriges Vorhaben stabilisieren

Ergebnisse Hat einen besseren Überblick über die (zeitliche) Entwicklung im Vorhaben Kann einen Abschnitt des Vorhabens vom Ende her betrachten Kann proaktiv erforderliche Maßnahmen / Änderungen einleiten

Aufgabe 1Denken Sie an ein Vorhaben, mit dessen Ablauf Sie vertraut waren und notieren Sie:

Hat es Verschiebungen von Zwischen- und Endterminen gegeben? Ab wann wären die Verschiebungen absehbar gewesen? Wann, wo und wie haben Sie von den Verschiebungen erfahren? Sind alle korrigierenden Maßnahmen so rechtzeitig eingeleitet worden, wie es möglich

gewesen wäre?

Wenn Sie denken, dass mit es mehr Vorausschau auch bessere Möglichkeiten des Eingreifens gegeben hätte, sollten Sie diese Lernkarte durcharbeiten.

AusgangspunktIn Vorhaben wird oft hauptsächlich gefragt, ob die Arbeit im Zeitplan liegt. Diese Frage kann aber leicht in die Irre führen oder zumindest ein unvollständiges Bild zeichnen von der aktuellen Situation. Gründe dafür können sein:

Zwar liegt die Arbeit aktuell im Zeitplan, aber es sind bereits Verspätungen absehbar (z.B. längere Abwesenheit von Schlüsselpersonen, Lieferschwierigkeiten von Zuarbeitern, …) => Verzögerungen

Die Anforderungen an Arbeiten, die noch in der Zukunft liegen, haben sich erweitert => Verzögerungen

Es werden zusätzliche Ressourcen erhältlich sein => Beschleunigung

Die Anforderungen an Arbeiten, die noch in der Zukunft liegen, verringern sich => Beschleunigung

Wichtiger als die Frage, ob ein Vorhaben aktuell im Zeitplan liegt, ist also, wann das Vorhaben seine Zwischen- und Endziele erreicht haben wird!

- 48 -


Vorgehen Festhalten, wann ein Vorhaben beendet sein muss bzw. ein wichtiger Zwischenstand erreicht

sein muss (Übergabe an die Fertigung, Auslieferung, …) Festlegen von Meilensteinen, an denen dafür wichtige Zwischenstände erreicht sein müssen

(Konzeptabnahme durch den Kunden, Vorlage zur Genehmigung, …). Festlegen von Verantwortlichen für jeden Meilenstein In regelmäßigen Abständen, z.B. in jeder Sprintreview, wird der Verantwortliche gefragt,

wann diese Meilensteine nach heutigem Kenntnisstand erreicht sein werden. Zeichnen sich Verschiebungen ab, können sofort Maßnahmen ergriffen werden.

Grafische AufbereitungDie Meilenstein-Trendanalyse eignet sich sehr für eine grafische Aufbereitung. Dabei werden auf der einen Achse in den Zeitstrahl die Meilensteine eingetragen. Auf der anderen Achse wird bei jeder Sprintreview die aktuelle Prognose für jeden Meilenstein eingetragen. Dadurch werden Verschiebungen schnell deutlich sichtbar.

Grafik 1

Im Beispiel von Grafik 1 wurde für den 1. Meilenstein der 1. Februar festgelegt, für den 2. Meilenstein der 1. April und für das Projektende der 15. Juni. Dann wurde alle halben Monate die Prognose abgefragt. Bei der ersten Review gab es noch keine Verschiebung, bei der 2. Review am 1.

- 49 -


Februar hätte der 1. Meilenstein erreicht sein müssen, prognostiziert war statt dessen ca. der 10. Februar. Der 2. Meilenstein hatte sich parallel ebenfalls um einige Tage verschoben, das Projektende aber nicht. Bei der 3. Review war der 1. Meilenstein erreicht. Der 2. Meilenstein hatte sich noch etwas weiter verschoben und das Projektende jetzt auch, allerdings nur um wenige Tage. So lässt sich über die Zeit gut ablesen, ob und wie sich das Vorhaben in der Zeit verändert hat.

In Grafik 2 sind die Achsen vertauscht, aber das Prinzip: Eintragen und Verfolgen von Meilensteinen, bleibt gleich. Hier wird deutlich, wie Verschiebungen nach hinten und vorne aussehen. Bildet der Graph eine gerade Linie, hat sich der Meilenstein über die Laufzeit nicht verschoben.

Grafik 2

Vorteile der Meilenstein-Trendanalyse Die Meilenstein-Trendanalyse fordert ein Vorausschauen heraus. Die Verantwortlichen

müssen nicht nur über den aktuellen Stand nachdenken, sondern auch über absehbare und mögliche Verschiebungen in der Zukunft. Diese werden für alle an der Review Beteiligten deutlich. So lassen sich auch wechselseitige Abhängigkeiten besser klären.

Dies ermöglicht eine proaktive Steuerung des Vorhabens. Erforderliche neue Aktivitäten und Maßnahmen können sofort ins Backlog aufgenommen werden und bei Bedarf Prioritäten geändert werden.

Wenn der Graph gerade verläuft, war die Prognose belastbar. Verschiebt er sich, waren bei der Planung nicht alle Faktoren im Blick. Daraus können Lehren für die Zukunft gezogen werden.

Wenn ein Verantwortlicher über lange Zeit erklärt, dass ein Meilenstein stabil wäre, und dieser dann kurz vor Erreichung immer wieder nach hinten verschoben werden muss, fordert

- 50 -

Projektfortschritt real

geplanteMeilensteine

MS 1

MS 2

MS 3‘2

02019

2020

2019

123456789101112123456

1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8

Monat


dies Ursachenforschung heraus: War die Abweichung wirklich unvermeidbar, weil z.B. eine wichtige Person überraschend ausgefallen ist, oder sind Warnzeichen ignoriert worden?

Aufgabe 2Stellen Sie bitte für eines Ihrer aktuellen Vorhaben ein Chart auf, in das die wichtigsten Meilensteine eingetragen sind (Achtung: Ein Zuviel an Meilensteinen macht ein Vorhaben eher schwerfällig und unübersichtlich – beschränken Sie sich!).

Listen Sie auf, an welchen Punkten Sie am ehesten Verschiebungen erwarten.

Wenn möglich, datieren Sie das Chart zurück: Wie waren die Vorstellungen zu Beginn, was hat sich im Laufe des Vorhabens bis jetzt schon geändert?

VideoEin recht gutes Video zur Erstellung einer Meilenstein-Trendanalyse findet sich unter

https://www.youtube.com/watch?v=k3neYhan6Ts

LiteraturZ.B. Drews, G. & Hillebrand, N. (2007); Lexikon der Projektmanagement-Methoden; Rudolf Haufe Verlag München

- 51 -

agile-learning.eu · web viewagiles arbeiten im team verlangt von allen beteiligten konzentration...

Documents