PRINCE2 Agile® Foundation

Erstellt und pflegt eine geschäftliche Rechtfertigung für das Projekt. Stellt sicher, dass die Projektergebnisse erreicht und die Vorteile realisiert werden. So werden u.a. wesentliche Risiken und der Ansatz zur Messung des erwarteten Nutzen dokumentiert.

Zweck:

• Einrichtunng geeigneter Mechanismen, für die Beurteilung ob ein Projekt realisierbar und erreichbar ist (und bleibt).
• Auf dieser Grundlage wird über weitere Investitionen entschieden.
•  Anforderungen auf hoher Ebene oder (eventuell) mittlerer Ebene definieren

"Warum?"

Definiert die Projektorganisationsstruktur und die Rollen. Definiert den Ansatz zur Kommunikation und Interaktion mit Stakeholdern.

Definiert den Projektqualitätsmanagement-Ansatz. Gibt priorisierte Akzeptanzkriterien für das/die endgültige(n) Projektprodukt(e) an.

Bedingungen zur Nutzbarkeit des Produkts.

• Qualitätsmanagement (Tools und Techniken)
• Qualitätsplanung (Wie durchführung im Vorfeld, wie Kunde einbeziehen, Customer SME vertritt breitere Kundensicht)
• Testen (frühes Testen, je später desto teurer, welche Testkonzepte)

Durch das zur Verfügung stellen einer vollständigen Dokumentation trägt zur Sicherung des Qualitätsniveaus bei.

Qualitätstoleranzen werden am besten auf Basis der Priorisierung der Kriterien festgelegt.

Pläne ermöglichen die Realisierung des Business Case.
Empfiehlt verschiedene Planebenen, um die Kommunikation und Kontrolle aus den unterschiedlichen Perspektiven der Projektorganisation zu erleichtern. 

- Zweck: Ansätze zur Lieferung von Produkten kommunizieren
- Planung kollaborativ durch Teambeteiligung
- Planung auf unterer Ebene möglichst spät JIT (Just in time), was Fehlerquote und Aufwand senkt
- Planung aufgrund Agiler Schätzung und Empirie (nicht Rationalismus) 
- Planungsbasis Features oder Feature-Gruppen
- Formulierung der Features als Anforderungen oder User Storys
- Wichtig: Retrospektiven, Kaizen (kontinuierliche Verbesserung), Stabile Teams die für Fortschritte sorgen (Velocity)- Fokus auf Features

Produkte:

1. Beschreibung des Projektprodukts: Eine Beschreibung der Gesamtleistung des Projekts.
    
2. Produktbeschreibung: Eine Beschreibung des Zwecks eines jeden Produkts, Zusammensetzung, Ableitung und Qualität.
    
3. Produktstrukturplan: Eine Hierarchie aller Produkte, die im Rahmen eineswährendeines Plans produziert werden.
    
4. Plan: Gibt eine Erklärung darüber ab, wie und wann die Ziele erreicht werden sollen

Zweck:

• Unsicherheiten zu identifizieren, zu bewerten und zu steuern und dadurch die Erfolgschancen des Projekts zu erhöhen.

Wie geht PM mit "Was, wenn?" um.

Genauer
===

Definiert den Risikomanagementansatz und stellt sicher, dass Projektrisiken identifiziert, bewertet und kontrolliert werden. Änderung Definiert den Änderungssteuerungsansatz und stellt sicher, dass Probleme erfasst, bewertet und kontrolliert werden.

Risikomanagement in PRINCE2 Agile sollte sich nach den Anforderungen des Projekts richten.

Im Daily Stand-up-Meeting werden Issues besprochen. Aus Issues können Risiken entstehen.

Im Vorfeld können einige Risiken schon vermieden werden durch die Priorisierung von Anforderungen (MoSCoW). Risikominderung vermindert Riskiken und Konsequenzen.

