Springe zum Inhalt

Scrum-Glossar

Bereitgestellt von Peterjohann Consulting, 2016-2024

In die­ser Tabel­le wer­den die Scrum-Begrif­fe in kur­zer Form gelis­tet und beschrie­ben — dies ist das kom­plet­te Scrum-Glos­sar in deut­scher Spra­che. Zur Sor­tie­rung kön­nen Sie ein­fach auf die Spal­ten­über­schrift klicken.

Dabei bedeu­ten im Einzelnen:

  • Begriff: Der Begriff, so wie er im All­ge­mei­nen in der deut­schen Scrum Com­mu­ni­ty ver­wen­det wird
  • Eng­lisch: Der Begriff auf englisch
  • Top: Ran­king — mit A wer­den Begrif­fe bewer­tet, die man ken­nen muss, mit B die­je­ni­gen, die man ken­nen soll­te (wenn man schon ers­te Schrit­te voll­zo­gen hat), mit C die­je­ni­gen, die man ken­nen könn­te
  • Erklä­rung: Erklä­rung auf Deutsch, in kur­zer Form zum Teil mit Verweisen
  • Quelle(n): Woher kommt die Erklä­rung? (Gibt es an ande­rer Stel­le eine Erklä­rung hierfür?)
  • Ein­trag vom: Datum des Ein­trags oder der letz­ten Änderung
BegriffEng­lischTopErklä­rungQuel­le (n)Ein­trag vom
Agi­le CoachAgi­le CoachBEine Per­son, die bei der Ein­füh­rung und Umset­zung von agi­len Vor­ge­hens­wei­sen (wie Scrum) hilft. Der Begriff / die Rol­le Agi­le Coach ist nicht geschützt oder genau­er defi­niert, wird aber ähn­lich häu­fig ver­wen­det wie der Begriff Scrum Coachselbst16.05.16
Agi­le MethodeAgi­le MethodAMetho­de zur / der Soft­ware­ent­wick­lung, die sich an Agi­li­tät aus­rich­tet. Zu den agi­len Metho­den zäh­len unter ande­rem das Pair Pro­gramming (Paar­pro­gram­mie­rung), Test­ge­trie­be­ne Ent­wick­lung (Test Dri­ven Deve­lo­p­ment, TDD), kon­ti­nu­ier­li­ches Refac­to­ring, Sto­ry Cards, Code­re­views, Dojos-24.04.16
Agi­le PrinzipienAgi­le PrinciplesALeit­satz für die agi­le Arbeit. Im Agi­len Mani­fest wer­den 12 Prin­zi­pi­en beschrieben-24.04.16
Agi­le TransitionAgi­le TransitionBÜber­gang von bis­he­ri­ger Arbeits- und Vor­ge­hens­wei­se zur agi­len Arbeits­form (z.B. Scrum). Eine Agi­le Tran­si­ti­on ist ein Chan­ge Pro­zess und soll­te von ent­spre­chen­den Coa­ches, Bera­tern und Trai­nern beglei­tet werden

Ober­be­griff: Orga­niza­tio­nal Change
selbst22.06.16
Agi­le, Agil, AgilitätAgi­leAAgil(e) heißt zunächst (aus dem lat. agi­lis) flink oder beweg­lich. Inzwi­schen wer­den dar­über ver­schie­de­ne Metho­den, Regeln, Prak­ti­ken, Prin­zi­pi­en, Wer­te, … ver­stan­den, die ins­be­son­de­re in der Soft­ware­ent­wick­lung den “büro­kra­ti­schen” Auf­wand ver­min­dern und die Leis­tungs­fä­hig­keit erhö­hen sol­len. Scrum ist die bekann­tes­te agi­le Methodeselbst06.05.16
Agi­ler FestpreisAgi­le ContractBSamm­lung von Ansät­zen, um gegen­über den Auf­trag­ge­ber Fest­prei­se bei gleich­zei­ti­gem agi­len Vor­ge­hen nen­nen zu können selbst06.08.16
Agi­les ManifestMani­festo for Agi­le Soft­ware Deve­lo­p­ment — short: Agi­le ManifestoAIm Agi­len Mani­fest (aus dem Jahr 2001) wer­den die 4 Wer­te und 12 Prin­zi­pi­en der agi­len Soft­ware­ent­wick­lung beschrie­ben. Das Agi­le Mani­fest wur­de von 17 Exper­ten ver­fasst und bil­det die Grund­la­ge für Scrum und wei­te­re agi­le Metho­den und Frameworks-24.04.16
Agi­les ProjektmanagementAgi­le Pro­ject ManagementBDer Begriff Agi­les Pro­jekt­ma­nage­ment ist nicht ein­deu­tig defi­niert. In der Regel wird dar­un­ter eine Anpas­sung oder Ver­mi­schung des “klas­si­schen” Pro­jekt­ma­nage­ments durch agi­le Metho­den und Ansät­ze verstandenselbst30.08.16
Akzep­tanz­kri­te­ri­umAccep­tance CriteriaBAkzep­tanz­kri­te­ri­en beschrei­ben, wie eine → User Sto­ry abge­nom­men wird / wann eine User Sto­ry als abge­nom­men giltselbst04.05.16
Arte­faktArte­factAEtwas, das (im Scrum-Pro­zess) geschaf­fen wird. Bei Scrum im All­ge­mei­nen Doku­men­te wie die Backlogsselbst04.05.16
Back­logBack­logASamm­lung von The­men, die bear­bei­tet wer­den sol­len. Am bekann­tes­ten sind das → Pro­duct Back­log und das → Sprint Back­log. Ande­re Back­logs sind bei­spiels­wei­se: Impe­di­ment Back­log, Sel­ec­ted Pro­duct Back­log, Tran­si­ti­on Backlog.

