Scrum Glossar

Auch als „Manifest für agile Softwareentwicklung“ bezeichnet. Hier haben sich namhafte Entwickler, Coaches und Autoren (u.a. Ken Schwaber, Jeff Sutherland, Mike Beedle) auf Werte und Prinzipien für die agile Softwareentwicklung geeinigt. 

Siehe www.agilemanifesto.org (extern)

Qualitätskriterien, die ein Produkt (oder ein Teil davon) erfüllen muss, um von relevanten Stakeholdern abgenommen werden zu können – meist werden diese aus Kundensicht formuliert.

„Wünsche“ bzw. Qualitätskriterien des Kunden, relevanter Stakeholder und/oder des Scrum Teams an das Produkt, siehe Requirement. Werden vom Product Owner aufgenommen.

Das Scrum Backlog (auch Product Backlog) ist ein Scrum Artefakt und die einzige Anforderungsquelle. Enthält alle Einträge/Anforderungen, die in einem Produkt enthalten sein sollten. Ist stets angemessen detailliert, geschätzt, dynamisch und priorisiert. Wird durch den Product Owner gemanagt.

Das Backlog Refinement ist das "Tagesgeschäft" des Product Owners. Es bezeichnet die stetige Ausformulierung, Verfeinerung und Priorisierung von Einträgen im Product Backlog. Input holt sich der Product Owner von Stakeholdern (Business Value) und/oder Developern (Kosten, Aufwände, Risiken).

Methoden und Prozesse haben sich im Laufe der Zeit etabliert, wurden bis zum Optimum verfeinert/verbessert und bringen stets beste Ergebnisse.

Tool, welches den Fortschritt der Arbeit des Teams auf Release- oder Sprintebene zeigt und Prognosen zulässt. Auf der Y-Achse ist der Aufwand (Story Points, Stunden) zu sehen, auf der X-Achse die Zeit (Sprints, Tage).

Wirtschaftliche Betrachtung eines Projektes mit zentraler Kosten-/Nutzen-Abwägung.

Das Daily Scrum - auch: Daily Stand Up genannt - ist ein Scrum Event. Tägliche Synchronisation des Development Teams, bei der geprüft wird, ob das Sprint Ziel erreicht werden kann und wo Hindernisse bei der Arbeit gesehen werden. Alle 24 Stunden am selben Ort / in der gleichen Session zur selben Zeit mit einer maximalen Dauer von 15 Minuten. 

Ein definierter Prozess kann mit allen Zwischenschritten sehr genau im Vorfeld festgelegt bzw. vorhergesagt werden, siehe Best Practices. Regelmäßige oder stichprobenartige Inspektion des Fortschritts durch Vergleich von IST mit SOLL. Wiederholung des Vorgehens bringt gleiches Ergebnis.

Qualitätsanspruch, den das Scrum Team an sich selbst stellt. Enthält eine Reihe von Kriterien und Aktivitäten, die erfüllt sein müssen, um ein Produkt oder Teile davon auslieferbar oder nutzbar und für das Sprint Review „vorzeigbar“ zu machen. Eine DoD ist für jeden Backlogeintrag zu definieren.

Eine Reihe von Kriterien, die ein Product Backlog Eintrag erfüllen muss, um in einem Sprint Planning in das Sprint Backlog überführt werden zu können (z.B. ausreichend verfeinert und geschätzt).

Entwickler, Spezialisten, selbst-gemanagt, keine Titel und Hierarchien, erstellt den Sprint Plan bzw. das Sprint Backlog und das (Product) Increment.

Erwartet das Unerwartete. Vorgehen oder Methode, welche(s) sich auf Basis von Erfahrungen weiterentwickelt. Planung von Zwischenzielen/Iterationen. Häufige Kontrolle des IST-Zustandes und ggf. Anpassung. Ziel: Best Practices.

Auch: Meeting, Veranstaltung. Gekennzeichnet durch eine Time Box (max. zulässiger Zeitrahmen). In Scrum gibt es insgesamt 5 Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Ein Event ist spätestens dann beendet, wenn die Time Box abgelaufen ist. Darf beendet werden, sobald Sinn und Zweck erfüllt sind (mit Ausnahme des Sprints).

Auch: Rahmenwerk, Regelwerk, Leitplanken. Kann eine oder mehrere Methoden und Techniken enthalten. Scrum versteht sich nicht als Softwareentwicklungs- oder Projektmanagementmethode. Stattdessen definiert Scrum einen Rahmen bestehend aus Rollen, Events und Artefakten. Innerhalb dieses Rahmens ist das Team frei, sich zu managen und Methoden und Techniken festzulegen, um ein optimales Ergebnis zu erzielen.

Eine Methode zum Schätzen von relativen Größen der Arbeit, der Komplexität bzw. des Aufwandes.

Ein Eintrag im Product Backlog (z.B. Anforderung, Feature, Defect, Use Case, Improvement…).

Eine Rolle im Scrum Framework, die für das Ergebnis/Produkt verantwortlich ist. Der PO definiert in Absprache mit relevanten Stakeholdern und dem Scrum Team Anforderungen und Qualitätskriterien. Er managt das Product Backlog und trifft Entscheidungen hinsichtlich der Priorisierung und Releases. Stellt Roadmap auf und plant auf auf nahezu allen Ebenen. Schnittstelle für das Scrum Team zum Business und den Stakeholdern.

Mehr Infos zu Product Owner vs Scrum Master

Ein Scrum Artefakt, Teil eines Ganzen, sollte potenziell nutzbar und/oder auslieferbar sein. Muss die DoD-Kriterien erfüllen, auch wenn nicht ausgeliefert wird, um Restarbeit zu vermeiden.