Definiert den Änderungssteuerungsansatz und stellt sicher, dass Probleme erfasst, bewertet und kontrolliert werden. 

Zweck: 

• "potenzielle und genehmigte Änderungen an der Baseline zu identifizieren, zu bewerten und zu steuern."

"Was sind die Auswirkungen?"

Dieses Thema befasst sich mit bereits eingetretenen Problemen
1. Spezifikationsabweichungen
2. Probleme/Bedenken
3. Änderungsanträge

Hohe Ebene: Auswirkung auf die Baseline mit potenziell negativen Auswirkungen auf das Projekt.
Mittlere Ebene: Evtl. Auswirkungen auf Baseline.
Detailebene: Auswirkungen sind i.d.R. positiv, da Team dynamisch und selbstorganisiert im Rahmen des Umfangs und der Qualitätstoleranzen handelt- Tangieren nicht die Baseline. (zB. eine could-Anforderung weglassen)

Genauer
===

Im Falle von Detailänderungen: Erfassen, Bewerten, Vorschlagen, Entscheiden, Implementieren
Für bedeutendere Änderungen gleiches Verfahren, aber mit Eskalation bis zum zun Lenkungsausschuss oder der Änderungsinstanz.

Prince2 Agile befasst sich in erster Linie mit Änderungsanträgen und ist sehr änderungsfreundlich.

Prince2: "Nichts bewegt sich, nichts ändert sich mehr ohne Genehmigung." Änderungen also gerne, aber nur wenn Sie gesteuert werden. Außerdem sollte der Nutzen die Kosten und Risiken überwiegen.

Überwachen des Liefergegenstandes steht im Vordergrund. Definiert die Art und Weise, wie der Projektfortschritt gemessen und mit den Leistungszielen verglichen wird. Der Fortschritt ermöglicht eine Prognose der weiteren Projektdurchführbarkeit.

Überwachen des Liefergegenstandes steht im Vordergrund.

Zwecke:

• Schaffung eines Systems für die Überwachung der tatsächlich erbrachten Leistungen und deren Vergleich mit den Planzielen
• Prognose hinsichtlich der Projektziele und der weiteren Realisierbarkeit des Projekts
• Steuerung inakzeptabler Abweichungen.
• Festlegen von Toleranzen und Steuerung nach dem Ausnahmeprinzip anhand der Toleranzen
• Prüfen der geschäftlichen Rechtfertigung, wenn Ausnahmen gemeldet werden
• Lernen aus Erfahrung

"Wo stehen wir" Wo gehen wir hin? Sollen wir weiter machen"

Genauer
===

Prince2
- Fasst Steuerelemente für die verschiedenen Managementphasen zusammen
- Konzepte Toleranz und Ausnahmen werden erwähnt
- Ereignisorientierte Natur von P2 wird hervorgehoben
- Zeitgesteuerte Projekt- und Teamstatusberichte
Bsp. Verfolgung von Zeit und Kosten mittels Gant-Diagramm. Vorgabe ist % Umfang zu liefern.

Agile
- Fokus auf Lieferebene
- Eher Zeitgesteuert
Bsp.: Muss Kosten und Zeit nicht verfolgen, da vorab festgelet. Umfag dafür flexibel. Daher müssen tatsächlich gelieferte Werte verfolgt werden.

Prince2 Agile
Definiert den Begriff Fortschritt: "Wie überwachen wir, wie wir im Vergleich zum Plan vorankommen?"

• Burn-down Charts
• Burn-up Charts
• Information Radiators (z.B. BurnCharts, Kanban, WiP-Board, digitales Teamboard)
• Stabile Teams

Plan - Do - Check - Act (Bekannteste)

Planen - Delegieren - Planen - Steuern (Prince2)

Observe - Orientate - Decide - Act (OODA-Schleife)

Zeigen die bereits erledigte, sowie die noch zu erledigende Arbeit an.

zeigt den Fortschritt der noch ausstehenden Arbeit über die Zeit

