AYKEYwords

Agiles Arbeiten ist ganz neu für dich?

Du verstehst nur Bahnhof, wenn die anderen von Review, inkrementell und Sprint Goal sprechen? 
Im agilen Kontext ist Kommunikation das A und O, um Transparenz zu schaffen und Prozesse stetig zu verbessern. Umso wichtiger ist es also, innerhalb der Teams die gleiche Sprache zu sprechen.

Wir haben die wichtigsten Begrifflichkeiten für dich zusammengetragen, damit du im Handumdrehen ein Ass wirst, wenn es um den agilen Austausch geht.

Wir nennen das AYKEYwords.

Agiles Fachchinesisch

Du weißt bereits, was du suchst?

A

Scrum definiert drei spezifische Verantwortlichkeiten – sogenannten Accountabilities – innerhalb des Scrum-Teams: die Entwickler, den Product Owner und den Scrum Master.

Die im Agilen Manifest definierten vier Leitsätze für agiles Arbeiten werden durch zwölf Prinzipien näher in der Praxis ausgeführt. Sie beschreiben, von welche Werten sich Unternehmen bzw. ihre Mitarbeiter und Teams beim agilen Arbeiten leiten lassen.

Das Agile Manifest (Agile Manifesto) ist die Basis für agiles Projektmanagement und wurde 2001 von Kent Beck, Ken Schwaber, Jeff Sutherland, Alistair Cockburn und 13 weiteren Autoren veröffentlicht. Es umfasst vier Leitsätze:

  1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  2. Funktionierende Software mehr als umfassende Dokumentation
  3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  4. Reagieren auf Veränderung mehr als das Befolgen eines Plans 

Agilität ist die Fähigkeit einer Organisation, sowohl flexibel (im Sinne von reaktiv) als auch proaktiv zu handeln sowie die sich immer schneller ändernden Rahmenbedingungen im unternehmerischen Umfeld zu antizipieren und initiativ zu werden, um notwendige Veränderungen einzuführen und sich wandelnden Märkten anzupassen.

Dritte Säule von Scrum:
Der empirische Prozess sieht vor, dass man aufgrund der durch Transparenz (Säule 1) und Überprüfung (Säule 2) gewonnenen Erkenntnisse auch tätig wird.

Die Scrum Artefakte tragen zum reibungslosen Ablauf innerhalb des Scrum Frameworks bei, da sie für einen lückenlosen und kontinuierlichen Austausch von Informationen sorgen und gewährleisten, dass ein optimaler Grad an Transparenz bezüglich der geleisteten Arbeit vorhanden ist. Es gibt im Scrum Guide 3 Scrum Artefakte: das Sprint Backlog, das Product Backlog und das erzeugte Product Inkrement.

DAS SIND WIR - Respektvoll, mutig, offen, engagiert, fokussiert. Wir bringen dein Unternehmen nach vorne.

B

Sammlung von Themen, die bearbeitet werden sollen. Am bekanntesten sind das Product Backlog und das Sprint Backlog.

Ein Eintrag im Product Backlog wird als Backlog Item bezeichnet. Dieses entspricht einer einzelnen Umsetzungsanforderung und wird in der Praxis der agilen Welt oft auch User Story genannt.

Das Überprüfen und Verbessern der Inhalte im Backlog. Meistens wird dabei systematisch vorgegangen und ein gesamtes Backlog überprüft und verbessert.

Eine Vorgehensweise, Methode oder ein Werkzeug, welche sich im Einsatz als besonders geeignet gezeigt hat. Diese existiert nur im einfachen Bereich (siehe Cynefin Framwork).

Eine Grafik, die anzeigt, wieviel in einer Zeiteinheit (innerhalb einer Timebox) umgesetzt wurde. Üblicherweise werden die Story Points pro Tag innerhalb eines Sprints aufgezeigt.

C

Funktionsübergreifende Teams sind wie Superhelden-Teams, in denen verschiedene Personen mit unterschiedlichen, einzigartigen Fähigkeiten für ein gemeinsames Ziel zusammenarbeiten. Das heisst, das Team vereint alle notwendigen Fähigkeiten, die es braucht, um ein spezifisches Produkt zu entwickeln.