Im Scrum-Kon­text ist mit “Back­log” häu­fig das “Pro­duct Back­log” gemeint.

Eine umfas­sen­de Dar­stel­lung des Back­logs hier auf mei­ner zen­tra­len Website
Scrum Gui­de24.04.16
Back­log GroomingBack­log GroomingB[Ver­al­tet] Pfle­gen des Back­logs, indem die Inhal­te über­prüft und ver­bes­sert wer­den. Heu­te wird eher der Begriff → Back­log Refi­ne­ment verwendetselbst14.05.16
Back­log ItemBack­log ItemAEin Ein­trag im → Back­log wird als Back­log Item bezeichnet. 
Bei­spiel: Im Pro­duct Back­log ist meis­tens eine User Sto­ry ein Back­log Item 
selbst16.05.16
Back­log RefinementBack­log RefinementADas Über­prü­fen und Ver­bes­sern des → Back­logs. Meis­tens wird dabei sys­te­ma­tisch vor­ge­gan­gen und ein gesam­tes Back­log über­prüft und verbessert.selbst04.05.16
Benut­zerUserC→ Userselbst30.08.16
Best Prac­ti­ceBest Prac­ti­ceCEine Vor­ge­hens­wei­se, Metho­de oder ein Werk­zeug, wel­che sich im Ein­satz als beson­ders geeig­net gezeigt hatselbst06.08.16
BoardBoardBIm Scrum-Kon­text wird unter Board meis­tens ein White­board (deutsch: Wand­ta­fel) ver­stan­den. Häu­fig wird auch der Begriff → Task Board (oder → Scrum Board) verwendetselbst14.05.16
Burn­down ChartBurn­down ChartAEine Gra­fik, die anzeigt, wie­viel in einer Zeit­ein­heit (inner­halb einer Time­box) umge­setzt wur­de. Übli­cher­wei­se wer­den die Sto­ry Points pro Tag inner­halb eines Sprints aufgezeigt