Y-Achse = noch ausstehende Arbeit
X-Achse = Zeit

Wird genutzt wenn das Arbeitsvolumen innerhalb Timebox vorab festgelegt ist. Umfang wird angepasst durch Zerlegung des Umfangs von Aufgaben (Kies).

Zeigt wieviel Arbeit in einer Timebox noch zu erledigen ist. (Gesamtarbeit - Geleistete Arbeit)

Zeigt den Gesamtfortschritt des Projekts über die Zeit. 

Y-Achse = Menge der abgeschlossenen Arbeiten
X-Achse = Zeit

Wird genutzt wenn das Arbeitsvolumen innerhalb Timebox sich ändern kann. Das Diagramm zeigt Arbeiten die hinzugekommen oder entfallen sind. 
Könnte für einen Plan auf höherer Ebene funktionieren. Z.B. für einen Phasenplan.

Gibt an welche Aufgaben und Arbeiten von den Projektbeteiligten zu erledigen sind.

Diagramm mit sofort zugänglichen Informationen, wie Risiken und Issues, Qualität und Defekten, Visionen, Arbeitspraktiken etc.
Es sollten idealerweise besser einfache "Low-Tech"-Methoden zur Erstellung und Aktualisierung verwendet werden.

Teammitglieder aktualisieren diese Borads und verschieben ToDos von links nach rechts bis sie auf erledigt stehen.

Beispiele:
- BurnCharts
- Kanban
- WiP-Board (Push - wenn PM dem Daily Standup beiwohnt), 
- digitales Teamboard (Pull - da ggf. Projektbericht persönlich erfragt werden muss)

SU - Vorbereiten eines Projekts
IP - Initiieren enes Projekts
CS - Steuern einer Phase
MP - Managen der Produktlieferung
SB - Managen eine Phasenübergangs
CP - Abschließen eines Projekts
DP - Lenken eines Projekts

Was Sie möglicherweise vorfinden:

• In unreiferen agilen Umgebungen: Evtl. Nutzung des Konzepts emergente Praxis.
• In reiferen agilen Umgebungen: Sprint Zero (nicht Teil von Scrum, sondern von Teams geschaffen), evtl. Produktvision die an das Konzept Agile-Chartering anknüpft.

Was zu tun ist:

• Komplexitätsniveau der Umgebung mittels KUNEWIND untersuchen
• Agilometer zur Risikobewertung und Eignung von Agile
• Produkte auf hoher Ebene definieren: Ohne Details - reiner Fokus auf Ergebnisse und Nutzen
• Projektplan durch Team (Übersicht für Lenkungsausschuss): Format i.d.R. Gantt-Diagramm oder Produkt-Backlog
• Projektproduktbeschreibung 
• Nutzen-Management-Ansatz
• Business Case
• Risiken
• Bei der Vorbereitung zeigt sich, dass P2 vorhersagbar ist aber auch emergent sein kann.
• Bei der initiierung findet zum ersten Mal Releaseplanung statt.

Wie es aussehen könnte

• Einbindung des Kunden persönlich in Workshops
• Eher Präsentation des Nutzen-Management-Ansatzes statt nur schriftlich

Stellt sicher, dass ein Projekt den beabsichtigten Nutzen für die Organisation langfristig liefert.  

===
Schritt 1. Festlegung der Nutzenziele
in Form von KPIs oder quantitativen Zielvorgaben. 

Schritt 2. Identifizierung der Maßnahmen
um die definierten Nutzenziele zu erreichen. 

Schritt 3. Bewertung der Nutzen

Schritt 4. Umsetzung der Maßnahmen
Die identifizierten Maßnahmen werden umgesetzt, um den erwarteten Nutzen zu realisieren. 

Schritt 5. Nachverfolgung und Überwachung des Nutzens

Dinge zeigen sich erst wenn man mit der Arbeit beginnt.  (Teil von Scrum)