Das Cynefin Framework ist ein Modell zur Einordnung von Aufgaben, Problemen und Situationen im Hinblick auf Komplexität und unterstützt die Entscheidungsfindung und Strategieplanung hinsichtlich des weiteren Vorgehensweise, um selbige zu lösen.
Die Einordnung erfolgt dabei in die fünf Bereiche "einfach, kompliziert, komplex, chaotisch und in Aufruhr", welchen jeweils verschiedene Handlungsempfehlungen zugeordnet sind. 

D

Beim Daily (Scrum) trifft sich das Entwicklungsteam, um vorzustellen, woran der Einzelne gerade arbeitet, welche Herausforderungen es gerade gibt und was der Plan für den folgenden Tag ist. Wie der Name schon andeutet, findet dieses Meeting täglich statt. Die Dauer ist dabei üblicherweise auf 15 Minuten beschränkt.

Sie beschreibt im Vorhinein, wann eine User Story im Hinblick auf allgemeingültige Qualitätskritrien als fertig gilt. Die DoD wird vom Scrum Team definiert, schriftlich fixiert, für jedermann zugänglich gemacht und kann in der Retrospektive nachgeschärft werden.

Ist eine User Story geschrieben, so soll sie auch in die Umsetzung gelangen. Um sicherzustellen, dass sie auch eine gewisse Qualität besitzt, die es dem Entwicklungsteam erlaubt ohne zu großen Aufwand die Umsetzung vorzunehmen, wird eine Definition of Ready (DoR) verwendet, die übergreifend für alle User Stories gilt. Hierüber wird geregelt, welchen Vorgaben eine User Story folgen muss.

E

Das Entwicklungsteam setzt sich aus Fachleuten zusammen, die im Verlauf eines Sprints gemeinsam an einem Teil eines Produktes arbeiten. Es handelt sich um ein selbstorganisierendes Team, das für sein Arbeitsergebnis selbst verantwortlich ist. Es entscheidet in Eigenregie, wie viel Arbeit es aus dem Product Backlog übernimmt. Auch wie die jeweiligen Aufgaben erledigt werden, bestimmt es selbst. Während der Product Owner über das „Was“ entscheidet, tut es das Entwicklungsteam über das „Wie“. 

Ein Epic ist ein großes Feature, dessen Fertigstellung sich über mehrere Sprints erstrecken kann. Ein Epic an sich kann auch eine User Story sein, die aber so groß ist, dass sie in mehrere kleinere User Stories zerlegt wird. In einem Projekt ist ein Epic dazu da, um bestimmte Anforderungen und Funktionen zusammen zu fassen. 

Schätzen von Aufwänden für zu entwickelnde Funktionalitäten (Features, User Stories) nach Komplexität (und nicht in Personentagen). Es gibt verschiedene Möglichkeiten des Schätzens wie Planning Poker, Magic Estimation, T‑Shirt-Größen etc.

F

Features bezeichnen die (von den Anwendern gewünschten) Merkmale oder Funktionen des zu erstellenden Produkts.

Die (Scrum-)Fibonacci Reihe wird im Backlog Refinement verwendet, um Backlog Items mit Story Points zu bewerten. Die angepasste Reihe  lautet: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Der Wert "Fokus" steht dafür, dass sich das Scrum Team auf die Erreichung des Sprint Ziels fokussiert und nicht versucht parallel noch möglichst viele andere Anfragen zu bearbeiten. 

G

Eine Vorgehensweise, Methode oder ein Werkzeug, welche sich im Einsatz als sehr geeignet gezeigt hat. Diese existiert nur im komplizierten Bereich (siehe Cynefin Framwork).

I

Ein Impediment (deutsch: Hindernis) behindert das Team bei der Arbeit. Es ist die Aufgabe des Scrum Masters, das Team bei der Beseitigung des Hindernisses zu unterstützen (Hilfe zur Selbsthilfe). Impediments können im Impediment Backlog festgehalten und in der Sprint Retrospektive besprochen werden.

