Scrum Begriffe

In Scrum gibt es einige englisch-sprachige Begriffe, die im normalen Sprachgebrauch trotz fortschreitendem Anglizismus (noch) nicht verwendet werden. Wir wollen euch daher einen Überblick relevanter Scrum Begriffe geben.

Scrum “besteht” aus 3 Rollen, 4 Ereignissen (auch “Zeremonien”, also fixe Termine, da wir “Meetings” vermeiden;) und 3 Artefakten. Doch was ist eigentlich Scrum?

 

SCRUM

Scrum ist ein Rahmenwerk für agiles Projektmanagement und somit mehr als bloß eine Methode. Besonders beliebt und weit verbreitet ist Scrum in der Softwareentwicklung, da schnell und einfach brauchbare Ergebnisse geliefert werden können. Gearbeitet wird mit cross-funktionalen, multidisziplinären Teams, die in kurzen Abständen (Iterationen aka Sprints) funktionierende Teil-Umsetzungen erstellen. Für einen effektiven Arbeitsprozess sorgen die enge Zusammenarbeit mit den Kunden, dessen Feedback sowie der Team-Spirit. Obwohl Scrum für die Softwareentwicklung entwickelt wurde, werden Methoden und Ableitungen daraus mittlerweile auch im Management, in der Administration, im Verkauf, im Marketing und in weiteren Fachgebieten eingesetzt.

 

EINLEITENDE SCRUM BEGRIFFE

STAKEHOLDER (SH)

Stakeholder ist keine Rolle in Scrum, man verwendet diesen Begriff allerdings als Sammelbegriff für eine bestimme Art von Akteuren: nämlich jenen Personen, die direkt oder indirekt am Projekt bzw. am Produkt beteiligt sind. Je nach Aufgaben des Stakeholders differenziert man meist zwischen den 3 Rollen Kunde, Anwender & Manager.

SPRINT

Scrum funktioniert iterativ, wobei jede Iteration (Sprint) zw. 2 und 4 Wochen dauert. In dieser Zeit möchte das Team eine Auswahl von Aufgaben vollständig abarbeiten. Nach dieser Zeit (am Ende eines Sprints) liefert das Team als Ergebnis ein Inkrement (= Teilstück einer funktionierender Software). Durch die schnelle Einsetzbarkeit des Produkts liefert der Kunde meist direktes Feedback zum Produkt und zum Prozess.

DEFINITION OF DONE (DoD)

Die DoD ist eine Liste von Fertigstellungs-Kriterien, die das Team zur Abarbeitung seiner Aufgaben berücksichtigen muss. Ziel ist, eine gleichbleibende Qualität zu garantieren. Die Definition of Done-Kriterien gelten für jedes Backlog Item und werden vom Team selbst erstellt bzw. bearbeitet und kann mehrere Teilaspekte der Entwicklung betreffen (Testen, Dokumentation, …).

SCRUM ROLLEN

Die Rollen beschreiben jene Positionen, die unabhängig vom Unternehmens-Organigramm neu im Team eingeführt und von jemandem besetzt werden müssen.

PRODUCT OWNER (PO)

Der PO vertritt die Interessen der Kunden und ggf. weiterer Stakeholder. Er hat stets ein Auge am Markt bzw. beim Kunden, um den Markt und die Anforderungen zu verstehen. Zum anderen sorgt der PO dafür, dass sich sein Team stets mit den richtigen Dingen beschäftigt. Dazu verwaltet der Product Owner eine Queue (eine geordnete Liste, sog. Product Backlog), welche er mit Items (Anforderungen, meist Issues oder Stories genannt) füttert, die dem Produkt noch fehlen. Dieses Backlog zu verwalten bzw. zu verfeinern (refinen) ist auch gleichzeitig die Hauptaufgabe eines POs, sowie diese richtig zu priorisieren. Die im Sprint festgelegten Tätigkeiten sollen den Kunden einen echten Mehrwert bringen.

SCRUM MASTER (SM)

Der SM ist nicht anderes als der Team-Coach. Er achtet auf die Einhaltung der Scrum-Spielregeln und schützt das Team während des Sprints vor Hindernissen (Impediments) und Einflüssen von außen. Das Team soll konzentriert an den vereinbarten Ziele arbeiten können. Weiters hilft der Scrum Master dem Team bei der laufenden Prozess-Verbesserung – dh schneller zu werden und eine hohe Qualität zu liefern.