Projekt-Charter die Informationen über das Projekt in sehr einfacher Auflistungsform festhält. Äquivalent in P2 ist die Projektleitdokumentation.

Was Sie möglicherweise vorfinden

Unreife Umgebungen: Rolle PO gibt die Richtung vor, welche auch ToDo-Liste oder Product-Backlog vorgibt.

Reife Umgebungen: Evtl. Einführung "Sponsor" oder "Big Boss" der Entscheidungen trifft. P2 Agile Lenkungsausschuss wäre vorteilhaft. Evtl. bereits ähnliche Struktur vorhanden mit Vertretern von Kunden und Lieferanteninteressen. Dann ist es fraglich ob die Integration von P2 Agile von nutzen wäre.

Was zu tun ist

Lenkungsausschuss muss sicherstellen dass das Konzept "Steuern nach dem Ausnahmeprinzip" funktioniert. Er liefert Entscheidungen und weist die Richtung die bei "Steuern nach dem Ausnahmeprinzip" benötigt wird.

- Vertrauen ins Agile Team zeigen (Team-Handhabung über Toleranzüberschreitungen die Ausnahmen auslösen,...)

- Kultur in der das Projekt angesiedelt ist beurteilen und verbessern (Schuldzuweiseungen, unpersönliche Kommunikation,...)

- Teilnahme an Demos

- Werte prüfen nach Releases (wie viel wurde geliefert)

- Informationen ziehen bei Bedarf (Information Radiators, Burncharts...)

- Information durch PM persönlich und weniger formell

Zweck: Den Lenkungsausschuss in die Lage zu versetzen, seiner Rechenschaftspflichtigkeit für den Projekterfolg nachzukommen. Dies geschieht, indem er wichtige Entscheidungen fällt und als oberste Steuerungsinstanz agiert, aber die Abwicklung des Tagesgeschäfts dem Projektmanager überlässt.

Ziele, sicherzustellen dass:

1. die Befugnisse vorhanden sind für die Initiierung, die Lieferung der Projektprodukte, den Abschluss des Projekts 
2. das Projekt während seiner gesamten Laufzeit gelenkt und überwacht wird;
3. die Realisierbarkeit des Projekts gewährleistet bleibt;
4. eine Schnittstelle zum Unternehmens- bzw. Programmmanagement oder zum Kunden vorhanden ist;
5. Pläne für die Realisierung des angestrebten Nutzens über den Projektabschluss hinaus gemanagt und geprüft werden.

Zweck:

• Beziehung zwischen dem Projektmanager und dem/den Teammanager(n) zu steuern, indem die Anforderungen an Abnahme, Ausführung und Lieferung der Projektarbeit festgelegt werden.
• Erstellung Teamplan
• Abnahme  Arbeitspakete vom Teammanager

Was Sie möglicherweise vorfinden

P2: Spezialisten managen - Arbeiten annehmen, ausführen, abliefern.
Agile: Ablieferung ist Hauptfokus. Durch die agilen Techniken gibt es einiges zu managen, was sich aber auf die Schnittstelle zum Bereich Produktlieferung bezieht, nicht nicht auf das managen der Teammitglieder, was die Aufgabe des Teammanagers ist.

Was zu tun ist

• Kernstück der Schnittstelle kollaborativ erstellte Arbeitspakete
• PM legt Formalität der Berichterstattung bei Erstellung der Arbeitspakete fest
• Zeit und Kosten
• PM legt Umfangtoleranzen fürs Team fest
• Weitere Flexibilität durch Qualitätstoleranzen
• Im Anhang Produktbeschreibungen auf hoher Ebene (Beschreibungen grob) aus der ggf. UserStorys auf niedriger Ebene formuliert werden.
• PM legt fest wie Risiken gehandhabt und eskaliert werden
• Tägl. Stand-up als wichtige Plattform
• PM stellt benötigte Infos zu Releases und üparallel arbeitenden Teams

Wie es aussehen könnte