Bei einem inkrementellen Prozess wird das Produkt in Einzelteilen entwickelt und ausgeliefert. Jedes dieser Teile – sogenannte Inkremente – repräsentiert eine eigene und komplette Funktionalität des Endprodukts. Generell ist inkrementell als ein auf vorherigen Erkenntnissen aufbauendes Vorgehen definiert. Hierbei wird das Ziel einer fortlaufenden Produkterweiterung verfolgt.

Iterativ bezeichnet ein Projektvorgehen, das in immer wiederkehrenden Phasen und Zyklen – sogenannten Iterationen – erfolgt. Dabei werden Verbesserungen am Produkt schrittweise durchgeführt, bis das Ergebnis der Definiton of Done entspricht und ein auslieferbares Inkrement entwickelt wurde. 

K

Der Kunde ist derjenige, für den das Produkt (in Scrum) entwickelt wird; er ist damit auch ein (spezifischer) Stakeholder.

L

LeSS ist ein Framework für die Skalierung von Scrum auf mehrere Teams, die gemeinsam an einem Produkt arbeiten. Das LeSS-Framework zielt darauf ab, die Prinzipien und Ideale von Scrum in einem groß angelegten Unternehmenskontext so einfach wie möglich durch definierte Regeln und Anleitungen anzuwenden.

M

Ein MVP, wörtlich ein „minimal brauchbares Produkt“, ist die erste minimal funktionsfähige Iteration eines Produkts, die dazu dient, möglichst schnell aus Nutzerfeedback zu lernen und so Fehlentwicklungen an den Anforderungen der Nutzer vorbei zu verhindern.

Das Scrum Team soll mutig sein, eigene Ideen zu entwickeln und eigenständig zu handeln.

O

Gedanken, Ideen und Themen werden offen im Sinne von "Transparency" im Team geteilt. Es gibt möglichst wenig Herrschaftswissen oder Geheimnisse im Team. Es wird offen mit Fehlern unmgegangen. 

P

Methodik zum Schätzen von User Stories nach Komplexität durch das Entwicklerteam im Sprint Planning mit Hilfe von “Pokerkarten”. Jedes Teammitglied bewertet die User Stories für den aktuellen Sprint mithilfe von Story Points, welche als Fibonacci-Reihe auf Planning Poker Cards dargestellt sind. Der am höchsten und der niedrigsten Schätzende diskutieren den Aufwand so viele Runden, bis eine Einigung beider auf eine Schätzung erzielt wird. Die Schätzung hilft den Entwicklungsteam dabei zu überprüfen, ob nicht zu viele oder zu wenige Stories in den Sprint aufgenommen werden. Zusätzlich kann anhand der Story Points die Velocity der Teams gemessen werden.

Das Product Backlog ist eine Auflistung aller Funktionen, die das Endprodukt enthalten soll. Die Funktionen im Product Backlog werden in Scrum als ein Backlog Item bezeichnet. Sie sind in ihrer Reihenfolge nach Priorität geordnet und können jederzeit vom Scrum Team ergänzt werden, dürfen reifen oder sich ändern, wenn neue Erkenntnisse gewonnen wurden. Verantwortlich für die Pflege des Product Backlogs ist der Product Owner. Aus den am höchsten priorisierten Product Backlog Items wird zu Beginn eines Sprints (im Sprint Planning) das Sprint Backlog erstellt.

Der Product Owner ist für das "Was" zuständig. Er managt das Product Backlog, definiert die Anforderungen und Akzeptanzkriterien, schreibt und priorisiert die Product Backlog Items und verantwortet den wirtschaftlichen Erfolg. Zudem agiert er als Schnittstelle zwischen Stakeholdern und dem Scrum Team.

R

Das Scrum Team kommuniziert respektvoll miteinander. Seine Stärke liegt in der Zusammenarbeit untereinander. 

S

Der Sprint sowie die vier Meetings (Sprint Planning, Daily Scrum, Sprint Retrospektive, Sprint Review) werden im Scrum Guide zusammenfassend als Scrum Events bezeichnet.