DEVELOPMENT TEAM (DEV oder Team)

Das Team ist cross-funktional, multidisziplinär und selbstständig. Kurz: Sie sind fähig, alle Aufgaben (Analyse – Design – Umsetzung – Testen) selbständig bis zur Auslieferung (Release) zu steuern. Das Team besteht meist aus mehr als nur reinen Entwicklern (so wird zB das Thema Datenschutz oft von geschulten Rechtsanwälten begleitet, die das Team je nach Notwendigkeit einlädt) und ist zw. 5 und 9 Mitgliedern groß. Sie planen ihre Tätigkeiten selbst und führen diese während des Sprints auch selbstständig durch. Diese Eigenverantwortung ist auch das Kennzeichnende an Scrum.

 

SCRUM ZEREMONIEN

Mit Zeremonien meint man Ereignisse (aka Termine, Meetings).

DAILY SCRUM (DS oder Daily)

Das DS findet täglich statt und dauert genau 15 Minuten (Timebox). Das Daily findet als Standing (also im Stehen) statt und wird deshalb auch gerne Daily Standup genannt. Ziel: Jeder soll so effektiv wie möglich beschäftigt sein und beantwortet deshalb stehend folgende 3 Fragen:

• Was habe ich seit dem letzten Mal getan?
• Was werde ich bis zum nächsten Mal tun?
• Was hindert mich derzeit an meinen Umsetzungen?

SPRINT REVIEW (SR)

Im SR zu Ende des Sprints wird das Ergebnis vorgestellt. Dh das Team demonstriert seine Fortschritte und zeigt, dass das Produkt tatsächlich funktioniert und der DoD entspricht. Feedback von anwesenden Stakeholdern ist mehr als erwünscht, der Fokus liegt klar am Produkt bzw. an der Teil-Umsetzung.

SPRINT RETROSPECTIVE (Retro)

Jeder Sprint endet mit einer Evaluation – der sog. Retro. Gemeinsam wird auf den Arbeitsprozess des (noch) aktuellen Sprints geblickt. Was lief gut, was lief weniger gut? Was muss beibehalten, was verbessert werden? Der Fokus liegt klar am Prozess bzw. beim Team.

SPRINT PLANNING (Plan)

Jeder Sprint beginnt mit einem Plan. In diesem Ereignis bespricht der PO die Aufgaben, die er vom Team erledigt haben möchte. Diese Backlog Items wählt das selbstständig aus und berücksichtigt, dass diese in einem einzigen Sprint abgearbeitet werden können. Das Team teilt diese wie erwähnt in Unteraufgaben und versieht diese mit einer Schätzung. Raus kommt ein ein Sprintplan, der in wenigen Wochen umzusetzen ist.

 

SCRUM ARTEFAKTE

Artefakte sind Ergebnisse von Aktivitäten (zB auslieferbarer Code).

PRODUCT BACKLOG (PB)

Der PB ist eine Queue (= geordnete Liste) mit noch offenen Tätigkeiten und Aufgaben für das jeweilige Produkt, welche mit Anforderungen gefüttert wird. Diese Anforderungen nennt man Product Backlog Items – bei diesen handelt es sich meist um User Stories. Eine User Story umfasst immer einen bestimmten Mehrwert (Business Value), welcher angibt wie viel Wert ein Item für den eigentlichen Benutzer hat. Dazu führt das Team Schätzungen (meist anhand von Story Points durch), auf Basis derer wiederum (erwarteten Werts vs. erforderlicher Einsatz) der RoI (Return on Investment) berechnet werden kann.

SPRINT BACKLOG (SB)

Der SB ist eine Auswahl von den oben genannten (PB) Aufgaben, die das Team während des Sprints abarbeiten möchte. Um diese Aufgaben in Unteraufgaben aufzuteilen dient das Sprint Planning. Dabei geht das Team nach dem Pull-Prinzip vor: Die Mitglieder nehmen sich selbst die Aufgaben, welche sie für wichtig erachten und deren Wissen und Erfahrung entsprechen.

INKREMENT

Das Ergebnis eines Sprints – der Umfang wurde zuvor im Sprint Backlog erfasst – ist das Inkrement, also das Teilergebnis bzw. die funktionsfähige Teil-Umsetzung.

 