Ähn­li­che Bezeich­nung: Sprint Burn­down Chart
selbst28.05.16
CI/CDCI/CDBDie Ver­bin­dung von Con­ti­nuous Inte­gra­ti­on (CI) und Con­ti­nuous Deli­very (CD) wird als CI/CD bezeich­net. Es wer­den über CI/CD somit fort­lau­fend Com­pi­la­ti­ons­vor­gän­ge aus­ge­führt, die zu neu­en lie­fer­ba­ren Soft­ware­stän­den füh­ren. Aber Ach­tung: Lie­fer­bar heißt nicht, dass auch tat­säch­lich deployt wird — das “D” steht für Deli­very und nicht für Deploymentselbst30.08.16
Coll­ec­ti­ve Code Owner­ship — Gemein­sa­mer Code-BesitzColl­ec­ti­ve Code OwnershipBDie Ver­bin­dung von Con­ti­nuous Inte­gra­ti­on (CI) und Con­ti­nuous Deli­very (CD) wird als CI/CD bezeichnet -24.04.16
Com­mu­ni­ty of Prac­ti­ce — CoPCom­mu­ni­ty of Prac­ti­ce — CoPBZur Ein­füh­rung und Siche­rung des Erfah­rungs­wis­sens wer­den in eini­gen Orga­ni­sa­tio­nen und Unter­neh­men Com­mu­ni­ties of Prac­ti­ce ein­ge­führt, in den sich die Scrum-Betei­lig­ten tref­fen und ihr Know-how austauschenselbst30.08.16
Con­ti­nuous Deli­very — CDCon­ti­nuous Deli­very — CDBCon­ti­nuous Deli­very bezeich­net die Fähig­keit, in kur­zen Abstän­den Inkre­men­te des Pro­dukts (im All­ge­mei­nen Soft­ware) aus­lie­fern zu kön­nen. Dies bedeu­tet in der Regel, dass Nachts (auto­ma­tisch) ein lauf­fä­hi­ges Sys­tem erstellt wirdselbst30.08.16
Con­ti­nuous DeploymentCon­ti­nuous DeploymentBCon­ti­nuous Deploy­ment ist eine “Fort­füh­rung” des Con­ti­nuous Deli­very: Es wird nicht nur das Sys­tem lie­fer­fä­hig gehal­ten, son­dern tat­säch­lich auch ver­teilt (“pro­duk­tiv gesetzt”)selbst30.08.16
Con­ti­nuous Inte­gra­ti­on — CICon­ti­nuous Inte­gra­ti­on — CIBWer­den neue, fer­tig­ge­stell­te Teil­stü­cke einer Soft­ware unmit­tel­bar dem lau­fen­den Sys­tem hin­zu­ge­fügt, so spricht man von Con­ti­nuous Integrationselbst30.08.16
Cross-funk­tio­nalCross-funk­tio­nalBHier­un­ter wird ver­stan­den, dass ein Team aus Mit­glie­dern besteht, die unter­schied­li­che Exper­ti­sen haben und so ein brei­tes Spek­trum an Fähig­kei­ten / Funk­tio­nen abdecktselbst30.09.19
Cus­to­merCus­to­merBDer Cus­to­mer (oder auch Kun­de) ist der­je­ni­ge, der das ent­ste­hen­de Pro­dukt nutzt oder bezahlt. Der Cus­to­mer wird in Scrum nicht expli­zit beschriebenselbst30.08.16
Dai­ly Scrum Dai­ly ScrumABeim Dai­ly Scrum oder kurz Dai­ly (ein Scrum Ereig­nis / Scrum Mee­ting) trifft sich das Ent­wick­lungs­team, um vor­zu­stel­len, wor­an der Ein­zel­ne gera­de arbei­tet. Wie der Name schon andeu­tet, fin­det die­ses Mee­ting täg­lich statt. Die Dau­er soll­te beschränkt sein — typi­scher­wei­se 15 Minu­ten. Häu­fig ste­hen die Teil­neh­mer beim Dai­ly Scrum: daher ist auch der Name Dai­ly Stand-up gebräuchlichselbst04.05.16
Dai­ly Stand-upDai­ly Stand-upADie übli­che Form des Dai­ly Scrums: Die Teil­neh­mer ste­hen (an einem Tisch) und bespre­chen, was sie der­zeit bearbeitenselbst28.05.16
Defi­ni­ti­on of Done — DoDDefi­ni­ti­on of Done ADie Defi­ni­ti­on of Done (DoD) beschreibt (im Vor­hin­ein), wann eine User Sto­ry als fer­tig gilt, das heißt, vom Anwen­der abge­nom­men wer­den kann. Die DoD wird vor Beginn des Scrum-Pro­jekts vom Scrum Team (Ent­wick­lungs­team, Pro­duct Owner, Scrum Mas­ter) defi­niert, schrift­lich fixiert und für jeder­mann zugäng­lich gemacht. Die (uni­ver­selle) Über­prü­fung der DoD-Kri­te­ri­en fin­det nach der voll­stän­di­gen Umset­zung der User Sto­ry statt. Übli­cher­wei­se wird die DoD über eine (Check-)Liste rea­li­siert. Eine ver­tie­fen­de Dar­stel­lung fin­det sich hier auf mei­ner zen­tra­len Website
selbst16.05.16
Defi­ni­ti­on of Rea­dy — DoRDefi­ni­ti­on of ReadyBIst eine User Sto­ry geschrie­ben, so soll sie auch in die Umset­zung gelan­gen. Um sicher­zu­stel­len, dass sie auch eine gewis­se Qua­li­tät besitzt, die es dem Ent­wick­lungs­team erlaubt ohne zu gro­ßen Auf­wand die Umset­zung vor­zu­neh­men, wird eine Defi­ni­ti­on of Rea­dy (DoR) ver­wen­det, die über­grei­fend für alle User Sto­ries gilt. Hier­über wird gere­gelt, wel­chen Vor­ga­ben eine User Sto­ry fol­gen mussselbst16.05.16
Deve­lo­p­ment TeamDeve­lo­p­ment Team A→ Ent­wick­lungs­teamselbst06.08.16
Ent­wick­lungs­teamDeve­lo­p­ment TeamADie­je­ni­gen, die im Sprint die Umset­zung der Items im Sprint Back­log vornehmenselbst04.05.16
EpicEpicBAls Epi­cs wer­den User Sto­ries bezeich­net, die „sehr groß“ oder „grob-gra­nu­lar“ sind, sodass sie bei­spiels­wei­se nicht mehr in einem Sprint untergebracht/umgesetzt wer­den können
selbst16.05.16
Ereig­nisEventADer Sprint und die vier Mee­tings (Sprint Plan­ning, Dai­ly Scrum, Sprint Retro­spek­ti­ve, Sprint Review) wer­den im Scrum Gui­de zusam­men­fas­send als Ereig­nis­se bezeichnetselbst30.08.16
Esti­ma­ti­onEsti­ma­ti­onBSchät­zen von Auf­wän­den in der Soft­ware­ent­wick­lung für zu ent­wi­ckeln­de Funk­tio­na­li­tä­ten (Fea­tures, User Sto­ries) nach Kom­ple­xi­tät (und nicht in Per­so­nen­ta­gen, PT). Es gibt ver­schie­de­ne Mög­lich­kei­ten des Schät­zens wie Plan­ning Poker, Magic Esti­ma­ti­on, T‑Shirt-Grö­ßenselbst06.08.16
Esti­ma­ti­on MeetingEsti­ma­ti­on MeetingAIm Esti­ma­ti­on Mee­ting wer­den die Auf­wän­de für die User Sto­ries aus dem Back­log vor­ge­nom­men. Die Schät­zung ist die Grund­la­ge für die Prio­ri­sie­rung der User Sto­ries durch den Pro­duct Owner und ist eine Vor­be­rei­tung für das Plan­ning Mee­ting zum Sprintauftaktselbst24.04.16
Fea­tureFea­tureBFea­tures bezeich­nen die (von den Anwen­dern gewünsch­ten) Merk­ma­le des zu erstel­len­den Produktsselbst16.05.16
Geschwin­dig­keitVelo­ci­tyB→ Velo­ci­tyselbst30.08.16
GoalGoalAoder auch Sprint Goal, sie­he → Sprint-Zielselbst06.08.16
Good Prac­ti­ceGood Prac­ti­ceCEine Vor­ge­hens­wei­se, Metho­de oder ein Werk­zeug, wel­che sich im Ein­satz als sehr geeig­net gezeigt hatselbst06.08.16
Impe­di­mentImpe­di­mentBEin Impe­di­ment (deutsch: Hin­der­nis) behin­dert das Team bei der Arbeit. Es ist die Auf­ga­be des Scrum Mas­ters, Impe­di­ments zu besei­ti­gen. Impe­di­ments kön­nen im Impe­di­ment Back­log [Ver­al­tet auch Block List] fest­ge­hal­ten und in der Sprint Retro­spek­ti­ve bespro­chen werden selbst16.05.16
Impe­di­ment BacklogImpe­di­ment BacklogBSamm­lung von Impe­di­ments. In Scrum übli­cher­wei­se durch das Ent­wick­lungs­team verwaltetselbst06.08.16
Inkre­mentIncre­mentAAll­ge­mein: Zuwachs an Funk­tio­na­li­tät; typi­scher­wei­se wird in Scrum (ite­ra­tiv) inkre­men­tell entwickeltselbst04.05.16
INVESTINVESTAINVEST steht abge­kürzt für die sechs Eigen­schaf­ten, die eine qua­li­ta­tiv hoch­wer­ti­ge User Sto­ry erfül­len sollte:
I = Inde­pen­dent (unab­hän­gig, in sich geschlossen)
N = Nego­tia­ble (ver­han­del­bar)
V = Valuable (wert­voll, für den Benut­zer Wert schaffend)
E = Esti­ma­ble (schätz­bar, Auf­wand soll jeder­zeit ein­schätz­bar sein)
S = Small (klein, so klein wie mög­lich geschnitten)
T = Test­a­ble (test­bar, sie muss so viel Infor­ma­ti­on ent­hal­ten, dass sie test­bar ist)