Visuelle Darstellung der (Product) Vision, Idee. Enthält z.B. Zielgruppen, Hauptfeatures, Business Case und Unique Selling Proposition (USP).

Der Release - also die Freigabe und Auslieferung eines Increments nach Abschluss eines Sprints - wird vom PO in Absprache mit Kunden, relevanten Stakeholdern und dem Scrum Team geplant. 

Scrum Event, mit dem der Sprint endet. Scrum Team wertet aktuellen Sprint aus und identifiziert Maßnahmen zur Verbesserung des eigenen Vorgehens. Mindestens eine Aktivität zur Verbesserung sollte gleich im nächsten Sprint umgesetzt werden. Max. Dauer = 3 h pro Sprint Monat.

Ein Scrum Event, bei dem mind. ein (Product) Increment, welches die DoD erfüllt, vorgestellt wird. Relevante Stakeholder und Kunden haben die Möglichkeit, Feedback zu geben. Ziele für den/ die nächsten Sprint(s) werden besprochen, neue Anforderungen werden aufgenommen und/oder nicht mehr benötigte Anforderungen verworfen. Max. Dauer = 4 h pro Sprint Monat.

Funktionale oder nicht-funktionale Anforderung an das Produkt im Product Backlog aus Sicht der Kunden/Stakeholder und/oder des Scrum Teams. Wird vom PO formuliert.

Englische Bezeichnung für das angeordnete „Gedränge“ im Rugby-Sport. Der Bezug zu Scrum als Prozess für Projektmanagement und Entwicklung liegt darin, dass das selbst-organisierte Scrum Team im Mittelpunkt steht. 

Der Scrum Master ist eine Rolle im Scrum Framework, die für die Einhaltung des Scrum-Prozesses verantwortlich ist. Sie sorgt dafür, dass Scrum innerhalb der Organisation funktioniert und die nötigen Rahmenbedingungen dafür geschaffen werden. Beseitigt Störungen und Hindernisse, damit das Scrum Team ungestört arbeiten kann. Schützt vor negativen Einflüssen von außen (z.B. Micro-Management, Querkommunikation, Überlastung durch Tagesgeschäft, …).

Mehr zu Scrum Master vs. Product Owner

Steht für alle Verantwortlichkeiten im Scrum Framework: Product Owner, Scrum Master und Developer.

Bedeutet, dass das Scrum Team die Art der Zusammenarbeit, die Regeln, Werkzeuge und Methoden sowie die konkreten Arbeitsschritte selbst festlegt, um die gemeinsam vereinbarten Ziele zu erreichen.

Ein Scrum Event, Herzschlag von Scrum, Container für alle anderen Scrum Events, max. Dauer = 1 Monat bzw. 4 Wochen, Ergebnis = (Product) Increment und aktualisiertes Product Backlog.

Ein Scrum Artefakt, wird von den Developern gemanagt. Zeigt das Sprint Goal und enthält alle PBI’s, die im aktuellen Sprint von den Developern umgesetzt werden sollen. Ziel wird gemeinsam im Scrum Team vereinbart, Art der Implementierung und Umfang wird von den Developern festgelegt.

Abgestimmt zwischen Product Owner, relevanten Stakeholdern und den Entwicklern. Enthält alle nötigen Informationen zur Erreichung eines gemeinsam vereinbarten Ziels am Sprintende. (Vor-) Formuliert vom PO, soll es innerhalb des Scrum Teams von allen verstanden und vereinbart / commitet werden.

Ein Scrum Event, mit dem der Sprint beginnt. PO stellt die Anforderungen bzw. die der Stakeholder vor und erklärt das “Warum?”. Anschließend wird das Sprint Goal vereinbart (das “Was?”). Die Entwickler planen danach die Umsetzung (das “Wie?”) und halten diese im Sprint Backlog fest. Maximale Dauer ist 8 Stunden pro Sprint Monat, Ergebnis = Sprint Goal, Sprint Backlog.

Jemand, der ein besonderes Interesse am Projektergebnis hat, weil  er entweder das Budget zur Verfügung stellt, das Produkt benutzen  wird oder in sonstiger Weise durch das Projekt direkt, aber auch  indirekt betroffen ist. Sind meistens Vertreter der Endanwender  und geben Wünsche und Anforderungen an das Produkt an den PO  weiter.

Synthetische, team- und evtl. projektspezifische Einheit für relative Schätzgrößen von Anforderungen im Product Backlog, spiegeln den Funktionsumfang, ggf. auch die Komplexität von Anforderungen wider.

Maximal zulässige Dauer eines Events. Keine Mindestdauer. Darf nicht verlängert werden.

Gängiges Format einer Anforderungsbeschreibung. Inhalt: (1)  Persona/Zielgruppe, (2) Funktionalität, (3) Mehrwert/Nutzen.  Zusätzlich z.B.: ID, Wert/Value, Aufwand, Kosten.

Verbleibende Arbeit an einem „done“ (Product) Increment, die vollbracht werden muss, um es auslieferbar zu machen. Meistens durch andere Stellen/Personen durchgeführt, wie z.B. Qualitätssicherung oder spezifisches Testing.

Alleinstellungsmerkmal, welches das Produkt einzigartig macht.

Engl. für „Wert“, relativ geschätzte Größe für den Wert bzw. die Wichtigkeit einer User Story, um effizienter priorisieren zu können. Nutzenwertigkeit wird zwischen Kunden und PO, technische Wertigkeit zwischen Developern und PO ausgehandelt.

Geschwindigkeit, mit der die Developer Aufgaben erledigen, gemessen z.B. in Story Points pro Sprint. Wird regelmäßig gemessen, analysiert und ausgewertet, um immer bessere Vorhersagen treffen zu können.