WEITERE SCRUM BEGRIFFE

BURNDOWN CHART

Der Fortschritt eines Sprints wird in einer für jeden einsehbaren Grafik dargestellt. 2 Linien zeigen die verfügbaren Kapazitäten sowie die Zeit. Sie gibt Auskunft darüber, ob der Sprint plangemäß verläuft und wird deshalb einmal am Tag aktualisiert.

PLANNING POKER

Planning Poker ist eine Schätzmethode, um gemeinsam im Team Schätzungen abgeben zu können. Dazu notwendig sind Karten (welche eine Zahl ähnlich einer Fibonacci-Folge repräsentiert), welche die Arbeit an einem bestimmten Backlog Item schätzen soll. Bei der Schätzung sollen Komplexität und Umfang der Aufgabe geschätzt werden. Jeder zieht eine Karte, legt diese verdeckt auf den Tisch und deckt diese gleichzeitig mit allen anderen auf. Unterschiedliche Schätzungen werden diskutiert und wiederholt, bis Einstimmigkeit vorherrscht. Vorteil: Die dadurch angeregte Diskussion sichert, dass auf nichts vergessen wird und zusätzlich jedes Mitglied eingebunden wird, wodurch eine zuverlässige Schätzung erreicht werden kann.

SCRUM BOARD

Beim Scrum bzw. Task Board handelt es sich um eine (virtuelle) Tafel, die alle Backlog Items des aktuellen Sprints (Sprint Backlog) repräsentiert. Die Aufgaben am Board sind meist auf 3 oder mehr Spalten verteilt: To Do (Offen), In Progress (In Arbeit) und Done (Fertig). Der Einsatz von virtuellen Boards (zB JIRA Boards) nimmt zu und wird oft dazu verwendet, um nicht an einem Ort gebunden zu sein. Das Board ist meist der Mittelpunkt eines jeden Teams und regt zu Besprechungen von offenen Aufgaben und beschlossenen Maßnahmen an. Die hoch priorisierten Aufgaben befinden sich oben und geben einen Überblick zum aktuellen Status.

TEAM VELOCITY

Die Team-Geschwindigkeit (Velocity) bezeichnet die Menge an Arbeit, die ein Team in einem einzelnen Sprint bearbeiten hat. Auf dieser Basis kann das Team schätzen, wie viel Arbeit es pro Sprint schaffen kann.

USER STORY (US)

Eine User Story ist ein Product Backlog Item, welches Kunden-Anforderungen (Requirements) beschreibt, die noch zu realisieren sind. Dabei werden im Unterschied zu klassischen Anforderungsbeschreibungen beschrieben, warum etwas getan werden muss. Es geht nicht darum, das “Wie” festzuhalten, sondern die Sicht des Kunden darzustellen, damit der Umsetzer eine passende Lösung entwickeln kann. Das “Wie” wird erst im Sprint Planning festgelegt. Zusätzlich werden Abnahmekriterien (AKs, selten auch Akzeptanzbedingungen genannt) in die US aufgenommen werden.

JIRA

JIRA ist ein online Vorgangs- und Projektverfolgungs-Tool für Softwareteams – also eine Webanwendung zur Fehlerverwaltung, Problembehandlung und operativem Projektmanagement. Primär wird JIRA für die Softwareentwicklung eingesetzt, findet aber auch immer mehr in nicht-technischen Bereichen für das Aufgabenmanagement Verwendung. JIRA unterstützt vor allem das Anforderungsmanagement, die Statusverfolgung sowie den Fehlerbehebungsprozess und lässt sich auch im “Workflow-Management” (Ablauforganisation) für Prozessmanagement und -verbesserung verwenden.

ISSUE / TASK / TYPEN

Ein Issue bzw. ein Task ist eine Aufgabe oder ein Problem, das gelöst werden muss. Dabei unterscheiden Teams meist zwischen speziellen Typen:

• Story: eine Anforderung (Feature), die noch nicht realisiert ist
• Spike: ein Analyse-Task, der neue Erkenntnisgewinne bringen soll und meist als Vorarbeit für eine Story dient
• Bug: ein Fehler, der am System auftritt und eine Funktion an der korrekten Ausführung hindert

 

BEREIT DEN AGILEN WEG EINZUSCHLAGEN?

Dann kontaktieren Sie uns!