Eine ver­tie­fen­de Dar­stel­lung fin­det sich hier auf mei­ner zen­tra­len Website
-24.04.16
Ite­ra­ti­onIte­ra­ti­onBZeit­li­cher oder inhalt­li­cher Schritt, um ein Pro­dukt oder eine Dienst­leis­tung zu ergänzenselbst30.08.16
Kun­deCus­to­merBDer Kun­de ist der­je­ni­ge, für den das Pro­dukt (in Scrum) ent­wi­ckelt wird; er ist damit auch ein (spe­zi­fi­scher) Stake­hol­der. Der Begriff selbst wird in Scrum nicht näher defi­niert und auch nicht verwendet. 
→ Customer
selbst22.06.16
Magic Esti­ma­ti­onMagic Esti­ma­ti­onASchät­zen von vie­len User Sto­ries in sehr kur­zer Zeit mit ver­gleich­ba­ren Auf­wän­den. Es fin­det die Fibo­nac­ci-Ska­la Anwendungselbst24.04.16
Mini­mal Mar­ke­ta­ble Fea­ture — MMFMini­mal Mar­ke­ta­ble Fea­ture — MMFBKleins­te Men­ge an Funk­tio­na­li­tät, die für sich genom­men ver­markt­bar wäreselbst30.08.16
Mini­mum Via­ble Pro­duct — MVPMini­mum Via­ble Pro­duct — MVPBPro­dukt, wel­ches mini­ma­le Anfor­de­run­gen umsetzt, aber noch Nut­zen erbringt.
Ver­al­tet auch: Mini­mal Via­ble Product.
Eine ver­tie­fen­de Dar­stel­lung fin­det sich hier auf mei­ner zen­tra­len Website
Lean Start­up24.04.16
Plan­ning Meeting Plan­ning Meeting B→ Sprint Planningselbst30.08.16
Plan­ning PokerPlan­ning PokerASchät­zen von User Sto­ries nach Kom­ple­xi­tät durch das Ent­wick­ler­team im Sprint Plan­ning mit Hil­fe von “Poker­kar­ten”. Der am höchs­ten und der nied­rigs­ten Schät­zen­de dis­ku­tie­ren den Auf­wand so vie­le Run­den, bis eine Eini­gung bei­der auf eine Schät­zung erzielt wird. Metrik der Auf­wands­schät­zung ist häu­fig eine modi­fi­zier­te Fibo­nac­ci-Zah­len­rei­he mit den Wer­ten 2, 3, 5, 8, 13, 20, 40, 100selbst24.04.16
Poten­zi­ell aus­lie­fer­ba­res Pro­dukt-Inkre­ment — PSIPoten­ti­al­ly Shippable Pro­duct Incre­ment — PSIADas PSI ist eine Ergän­zung zum bestehen­den Pro­dukt, die in einem Sprint umge­setzt wer­den soll­te und die einen Mehr­wert für den Kun­den / für das Pro­dukt bringt. Das PSI muss aus­lie­fer­bar sein (aber nicht zwangs­läu­fig aus­ge­lie­fert werden)selbst28.05.16
Pro­duct BacklogPro­duct BacklogASamm­lung von Inhal­ten, die (ins­ge­samt) umge­setzt wer­den könn­ten. Das Pro­duct Back­log wird häu­fig durch eine (fort­lau­fen­de) Lis­te rea­li­siert. Die ein­zel­nen Ein­trä­ge wer­den als Pro­duct Back­log Items oder ein­fach als Procduct-Back­log-Ein­trä­ge bezeich­net. Ver­ant­wort­lich für die Pfle­ge des Pro­duct Back­logs ist der Pro­duct Owner, der auch die Prio­ri­sie­rung über­nimmt. Aus den am höchs­ten prio­ri­sier­ten Pro­duct Back­log Items wird zu Beginn eines Sprints (im Sprint Plan­ning) das Sprint Back­log erstelltselbst06.08.16
Pro­duct Back­log ItemPro­duct Back­log ItemAEin ein­zel­nes Ele­ment im Pro­duct Backlogselbst06.08.16
Pro­duct OwnerPro­duct OwnerADer Pro­duct Owner agiert in der Rol­le des Kun­den als Schnitt­stel­le zwi­schen Scrum Team und inter­nen und exter­nen Stake­hol­dern des Pro­jekts. Er managt das Pro­duct Back­log, defi­niert die Anfor­de­run­gen und Akzep­tanz­kri­te­ri­en, schreibt und prio­ri­siert die Pro­duct Back­log Items / User Sto­ries. Er ver­ant­wor­tet den wirt­schaft­li­chen Erfolg.

