Scrum

Das Backlog ist ein Artefakt aus dem Scrum-Framework. Enthält die Summe / den Rückstau aller Aufgaben, an denen das Team arbeiten darf. Das Backlog wird vom Product Owner gemanagt. Dabei enthält ein Product Backlog alle Leistungsmerkmale für die Entwicklung und den Betrieb deines Produktes, das Project Backlog alle Aufgaben im Rahmen eines Projektes.

Tägliches 15 minütiges Meeting im Scrum Framework während des Sprints. Das umsetzende Team trifft sich, um sich kurz auf den aktuellen Stand zu bringen und sich gegenseitig zu synchronisieren. Da diese Meetings im Stehen stattfinden auch als „Stand-Up Meeting“ bezeichnet.

Rolle / Verantwortung im Scrum Framework, 6 ± 3 Personen, setzen die priorisierten Aufgaben selbstorganisiert gemäß der “Definition of Done” um, schätzen den Umfang und verpflichten sich (autonom) auf das Sprint-Ziel.

Konkretes Arbeitsergebnis am Ende des Sprints, erfüllt die “Definition of Done”.

Das „Product Backlog Item“ ist ein Eintrag in deinem (Product) Backlog und bezeichnet ganz allgemein eine Arbeitseinheit.

Verfahren, um während des Sprint Plannings in einem Scrum Team den Aufwand anstehender Aufgaben zu schätzen. Dabei schätzen Teammitglieder „verdeckt“ und unabhängig voneinander und spielen gleichzeitig ihre Planning Poker Karte aus. Die Werte auf den Karten orientieren sich an der Fibonacci Reihe (1, 2, 3, 5, 8, 13, 21 …).

Rolle / Verantwortung im Scrum Framework. 1 Person, balanciert Business und User Interessen für maximalen Wert, pflegt und priorisiert das Backlog. Ist erster Ansprechpartner für Stakeholder, Kunden und inhaltliches Feedback.

Meeting im Scrum Prozess, während des Sprints (2-4h / Woche). Ziel: Klärung und Schätzung der Backlog Items, Teilnehmer: Product Owner und Entwickler.

Meeting eines (agilen) Teams am Ende eines Iterationszyklus / Sprints, um die Zusammenarbeit zu reflektieren und Verabredungen für künftige Verbesserungen zu treffen. Im Scrum Prozess, zum Ende des Sprints (3h / 4 Wochen Sprint). Ziel: Optimierung der Zusammenarbeit, Anpassung der Definition of Done, verbindliche Formulierung von Vereinbarungen für den kommenden Sprint zur Optimierung des Arbeitsprozesses. Teilnehmer: PO, Scrum Master, Entwickler.

Meeting im Scrum Prozess, zum Ende des Sprints (4h / 4 Wochen Sprint). Ziel: Vorstellung der Arbeitsergebnisse durch die Entwickler. Teilnehmer: Entwickler, PO, Scrum Master; Kunden und Stakeholder geben Feedback.

Framework für die Organisation mehrerer agiler Teams, sehr auf technische Teams und Organisationen ausgerichtet.

Scrum ist ein Rahmenwerk für die Zusammenarbeit von Teams basierend auf einer Definition von Rollen, Meetings und Werkzeugen, die einem Team Struktur und einen klar definierten Arbeitsprozess basierend auf agilen Prinzipien geben.

Offizielle Erklärung und Dokumentation des Scrum Frameworks, ein „MUST READ“ für jeden der mit Scrum arbeitet. Das letzte Update des Scrum Guide erfolgte im Nov 2020, alle Revisionen von 2010 an findest Du hier.

Rolle / Verantwortung im Scrum Framework (1 Person), ist “Servant Leader” des Teams und befähigt den PO und das Team in der agilen Umsetzung. Schafft den Rahmen, achtet auf “Prozesstreue”, räumt Hindernisse aus dem Weg und ist erster Ansprechpartner für den Arbeits- bzw. Scrum-Prozess.

Skaliertes Scrum Framework mit „Scrum of Scrums“ im Zentrum, konzipiert von Jeff Sutherland. Siehe auch Nexus.

Iterationszyklus von maximal 4 Wochen in einem Scrum Team.

Ein Artefakt aus dem Scrum Framework, enthält alle zu erledigenden Arbeiten für den laufenden Sprint.

Definiertes Meeting im Scrum Framework zu Beginn des Sprints. Dauer 8h in einem 4 Wochen Sprint). Im Planning vereinbart das Scrum Team die Aufgaben für den kommenden Sprint, Definition des Sprint Ziels.

Strukturgebendes Element deines Backlogs. Eine technische Story beschreibt technische, formale und notwendige Anforderungen. Also Anforderungen, die nicht unmittelbar aus Sicht des Nutzer resultieren, jedoch fachlich oder formal notwendig sind. In Abgrenzung dazu beschreibt eine User Story eine Anforderung aus Sicht des Users. Eine Technical Story enthält wiederum mehrere Tasks.

Strukturgebendes Element deines Backlogs. Dabei sind User Stories sind funktionale Anforderungen, die in sich geschlossen einen Wert für den Kunden bzw. den Nutzer schaffen als Teil eines Features. Zudem ist eine User Story eine definierte sprachliche Konvention, um Anwendungsfälle aus Sicht des Nutzers zu beschreiben (“Als [Nutzer] möchte ich [Funktion], damit [Nutzen].”). Das technische Pendant zu einer User Story ist eine Technical Story. Eine User Stories enthält wiederum mehrere Tasks.