Flexibles Management für dynamische und effiziente Projekte
Glossar Agiles Projektmanagement
Agiles Manifest
Das Agile Manifest wurde von erfahrenen Software-Entwicklern als Reaktion auf das Scheitern vieler Softwareprojekte geschrieben. Es ist ein kurzes Dokument, in dem festgelegt wird, nach
welchen agilen Werten und agilen Prinzipien Software entwickelt werden sollte.
Agile Prinzipien
Die agilen Prinzipien beschreiben die grundlegende Vorgehensweise bei der agilen Produktentwicklung. Dazu gehören z. B. die Entwicklung in Iterationen und die Selbstorganisation des
Entwicklungsteams.
Agile Werte
Die agilen Werte beschreiben eine Grundhaltung, die bei der agilen Produktentwicklung vorherrschen sollte. Die vier agilen Werte sind dabei jeweils den Werten des klassischen
Projektmanagements gegenübergestellt, wobei die agilen Vorrang haben sollten. Beispielsweise soll die Zusammenarbeit mit dem Kunden wichtiger genommen werden als Vertragsverhandlungen.
Anwendungsfälle (Use Cases)
Anwendungsfälle, sog. Use Cases, beschreiben die Anforderungen an ein Produkt aus Sicht des Produktnutzers. Ein einzelner Anwendungsfall ist also eine Beschreibung für eine konkrete
Situation, in der das Produkt genutzt wird. Die Summe aller Anwendungsfälle beschreibt dann die gesamte Funktionalität des Produktes.
Backlog Grooming
Mit Backlog Grooming wird bei Scrum die Pflege des Product Backlogs bezeichnet. Dazu gehört z. B. Einträge des Product Backlogs für eine Übernahme in den Sprint Backlog vorzubereiten, also
deren Beschreibung zu verfeinern.
Burn-Down-Chart
Ein Burn-Down-Chart stellt den Arbeitsstand des Projektes über einen bestimmten Zeitraum dar. Die Kurve des Diagramms beginnt auf der vertikalen Achse oben bei dem noch zu erledigenden
Aufwand und läuft dann mit dem abgearbeiteten Aufwand abwärts.
Business Value
Jeder Anwendungsfall hat für die Stakeholder bzw. den Kunden einen bestimmten Business Value (zu Deutsch: Geschäftswert). Die verschiedenen Anwendungsfälle sind somit also unterschiedlich
wertvoll. Im einfachsten Fall kann man dies abbilden, in dem den Anwendungsfällen entsprechende Werte von 1 bis 3 zugewiesen werden.
Cumulative Flow
Cumulative-Flow-Diagramme helfen bei mehrstufigen Prozessen, Engpässe zu identifizieren. Dabei werden für jede Prozessstufe über die Zeit die Anzahl der anliegenden Arbeitsaufträge
eingezeichnet. Flaschenhälse im Prozess zeigen sich dann durch „Bäuche“ im Diagramm.
Daily Scrum
Das ist die Bezeichnung für eine Daily-Standup-Besprechung innerhalb der Methode Scrum.
Daily-Standup-Meeting
Eine täglich mit dem Entwicklungsteam durchgeführte, kurze Besprechung im Stehen. Deren Ziel ist es, dass jeder mitbekommt, woran die anderen gerade arbeiten. Zudem werden darin vom Moderator
(z. B. Projektleiter) aktuelle Arbeitshindernisse erkannt, und es können entsprechende Lösungswege vorgeschlagen werden.
Definition of Done
Das agile Team einigt sich darauf, welche Kriterien erfüllt sein müssen, damit eine Aufgabe als erledigt gilt. Diese Kriterien werden Definition of Done genannt. Auf einem Task Board darf
dann z. B. eine Aufgabe nur nach „Done“ bewegt werden, wenn diese Kriterien erfüllt sind.
Development Team
Bei Scrum wird das Entwicklungsteam als Development Team bezeichnet.
Drama-Dreieck
Dieses Modell, das aus der Psychologie stammt, veranschaulicht ein soziales Verhaltensmuster, das recht häufig anzutreffen ist. Dabei interagieren ein „Verfolger“, ein „Opfer“ und ein
„Retter“. In vielen Projektmeetings läuft dieses Muster in irgendeiner Form ab.
Earned Value
In Earned-Value-Diagrammen werden die Projektkosten fortlaufend den erledigten Aufgaben gegenübergestellt. Daraus lassen sich verschiedene Kennwerte für einen Projektreport ableiten. Zudem
wird es darin sichtbar, wenn zu den Projektkosten kein passender Wert in Form von erledigten Aufgaben geschaffen wird.
Epic
Eine Gruppe von zusammengehörigen Anwendungsfällen kann in einem Epic zusammengefasst werden. Epics sind praktisch ein Abstraktionsgrad über Anwendungsfälle, um die Übersichtlichkeit zu
erhöhen. Im Englischen werden grobe Beschreibungen von Anwendungsfällen auch als User Storys bezeichnet.
Inkrement
Dies ist ein Teilprodukt bei der agilen Entwicklung. Ein Inkrement entsteht während einer Iteration. Das Inkrement sollte als Teilprodukt funktionsfähig sein, damit die Stakeholder es nutzen
und Rückmeldung dazu geben können.
Iteration
Eine Iteration ist eine Phase im Projekt, während der ein Teilprodukt entwickelt wird. In der agilen Methode Scrum werden Iterationen als Sprint bezeichnet. Kanban Eine Methode zur
Prozesssteuerung, die in ihren Grundideen einige Gemeinsamkeiten mit Scrum aufweist. In der Softwareentwicklung wird Kanban manchmal für den Prozess der Fehlerbehebung (Bug Fixing)
eingesetzt. Dabei kommen dann Cumulative-Flow-Diagramme zum Einsatz.
Minimally Marketable Features
Damit sind Eigenschaften und Funktionen eines Produkts gemeint, die sich eigenständig vermarkten lassen. Daraus lässt sich dann ableiten, welche Produktfunktionen man zuerst entwickeln
sollte, um ein bereits verkaufsfähiges Teilprodukt zu erhalten.
Persona
Hier werden „Personen“, die einem ganz bestimmten Kundentyp mit ganz bestimmten Interessen entsprechen, entwickelt. Dies hilft z. B. dabei, Produktanforderungen für bestimmte Zielgruppen
gedanklich zu entwerfen oder zu testen. Dabei überlegt man dann, ob die Produktanforderung für eine bestimmte Persona geeignet wäre oder welche Anforderungen die Persona wohl hätte.
Planning Poker
Ein dynamisches Schätzverfahren in einer Gruppe bzw. einem Projektteam. Ziel dabei ist es, möglichst zeiteffizient zu möglichst genauen Aufwandsschätzungen zu gelangen. Dazu gibt es
vorgefertigte Kartensätze, mit denen die Teilnehmer nach bestimmten Regeln ihre Schätzungen abgeben.
Product Backlog
Bei Scrum werden die Produktanforderungen im Product Backlog gespeichert. Dort finden sich die (noch relativ groben) Beschreibungen aller bekannten Anforderungen, deren Realisierung dann
später das Produkt ergeben. Zu Beginn eines Sprints wandern dann eine Reihe von Anforderungen aus dem Product Backlog in das Sprint Backlog.
Product Owner
Der Product Owner ist eine Rolle im Scrum-Team. Er vertritt die Sicht des Kunden bzw. des Produktnutzers und muss daher sehr gut mit den Produktanforderungen vertraut sein. Er hat
verschiedene damit zusammenhängende Verantwortlichkeiten. Insbesondere muss er dem Entwicklungsteam für Detailfragen zu den Produktanforderungen kurzfristig zur Verfügung stehen.
Retrospektive
Bei einer Retrospektive handelt es sich um eine Rückschau auf das Projekt, mit dem Ziel, Prozessverbesserungen für die Zukunft abzuleiten. Bei Scrum sind Retrospektiven nach jedem Sprint
(Teilproduktentwicklung) vorgeschrieben.
Review
Bei einem Review wird das bisher entstandene Teilprodukt den Stakeholdern (insbesondere den Kunden) vorgestellt, um Rückmeldungen dazu zu bekommen. Dabei geht es um die Frage, inwiefern das
Teilprodukt den Vorstellungen der Stakeholder entspricht und welche Erkenntnisse sich daraus für weitere, noch zu entwickelnde Anforderungen ableiten lassen. Ein Review unterscheidet sich
also klar von einer Retrospektive. Beim Review geht es um die Produktebene, bei der Retrospektive um die Prozessebene.
Scrum
Diese Methode ist ein „Rahmenwerk“ für agile Prozesse. Scrum gibt Strukturen vor, die einen erfolgreichen Einsatz des agilen Projektmanagements fördern. Zu diesen Strukturen gehören
Projektrollen wie der Scrum Master und Besprechungen wie das Daily Scrum.
Scrum But
Die Gründer von Scrum verstehen unter „Scrum But“ (zu Deutsch: „Scrum, aber“) Projekte, die sich an Scrum anlehnen, es aber nicht exakt befolgen. Dadurch können dann typische Probleme
entstehen, für die innerhalb von Scrum keine Lösungen vorgesehen sind. Interessant ist: In der Praxis finden sich weitaus mehr Scrum But- als reine Scrum-Projekte.
Scrum Master
Der Scrum Master ist in einem Scrum Team dafür verantwortlich, dass die Regeln des Scrum-Prozesses eingehalten werden. Zudem unterstützt er alle wichtigen Stakeholder dabei, die Auswirkungen
des Scrum-Prozesses auf ihre Arbeit zu verstehen. In der Praxis übernimmt der Scrum Master häufig verschiedene Aufgaben, die traditionell beim Projektmanager angesiedelt sind.
Sprint
Ein Sprint im Scrum entspricht einer Iteration im agilen Projektmanagement. Während eines Sprints wird also vom Scrum Team ein Teilprodukt entwickelt. Ein Sprint darf bei Scrum
höchstens einen Monat dauern. Die verschiedenen Sprints innerhalb eines Scrum-Prozesses sollten alle jeweils die gleiche Dauer haben, z. B. eine Woche. Dabei schließen die Sprints zeitlich
direkt aneinander an.
Sprint Backlog
Innerhalb von Scrum beschreibt das Sprint Backlog die Arbeiten, die für das kommende Teilprodukt erledigt werden müssen. Dazu werden in einem speziellen Meeting (Sprint Planning) passende
Anforderungen aus dem Gesamtumfang (Product Backlog) ausgewählt. Außerdem werden die Beschreibungen der Anforderungen für das Sprint Backlog verfeinert.
Sprint Planning
In Scrum dient das Sprint-Planning-Meeting der Planung eines Sprints. Dort wird entschieden, welche Anforderungen für das nächste Teilprodukt umgesetzt werden sollen. In diese Planung wird
das gesamte Scrum Team einbezogen. Damit soll insbesondere erreicht werden, dass das gesamte Team dann auch hinter der Planung des Sprints steht und motiviert und eigenverantwortlich an der
Zielerreichung mitarbeitet.
Sprint Retrospective
Innerhalb von Scrum werden die Retrospektiven als Sprint Retrospective bezeichnet. Dabei reflektiert das Scrum Team die Zusammenarbeit im Team, sowie Werkzeuge und Prozesse zu dieser
Zusammenarbeit. Das Ziel dabei ist es, konkrete Maßnahmen der Verbesserungen für die kommende Teilproduktentwicklung (Sprint) abzuleiten.
Sprint Review
Das Sprint Review bei Scrum entspricht im Wesentlichen dem Review im agilen Projektmanagement. Dabei stellt das Scrum Team zum Ende der Teilproduktentwicklung (Sprint) den wichtigen
Stakeholdern das Ergebnis vor.
Statusquadrat
Das Statusquadrat stellt den Zusammenhang zwischen Statusverhalten und Kooperation bzw. individueller und gemeinsamer Verantwortung grafisch dar. Es hebt hervor, wie wichtig es ist, in einem
Gespräch Statusflexibilität zu zeigen.
Statusradar
Der Statusradar stellt den Status als Kombination aus „Einfluss“, „Rang“, „Selbstwert“ und „Statusverhalten“ dar. Im Statusradar können individuelle Personen oder allgemeine Typen dargestellt
werden.
Stakeholder
Ein Begriff aus dem klassischen Projektmanagement. Unter den Stakeholdern eines Projektes werden Personen verstanden, die direkt oder indirekt von dem Projekt betroffen sind, also informiert
sein wollen oder sogar Einfluss auf den Projektverlauf nehmen möchten.
Story Points
Ein Story Point ist ein abstraktes Maß für die Komplexität einer User Story. Auf Basis der Erfahrung mit anderen User Storys, deren Story Points und Entwicklungsdauer kann dann letztlich die
Entwicklungsdauer zu einem Story Point abgeschätzt werden.
Task Board
An einem Task Board werden aktuelle Aufgaben visualisiert. Es wird unterschieden zwischen Aufgaben, die anstehen, in Bearbeitung sind, fertig sind usw. Ein Task Board kann mit Klebezetteln an
einer Wand gestaltet sein oder auch virtuell mit einem Online-Tool.
Timeboxing
Unter Timeboxing versteht man das strikte Einhalten vorgegebener Zeitrahmen. Dies findet beim agilen Projektmanagement durchgehend Anwendung, z.B. bei Besprechungen oder bei Iterationen.
Sollte die Zeit einer Timebox nicht ausreichen, so wird der Umfang möglichst sinnvoll reduziert, damit der Zeitrahmen eingehalten werden kann.
Use Case
Englischer Begriff, der synonym für Anwendungsfall verwendet wird.
User Story
Eine sehr kurze Beschreibung einer Anforderung in Alltagssprache. Eine User Story besteht typischerweise nur aus einem oder ein paar wenigen Sätzen und beschreibt einen Anwendungsfall auf
grober Ebene.
Wertequadrat
Kommunikationsmodell, das den Zusammenhang zwischen gegensätzlich ausgerichteten Werten aufzeigt. Zwei solcher Werte bilden ein Wertepaar. Die Übertreibungen der beiden Werte ins Negative
werden dann als zugehörige Unwerte bezeichnet.
WIP-Limit
WIP-Limit steht für „Work in Progress Limit“, übersetzt bedeutet dies in etwa „Begrenzung gleichzeitiger Aufgaben“. Es ist ein Wert, der die Anzahl von parallelen Aufgaben begrenzt, die ein
Mitarbeiter haben darf. Möchte er diese Grenze überschreiten, so muss er dies gut begründen können. Für WIP-Limits werden üblicherweise erst im Verlauf eines Projektes die optimalen Werte
gefunden, da dieses Optimum vom jeweiligen Projekt und Team abhängt.