Eine ver­tie­fen­de Dar­stel­lung fin­det sich hier auf mei­ner zen­tra­len Website 
Scrum Gui­de24.04.16
Pro­dukt-Inkre­mentPro­duct IncrementCEine Ergän­zung oder Erwei­te­rung eines (bestehen­den) Pro­dukts. Der Begriff wird so in Scrum nicht ver­wen­det, da ein Pro­duct Incre­ment nicht lauf­fä­hig sein muss und daher kein Ergeb­nis eines Sprints sein kann. Daher wird der Begriff → “Poten­zi­ell aus­lie­fer­ba­res Pro­dukt-Inkre­ment — PSI” ver­wen­det; in der Pra­xis wird häu­fig auch ein­fach der Begriff “Inkre­ment” verwendetselbst30.08.16
ReleaseRelease“Frei­ga­be” — meint die Frei­ga­be eines Soft­ware-Pro­dukts oder Tei­len davon. In einem Release wer­den die Ergeb­nis­se eines oder meh­re­rer Sprints zusam­men­ge­fasst; übli­cher­wei­se wer­den Releases auch vor­ab geplantselbst30.08.16
Release Plan­ningRelease Plan­ningAPro­zess oder Mee­ting, in dem die Releases für das zu erstel­len­de Pro­dukt geplant wer­den. Nicht näher im Scrum Gui­de defi­niert, den­noch fes­ter Bestand­teil von Scrumselbst06.08.16
Rol­leRoleBÜber Rol­len wer­den gene­rell Tätig­kei­ten und Auf­ga­ben den Mit­ar­bei­tern zuge­wie­sen. Eine Rol­len­defi­ni­ti­on/-beschrei­bung regelt die Ver­ant­wort­lich­kei­ten und schafft Klar­heit und Sicher­heit. In Scrum sind drei Rol­len defi­niert: Pro­duct Owner, Ent­wick­lungs­team und Scrum Master
selbst30.08.16
Schät­zenEsti­ma­ti­onAsie­he → Estimationselbst24.04.16
ScrumScrumAHier­zu gibt es ver­schie­de­ne Defi­ni­tio­nen; hier ver­wen­det: Ein Frame­work zur Ent­wick­lung von ProduktenScrum Gui­de24.04.16
Scrum BoardScrum Board→ Task Boardselbst30.08.16
Scrum CoachScrum CoachCEine Per­son, die bei der Ein­füh­rung und Umset­zung von Scrum hilft. Der Begriff / die Rol­le Scrum Coach ist nicht geschützt, gehört nicht zur Scrum-Defi­ni­ti­on des Scrum Gui­des und wird häu­fig durch den → Agi­le Coach ersetzt. Der Scrum Mas­ter kann die Auf­ga­ben des Scrum Coa­ches übernehmenselbst30.08.16
Scrum Ereig­nis­seScrum EventsASprint, Dai­ly Scrum, Sprint Plan­ning, Sprint Review und Sprint Retro­spek­ti­ve wer­den zusam­men­fas­send als Scrum Ereig­nis­se bezeich­net. Jedes Ereig­nis hat eine maxi­ma­le Dau­er (Time­box = zeit­li­che Beschränkung)selbst; Scrum Guide06.05.16
Scrum Gui­deScrum Gui­deAEine Beschrei­bung was Scrum ist — von den Scrum-“Erfindern” Ken Schwa­ber und Jeff Sut­her­land. Erst­ma­lig 2010 erschie­nen, ist im Juli 2016 die fünf­te Fas­sung ver­öf­fent­licht wor­den. Obwohl der Scrum Gui­de kei­nen “bin­den­den Cha­rak­ter” hat, ist er doch die Grund­la­ge sämt­li­cher Scrum-Lite­ra­tur, ‑Defi­ni­tio­nen und ‑Zer­ti­fi­ka­te. Der Scrum Gui­de ist frei online in ver­schie­de­nen Spra­chen ver­füg­bar und umfasst etwa 20 Sei­ten. Web­link: Scrum Gui­deselbst30.08.16
Scrum Mas­terScrum Mas­terADer Scrum Mas­ter ist dafür ver­ant­wort­lich, dass das Ent­wick­lungs­team gemäß des Scrum-Pro­zes­ses arbei­ten kann. Er sorgt für die Besei­ti­gung von Impe­di­ments (für das Ent­wick­lungs­team) und för­dert die Zusam­men­ar­beit des Entwicklungsteams
[Ver­al­te­te Schreib­wei­se: Scrum­Mas­ter (zusam­men­hän­gend / CamelWave-Notation)]
Scrum Gui­de24.04.16
Scrum Mee­tingsMee­tingsCDai­ly Scrum, Sprint Plan­ning (1 + 2), Sprint Review und Sprint Retro­spek­ti­ve wer­den zusam­men­fas­send als Mee­tings bezeich­net. Zusam­men mit dem Sprint wird nach Scrum Gui­de dafür der Begriff Scrum Ereig­nis­se ver­wen­det. In frü­hen Beschrei­bun­gen fin­det sich hier­für auch der Begriff Zere­mo­nien / Cere­mo­nien (Cere­mo­nies). Wei­te­re Mee­tings, die jedoch nicht im Scrum Gui­de auf­ge­führt wer­den, sind das Release Plan­ning Mee­ting und das Esti­ma­ti­on Meetingselbst06.05.16
Scrum of ScrumsScrum of ScrumsBKon­zept, um Scrum in grö­ße­ren Grup­pen mit meh­re­ren Scrum Teams zu betreibenselbst30.08.16
Scrum TeamScrum TeamADas Scrum Team besteht aus dem Pro­duct Owner, dem Ent­wick­lungs­team sowie dem Scrum Mas­ter. Da das Ent­wick­lungs­team nach Srum Gui­de idea­ler­wei­se aus 3 bis 9 Per­so­nen bestehen soll, ergibt sich eine Grö­ße von 4 (wenn der Scrum Mas­ter auch Mit­glied des Ent­wick­lung­teams ist) bis 11 PersonenScrum Gui­de24.04.16
Scrum ValuesScrum ValuesADie fünf Scrum Values (Scrum-Wer­te) sind laut Scrum Gui­de: Selbst­ver­pflich­tung, Mut, Fokus, Offen­heit, Respekt. Sie bil­den die Grund­la­ge für erfolg­rei­ches Arbei­ten mit Scrum
selbst04.04.17
Scrum-Pro­zessScrum Pro­cessADurch den → Scrum Gui­de vor­ge­ge­be­ne Rei­hen­fol­ge von Bear­bei­tungs­schrit­ten; sie­he Scrum-Grund­la­gen auf die­ser Websiteselbst10.10.19
selbst­or­ga­ni­sie­rendself-orga­ni­zedADas Ent­wick­lungs­team arbei­tet selbst­or­ga­ni­sie­rend, d.h. es erkennt selbst­stän­dig Auf­ga­ben, Her­aus­for­de­run­gen und Hin­der­nis­se und kann damit umge­hen, ohne dass von außen ein­ge­grif­fen wer­den muss.
Ach­tung: Den Begriff “selbst­or­ga­ni­siert” (statt selbst­or­ga­ni­sie­rend) gibt es nicht
selbst30.08.16
Sel­ec­ted Pro­duct BacklogSel­ec­ted Pro­duct BacklogB[Ver­al­tet] Bezeich­net den Bereich des Pro­duct Back­logs der wäh­rend des Sprint Plan­nings 1 zur Umset­zung im nächs­ten Sprint aus­ge­wählt wur­de. Das Sel­ec­ted Pro­duct Back­log geht dann in das → Sprint Back­log überselbst04.04.17
SprintSprintAZeit­dau­er (Time­box) in der ein Zyklus in Scrum abge­ar­bei­tet wird. Typi­scher­wei­se 2 bis 4 Wochen. Die Sprint­län­ge wird vor Beginn des Pro­jekts fest­ge­legt und soll­te dann nicht mehr ver­än­dert werdenselbst04.05.16
Sprint Back­logSprint Back­logAIm Sprint Back­log wer­den die­je­ni­gen Auf­ga­ben (Items oder Tasks) fest­ge­hal­ten, die im aktu­el­len Sprint umge­setzt wer­den (sol­len)selbst14.05.16
Sprint Can­cel­la­ti­onSprint Can­cel­la­ti­onBAbbruch des Sprints, um ihn neu auf­zu­set­zen. Die Sprint Can­cel­la­ti­on soll­te eine Aus­nah­me sein und kann nur durch den Scrum Mas­ter erfol­gen. Typi­sche Ursa­chen sind völ­lig fal­sche Schät­zun­gen für den Umset­zungs­auf­wand oder mas­si­ve Dis­har­mo­nien im Entwicklungsteamselbst30.08.16
Sprint GoalSprint GoalAoder auch Goal, sie­he → Sprint-Zielselbst06.08.16
Sprint Plan­ningSprint Plan­ningAEin Mee­ting in Scrum, bei dem zu Beginn eines Sprints die Pla­nun­gen für den Sprint durch­ge­führt wer­den. Kann unter­teilt wer­den in Sprint Plan­ning 1 (stra­te­gisch, grob) und Sprint Plan­ning 2 (tak­tisch, detail­liert). Im Sprint Plan­ning wird auch das Sprint-Ziel festgelegtselbst14.05.16
Sprint Retro­spek­ti­veSprint Retro­s­pec­ti­veAEin Ereig­nis / Mee­ting (bei Scrum am Ende eines Sprints) bei dem das Team den eige­nen Ent­wick­lungs­pro­zess betrach­tet und Ver­bes­se­run­gen erarbeitetScrum Gui­de24.04.16
Sprint ReviewSprint ReviewAIm Sprint Review — ein Scrum Ereig­nis / Mee­ting — wird das Pro­dukt-Inkre­ment überprüftScrum Gui­de24.04.16
Sprint ZeroSprint ZeroBDer Sprint Zero bezeich­net den ers­ten Sprint, bei dem noch kei­ne genau­en Aus­sa­gen über die Sprint­ge­schwin­dig­keit (Velo­ci­ty) getrof­fen wer­den können24.04.16
Sprint-ZielSprint GoalADas Ergeb­nis, wel­ches in einem Sprint erreicht wer­den soll. Das Sprint Goal wird zu Beginn eines Sprints durch das Team festgelegtselbst04.05.16
Stake­hol­derStake­hol­derBPer­son oder Grup­pe, die von der Umset­zung (des Pro­jekts) betrof­fen sein könn­te. Stake­hol­der sind damit immer zumin­dest die Kun­den und das Scrum Team

