PRINCE2 Agile® Foundation

Häufig verwendete Priorisierungstechnik in PRINCE2

Ohne Fristen bedeutungslos.
In Agile werden daher Zeit und Kosten festgelegt und der Umfang durch die Priorisierung flexibel gehalten.

Dabei werden die Aufgaben in die Kategorien

• "Must have", "Should have"
• "Could have"
• "Won't have" eingeteilt.

Must have"
Aufgaben, die unbedingt erledigt werden müssen, um das Projektziel zu erreichen.

"Should have"
Aufgaben, die wichtig sind, aber nicht zwingend für das Projektziel erforderlich.

"Could have"
sind Aufgaben, die wünschenswert sind, aber nicht unbedingt notwendig.

"Won't have"
Aufgaben, die bewusst ausgeschlossen werden, da sie nicht zum Projektziel beitragen.

Diese Priorisierungstechnik hilft dem Projektteam und den Stakeholdern, sich auf die wesentlichen Aufgaben zu konzentrieren und sicherzustellen, dass die wichtigsten Anforderungen erfüllt werden. Es ist jedoch wichtig zu beachten, dass PRINCE2 keine spezifischen Priorisierungstechniken vorschreibt. Die Methode "MoSCoW" ist nur eine von vielen Möglichkeiten, Aufgaben zu priorisieren. Je nach Projekt und Kontext können auch andere Priorisierungstechniken angewendet werden.

Die 'Tailoring'-Praxis in PRINCE2 bezieht sich darauf, dass das PRINCE2-Framework an die spezifischen Anforderungen eines Projekts angepasst werden kann. Es geht darum, die PRINCE2-Methode entsprechend der Größe, Komplexität und Art des Projekts anzupassen, um effektiver und effizienter zu sein. Ein Beispiel für Tailoring könnte sein, dass bestimmte Prozesse oder Dokumentationen, die für dein Projekt nicht relevant oder notwendig sind, angepasst oder weggelassen werden können. So kann das PRINCE2-Framework maßgeschneidert werden, um den Anforderungen des Projekts gerecht zu werden und gleichzeitig eine solide Basis für das Projektmanagement zu bieten.

Ein stabiles Team ist ein Team, das über einen längeren Zeitraum hinweg unverändert bleibt. Das bedeutet, dass die Teammitglieder konstant bleiben und keine häufigen Wechsel oder Rotationen stattfinden. Ein stabiles Team hat einige Vorteile:

1. Vertrauen und Zusammenarbeit: Da sich die Teammitglieder gut kennen und schon längere Zeit miteinander gearbeitet haben, entwickeln sie ein starkes Vertrauen zueinander. Dadurch können sie effektiv zusammenarbeiten und sich aufeinander verlassen.

2. Effizienz: Ein stabiles Team profitiert von der eingespielten Zusammenarbeit. Die Teammitglieder kennen die Stärken und Schwächen der anderen und können so effizienter arbeiten. Es ist nicht notwendig, neue Teammitglieder kontinuierlich einzuarbeiten.

3. Kontinuität: Ein stabiles Team kann über einen längeren Zeitraum hinweg kontinuierlich an Projekten arbeiten. kann es eine langfristige Sichtweise entwickeln, um Ziele zu erreichen und stetige Verbesserungen vorzunehmen. Allerdings gibt es auch einige Herausforderungen bei der Aufrechterhaltung eines stabilen Teams, wie z.B. die Motivation der Teammitglieder langfristig aufrechtzuerhalten oder die Vermeidung einer zu starken Abhängigkeit von einzelnen Teammitgliedern.

Dieses Dokument gibt einen Überblick über das Projekt, einschließlich der Ziele, des Umfangs und der Stakeholder. Es hilft dabei, ein gemeinsames Verständnis für das Projekt zu schaffen und dient als Ausgangspunkt für die Planung.

Defintion des Endprodukts des Projekts.

Das Element "Aufbau" beschreibt beschreibt die Hauptprodukte/Produktgruppen und damit den Umfang des Projekts. Die Hauptprodukte können als Epics bezeichnet werden. Evtl. n grobe UserStorys auf mittlerer Ebene.
Agile Fehlschätzungen des Aufwands darf hier noch bei 50-100% liegen.

In der Produktbeschreibung wird jedes zu liefernde Produkt beschrieben, einschließlich seiner Merkmale, Funktionen und Qualitätskriterien. Dies dient als Referenz für die Entwicklung und Überprüfung der Produkte im Laufe des Projekts.

Aufgenommene Anforderungen sind Epics hoher Ebene (bis zu 10? L5S6), grob formulierte UserStorys, oder Steine mittlerer Ebene .

Grober Überblick über die Hauptprodukte des Projekts mit Lieferterminen, Kosten, Ressourcenbedarf und Abhängigkeiten. 

• Erstellung Projektplan durch Team
• Erste Version ist Teil der Projektleitdokumentation.
• Aktualisierung während des Projekts mit aktuellen Ist-Daten, um sicherzustellen, dass das Projekt auf Kurs bleibt.
• Format i.d.R. Gantt-Diagramm oder Produkt-Backlog

Wichtigstes Dokument für den Lenkungsaussschuss, zur Überprüfung von Soll und Ist (ursprüngliche Erwartungen und aktueller Projektstatus)

Teilmenge des Product Backlog.

Im agilen Kontext enthält der Sprint Backlog eine Liste der Features, die in einem Sprint entwickelt werden sollen. Es dient als Leitfaden für das Entwicklungsteam während des Sprints. 

Das Produktinkrement ist das Ergebnis eines Sprints und stellt eine potenziell shippbare Version des Produkts dar. Es wird nach jedem Sprint erstellt und kann dem Kunden präsentiert werden.