Agiles Projektmanagement Glossar


Kanban-Methode

Ursprünglich stammt die Kanban-Methode aus der Produktionssteuerung. Im Rahmen des agilen Projektmanagements wurde die Kanban-Methode jedoch auch als Methode entdeckt. Das Herzstück ist eine Visualisierungstafel mit drei Spalten: „Backlog“, „In Progress“ und „Done“. Aufgaben werden als sog. Tasks auf Haftnotizen festgehalten, um diese entsprechend visualisieren zu können. Im Backlog, werden alle To Dos eingetragen. Sobald eine Aufgabe in Arbeit genommen wird, wandert der Task in die zweite, In Progress, Spalte. Nach Beendigung der entsprechenden Aufgabe, wird diese in die Done-Spalte gesetzt. Jedem Gruppenmitglied ist es erlaubt sich neue Aufgabenkarten zu ziehen und in Bearbeitung zu nehmen.


Scrum-Methode

Die Scrum-Methode ist eine Methode für das agile Projektmanagement. Seinen Ursprung hat es in der Software-Entwicklung, wird jedoch mittlerweile branchenübergreifend angewendet. Merkmale der Scrum-Methode sind u. a. einfache Regeln, wenige Meetings sowie die Selbstorganisation und das eigenverantwortliche Handeln interdisziplinärer Projektteams. Das Ziel ist eine effiziente und kostengünstige Umsetzung von Produktvisionen. Die Scrum-Methode kennt vier Funktionsträger, die den Entwicklungsprozess vorantreiben:

  • Product Owner
  • Scrum Master
  • Entwicklerteam
  • Stakeholder

Product Owner

Der Product Owner hat die zu entwickelnde Produktvision. Er stellt fachliche Anforderungen an das Produkt und priorisiert diese.


Entwicklungsteam

Das Entwicklungsteam entwickelt das Produkt. Es kümmert sich um die Aufteilung von User Stories in umsetzbare Tasks sowie deren Aufwandsschätzung und um die Umsetzung.


Scrum Master

Er kümmert sich um die Einhaltung der Scrum-Regeln und ist letztendlich dafür verantwortlich, dass der Sprint erfolgreich ist. Er arbeitet eng mit dem Entwicklerteam zusammen, ist dabei aber selbst nicht Teil des Teams. Neben Moderation und Behebung von Störfaktoren steuert der Scrum Master die Kommunikation innerhalb des Teams und mit dem Product Owner. 


Stakeholder

Dieser ist beispielsweise ein Kunde mit einer Idee oder Vision die umgesetzt werden soll. Er ist der Auftraggeber des Produkts. 


Backlog (Scrum-Methode)

Dieser Backlog enthält User Stories, die der Product Owner in Zusammenarbeit mit dem Stakeholder erstellt hat.


Backlog (Kanban-Methode)

Der Backlog enthält die Aufgaben (Tasks).


User Stories

Sie beschreiben die Anforderungen aus Sicht eines Benutzers unter Verwendung einer klaren Aussage. Die User Story beschreibt die Produkteigenschaften. 


Sprint

Ein Sprint ist ein festgelegter Zeitraum, in der Regel dauert dieser 2 Wochen, in welchem die zu Beginn im Sprint-Planning festgelegten Aufgaben (Sprint-Backlog) abgearbeitet und am Sprint Ende in der Sprint-Review abgenommen werden. In der Sprint-Retrospektive wird in einer positive/delta Liste festgehalten, was im Sprint gut (positive) und nicht gut (delta) verlief, um im nächsten Sprint besser werden zu können. Die Dauer der im Sprint-Planning geplanten Tasks sollte den Zeitrahmen des Sprints nicht überschreiten.


Sprint-Backlog

Er beinhaltet alle Tasks für den aktuellen Sprint. Er wird gemeinsam zwischen Entwicklerteam und Product Owner erarbeitet.


Sprint-Planning I

Der Product Owner stellt dem Entwicklerteam seinen priorisierten Product Backlog vor. Zusammen mit dem Team werden die Eigenschaften und Akzeptanzkriterien besprochen. Im Anschluss wird vom Team festgelegt, welche User Stories aus dem Product Backlog im nächsten Sprint umsetzbar sind und es wird gemeinsam ein Sprint Ziel formuliert.


Sprint-Planning II

Im zweiten Teil des Sprint Plannings werden die im Sprint Planning I gewählten User Stories in einzelne Tasks übersetzt. 


Daily Scrum

Im Daily Scrum, welches maximal 15 Minuten geht und am besten im Stehen abgehalten wird, werden im Entwicklungsteam mit dem Product Owner immer die folgenden 3 Fragen geklärt:

  • Was wurde seit dem letzten Daily Scrum umgesetzt?
  • Was wird bis zum nächsten Daily Scrum umgesetzt?
  • Gab es Probleme? Und wenn ja – welche.

Sprint-Review

Das Sprint-Review wird am Ende eines jeden Sprints durchgeführt. Die Zielerreichung eines Sprints wird dabei überprüft. Es dient in erster Linie dazu umgesetzte Funktionen zu validieren und dass diese wie vom Stakeholder gewünscht umgesetzt werden. Das daraus resultierende Feedback von allen beteiligten ist dabei besonders wichtig, um gewonnene Erkenntnisse in den nächsten Sprint-Backlog einfließen lassen zu können.


Sprint-Retrospective

In der Sprint-Retrospektive hält das Team den letzten Sprint in einer positive/delta Liste fest, um die bisherige Arbeitsweise bewerten zu können, um diese in Zukunft noch effektiver und effizienter umzusetzen.