Ande­re Bezeich­nun­gen: Interessensvertreter
selbst08.06.16
Stand-upStand-upB“Irgend­was im Ste­hen” — wird in Scrum häu­fig für das Dai­ly Stand-up verwendetselbst28.05.16
Sto­rySto­ryBsie­he → User Storyselbst14.05.16
Sto­ry CardSto­ry CardAJede (für einen Sprint aus­ge­wähl­te) User Sto­ry wird auf eine Sto­ry Card geschrie­ben (häu­fig als Kar­te im DIN-A5-For­mat). Die Sto­ry Card ent­hält eine gro­be Beschrei­bung der Funk­tio­na­li­tät, die Abnah­me­kri­te­ri­en, aus denen sich die Test­fäl­le sowie die geschätz­ten Sto­ry Points ablei­ten las­sen. Die für einen Sprint umzu­set­zen­de Sto­ry Card wird an das Task Board gehängtselbst24.04.16
Sto­ry DecompositionSto­ry DecompositionBUnter Sto­ry Decom­po­si­ti­on wird das (sys­te­ma­ti­sche) Unter­tei­len von (User) Sto­ries verstandenselbst16.05.16
Sto­ry MapSto­ry MapBGra­fi­sche Über­sicht von meh­re­ren User Sto­ries, um so die Zusam­men­hän­ge darzustellenselbst16.05.16
Sto­ry PointSto­ry PointADer Auf­wand zur Umset­zung von User Sto­ries wird vom Ent­wick­lungs­team in Sto­ry Points geschätzt. Hier­aus errech­net sich die Velo­ci­ty des Ent­wick­lungs­teams, sodass der Pro­duct Owner ihren jewei­li­gen Wert kennt und das Back­log prio­ri­sie­ren kann selbst24.04.16
T‑Shirt-Grö­ßenT‑Shirt SizesBGro­be, ver­glei­chen­de Schätz­ska­la anhand von T‑Shirt-Grö­ßen S — M — L (drei­stu­fig) oder XS — S — M — L — XL (fünf­stu­fig)selbst24.04.16
TaskTaskBAuf­ga­be. Kleins­te Ein­heit, die umge­setzt wird. Eine User Sto­ry umfasst einen oder meh­re­re Tasksselbst14.05.16
Task BoardTask BoardBÜber das Task Board wer­den die Sta­tus der Auf­ga­ben (Tasks, User Sto­ries) visua­li­siert. Das Task Board ist meis­tens eine Wand­ta­fel (White­board), auf der die Auf­ga­ben mit Kar­ten unter­ge­bracht werdenselbst14.05.16
TeamTeamBGrup­pe von Per­so­nen; in Scrum gibt es das Ent­wick­lungs­team und das Scrum Team (wel­ches das Ent­wick­lungs­team, den Pro­duct Owner und den Scrum Mas­ter umfasst)selbst28.05.16
Tech­ni­sche SchuldenTech­ni­cal DebtsBSind Tei­le einer Soft­ware auf einem tech­nisch nicht guten Stand und behin­dern sie dadurch die Wei­ter­ent­wick­lung oder War­tung, so spricht man von tech­ni­schen Schul­den. Da durch die Behe­bung von tech­ni­schen Schul­den kein inhalt­li­cher Mehr­wert geschaf­fen wird, wer­den sie nicht in Scrum häu­fig nicht berücksichtigtselbst30.08.16
Tes­tenTest­ingBZen­tra­les Ele­ment der agi­len Soft­ware­ent­wick­lung ist das Tes­ten, wel­ches durch das Ent­wick­lungs­team durch­ge­führt wird. Dabei wer­den häu­fig die Test­kri­te­ri­en (oder auch die Akzep­tanz­kri­te­ri­en) auf die User Sto­ry Card notiertselbst08.06.16
The­meThe­meBZusam­men­fas­sung meh­re­rer Berei­che eine Anwen­dung. Übli­cher­wei­se besteht ein The­me aus meh­re­ren Epi­cs und User Storiesselbst16.05.16
Time­boxTime BoxAFes­ter Zeit­ab­schnitt / Fes­ter Zeit­rah­men. In Scrum sind fast alle Ereig­nis­se time­bo­xed — so dau­ert der Sprint immer gleich lang (2 oder 4 Wochen), das Dai­ly Scrum immer 15 Minutenselbst28.05.16
Time­boxingTime BoxingAErle­di­gen einer Auf­ga­be in einem fest vor­ge­ge­be­nen Zeit­rah­men (Time­box). In Scrum wer­den die Ereig­nis­se zeit­lich begrenzt: so soll­te das Dai­ly Scrum auf 15 Minu­ten und der Sprint auf 2 (bis 4 ) Wochen beschränkt sein-24.04.16
Tran­si­ti­on BacklogTran­si­ti­on BacklogCLis­te mit Tätig­kei­ten / Auf­ga­ben um eine → Agi­le Tran­si­ti­on durchzuführenselbst04.10.16
UserUserADer- oder die­je­ni­ge Per­son oder Grup­pe, die das zu erstel­len­de Pro­dukt (oder Fea­ture) nutzt oder nut­zen wird. Im Scrum Gui­de nicht näher beschrieben/definiert.
Der deut­sche Begriff “Anwen­der” wird kaum verwendet
selbst06.08.16
User Sto­ryUser Sto­ryAEine in “nor­ma­ler Spra­che” for­mu­lier­te Anfor­de­rung, typi­scher­wei­se auf einer Kar­te (Sto­ry Card) beschrie­ben — meis­tens in der Form
“Als Rol­le
möch­te ich Ziel/Wunsch
um Nut­zen zu errei­chen“.

