Glossar Agiles Projektmanagement |
||
Aktivitäten |
||
|
Backlog |
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. | Zum Video ➡️ |
|
Backlog Refinement |
Product Backlog kontinuierlich verfeinern und aktualisieren. Einträge detaillierter ausarbeiten, priorisieren und für Sprint Planning vorbereiten. | |
Anwendungsfälle |
||
|
Use Cases |
Anwendungsfälle, sogenannte 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. | |
|
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. |
|
| 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 eines Sprints. Das Inkrement ist als Teilprodukt funktionsfähig, damit die Stakeholder es nutzen und Rückmeldung dazu geben können. | Zum Video ➡️ |
|
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. | |
| User Story Map | Zusammenhängende User Stories visuell auf einer Karte anordnen. Nutzerreise abbilden und Prioritäten für Releases festlegen. | |
Backlogs |
||
| Impediment Backlog | Blockaden und Hindernisse sammeln und verwalten. Impediments dokumentieren, priorisieren und Lösungsmaßnahmen verfolgen. | |
| 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. | Zum Video ➡️ |
| 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 Backlog Task | Sprint Backlog Items in konkrete Arbeitsschritte unterteilen. Detaillierte Aufgaben definieren und dem Team zuordnen. | |
Events |
||
| 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. | Zum Video ➡️ |
| Estimation Meeting | Aufwandsschätzungen in einer Gruppe durchführen. Team versammeln, User Stories vorstellen und gemeinsam Komplexität bewerten. | |
| 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. | |
| 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. | Zum Video ➡️ |
| 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. | Zum Video ➡️ |
| 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. | |
Grundlagen |
||
| 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. | Zum Video ➡️ |
|
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. | Zum Video ➡️ |
| 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. | |
Hilfsmittel |
||
| 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. | |
| 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. | |
| 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. | |
Methoden |
||
| 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. | |
| 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. | |
|
WIP-Limit |
WIP-Limit steht für „Limit Work in Progress" und bedeutet „begrenzte Anzahl gleichzeitiger Aufgaben". Es ist ein Wert, der die Anzahl von parallelen Aufgaben der Mitarbeitende begrenzt. Wenn diese Grenze ausnahmsweise überschritten werden soll, braucht es eine eigene Begründung. Die WIP-Limits werden im Verlauf des Projektes festgelegt, da das Optimum vom jeweiligen Projekt und Team abhängt. | |
Produktkonzepte |
||
|
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. | |
| Minimum Viable Produkt | Ein minimal brauchbares oder existenzfähiges Produkt. Es ist die Erstversion, die von hinkünftigen Benutzern auf Praxistauglichkeit geprüft werden kann und über deren Feedback weiterentwickelt wird. | |
Rollen |
||
| Development Team | Bei Scrum wird das Entwicklungsteam als Development Team (Dev-Team) bezeichnet. | |
| 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. | |
| 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. | Zum Video ➡️ |
| 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. | Zum Video ➡️ |
| Stakeholder | Ein Begriff aus dem klassischen Projektmanagement. Unter 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. | |
Sonstiges |
||
| 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. | |
| 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. | |