Das Lieferteam muss den gesamten Projektkontext verstehen:

• Konzept "Steuern nach dem Ausnahmeprinzip"
• Wissen wo Rolle des PM beginnt und endet
• Warum Ausschuss darüber hinaus Entscheidungen treffen muss
• Die Art der Berichterstattung sollte vereinbart werden
• Teamstatuskontrolle oder aktualisierung des Qualitätsregisters
• Teamstatusberichte an PM z.B. mündl. oder per Word
• Üblich wäre in P2 das verfassen des Arbeitspakets durch den PM, der sich wiederum mit dem TM abspricht
• TM bereits bei Erstellung des Phasenplans (Features) involviert
• Team kann auf Detailebene in der Sprint-Planung verhandeln.

Definition: "Abschnitt des Projets, der im Auftrag des Lenkungsausschusses von einem Projektmanager ausgeführt wird."

Nach Genehmigung kann PM Arbeitspakete mit Spezialistenteams vereinbaren.

Was Sie möglicherweise vorfinden

Eine Phase könnte aus mehr als einem Release bestehen.

Bei mehreren Teams könnten einige "Scrum of Scrums" einsetzen. (Nicht Teil des Scrum-Frameworks. Fördert Kommunikation, erfordert aber immer noch einen PM zur Steuerung)

Was zu tun ist

- Phasenplan basiert auf Features(-Gruppen), nicht auf traditionellen Gantt-Diagramm-Aktivitäten

- Gemeinschaftliche mit den Spezialistenteams ...
  ...Arbeitspakete erarbeiten
  ...Zeit und Kosten festlegen 
  ...Toleranzen für Umfang und Qualität definieren

- Ermutingung Team zur Selbstorganisation auf Detailebene

- Sammeln von Informationen und Projektstatusberichte erstellen

- Teilnahme an Daily Stand-Ups

- Risikoüberwachung auf Basis des Agilometers

Wie es aussehen könnte

- Überwachung kooperativer Teamarbeit
- Ermutigung des Teams zum Einsatz visueller Kommunikationsmittel
- Ermutigung des Teams selbst zu überprüfen und anzupassen (Stand-Ups, Reviews, Retrospektiven)
- Stand-Up beiwohnen, assistieren oder moderieren
- Teilnahme an Demos und Einbeziehung der Stakeholder
- Bei Planung nächster Phase "Inspect and Adapt" einsetzen und Erfahrungen in nächste Phase einfließen lassen.

Findet gegen Ende einer Phase statt und bewertet Realisierbarkeit des Projekts bevor die nächste Phase genehmigt wird.

1. nächste Phase planen
2. Wichtige Dokumente aktualisieren (inkl. Business Case)
3. Phasenabschlussbericht erstellen

Lenkungsausschuss bitten die nächste Phase einzuleiten

Was Sie möglicherweise vorfinden

• Eine Phase kann mehrere Releases beinhalten. In Agile wo evtl. kein SB eingesetzt wird, würde ein umfassendes Release-Review dem am nächsten kommen. 
• Zeigt sich der Business Case als nicht mehr erstrebenswert, praktikabel und realisierbar kann das Projekt vom Lenkungsausschuss gestoppt werden. In P2 kommen solche Bruchstellen weniger vor.

Was zu tun ist

• Anzahl, Qualität, Nutzen der gelieferten Features prüfen (nicht Zeit und Kosten, das wurde in MP festgelegt)
• Agile Prozesse hinterfragen und verbessern (z.B. Menge an Sprints eines einzelnen Releases)
• Release-Review könnte mit einem formalen Teil hierzu ausgestattet werden.

Wie es aussehen könnte
Wenig Wirbel in dieser Phase, da durch Releases und Demos Lenkungsausschuss bereits informiert ist. Kontakt jedoch trotzdem wichtig, falls strategische Ziele oder Marktänderungen das Projekt z.B. überflüssig machen.