Die User Sto­ries wer­den durch die 3 Cs: Card, Con­ver­sa­ti­on und Con­fir­ma­ti­on charakterisiert.

Die User Sto­ry ist das zen­tra­le Ele­ment zur Beschrei­bung von Anfor­de­run­gen im agi­len Kon­text. User Sto­ries wer­den übli­cher­wei­se im → Pro­duct Back­log festgehalten.

Eine umfas­sen­de Dar­stel­lung der User Sto­ries fin­det sich hier auf mei­ner zen­tra­len Website
-24.04.16
ValueValueA1. Scrum defi­niert nach Scrum Gui­de fünf Wer­te (Selbst­ver­pflich­tung, Mut, Fokus, Offen­heit und Respekt), die im Scrum Team gelebt wer­den sollen
2. Scrum ori­en­tiert sich stark an Wer­ten, die geschaf­fen wer­den sol­len. Inner­halb eines Sprints soll für den User ein (Zusatz-)Nutzen oder Wert geschaf­fen werden
selbst06.08.16
Value StreamValue StreamBDer Value Stream (oder Wert­strom) ist die Zusam­men­fas­sung aller Akti­vi­tä­ten, die zur Errei­chung des Ziels / Umset­zung des Pro­dukts not­wen­dig sindselbst04.10.16
Velo­ci­tyVelo­ci­tyADie Velo­ci­ty ist ein Maß für die (Umsetzungs-)Geschwindigkeit, mit der ein Ent­wick­lungs­team die Inhal­te des Back­logs umsetzt. Sie wird in Sto­ry Points angegebenselbst04.05.16
Ver­schwen­dungWas­teB→ Was­teselbst30.08.16
Visi­onVisi­onBMoti­vie­ren­de Beschrei­bung, was mit dem zu erstel­len­den Pro­dukt oder der zu erbrin­gen­den Dienst­leis­tung erreicht wer­den soll; wird auch als “Pro­dukt­vi­si­on” bezeichnetselbst16.05.16
Was­teWas­teBWas­te (oder Ver­schwen­dung) soll­te bei der agi­len Arbeits­wei­se ver­mie­den wer­den. Der Fokus liegt ent­spre­chend auf den wert­schöp­fen­den Tätigkeitenselbst22.06.16
WertValueA→ Value
Ach­tung: Es wird zwi­schen “Busi­ness Value” und “Scrum Values” unterschieden
selbst06.08.16
Wert­stromValue StreamB→ Value Streamselbst04.10.16
XP — Extre­me ProgrammingXP — Extre­me ProgrammingBVor­ge­hens­mo­dell in der Soft­ware­ent­wick­lung, wel­ches die Code-Erstel­lung in den Vor­der­grund rückt. XP defi­niert 14 Prin­zi­pi­en, die sich teil­wei­se in Scrum wiederfindenselbst20.09.21

