In dieser Tabelle werden die Scrum-Begriffe in kurzer Form gelistet und beschrieben — dies ist das komplette Scrum-Glossar in deutscher Sprache. Zur Sortierung können Sie einfach auf die Spaltenüberschrift klicken.
Dabei bedeuten im Einzelnen:
- Begriff: Der Begriff, so wie er im Allgemeinen in der deutschen Scrum Community verwendet wird
- Englisch: Der Begriff auf englisch
- Top: Ranking — mit A werden Begriffe bewertet, die man kennen muss, mit B diejenigen, die man kennen sollte (wenn man schon erste Schritte vollzogen hat), mit C diejenigen, die man kennen könnte
- Erklärung: Erklärung auf Deutsch, in kurzer Form zum Teil mit Verweisen
- Quelle(n): Woher kommt die Erklärung? (Gibt es an anderer Stelle eine Erklärung hierfür?)
- Eintrag vom: Datum des Eintrags oder der letzten Änderung
| Begriff | Englisch | Top | Erklärung | Quelle (n) | Eintrag vom |
|---|---|---|---|---|---|
| Agile Coach | Agile Coach | B | Eine Person, die bei der Einführung und Umsetzung von agilen Vorgehensweisen (wie Scrum) hilft. Der Begriff / die Rolle Agile Coach ist nicht geschützt oder genauer definiert, wird aber ähnlich häufig verwendet wie der Begriff Scrum Coach | selbst | 16.05.16 |
| Agile Methode | Agile Method | A | Methode zur / der Softwareentwicklung, die sich an Agilität ausrichtet. Zu den agilen Methoden zählen unter anderem das Pair Programming (Paarprogrammierung), Testgetriebene Entwicklung (Test Driven Development, TDD), kontinuierliches Refactoring, Story Cards, Codereviews, Dojos | - | 24.04.16 |
| Agile Prinzipien | Agile Principles | A | Leitsatz für die agile Arbeit. Im Agilen Manifest werden 12 Prinzipien beschrieben | - | 24.04.16 |
| Agile Transition | Agile Transition | B | Übergang von bisheriger Arbeits- und Vorgehensweise zur agilen Arbeitsform (z.B. Scrum). Eine Agile Transition ist ein Change Prozess und sollte von entsprechenden Coaches, Beratern und Trainern begleitet werden Oberbegriff: Organizational Change | selbst | 22.06.16 |
| Agile, Agil, Agilität | Agile | A | Agil(e) heißt zunächst (aus dem lat. agilis) flink oder beweglich. Inzwischen werden darüber verschiedene Methoden, Regeln, Praktiken, Prinzipien, Werte, … verstanden, die insbesondere in der Softwareentwicklung den “bürokratischen” Aufwand vermindern und die Leistungsfähigkeit erhöhen sollen. Scrum ist die bekannteste agile Methode | selbst | 06.05.16 |
| Agiler Festpreis | Agile Contract | B | Sammlung von Ansätzen, um gegenüber den Auftraggeber Festpreise bei gleichzeitigem agilen Vorgehen nennen zu können | selbst | 06.08.16 |
| Agiles Manifest | Manifesto for Agile Software Development — short: Agile Manifesto | A | Im Agilen Manifest (aus dem Jahr 2001) werden die 4 Werte und 12 Prinzipien der agilen Softwareentwicklung beschrieben. Das Agile Manifest wurde von 17 Experten verfasst und bildet die Grundlage für Scrum und weitere agile Methoden und Frameworks | - | 24.04.16 |
| Agiles Projektmanagement | Agile Project Management | B | Der Begriff Agiles Projektmanagement ist nicht eindeutig definiert. In der Regel wird darunter eine Anpassung oder Vermischung des “klassischen” Projektmanagements durch agile Methoden und Ansätze verstanden | selbst | 30.08.16 |
| Akzeptanzkriterium | Acceptance Criteria | B | Akzeptanzkriterien beschreiben, wie eine → User Story abgenommen wird / wann eine User Story als abgenommen gilt | selbst | 04.05.16 |
| Artefakt | Artefact | A | Etwas, das (im Scrum-Prozess) geschaffen wird. Bei Scrum im Allgemeinen Dokumente wie die Backlogs | selbst | 04.05.16 |
| Backlog | Backlog | A | Sammlung von Themen, die bearbeitet werden sollen. Am bekanntesten sind das → Product Backlog und das → Sprint Backlog. Andere Backlogs sind beispielsweise: Impediment Backlog, Selected Product Backlog, Transition Backlog. Im Scrum-Kontext ist mit “Backlog” häufig das “Product Backlog” gemeint. Eine umfassende Darstellung des Backlogs hier auf meiner zentralen Website | Scrum Guide | 24.04.16 |
| Backlog Grooming | Backlog Grooming | B | [Veraltet] Pflegen des Backlogs, indem die Inhalte überprüft und verbessert werden. Heute wird eher der Begriff → Backlog Refinement verwendet | selbst | 14.05.16 |
| Backlog Item | Backlog Item | A | Ein Eintrag im → Backlog wird als Backlog Item bezeichnet. Beispiel: Im Product Backlog ist meistens eine User Story ein Backlog Item | selbst | 16.05.16 |
| Backlog Refinement | Backlog Refinement | A | Das Überprüfen und Verbessern des → Backlogs. Meistens wird dabei systematisch vorgegangen und ein gesamtes Backlog überprüft und verbessert. | selbst | 04.05.16 |
| Benutzer | User | C | → User | selbst | 30.08.16 |
| Best Practice | Best Practice | C | Eine Vorgehensweise, Methode oder ein Werkzeug, welche sich im Einsatz als besonders geeignet gezeigt hat | selbst | 06.08.16 |
| Board | Board | B | Im Scrum-Kontext wird unter Board meistens ein Whiteboard (deutsch: Wandtafel) verstanden. Häufig wird auch der Begriff → Task Board (oder → Scrum Board) verwendet | selbst | 14.05.16 |
| Burndown Chart | Burndown Chart | A | Eine Grafik, die anzeigt, wieviel in einer Zeiteinheit (innerhalb einer Timebox) umgesetzt wurde. Üblicherweise werden die Story Points pro Tag innerhalb eines Sprints aufgezeigt Ähnliche Bezeichnung: Sprint Burndown Chart | selbst | 28.05.16 |
| CI/CD | CI/CD | B | Die Verbindung von Continuous Integration (CI) und Continuous Delivery (CD) wird als CI/CD bezeichnet. Es werden über CI/CD somit fortlaufend Compilationsvorgänge ausgeführt, die zu neuen lieferbaren Softwareständen führen. Aber Achtung: Lieferbar heißt nicht, dass auch tatsächlich deployt wird — das “D” steht für Delivery und nicht für Deployment | selbst | 30.08.16 |
| Collective Code Ownership — Gemeinsamer Code-Besitz | Collective Code Ownership | B | Der entstehende Code darf durch alle Teammitglieder verändert werden, da er allen gehört | selbst | 24.04.16 |
| Community of Practice — CoP | Community of Practice — CoP | B | Zur Einführung und Sicherung des Erfahrungswissens werden in einigen Organisationen und Unternehmen Communities of Practice eingeführt, in den sich die Scrum-Beteiligten treffen und ihr Know-how austauschen | selbst | 30.08.16 |
| Continuous Delivery — CD | Continuous Delivery — CD | B | Continuous Delivery bezeichnet die Fähigkeit, in kurzen Abständen Inkremente des Produkts (im Allgemeinen Software) ausliefern zu können. Dies bedeutet in der Regel, dass Nachts (automatisch) ein lauffähiges System erstellt wird | selbst | 30.08.16 |
| Continuous Deployment | Continuous Deployment | B | Continuous Deployment ist eine “Fortführung” des Continuous Delivery: Es wird nicht nur das System lieferfähig gehalten, sondern tatsächlich auch verteilt (“produktiv gesetzt”) | selbst | 30.08.16 |
| Continuous Integration — CI | Continuous Integration — CI | B | Werden neue, fertiggestellte Teilstücke einer Software unmittelbar dem laufenden System hinzugefügt, so spricht man von Continuous Integration | selbst | 30.08.16 |
| Cross-funktional | Cross-funktional | B | Hierunter wird verstanden, dass ein Team aus Mitgliedern besteht, die unterschiedliche Expertisen haben und so ein breites Spektrum an Fähigkeiten / Funktionen abdeckt | selbst | 30.09.19 |
| Customer | Customer | B | Der Customer (oder auch Kunde) ist derjenige, der das entstehende Produkt nutzt oder bezahlt. Der Customer wird in Scrum nicht explizit beschrieben | selbst | 30.08.16 |
| Daily Scrum | Daily Scrum | A | Beim Daily Scrum oder kurz Daily (ein Scrum Ereignis / Scrum Meeting) trifft sich das Entwicklungsteam, um vorzustellen, woran der Einzelne gerade arbeitet. Wie der Name schon andeutet, findet dieses Meeting täglich statt. Die Dauer sollte beschränkt sein — typischerweise 15 Minuten. Häufig stehen die Teilnehmer beim Daily Scrum: daher ist auch der Name Daily Stand-up gebräuchlich | selbst | 04.05.16 |
| Daily Stand-up | Daily Stand-up | A | Die übliche Form des Daily Scrums: Die Teilnehmer stehen (an einem Tisch) und besprechen, was sie derzeit bearbeiten | selbst | 28.05.16 |
| Definition of Done — DoD | Definition of Done | A | Die Definition of Done (DoD) beschreibt (im Vorhinein), wann eine User Story als fertig gilt, das heißt, vom Anwender abgenommen werden kann. Die DoD wird vor Beginn des Scrum-Projekts vom Scrum Team (Entwicklungsteam, Product Owner, Scrum Master) definiert, schriftlich fixiert und für jedermann zugänglich gemacht. Die (universelle) Überprüfung der DoD-Kriterien findet nach der vollständigen Umsetzung der User Story statt. Üblicherweise wird die DoD über eine (Check-)Liste realisiert. Eine vertiefende Darstellung findet sich hier auf meiner zentralen Website | selbst | 16.05.16 |
| Definition of Ready — DoR | Definition of Ready | B | 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 | selbst | 16.05.16 |
| Development Team | Development Team | A | → Entwicklungsteam | selbst | 06.08.16 |
| Entwicklungsteam | Development Team | A | Diejenigen, die im Sprint die Umsetzung der Items im Sprint Backlog vornehmen | selbst | 04.05.16 |
| Epic | Epic | B | Als Epics werden User Stories bezeichnet, die „sehr groß“ oder „grob-granular“ sind, sodass sie beispielsweise nicht mehr in einem Sprint untergebracht/umgesetzt werden können | selbst | 16.05.16 |
| Ereignis | Event | A | Der Sprint und die vier Meetings (Sprint Planning, Daily Scrum, Sprint Retrospektive, Sprint Review) werden im Scrum Guide zusammenfassend als Ereignisse bezeichnet | selbst | 30.08.16 |
| Estimation | Estimation | B | Schätzen von Aufwänden in der Softwareentwicklung für zu entwickelnde Funktionalitäten (Features, User Stories) nach Komplexität (und nicht in Personentagen, PT). Es gibt verschiedene Möglichkeiten des Schätzens wie Planning Poker, Magic Estimation, T‑Shirt-Größen | selbst | 06.08.16 |
| Estimation Meeting | Estimation Meeting | A | Im Estimation Meeting werden die Aufwände für die User Stories aus dem Backlog vorgenommen. Die Schätzung ist die Grundlage für die Priorisierung der User Stories durch den Product Owner und ist eine Vorbereitung für das Planning Meeting zum Sprintauftakt | selbst | 24.04.16 |
| Feature | Feature | B | Features bezeichnen die (von den Anwendern gewünschten) Merkmale des zu erstellenden Produkts | selbst | 16.05.16 |
| Geschwindigkeit | Velocity | B | → Velocity | selbst | 30.08.16 |
| Goal | Goal | A | oder auch Sprint Goal, siehe → Sprint-Ziel | selbst | 06.08.16 |
| Good Practice | Good Practice | C | Eine Vorgehensweise, Methode oder ein Werkzeug, welche sich im Einsatz als sehr geeignet gezeigt hat | selbst | 06.08.16 |
| Impediment | Impediment | B | Ein Impediment (deutsch: Hindernis) behindert das Team bei der Arbeit. Es ist die Aufgabe des Scrum Masters, Impediments zu beseitigen. Impediments können im Impediment Backlog [Veraltet auch Block List] festgehalten und in der Sprint Retrospektive besprochen werden | selbst | 16.05.16 |
| Impediment Backlog | Impediment Backlog | B | Sammlung von Impediments. In Scrum üblicherweise durch das Entwicklungsteam verwaltet | selbst | 06.08.16 |
| Inkrement | Increment | A | Allgemein: Zuwachs an Funktionalität; typischerweise wird in Scrum (iterativ) inkrementell entwickelt | selbst | 04.05.16 |
| INVEST | INVEST | A | INVEST steht abgekürzt für die sechs Eigenschaften, die eine qualitativ hochwertige User Story erfüllen sollte: I = Independent (unabhängig, in sich geschlossen) N = Negotiable (verhandelbar) V = Valuable (wertvoll, für den Benutzer Wert schaffend) E = Estimable (schätzbar, Aufwand soll jederzeit einschätzbar sein) S = Small (klein, so klein wie möglich geschnitten) T = Testable (testbar, sie muss so viel Information enthalten, dass sie testbar ist) Eine vertiefende Darstellung findet sich hier auf meiner zentralen Website | - | 24.04.16 |
| Iteration | Iteration | B | Zeitlicher oder inhaltlicher Schritt, um ein Produkt oder eine Dienstleistung zu ergänzen | selbst | 30.08.16 |
| Kunde | Customer | B | Der Kunde ist derjenige, für den das Produkt (in Scrum) entwickelt wird; er ist damit auch ein (spezifischer) Stakeholder. Der Begriff selbst wird in Scrum nicht näher definiert und auch nicht verwendet. → Customer | selbst | 22.06.16 |
| Magic Estimation | Magic Estimation | A | Schätzen von vielen User Stories in sehr kurzer Zeit mit vergleichbaren Aufwänden. Es findet die Fibonacci-Skala Anwendung | selbst | 24.04.16 |
| Minimal Marketable Feature — MMF | Minimal Marketable Feature — MMF | B | Kleinste Menge an Funktionalität, die für sich genommen vermarktbar wäre | selbst | 30.08.16 |
| Minimum Viable Product — MVP | Minimum Viable Product — MVP | B | Produkt, welches minimale Anforderungen umsetzt, aber noch Nutzen erbringt. Veraltet auch: Minimal Viable Product. Eine vertiefende Darstellung findet sich hier auf meiner zentralen Website | Lean Startup | 24.04.16 |
| Planning Meeting | Planning Meeting | B | → Sprint Planning | selbst | 30.08.16 |
| Planning Poker | Planning Poker | A | Schätzen von User Stories nach Komplexität durch das Entwicklerteam im Sprint Planning mit Hilfe von “Pokerkarten”. 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. Metrik der Aufwandsschätzung ist häufig eine modifizierte Fibonacci-Zahlenreihe mit den Werten 2, 3, 5, 8, 13, 20, 40, 100 | selbst | 24.04.16 |
| Potenziell auslieferbares Produkt-Inkrement — PSI | Potentially Shippable Product Increment — PSI | A | Das PSI ist eine Ergänzung zum bestehenden Produkt, die in einem Sprint umgesetzt werden sollte und die einen Mehrwert für den Kunden / für das Produkt bringt. Das PSI muss auslieferbar sein (aber nicht zwangsläufig ausgeliefert werden) | selbst | 28.05.16 |
| Product Backlog | Product Backlog | A | Sammlung von Inhalten, die (insgesamt) umgesetzt werden könnten. Das Product Backlog wird häufig durch eine (fortlaufende) Liste realisiert. Die einzelnen Einträge werden als Product Backlog Items oder einfach als Procduct-Backlog-Einträge bezeichnet. Verantwortlich für die Pflege des Product Backlogs ist der Product Owner, der auch die Priorisierung übernimmt. Aus den am höchsten priorisierten Product Backlog Items wird zu Beginn eines Sprints (im Sprint Planning) das Sprint Backlog erstellt | selbst | 06.08.16 |
| Product Backlog Item | Product Backlog Item | A | Ein einzelnes Element im Product Backlog | selbst | 06.08.16 |
| Product Owner | Product Owner | A | Der Product Owner agiert in der Rolle des Kunden als Schnittstelle zwischen Scrum Team und internen und externen Stakeholdern des Projekts. Er managt das Product Backlog, definiert die Anforderungen und Akzeptanzkriterien, schreibt und priorisiert die Product Backlog Items / User Stories. Er verantwortet den wirtschaftlichen Erfolg. Eine vertiefende Darstellung findet sich hier auf meiner zentralen Website | Scrum Guide | 24.04.16 |
| Produkt-Inkrement | Product Increment | C | Eine Ergänzung oder Erweiterung eines (bestehenden) Produkts. Der Begriff wird so in Scrum nicht verwendet, da ein Product Increment nicht lauffähig sein muss und daher kein Ergebnis eines Sprints sein kann. Daher wird der Begriff → “Potenziell auslieferbares Produkt-Inkrement — PSI” verwendet; in der Praxis wird häufig auch einfach der Begriff “Inkrement” verwendet | selbst | 30.08.16 |
| Release | Release | A | “Freigabe” — meint die Freigabe eines Software-Produkts oder Teilen davon. In einem Release werden die Ergebnisse eines oder mehrerer Sprints zusammengefasst; üblicherweise werden Releases auch vorab geplant | selbst | 30.08.16 |
| Release Planning | Release Planning | A | Prozess oder Meeting, in dem die Releases für das zu erstellende Produkt geplant werden. Nicht näher im Scrum Guide definiert, dennoch fester Bestandteil von Scrum | selbst | 06.08.16 |
| Rolle | Role | B | Über Rollen werden generell Tätigkeiten und Aufgaben den Mitarbeitern zugewiesen. Eine Rollendefinition/-beschreibung regelt die Verantwortlichkeiten und schafft Klarheit und Sicherheit. In Scrum sind drei Rollen definiert: Product Owner, Entwicklungsteam und Scrum Master | selbst | 30.08.16 |
| Schätzen | Estimation | A | siehe → Estimation | selbst | 24.04.16 |
| Scrum | Scrum | A | Hierzu gibt es verschiedene Definitionen; hier verwendet: Ein Framework zur Entwicklung von Produkten | Scrum Guide | 24.04.16 |
| Scrum Board | Scrum Board | B | → Task Board | selbst | 30.08.16 |
| Scrum Coach | Scrum Coach | C | Eine Person, die bei der Einführung und Umsetzung von Scrum hilft. Der Begriff / die Rolle Scrum Coach ist nicht geschützt, gehört nicht zur Scrum-Definition des Scrum Guides und wird häufig durch den → Agile Coach ersetzt. Der Scrum Master kann die Aufgaben des Scrum Coaches übernehmen | selbst | 30.08.16 |
| Scrum Ereignisse | Scrum Events | A | Sprint, Daily Scrum, Sprint Planning, Sprint Review und Sprint Retrospektive werden zusammenfassend als Scrum Ereignisse bezeichnet. Jedes Ereignis hat eine maximale Dauer (Timebox = zeitliche Beschränkung) | selbst; Scrum Guide | 06.05.16 |
| Scrum Guide | Scrum Guide | A | Eine Beschreibung was Scrum ist — von den Scrum-“Erfindern” Ken Schwaber und Jeff Sutherland. Erstmalig 2010 erschienen, ist im Juli 2016 die fünfte Fassung veröffentlicht worden. Obwohl der Scrum Guide keinen “bindenden Charakter” hat, ist er doch die Grundlage sämtlicher Scrum-Literatur, ‑Definitionen und ‑Zertifikate. Der Scrum Guide ist frei online in verschiedenen Sprachen verfügbar und umfasst etwa 20 Seiten. Weblink: Scrum Guide | selbst | 30.08.16 |
| Scrum Master | Scrum Master | A | 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ür das Entwicklungsteam) und fördert die Zusammenarbeit des Entwicklungsteams [Veraltete Schreibweise: ScrumMaster (zusammenhängend / CamelWave-Notation)] | Scrum Guide | 24.04.16 |
| Scrum Meetings | Meetings | C | 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 Ereignisse verwendet. In frühen Beschreibungen findet sich hierfür auch der Begriff Zeremonien / Ceremonien (Ceremonies). Weitere Meetings, die jedoch nicht im Scrum Guide aufgeführt werden, sind das Release Planning Meeting und das Estimation Meeting | selbst | 06.05.16 |
| Scrum of Scrums | Scrum of Scrums | B | Konzept, um Scrum in größeren Gruppen mit mehreren Scrum Teams zu betreiben | selbst | 30.08.16 |
| Scrum Team | Scrum Team | A | Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam sowie dem Scrum Master. Da das Entwicklungsteam nach Srum Guide idealerweise aus 3 bis 9 Personen bestehen soll, ergibt sich eine Größe von 4 (wenn der Scrum Master auch Mitglied des Entwicklungteams ist) bis 11 Personen | Scrum Guide | 24.04.16 |
| Scrum Values | Scrum Values | A | Die fünf Scrum Values (Scrum-Werte) sind laut Scrum Guide: Selbstverpflichtung, Mut, Fokus, Offenheit, Respekt. Sie bilden die Grundlage für erfolgreiches Arbeiten mit Scrum | selbst | 04.04.17 |
| Scrum-Prozess | Scrum Process | A | Durch den → Scrum Guide vorgegebene Reihenfolge von Bearbeitungsschritten; siehe Scrum-Grundlagen auf dieser Website | selbst | 10.10.19 |
| selbstorganisierend | self-organized | A | Das Entwicklungsteam arbeitet selbstorganisierend, d.h. es erkennt selbstständig Aufgaben, Herausforderungen und Hindernisse und kann damit umgehen, ohne dass von außen eingegriffen werden muss. Achtung: Den Begriff “selbstorganisiert” (statt selbstorganisierend) gibt es nicht | selbst | 30.08.16 |
| Selected Product Backlog | Selected Product Backlog | B | [Veraltet] Bezeichnet den Bereich des Product Backlogs der während des Sprint Plannings 1 zur Umsetzung im nächsten Sprint ausgewählt wurde. Das Selected Product Backlog geht dann in das → Sprint Backlog über | selbst | 04.04.17 |
| Sprint | Sprint | A | Zeitdauer (Timebox) in der ein Zyklus in Scrum abgearbeitet wird. Typischerweise 2 bis 4 Wochen. Die Sprintlänge wird vor Beginn des Projekts festgelegt und sollte dann nicht mehr verändert werden | selbst | 04.05.16 |
| Sprint Backlog | Sprint Backlog | A | Im Sprint Backlog werden diejenigen Aufgaben (Items oder Tasks) festgehalten, die im aktuellen Sprint umgesetzt werden (sollen) | selbst | 14.05.16 |
| Sprint Cancellation | Sprint Cancellation | B | Abbruch des Sprints, um ihn neu aufzusetzen. Die Sprint Cancellation sollte eine Ausnahme sein und kann nur durch den Scrum Master erfolgen. Typische Ursachen sind völlig falsche Schätzungen für den Umsetzungsaufwand oder massive Disharmonien im Entwicklungsteam | selbst | 30.08.16 |
| Sprint Goal | Sprint Goal | A | oder auch Goal, siehe → Sprint-Ziel | selbst | 06.08.16 |
| Sprint Planning | Sprint Planning | A | 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 | selbst | 14.05.16 |
| Sprint Retrospektive | Sprint Retrospective | A | Ein Ereignis / Meeting (bei Scrum am Ende eines Sprints) bei dem das Team den eigenen Entwicklungsprozess betrachtet und Verbesserungen erarbeitet | Scrum Guide | 24.04.16 |
| Sprint Review | Sprint Review | A | Im Sprint Review — ein Scrum Ereignis / Meeting — wird das Produkt-Inkrement überprüft | Scrum Guide | 24.04.16 |
| Sprint Zero | Sprint Zero | B | Der Sprint Zero bezeichnet den ersten Sprint, bei dem noch keine genauen Aussagen über die Sprintgeschwindigkeit (Velocity) getroffen werden können | 24.04.16 | |
| Sprint-Ziel | Sprint Goal | A | Das Ergebnis, welches in einem Sprint erreicht werden soll. Das Sprint Goal wird zu Beginn eines Sprints durch das Team festgelegt | selbst | 04.05.16 |
| Stakeholder | Stakeholder | B | Person oder Gruppe, die von der Umsetzung (des Projekts) betroffen sein könnte. Stakeholder sind damit immer zumindest die Kunden und das Scrum Team Andere Bezeichnungen: Interessensvertreter | selbst | 08.06.16 |
| Stand-up | Stand-up | B | “Irgendwas im Stehen” — wird in Scrum häufig für das Daily Stand-up verwendet | selbst | 28.05.16 |
| Story | Story | B | siehe → User Story | selbst | 14.05.16 |
| Story Card | Story Card | A | Jede (für einen Sprint ausgewählte) User Story wird auf eine Story Card geschrieben (häufig als Karte im DIN-A5-Format). Die Story Card enthält eine grobe Beschreibung der Funktionalität, 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 | selbst | 24.04.16 |
| Story Decomposition | Story Decomposition | B | Unter Story Decomposition wird das (systematische) Unterteilen von (User) Stories verstanden | selbst | 16.05.16 |
| Story Map | Story Map | B | Grafische Übersicht von mehreren User Stories, um so die Zusammenhänge darzustellen | selbst | 16.05.16 |
| Story Point | Story Point | A | 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 | selbst | 24.04.16 |
| T‑Shirt-Größen | T‑Shirt Sizes | B | Grobe, vergleichende Schätzskala anhand von T‑Shirt-Größen S — M — L (dreistufig) oder XS — S — M — L — XL (fünfstufig) | selbst | 24.04.16 |
| Task | Task | B | Aufgabe. Kleinste Einheit, die umgesetzt wird. Eine User Story umfasst einen oder mehrere Tasks | selbst | 14.05.16 |
| Task Board | Task Board | B | Über das Task Board werden die Status der Aufgaben (Tasks, User Stories) visualisiert. Das Task Board ist meistens eine Wandtafel (Whiteboard), auf der die Aufgaben mit Karten untergebracht werden | selbst | 14.05.16 |
| Team | Team | B | Gruppe von Personen; in Scrum gibt es das Entwicklungsteam und das Scrum Team (welches das Entwicklungsteam, den Product Owner und den Scrum Master umfasst) | selbst | 28.05.16 |
| Technische Schulden | Technical Debts | B | Sind Teile einer Software auf einem technisch nicht guten Stand und behindern sie dadurch die Weiterentwicklung oder Wartung, so spricht man von technischen Schulden. Da durch die Behebung von technischen Schulden kein inhaltlicher Mehrwert geschaffen wird, werden sie nicht in Scrum häufig nicht berücksichtigt | selbst | 30.08.16 |
| Testen | Testing | B | Zentrales Element der agilen Softwareentwicklung ist das Testen, welches durch das Entwicklungsteam durchgeführt wird. Dabei werden häufig die Testkriterien (oder auch die Akzeptanzkriterien) auf die User Story Card notiert | selbst | 08.06.16 |
| Theme | Theme | B | Zusammenfassung mehrerer Bereiche eine Anwendung. Üblicherweise besteht ein Theme aus mehreren Epics und User Stories | selbst | 16.05.16 |
| Timebox | Time Box | A | Fester Zeitabschnitt / Fester Zeitrahmen. In Scrum sind fast alle Ereignisse timeboxed — so dauert der Sprint immer gleich lang (2 oder 4 Wochen), das Daily Scrum immer 15 Minuten | selbst | 28.05.16 |
| Timeboxing | Time Boxing | A | Erledigen einer Aufgabe in einem fest vorgegebenen Zeitrahmen (Timebox). In Scrum werden die Ereignisse zeitlich begrenzt: so sollte das Daily Scrum auf 15 Minuten und der Sprint auf 2 (bis 4 ) Wochen beschränkt sein | - | 24.04.16 |
| Transition Backlog | Transition Backlog | C | Liste mit Tätigkeiten / Aufgaben um eine → Agile Transition durchzuführen | selbst | 04.10.16 |
| User | User | A | Der- oder diejenige Person oder Gruppe, die das zu erstellende Produkt (oder Feature) nutzt oder nutzen wird. Im Scrum Guide nicht näher beschrieben/definiert. Der deutsche Begriff “Anwender” wird kaum verwendet | selbst | 06.08.16 |
| User Story | User Story | A | Eine in “normaler Sprache” formulierte Anforderung, typischerweise auf einer Karte (Story Card) beschrieben — meistens in der Form “Als Rolle möchte ich Ziel/Wunsch um Nutzen zu erreichen“. Die User Stories werden durch die 3 Cs: Card, Conversation und Confirmation charakterisiert. Die User Story ist das zentrale Element zur Beschreibung von Anforderungen im agilen Kontext. User Stories werden üblicherweise im → Product Backlog festgehalten. Eine umfassende Darstellung der User Story findet sich hier auf meiner zentralen Website | - | 24.04.16 |
| Value | Value | A | 1. Scrum definiert nach Scrum Guide fünf Werte (Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt), die im Scrum Team gelebt werden sollen 2. Scrum orientiert sich stark an Werten, die geschaffen werden sollen. Innerhalb eines Sprints soll für den User ein (Zusatz-)Nutzen oder Wert geschaffen werden | selbst | 06.08.16 |
| Value Stream | Value Stream | B | Der Value Stream (oder Wertstrom) ist die Zusammenfassung aller Aktivitäten, die zur Erreichung des Ziels / Umsetzung des Produkts notwendig sind | selbst | 04.10.16 |
| Velocity | Velocity | A | 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 | selbst | 04.05.16 |
| Verschwendung | Waste | B | → Waste | selbst | 30.08.16 |
| Vision | Vision | B | Motivierende Beschreibung, was mit dem zu erstellenden Produkt oder der zu erbringenden Dienstleistung erreicht werden soll; wird auch als “Produktvision” bezeichnet | selbst | 16.05.16 |
| Waste | Waste | B | Waste (oder Verschwendung) sollte bei der agilen Arbeitsweise vermieden werden. Der Fokus liegt entsprechend auf den wertschöpfenden Tätigkeiten | selbst | 22.06.16 |
| Wert | Value | A | → Value Achtung: Es wird zwischen “Business Value” und “Scrum Values” unterschieden | selbst | 06.08.16 |
| Wertstrom | Value Stream | B | → Value Stream | selbst | 04.10.16 |
| XP — Extreme Programming | XP — Extreme Programming | B | Vorgehensmodell in der Softwareentwicklung, welches die Code-Erstellung in den Vordergrund rückt. XP definiert 14 Prinzipien, die sich teilweise in Scrum wiederfinden | selbst | 20.09.21 |
Hier verwendete generelle Quellen:
- /Scrum-Guide/ Scrum Guide™, Website mit dem aktuellen Scrum Guide (von Ken Schwaber und Jeff Sutherland) in verschiedenen Sprachen (auch auf Deutsch), aktualisierte englische Version vom November 2017
Anmerkungen (zu Scrum):
Es haben sich einige “Verkürzungen” in der Scrum-Praxis etabliert, die “ein wenig” an den Definitionen vorbeigehen — dies sind beispielsweise:
- Backlog — hiermit ist häufig das Product Backlog gemeint
- Daily — damit wird das Daily Meeting bezeichnet
- PO (Pe-Oh) ist die typische Abkürzung für den Product Owner
- Team — wird häufig mit dem Entwicklungsteam gleichgesetzt
Generell wird häufig der Begriff “Sprint” weggelassen: So wird aus “Sprint Retrospektive” die Retrospektive (oder kurz: “Retro”), aus “Sprint Review” das Review und so weiter.
Ein “offizielles Scrum-Glossar” (von der Scrum Alliance) gibt es derzeit nicht.
Sie haben Fehler entdeckt oder möchten weitere Begriffe in die Tabelle aufgenommen haben? Schreiben Sie mir — unter kontakt@peterjohann-consulting.de bin ich zu erreichen.