Fokus: Demonstration Endprodukt, Folgemaßnahmen, Beurteilung Einsatz von Agile

Zweck:

• Einen Punkt zu definieren, an dem die Abnahme des Projektprodukts bestätigt wird 
• anzuerkennen, dass die ursprünglichen Ziele der Projektleitdokumentation (auch genehmigte Änderungen dieser Ziele) erreicht wurden oder mit dem Projekt keine weiteren Ergebnisse erzielt werden können.

Genauer
===

Wurden die Abgabekriterien aus der Projektproduktbeschreibung erfüllt? Es geht aber eher um die zeitliche Befristung (dank iterativer und inkrementeller Arbeitsweise). Wenn verfrühter Abschluss, wäre dieser im agilen Kontext wahrscheinlich schon früher eingetreten, durch "Fail Fast".

Was Sie möglicherweise vorfinden
In einfachen Agilen Umgebungen wahrscheinlich nicht zu finden.
Da es eher um Konsolidieung geht, ist diese Phase von eher gereingerer Bedeutung, wie schon in den SB Phasenübergängen.

Was zu tun ist / Wie es aussehen könnte

• Eigenständig moderierter Phasen-Workshop mit 
  - Lenkungsausschuss
  - Projektsicherung
  - Projektmanager
  - Projektteam
• Ist umfangreicher und könnte eine Demo des Endprodukts enthalten.
• Abzeichnung durch Kunde. 
• Letztes Release könnte etwas formeller, mit mehr öffentlicher Resonanz seitens der Benutzervertreter stattfinden.
• Fehlendes aus Umfangsanpassungen evtl. als neues Projekt oder über BAU
• Abgleich endgültige Information Radiators mit Basline (Projektproduktbeschreibung, Business Case Projektplan aus IP)
• Bestätigung Nutzen
• Überprüfung des Vorteilhaften Einsatzes von Agile vergleich mit anfänglichem Agilometer
• Auflösung der Veranstaltung, Dank und evtl. Einladung zum essen etc.

Wie Mini-Workshop:
Wie verlief die Arbeit und was kann verbessert werden (Kaizen-Prinzip), z.B. über Glad/Sad/Mad oder Vorschläge auf Karteikarten über die mit Punkten abgestimmt wird.

• Dauer etwa 3h für einen Monat.
• Geleitet oft vom ScrumMaster
• Jeder kann teilnehmen
• Findet nach jedem Sprint statt, solange es lohnt.

Gehört zu den 5 Events in Scrum
(1. Sprint Planning, 2. Daily Scrum, 3. Sprint Review, 4. Sprint Retrospective, 5. Backlog Refinement)

Team überprüft Arbeitsweise mit dem Ziel, sich von einer Timebox zur nächsten zu verbessern. 
- Geplant
- Um ein bestimmtes Ziel herum geplant
- Haben eine Agenda 
- unabhängige Moderierung
- Gelegennheit zu hinterfragen was geändert werden muss
- Absichtliche Stück für Stück Verbesserung (nach dem Kaizen-Konzept)
- Ergebnisse festhalten, z.B. Feedback-Technik Glad-Sad-Mad
- Für Frische vlt. mal den Ort wechseln etc. 
- Neben einer Sprint-Retrospektive kann auch auch ausweiten auf Release oder Phase. 

Nicht verwechseln mit "Sprint-Reviews", wo betrachtet wird wie viel geliefert wurde.

• Entwicklungsprozess zu optimieren
• Team bei der Erfüllung der Sprint-Ziele unterstützen
• Sorgt für Einhaltung der Scrum-Prinzipien

Diese Rolle wird oft auch als "Servant Leadership" bezeichnet. Denn er nimmt eine dienende Führungsrolle ein, indem er dem Team hilft und sich um seine Bedürfnisse kümmert. Es geht darum, das Team zu befähigen, effektiv und erfolgreich zu sein.