Der Scrum Guide ist das von Ken Schwaber und Jeff Sutherland verfasste und kontinuierlich gepflegte Manual für das agile Framework Scrum. Erstmalig 2010 erschienen, wurde er seitdem fünfmal aktualisiert (zuletzt 2020). Obwohl der Scrum Guide keinen “bindenden Charakter” hat, ist er doch die Grundlage sämtlicher Scrum-Literatur, ‑Definitionen und ‑Zertifikate.

Der Scrum Master ist dafür verantwortlich, dass das Entwicklungsteam gemäß des Scrum-Prozesses arbeiten kann. Er sorgt für die Beseitigung von Impediments, fördert die Zusammenarbeit des Entwicklungsteams und zeichnet für die Methodik verantwortlich. 

Daily Scrum, Sprint Planning (1 + 2), Sprint Review und Sprint Retrospektive werden zusammenfassend als Meetings bezeichnet. Zusammen mit dem Sprint wird nach Scrum Guide dafür der Begriff Scrum Events verwendet. 

Der Scrum Prozess beschreibt die Anordnung und Abfolge der im Scrum Guide beschriebenen Artefacts und Events.

Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam sowie dem Scrum Master. Da das Entwicklungsteam nach Scrum Guide idealerweise aus 3 bis 9 Personen bestehen soll, ergibt sich eine Größe von 3 bis 11 Personen.

Die fünf Scrum Werte sind laut Scrum Guide: Selbstverpflichtung, Mut, Fokus, Offenheit, Respekt. Sie bilden die Grundlage für erfolgreiches Arbeiten mit Scrum.

Selbstorganisation ist eine unerlässliche Eigenschaft des Entwicklungsteams. Das Team entscheidet also selbstständig, wie anfallende Aufgaben, Herausforderungen und Hindernisse bewältigt werden und kann damit umgehen, ohne dass von außen eingegriffen wird.

Das Scrum Team verpflichtet sich gemeinsam darauf, seine gesetzten Ziele für den laufenden Sprint zu erreichen und sich gegenseitig zu unterstützen. Durch das eingebrachte Engagement eines jeden Teammitglied erhöht sich die Wahrscheinlichkeit, dass gefasste Pläne auch wirklich umgesetzt werden.

Als Sprint bezeichnet man die umklammernde Zeitspanne (Timebox), in der ein Zyklus in Scrum abgearbeitet wird. Es handelt sich um ein Event mit fester Länge von einem Monat oder weniger. Die Sprintlänge wird vor Beginn des Projekts festgelegt und sollte dann nicht mehr verändert werden. Ziel eines jeden Sprints ist es, ein funktionsfähiges Zwischenprodukt (Inkrement) zu entwickeln.

Das Sprint Backlog ist ein Plan von und für das Entwicklungsteam. Es ist ein gut sichtbares Echtzeit-Bild der Arbeit, die die Entwickler während des Sprints zu erledigen planen, um das Sprint Ziel zu erreichen. Folglich wird das Sprint Backlog während des Sprints aktualisiert, wenn neue Erkenntnisse gewonnen werden.

Abbruch des Sprints, um ihn neu aufzusetzen. Die Sprint Cancellation sollte eine Ausnahme sein und kann nur durch den Product Owner erfolgen. Typische Ursachen sind völlig falsche Schätzungen für den Umsetzungsaufwand oder massive Disharmonien im Entwicklungsteam.

Ein Meeting in Scrum, bei dem zu Beginn eines Sprints die Planungen für den Sprint durchgeführt werden. Kann unterteilt werden in Sprint Planning 1 (strategisch, grob) und Sprint Planning 2 (taktisch, detailliert). Im Sprint Planning wird auch das Sprint Ziel festgelegt.

Ein Scrum Meeting am Ende eines jeden Sprints, bei dem das Team den eigenen Entwicklungsprozess innerhalb des Teams hinsichtlich der Methodik, Zusammenarbeit und Prozesse betrachtet und Verbesserungen erarbeitet. 

Der Zweck des Sprint-Reviews ist es, das Ergebnis des Sprints zu überprüfen und zukünftige Anpassungen festzulegen. Das Scrum Team präsentiert den wichtigsten Stakeholdern die Ergebnisse ihrer Arbeit und der Fortschritt in Richtung des Produkt Ziels wird diskutiert. Während der Veranstaltung überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Basierend auf diesen Informationen arbeiten die Teilnehmer gemeinsam daran, was als nächstes zu tun ist.