Hier ver­wen­de­te gene­rel­le Quellen:

  • /Scrum-Gui­de/ Scrum Gui­de™, Web­site mit dem aktu­el­len Scrum Gui­de (von Ken Schwa­ber und Jeff Sut­her­land) in ver­schie­de­nen Spra­chen (auch auf Deutsch), aktua­li­sier­te eng­li­sche Ver­si­on vom Novem­ber 2017

Anmer­kun­gen (zu Scrum):
Es haben sich eini­ge “Ver­kür­zun­gen” in der Scrum-Pra­xis eta­bliert, die “ein wenig” an den Defi­ni­tio­nen vor­bei­ge­hen — dies sind beispielsweise:

  • Back­log — hier­mit ist häu­fig das Pro­duct Back­log gemeint
  • Dai­ly — damit wird das Dai­ly Mee­ting bezeichnet
  • PO (Pe-Oh) ist die typi­sche Abkür­zung für den Pro­duct Owner
  • Team — wird häu­fig mit dem Ent­wick­lungs­team gleichgesetzt

Gene­rell wird häu­fig der Begriff “Sprint” weg­ge­las­sen: So wird aus “Sprint Retro­spek­ti­ve” die Retro­spek­ti­ve (oder kurz: “Retro”), aus “Sprint Review” das Review und so weiter.


Ein “offi­zi­el­les Scrum-Glos­sar” (von der Scrum Alli­ance) gibt es der­zeit nicht.


Sie haben Feh­ler ent­deckt oder möch­ten wei­te­re Begrif­fe in die Tabel­le auf­ge­nom­men haben? Schrei­ben Sie mir — unter kontakt@peterjohann-consulting.de bin ich zu erreichen.