• Er unterstützt, coacht und schult das Team, um sicherzustellen, dass alle Best Practices von Scrum eingehalten werden.
   
• Dabei geht es darum, die Entwicklung des Teams zu fördern und Hindernisse zu beseitigen, um einen reibungslosen Ablauf des Scrum-Prozesses zu gewährleisten.

Auch Scrum Master genannt.

Er nimmt eine dienende Führungsrolle ein, indem er dem Team hilft und sich um seine Bedürfnisse kümmert. Es geht darum, das Team zu befähigen, effektiv und erfolgreich zu sein. 

Besteht aus Mitgliedern verschiedener Fachbereiche oder Disziplinen, die gemeinsam an einem Projekt arbeiten.

Ermöglichen eine effizientere Zusammenarbeit, da das Team in der Lage ist, die benötigten Aufgaben selbstständig zu erledigen, ohne ständig auf externe Ressourcen angewiesen zu sein.

Jedes Mitglied

• bringt unterschiedliche Fähigkeiten und Kompetenzen mit und
• ist in der Lage, verschiedene Aufgaben und Verantwortlichkeiten innerhalb des Teams zu übernehmen.

Dadurch kann das Team flexibel und autonom arbeiten und ist nicht auf eine bestimmte einzelne Rolle oder Fachgebiet beschränkt.

High Level User Story die nicht ausformuliert ist.  Zur Beschreibung grober Anforderungen im Anfangsstadium.

1. Agilometer
2. Anforderungen
3. Umfassende Kommunikation
4. Regelmäßige Releases
5. Vertragsgestaltung mit Agile

Welches Prinzip wird dadurch angewandt:
Anpassen an das Projekt

Erstmaliger Einsatz in Prozess "Initiieren eines Projekts"

Wer und wie: PM zusammen mit Stakeholdern

• Bewerten von 6 Kategorien
• Werte festhalten mit Schieberegler
• Schieberegler Stufe 1 (nicht gut geeignet) bis 5 (sehr gut geeignet)
• Durchschnittswerte sind belanglos

Kategorien:

1. Flexibilität bzgl. Liefergegenstand
   Begüßen Stakeholder Änderungen oder ist alles ein "must"?
2. Maß der Zusammenarbeit
   Partnerschaft ohne Schuldzuweisungen und schlechte Vorerfahrungen?
3. Einfachheit der Kommunikation
   Misstrauen gegenüber Technologie oder Verteilung des Teams über verschiedene Zeitzonen?
4. Fähigkeit zu iterativer Arbeit und inkrementeller Lieferung
   Verständnis für Agile Methoden oder gegen Teillieferungen?
5. Vorteilhafte Umgebungsbedingungen
   Kunde bereit zu flexiblem Vertrag oder pocht auf Details?
6. Akzeptanz von Agile
   Haben Stakeholder agiles Verständnis und bereitsschaft dieses mit ihren MAs zu teilen?

Synonyme Verwendung des Begriffs in Agile häufig als Funktion/Feature/UserStory.
P2 Agile: "Ein Begriff, der beschreibt, was ein 
Produkt kann und/oder wie es funktioniert"

= Sammeln, Verstehen, Priorisieren und Verwalten von Anforderungen in einem Projekt, zur Umzuwandelung in klar definierte Anforderungen. 

Klare Definition durch:
User Story
Feature/Funktion: Was ein Produkt kann oder wie es funktioniert. Bezug auf UserStorys oder Epics möglich. Zuordnung zu jeder Ebene möglich.

Organisation - Mögliche Aufschlüsselung von hoher zu niedriger Detailebene:

