Hier finden Sie eine Übersicht über die wichtigsten Begriffe des agilen Projektmanagements und Scrum. Diese sind abgestimmt auf den Scrum Guide 2020.
Accountable – Responsible (ausführungsverantwortlich) ist, ist die Person, von der erwartet wird, oder die verpflichtet ist, eine Sache zu tun. Accountable (ergebinsverantwortlich oder rechenschaftspflichtig) ist, der sicherstellt, dass die Arbeit erledigt und korrekt ausgeführt wird
Agile Manifesto – Das im Jahr 2001 verabschiedete Manifest ist die Grundlage aller agilen Vorgehensweisen und beschreibt die zentralen agilen Werte.
Agile Prinzipien – Das Agile Manifesto beruht auf 12 Prinzipien, zu deren Einhaltung sich jeder Anwender agiler Methoden verpflichtet.
Agile Werte – Sind die wesentlichen Grundwerte für ein erfolgreiches, agiles Projektmanagement. Zusammengefasst: Mehr Flexibilität, weniger Strukturen, produktivere Zusammenarbeit. (siehe auch Agiles Manifesto)
Akzeptanzkriterien – Jedes Backlog Item (User Story) hat Akzeptanzkriterien. Diese sind Bestandteil der Fertigstellungskriterien (Definition of Done) und werden durch den Product Owner beim Review der fertigen User Story verwendet.
Anforderungen – Anforderungen werden in Scrum üblicherweise in einer User Story definiert (verpackt). Deshalb spricht man meistens von User Stories und nicht von Anforderungen.
Anforderungsliste – siehe Product Backlog
Artefakt – Artefakte sind die Ergebnisse von Aktivitäten im Softwareentwicklungsprozess. Zentrale Scrum Artefakte sind: Product Backlog, Sprint Backlog und das (auslieferbare) Product Increment.
Benutzergeschichte – siehe User Story
Burndown-/Burnup-Chart: Eine Grafik mit der die Developer die noch verbleibende Arbeit im Sprint in Relation zu der noch verbleibenden Zeit im Sprint visualisiert. Sie zeigt den Sprint-Fortschritt. Sie kann auf der Projekt-, Release- und Sprint-Ebene eingesetzt werden
Business Value – Er ist der (meist finanzielle) Wert eines Backlog Items für ein Unternehmen oder den Kunden. Das Product Backlog wird meistens so sortiert, dass Items mit dem höchsten Geschäftswert als Erstes erledigt werden.
Commitment – (Verpflichtung) Die Developer verpflichtet sich im Sprint Planning eine „Prognose“ zu liefern, welche Backlog Items im nächsten Sprint umgesetzt werden. Aber Commitment umfasst auch sich verpflichten zum Team, zur Qualität, zur Zusammenarbeit und zum Lernen. Sich verpflichten das Beste zu tun was man kann – jeden Tag
Chief Product Owner (CPO) – Ist in Scrum@Scale die skalierte Rolle des Product Owners. Er ist verantwortlich für das Gesamtprodukt, die Produktvision und das übergreifende Product Backlog des Projektes.
Daily Scrum – Ist ein Meeting von 15 Minuten, innerhalb dem die Developer ihre Aktivitäten synchronisieren und an der Planung für die nächsten 24 Stunden arbeiten. Es wird oft als Stand-up Meeting durchgeführt.
DEEP – Ein gute Product Backlog ist gemäß Mike Cohen DEEP. Dies bedeutet: Detailed, Estimated, Emergent (entwickelt sich), Prioritized.
Definition of Done (DoD) – Ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird. Die DoD ist eine Liste von Fertigstellungskriterien.
Definition of Ready (DoR) – Ist eine Liste von Kriterien, die an die Product Backlog Items gestellt werden, damit diese bereit (Ready) sind, um im Sprint daran zu arbeiten. Im Gegensatz zur DoD ist der Product Owner für die Einhaltung der DoR verantwortlich.
DevOps – Durch die enge Zusammenarbeit von Development and Operations im agilen Umfeld und durch Automatisierung im ganzen Lebenszyklus können Releases schneller, in höherer Qualität, zu niedrigen Kosten und Risiken geliefert werden.
Dienende Führung – (Leader who serves) Der Scrum Master ist Führer der dem Scrum-Team dient. Das heißt, er verfügt zwar über Einfluss, hat aber keine Autorität bezüglich der Arbeitsorganisation im Team. Er agiert als Coach und als Change Agent.
Dokumentation – Diese ist auch in agilen Projekten notwendig und hilfreich. Es gelten jedoch vorrangig die Grundsätze des Agilen Manifests (Working software over comprehensive documentation).
Done – In Scrum wird strikt unterscheiden zwischen »nicht fertig« und „fertig“. Ein Backlog Item gilt als „Done“, wenn alle Tasks erledigt sind und die Kriterien der Definition of Done erfüllt sind.
Developer – Die Developer führen alle Arbeiten aus, um die Anforderungen in ein nutzbares Produkteinkrement umzusetzen. Sie managen ihre Arbeit selbst.
Entwicklungsgeschwindigkeit (Velocity) – Ist die Summe aller Aufwände (Story Points), die das Scrum-Team in einem Sprint umgesetzt hat. Über die Zeit pendelt sich die Entwicklungsgeschwindigkeit auf einen relativ stabilen Wert ein. Die Entwicklungsgeschwindigkeit zu kennen ist für den Product Owner wichtig, damit er den Releaseplan erstellen und im diesen im Verlauf des Projektes justieren kann.
Epic – Ist eine grobgranulare Anforderung (große User Story), die zu groß oder zu komplex ist, um Sie in einem Sprint umzusetzen. Sie wird später, wenn die Kundenanforderungen klarer und mehr Details bekannt sind, im Product Backlog aufgeteilt in Stories.
Estimation – Damit ist meistens das Schätzen des Aufwandes von Product Backlog Items, bzw. User Stories gemeint. Schätzmethoden sind z.B. Planning Poker und Magic Estimation.
Estimation Meeting – Das Estimation Meeting (auch Backlog Refinement genannt) ist das Planungsmeeting mit dem Product Owner, um Klarheit für den nächsten Sprint zu erhalten. Ziel dabei ist: Details zu klären, Aufwände zu schätzen und die Priorisierung zu überprüfen.
Event (Ereignis) – Siehe Scrum Event.
Extreme Programming – Ist eine agile Softwareentwicklungsmethode, die mehrheitlich von Kent Beck entwickelt wurde. Sie folgt den fünf zentralen agilen Werten: Kommunikation, Einfachheit, Respekt, Feedback und Mut.
Feature —Ist eine funktionale Eigenschaft des zu entwickelnden Produktes.
Geschäftswert – siehe Business Value
Hindernis (Impediment) – Sind Probleme jeglicher Art, welche das Scrum-Team bei der effektiven Ausführung ihrer Arbeit behindern.
Impediment – siehe Hindernis
Impediment Backlog – Ist eine öffentliche im Teamraum aufgehängte Arbeitsliste des Product Owners mit allen Hindernissen.
Increment – Ein Increment ist ein Teil eines Ganzen. Unter einem Product Increment im Scrum versteht man das Ergebnis eines Sprints, als fertiges Teilstück des Gesamtproduktes.
Inspect & Adapt – Ein Prinzip der permanenten Verbesserung. Die eigene Arbeit wird in regelmäßigen Abständen überprüftund die Arbeitsprozesse, wenn notwendig, in der nächsten Iteration angepasst.
INVEST – Gute User Stories entsprechen INVEST-Kriterien. Sie sind: (I) Independend unabhängig, (N) Negotiable verhandelbar, (V) Valuable nützlich, (E) Estimable schätzbar, (S) Small klein, (T) Testable testbar
Iteration – Ein Zeitabschnitt, in dem ein Inkrement des Produktes entwickelt wird. In Scrum wird dieser „Sprint“ genannt, welcher immer gleich lange dauert.
Iterativ-inkrementell – In Scrum wird diese Technik verwendet, um durch kurze Feedbackzyklen Software zu erstellen. Iterativ (in einzelnen Sprints), werden Inkremente (fertige Produktteile) geliefert.
Kunde – Ist derjenige, der das Produktergebnis beauftragt (der Auftraggeber) und bestimmt, was dieses leisten soll und auch dafür bezahlt.
Lean Management – Ist eine Management-Philosophie, die Denkprinzipien, Methoden und Verfahrensweisen zur effizienten Gestaltung der gesamten Wertschöpfungskette von Produkten umfasst.
Magic Estimation – Ähnliche Aufwandschätz-Methode für User Stories wie Planning Poker®, jedoch einiges effizienter.
Manager – (Linien-) Manager sind wichtige Stakeholder auch bei Scrum-Projekten. Sie können das Projekt unterstützen und Hindernisse beseitigen, aber auch ein Umfeld schaffen, indem agile Prinzipien und Projekte sich entwickeln können.
MetaScrum – Ist ein Team von Product Ownern in Scrum@Scale, die selber ein Backlog koordinieren, welches dann ein Scrum of Scrums (SoS) speist. Zu jedem SoS gibt es ein zugehöriges MetaScrum.
Minimal Marketable Feature (MMF) – Ist die kleinstmögliche Menge an Funktionen, die für sich genommen vermarktbar ist. Software, die nur eines dieser Merkmale aufweist, hat einen Nutzen für den User, für den dieser bezahlen würde.
Minimal Viable Product (MVP) – Das Minimal Viable Product ist die minimale Menge von Features, die notwendig sind, um herauszufinden, was ein Kunde möchte. Es ist eine Strategie, um schnelles und breites Feedback vom Kunden zu erzielen, ohne das Produkt bis zu seiner Marktreife auszuarbeiten.
MuSCoW – Die MuSCoW-Methode ist eine Technik zur Priorisierung, um Backlog Items grob in vier Kategorien einzuordnen: Must have, Should have, Could have, Won’t have.
PBI – Product Backlog Item. Ein Element des Product Backlogs
PDCA-Zyklus – Ist ein vierstufiger Managementprozess, der zur ständigen Verbesserung bei der Softwareentwicklung verwendet wird: Plan (P), Do (D), Check (C) und Act (A).
Planning – siehe Sprint Planning
Planning Poker® – ist eine Technik für die Aufwandsschätzung von Backlog Items im Estimation Meeting. Dabei wird besonders Wert darauf gelegt, dass die Grösse eines Features geschätzt wird und nicht der Aufwand.
Product Backlog – Das Product Backlog eine Liste von Anforderungen (User Stories), die im laufenden Projekt umgesetzt werden sollen. Es wird vom Product Owner priorisiert, bereitgestellt, verantwortet und gemeinsam mit dem Developern gepflegt.
Product Increment – Ist lauffähige, getestete und dokumentierte Software, die Anforderungen aus dem Product Backlog umsetzt. Das Product Increment ist das Ergebnis eines Sprints.
Product Owner – Der Product Owner ist für den wirtschaftlichen Erfolg und das „Was“ im Scrum-Projekt verantwortlich. Er plant und steuert die Entwicklung in Scrum. Er ist Owner des Product Backlogs, priorisiert es und legt damit fest, welche Features wann realisiert werden.
Product Backlog Item (PBI) – Dies ist eine Anforderung, üblicherweise beschrieben in einer User Story. Es ist eine Arbeitseinheit, die klein genug ist, damit das Scrum-Team diese in einem Sprint abschließen kann.
Product Backlog Refinement – So wird die laufende Pflege des Product Backlog bezeichnet (siehe auch Estimation Meeting).
Produktvision – Die Produktvision wird vom Product Owner vor dem ersten Sprint erstellt. Sie leitet das Scrum in die richtige Richtung und ist ein übergeordnetes Ziel, dass jeder teilen muss, das Scrum Team, der Kunde und die Stakeholder. Die Vision beschreibt, warum das Projekt unternommen wird und was der erwünschte Endzustand ist.
Prognose – Die Developer lieferen im Sprint Planning eine Prognose, welche Backlog Items sie im nächsten Sprint umsetzten.
Release – Ist eine Softwareversion, die vom Anwender produktiv eingesetzt werden kann. Ein oder mehrere Release ist das Ergebnis des Scrum-Projektes.
Release-Burndown-Chart – Dies ist ein Burndown-Chart, das für jeden Zeitpunkt eines Projekts zeigt, wie viele Story Points bis zum Releaseende noch umzusetzen sind.
Releaseplanung – Ist die Mittelfristplanung des Projektes und gibt dem Kunden eine Übersicht, wann er welche Funktionalitäten geliefert bekommt.
Scaled Daily Scrum (SDS) – Ist ein Ereignis von Scrum@Scale. Bei großen Projekten spiegelt der SDS-Event das Daily Scrum wider, indem es die Zusammenarbeit und Leistung des Netzwerks von Teams optimiert.
Scrum Events (Ereignisse) – In Scrum gibt es fünf Events. Vier sind Meetings des des Scrum-Teams: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospektive und der fünfte ist der Sprint selbst.
Scrum Guide – Wird herausgegeben und regelmässig updated von Ken Schwaber und Jeff Sutherland und beschreibt die offiziellen Scrum Grundlagen. Die neuste Version ist vom November 2017.
Scrum@ScaleTM Guide – Wird herausgegeben von Jeff Sutherland und Scrum Inc. und beschreibt wie Scrum einfach skaliert werden kann. Die erste Version ist im Februar 2018 erschienen.
Scrum Master – Der Scrum Master ist eine Scrum-Rolle. Er hilft, Scrum richtig anzuwenden, unterstützt das Team und stellt die optimale Zusammenarbeit zwischen Product Owner und Developern sicher. Der Scrum Master beseitigt Hindernisse und hilft dem Team, seine Produktivität kontinuierlich zu steigern.
Scrum of Scrums (SoS) – Ist ein Team von Scrum Mastern und weiterer Fachfunktonen der beteiligten Scrum-Teilprojekte. Ein SoS agiert als Release-Team und muss in der Lage sein, den Kunden direkt Geschäftswert (Value) zu liefern.
Scrum of Scrums Master (SoSM) – Ist eine Rolle des Scrum@Scale. Es ist ein Team von Scrum Masters welches am Ende jedes Sprints verantwortlich ist für ein vollständiges Paket von potenziell lieferbaren Produktinkrementen von allen beteiligten Teams.
Scrum-Rollen – Sind: Product Owner, Scrum Master, Developer
Scrum-Team – Besteht aus den drei Scrum Rollen: Product Owner, Scrum Master, Developer
Scrum-Werte – Scrum basiert auf fünf Werten: Verpflichtung, Mut, Fokus, Offenheit und Respekt. Wenn diese Werte durch das Scrum-Team verkörpert und gelebt werden, werden die Scrum‐Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen bei allen Beteiligten Vertrauen zueinander auf.
Selbstmanagement – (Selbstorganisation) Ist ein wesentliches Merkmal von Scrum-Teams. Das Team managt seine Arbeit selber. Entscheidungen werden im Team getroffen, das Team einigt sich auf teaminterne Regeln und Arbeitsweisen. Einzig die Erreichung des Sprint-Ziels ist ein Maßstab für das Team.
Selected Product Backlog – siehe Sprint Backlog.
Servant Leadership – Der Scrum Master ist ein Leader, der dem Scrum Team dient. Das bedeutet, dass er zwar Einfluss hat, aber keine Autorität über die Organisation der Arbeit im Team besitzt. Er agiert als Coach und Change Agent.
Sprint – In Scrum werden Iterationen als Sprint bezeichnet. Ein Sprint hat eine feste Dauer, in welcher die Developer die Anforderungen des Kunden in funktionsfähige Software umsetzen.
Sprint Backlog – Im Sprint Planning entscheiden die Developer, wie viele der am höchsten priorisierten Backlog Items es in den folgenden Sprint implementieren können. Die gewählten Items sind dann das Sprint Backlog für den folgenden Sprint. Das Sprint Backlog entspricht der Forecast der Developer, was sie im startenden Sprint gemeinsam erreichen wollen.
Sprint Burndown Chart – siehe Burndown Chart
Sprint Planning Meeting – Das Sprint Planning Meeting findet zu Beginn eines Sprints statt und besteht aus zwei Teilen. Beide Meetings dauern jeweils max. vier Stunden für einen 4-Wochen Sprint.
Im ersten Teil definiert das Scrum-Team das Sprint Backlog, also WAS es im nächsten Sprint umsetzen will. Im zweiten Teil werden die Implementierungsdetails, das WIE geklärt. Am Ende des Sprint Plannings sind alle User Stories (WAS) und die dazugehörigen Tasks auf dem Taskboard dargestellt.
Sprint-Retrospektive – Wird nach jedem Sprint-Review durchgeführt. Der Sprint und die Geschehnisse werden analysiert und es werden Maßnahmen für die nächsten Sprints definiert, mit dem Ziel stetig zu lernen und besser zu werden.
Sprint-Review – Findet am Ende jedes Sprints statt, mit dem Ziel die entstandenen Arbeitsergebnisse dem Product Owner, dem Kunden und den Stakeholdern vorzustellen und Feedback zu erhalten. Der Scrum Owner überprüft dabei, ob die Developer alle User Stories, gemäß Prognose, umgesetzt haben.
Sprint-Abbruch – Der Product Owner kann einen Sprint abbrechen, wenn er sieht, dass das Sprint-Ziel entweder nicht erreicht werden kann oder inzwischen nicht mehr sinnvoll ist. In diesem Fall wird ein Sprint-Review durchgeführt und alle abgeschlossenen „Done“ Product Backlog-Einträge begutachtet und wenn brauchbar vom Product Owner abgenommen.
Sprint-Ziel – Das Sprint-Ziel wird vom Product Owner definiert und beschreibt das auszuliefernde Produktinkrement – möglichst in einen Satz. Es ist das, was der Product Owner am Ende des Sprints an den Kunden ausliefern will.
Stakeholder – (Interessensvertreter) werden Personen bezeichnet, die vom Projektergebnis betroffen oder daran interessiert sind, aber nicht am Projekt aktiv mitwirken, z.B. Anwender, Kunde, Vertrieb, Marketing, Manager.
Sprint 0 – So wird ein initialer Sprint genannt. Dieser ist meist kürzer als ein normaler Sprint und produziert keinen Business Value. Hier wird z.B. das Product Backlog vorbereitet, die Infrastruktur aufgesetzt, Architekturfragen geklärt und Regeln definiert, wie das Scrum-Team zusammenarbeitet.
Story – siehe User Story
Story Card – Beschreibt ein Backlog Item (User Story) auf einer Karteikarte mit max. zwei Sätzen. Auf der Vorderseite steht zusätzlich der Business Value und der Aufwand in Story Points. Auf der Rückseite stehen z.B. noch Abnahmekriterien und die Teststrategie.
Story Point – Story Points sind eine abstrakte Einheit, mit welcher der Aufwand (Grösse) eines Backlog Items bewertet wird, immer relativ zur einer anderen Story. Der Aufwand kann nur bestimmte vordefinierte Werte annehmen, die meistens der Fibonacci-Sequenz entsprechen.
Task – Im Sprint Planning definieren die Developer die Tasks (Aktivitäten, Aufgaben) mit denen die User Stories umgesetzt werden. Diese werden dann auf dem Taskboard neben den User Stories befestigt.
Taskboard – Das Taskboard visualisiert das Sprint Backlog. Darauf lässt sich jederzeit erkennen, welche Product Backlog Einträge für den Sprint ausgewählt wurden, welche Aufgaben (Tasks) dazu zu bearbeiten sind, und in welchem Bearbeitungszustand diese Aufgaben sind.
Team – siehe Scrum-Team
Timebox – Alle Scrum-Events haben eine zeitliche Beschränkung (Timebox). Der Event wird nach einer bestimmten Zeit beendet, auch wenn diese noch nicht inhaltlich abgeschlossen ist. Die Timebox hat zum Ziel, Verschwendung zu vermeiden, um sich auf die wirklich wichtigen Dinge im Sprint zu fokussieren.
User – Als User bzw. (End-) Nutzer bezeichnet man die Personen, die das Projektergebnis nutzen. Scrum stellt das Liefern von Funktionalität für einen User in den Vordergrund, nicht die Erfüllung von Aufgaben. Es ist eine bewährte Vorgehensweise, die Backlog Items aus Sicht des Nutzers in einer User Story zu beschreiben.
User Story – Auch Product Backlog Items (PBI), bzw. Anforderungen oder Features genannt, werden meistens in User Stories beschrieben. User Stories beschreiben Anforderungen aus der Sicht des Anwenders. Verfasst werden User Stories in einer speziellen Schreibweise: Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen/Grund> erreichen.
Velocity – siehe Entwicklungsgeschwindigkeit
Vision – siehe Produktvision
Werte – siehe Scrum-Werte
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