Das Ergebnis, welches in einem Sprint erreicht werden soll. Das Sprint Goal wird zu Beginn eines Sprints durch das Scrum Team festgelegt.

Als Stakeholder werden all diejenigen bezeichnet, die nicht Teil des Scrum Teams sind, aber dennoch Interesse an der Entwicklung des Produktes oder notwendiges Wissen zum Produkt haben.

Stakeholder Management dient dazu, die Bedürfnisse der wichtigsten Interessensgruppen (Stakeholder) zu ermitteln und bei der Projektplanung und -durchführung zu berücksichtigen, um Gefahren vom Projekt abzuwenden. In Scrum verantwortet der Product Owner das Stakeholder Management. 

Jede (für einen Sprint ausgewählte) User Story wird auf eine Story Card geschrieben. Die Story Card enthält eine grobe Beschreibung der Funktionalität sowie die Abnahmekriterien, aus denen sich die Testfälle sowie die geschätzten Story Points ableiten lassen. Die für einen Sprint umzusetzende Story Card wird an das Task Board gehängt.

Der Aufwand zur Umsetzung von User Stories wird vom Entwicklungsteam in Story Points geschätzt. Hieraus errechnet sich die Velocity des Entwicklungsteams, sodass der Product Owner ihren jeweiligen Wert kennt und das Backlog priorisieren kann.

T

In Scrum verwendet man Tasks, um kleine Arbeiten zu identifizieren, die dann von einem Mitglied des Scrum Teams während des Sprints erledigt werden. Zur besseren Visualisierung werden die identifizierten Tasks auf eine Karte oder ein Post-It geschrieben und auf einem Task Board organisiert.

Über das Task Board wird der Status (meist To Do, In Progress, Done) einer Aufgabe (Task) visualisiert. Das Task Board ist meistens ein Whiteboard, auf der die Aufgaben mit Karten untergebracht werden.

Fester Zeitabschnitt / Fester Zeitrahmen. In Scrum sind fast alle Events timeboxed — so dauert der Sprint immer gleich lang (1-4 Wochen), das Daily Scrum immer 15 Minuten usw.

Erste Säule von Scrum: 
Alle Informationen, die für das Ergebnis der Produktentwicklungen relevant sind, müssen für alle an der Produktentwicklung beteiligten Personen transparent sein.

Grobe, vergleichende Schätzskala anhand von T‑Shirt-Größen S — M — L (dreistufig) oder XS — S — M — L — XL (fünfstufig)

Ü

Zweite Säule von Scrum:
Der Fortschritt und die erzielten Ergebnisse werden regelmäßig daraufhin geprüft, ob sie zum Erfüllen des Sprint Ziels dienlich sind.

U

Der- oder diejenige Person oder Gruppe, die das zu erstellende Produkt (oder Feature) nutzt oder nutzen wird. 

Eine User Story beschreibt eine Anforderung im Projekt, die sich in einem kurzen einfachen Satz zusammenfassen lässt. Dieser Satz ist so formuliert, dass er für jeden verständlich ist und beinhaltet daher auch keine technischen Informationen: Als (Rolle) möchte ich (Ziel/Wunsch), um (Nutzen). User Stories werden überlicherweise im Product Backlog festgehalten und für den Sprint wiederum im Sprint Backlog in Tasks heruntergebrochen.

V

Die Velocity ist ein Maß für die (Umsetzungs-)Geschwindigkeit, mit der ein Entwicklungsteam die Inhalte des Backlogs umsetzt. Sie wird in Story Points angegeben.

W

Im klassischen Projektmanagement wird das Projekt in mehrere, sich inhaltlich unterscheidende Phasen unterteilt. Eine Phase folgt auf die andere – eine Phase kann also erst dann beginnen, wenn die vorherige Phase abgeschlossen ist. Das Produkt oder das Projektergebnis wird nach Abschluss der letzten Phase ausgeliefert.