• Projektproduktbeschreibung (Epics, Dok auf hoher Ebene)
• Produktgruppen/Hauptprodukte ("Aufbau" in der PPB beschreibt Hauptprodukte und damit den Umfang des Projekts, sind Epics oder n grobe UserStorys auf mittlerer Ebene (Agile Fehlschätzungen 50-100%) 
• Produktbeschreibungen (Anforderungsliste, Tasks, User Storys, Agile Fehlschätzungen 10-20%)

Priorisierung

• In einfacher agiler Umgeung: Produkt-Backlog 1,2,3-n + Sprint-Backlog
• Komplexere Umgebungen: Kombi mit MoSCoW.
  Ohne Fristen bedeutungslos. In Agile werden daher Zeit und Kosten festgelegt und der Umfang durch die Priorisierung flexibel gehalten.

Anforderung auf hoher oder mittlerer Ebene aus der Perspektive des Benutzers.
Formulieren in Form von

Wer (Rolle)...
Was (Funktion)...
Warum (Nutzen) 
-> Ergänzung um Abnahmekriterien wenn die Anforderung besser verstanden wurde.

"Als...möchte ich...sodass/damit..."

Ist die User Story gut genug, erfüllt Sie die "Definion of Ready" (INVEST-Richtlinien) und das Lieferteam kann die Arbeit aufnehmen.

Es muss definiert werden, wer etwas ausführen muss.
Zusätzlich können technische Storys zur stärkeren Priorisierung  verwendet werden, die Bezug auf nicht funktionale Anforderungen nehmen, wie Verfügbarkeit, Portabilität, Leistung, Gewicht

z.B.: Als Entwickler möchte ich die Performance der Datenbank verbessern, um die Ladezeiten der Anwendung zu verkürzen.

Konzept um sicherzustellen, dass ein Product Backlog Item (PBI) bereit ist, in den Sprint aufgenommen zu werden. Sie erfüllt zum Beispiel die INVEST-Richtlinien.

Richtlinie für das Schreiben von User Stories die gut verständlich, umsetzbar und testbar sind:

I - Independent (Unabhängig)
Eine User Story sollte in sich abgeschlossen sein und unabhängig von anderen Stories umsetzbar sein. 

N - Negotiable (Verhandelbar)
Die Details der User Story sollten verhandelbar sein, um Raum für Diskussionen und Anpassungen zu lassen. 

V - Valuable (Wertvoll)
Eine User Story sollte einen klaren Wert für den Benutzer oder das Unternehmen liefern. 

E - Estimable (Schätzbar)
Es sollte möglich sein, den Aufwand für die Umsetzung der User Story zu schätzen. 

S - Small (Klein)
Eine User Story sollte klein genug sein, um in einem einzigen Sprint umgesetzt werden zu können. 

T - Testable (Testbar)
Eine User Story sollte klar definierte Akzeptanzkriterien haben, anhand derer die erfolgreiche Umsetzung getestet werden kann.

-> Teammitgliedern effektiveres Arbeiten zu ermöglichen

Umfänglich, persönlich, schnell Kommunizieren.
Enge Verknüpfung mit dem agilen Wert Transparenz.

Kanal wählen nach erstrebtem Zweck (Information Radiators,Gespräch, Meeting, Grafik, Workshop...)

Mails nur für große Anhänge oder eindeutige Informationen nützlich, bei denen Ton und Körpersprache keine Rolle spielen. Zu kurz evtl. unhöfliche, zu lang evtl. langweilig....

Leitlinie P2 Agile: 
"Wir brauchen Information, nicht unbedingt Dokumentation.
Wir brauchen Entscheidungen, nicht unbedingt Meetings."

• GAP-Analyse: Beschreibung Ist- und Sollzustand und der Maßnahmen, um zum Sollzustand zu gelangen.
• Aussagekräftige Bilder: Eine Form der Visualisierung bei der Hinweise(häufig Gefühle) mithilfe von Metaphern und Humor vermittelt werden können.
• Visionierung: Erstellung von gemeinsamen Zielen, häufig unter Einsatz von Visualisierung.
• Brainstorming: Eine Art Ideenfindung, normalerweise mithilfe von Haftnotizen.
• Priorisierungung mit Punkten: Schnelle Abstimmung über verschiedenen Optionen.