Im Folgenden haben wir alle im Buch verwendeten Fachbegriffe zusammengestellt. Darüber hinaus erläutern wir weitere Begriffe und Abkürzungen und verweisen auf Synonyme.
| Begriff | Beschreibung |
|---|---|
| Agile Coach | Ein Agile Coach ist über Scrum hinaus mit weiteren agilen Praktiken vertraut und kann auf ein umfangreiches Wissen aus verschiedenen Projekten zurückgreifen. Er hilft Unternehmen während der agilen Transition, Hinder- nisse und Blockaden zu beseitigen und über alle hierarchischen Ebenen hinweg die Vorteile agiler Verfahren zu erläutern. |
| Agile Manifesto | Das im Jahr 2001 verabschiedete Manifest ist die Grundlage aller agilen Vorgehensweisen. |
| Agile Methode | Für die agile Produktentwicklung kommen verschiedene agile Praktiken zum Einsatz wie z. B. Pair Programming (➝), User Stories (➝) oder TDD (➝). |
| Agile Prinzipien | Das Agile Manifesto (➝) beruht auf 12 Prinzipien, zu deren Einhaltung sich jeder Anwender agiler Methoden (➝) verpflichtet. (agilemanifesto.org) |
| Agile Vorgehensweise | Unter agilen Vorgehensweisen können allgemein Modelle verstanden werden, die Prozesse und Abläufe kontinuierlich reflektieren und verbessern. |
| Agile Werte | ➝ Agile Manifesto |
| Akzeptanzkriterien | Unter den Akzeptanzkriterien werden die Kriterien verstanden, die der Product Owner (➝) vor der Umsetzung eines Product Backlog Items (➝) festlegt und die bei der Entwicklung berücksichtigt werden sollten. Diese sind Bestandteil der Fertigstellungskriterien (➝ Definition of Done) und werden durch den Product Owner bei Abnahme (➝ Done) der jeweiligen Story überprüft. |
| Anforderungsliste | ➝ Product Backlog |
| Artefakt | Artefakte sind die Ergebnisse von Aktivitäten im Produktentwicklungsprozess. Die Artefakte sind: Product Backlog (➝), Sprint Backlog (➝) , Inkrement (➝ Inkrement). |
| Acceptance Test Driven Development (ATDD) | Acceptance Test Driven Development (ATDD) ist eine Entwicklungspraxis, in der die funktionalen Anforderungen eines Product Backlog Item als konkrete und automatisierbare Beispiele (oder Tests) vor der eigentlichen Entwicklung erstellt werden ( TDD). |
| (Product) Backlog Grooming | Backlog Grooming ist ein veralteter Begriff für das Backlog Refinement (➝), welches nicht Bestandteil des Scrum-Rahmenwerks ist. |
| (Product) Backlog Refinement | Als Backlog Refinement wird die laufende Pflege des Product Backlog (➝) bezeichnet. Das Refinement gehört nicht offiziell zu Scrum, wird aber von vielen Scrum-Teams im laufenden Sprint als Event durchgeführt. |
| (Product) Backlog Item (BI) | Ein Backlog Item (➝ User Story) ist eine Arbeitseinheit, die klein genug ist, um von einem Scrum-Team (➝) in einem Sprint (➝) abgeschlossen werden zu können. Backlog Items werden in einzelne Aufgaben (➝ Task) während des Sprint Planning (➝) zerlegt. |
| Benutzer | ➝ User |
| Benutzergeschichte | ➝ User Story |
| Blocker | Als Blocker bezeichnet man eine Störung für das Scrum-Team, die nicht umgehend behoben werden kann (➝ Impediment, ➝ Lean Management). |
| Brown Bag Session | Eine Brown Bag Session ist ein Meeting, das aus dem Scrum-Team (➝) heraus organisiert wird. Inhalt ist meist ein Thema, das von einem Teammitglied (➝) erarbeitet wurde und den Anwesenden vorgestellt wird. Da es oft über die Mittagszeit stattfindet und die Teilnehmenden dabei gemeinsam essen, hat sich der Name Brown Bag Session entwickelt. |
| Burndown-/Burnup-Chart | Ein Burndown- bzw. Burnup-Chart ist eine öffentlich sichtbare Darstellung des Fortschritts. Es kann auf der Projekt-, Release- und Sprint-Ebene eingesetzt werden. |
| Business Value | Der Geschäftswert ist der (meist finanzielle) Wert eines Backlog Items (➝) für eine Firma. Scrum (➝) hält den Product Owner (➝) dazu an, das Product Backlog (➝) immer wieder neu zu sortieren, so dass diejenigen Backlog Items als Erstes erledigt werden, die über den höchsten Geschäftswert verfügen. |
| Chicken | Als Chicken bezeichnet man die Gäste eines Scrum-Events (➝), die als stille Zuhörer teilnehmen und keinen Rede- oder Frageanteil haben (im Gegensatz zu ➝ Pigs), da diese nicht involviert (➝ Commitment) sind und nicht zur Realisierung beitragen. |
| Clean Code | Clean Code ist ein Regelwerk professioneller Softwareentwicklung, das auf dem gleichnamigen Buch von Robert C. Martin basiert. |
| Code Review | Code Reviews stellen eine manuelle Prüfung der Arbeitsergebnisse durch eine Person dar. |
| Collective Code Ownership | Jeder Developer (➝) ist für den gesamten Code zuständig und kann am Code arbeiten. |
| Commitment | Am Ende des Sprint Planning (➝) gibt das Scrum-Team (➝) gegenüber dem Product Owner (➝) ein Versprechen ab. Es bedeutet so viel wie: »Wir haben verstanden, welche Features (➝) du von uns erwartest, und wir werden im Sprint (➝) im Rahmen unserer Möglichkeiten alles tun, um dieses Ziel zu erreichen. Wir erwarten von dir aber tatkräftige Unterstützung bei der Erreichung dieses Ziels.« Seit dem Scrum Guide (➝) 2013 spricht man von einem Forecast (➝), einer Vorhersage. |
| Community of Practice (CoP) | Ein selbstorganisierte Zusammenschluss von Menschen, die ähnlichen Aufgabenstellungen gegenüberstehen, mit dem Ziel, voneinander zu lernen. |
| Continuous Integration (CI) | Continuous Integration ist ein Vorgehen in der Softwareentwicklung, bei dem Änderungen an Codeteilen sofort zusammen mit einer größeren Codebasis getestet werden, sobald sie in diese integriert werden (was regelmäßig geschehen sollte). Ziel von CI ist es, ein schnelles Feedback zu generieren, sodass potenzielle Fehler sofort erkannt und behoben werden können. |
| Crossfunktional | Unter einem crossfunktionalen Team versteht man Menschen mit verschiedenen funktionalen Fähigkeiten, die zusammen auf ein Ziel hinarbeiten. |
| Daily Scrum (Stand-up) | Ein tägliches, maximal 15-minütiges Zusammenkommen des Scrum-Teams (➝), in dem sich das Team synchronisiert und die taktische Planung, mit Hinblick auf die Erreichung des Sprint-Ziels (➝), für den Tag durchführt. Das Daily Scrum wird häufig auch als Daily Stand-up bezeichnet, da alle Teilnehmenden vor dem Taskboard stehen. |
| DEEP | Ein Begriff, der von Roman Pichler geprägt wurde und die Pflege des Product Backlog (➝) betrifft. Die Backlog Items (➝) sollen angemessen detailliert beschrieben (Detailed appropriately), geschätzt (Estimated), lebendig (Emergent) und sortiert (Prioritized) sein (➝ MuSCoW). |
| Definition of Done (DoD) | Die Definition of Done beschreibt das Qualitätsverständnis eines Scrum-Teams (➝). Ein Backlog Item (➝) gilt erst dann als fertig (➝ Done), wenn die in der DoD beschriebenen Qualitätsmerkmale erfüllt sind. Die DoD ist eine Liste von Punkten, die diese Kriterien festlegt. Diese sollte von jedem Scrum-Team (➝) individuell erarbeitet und verabschiedet werden. |
| Definition of Ready (DoR) | In der Definition of Ready wird zwischen Product Owner (➝) und Developern (➝) festgelegt, wann ein Backlog Item (➝) bereit für die Umsetzung ist, also wann ein Backlog Item (➝) vom Team in einem Sprint (➝) bearbeitet werden kann. Im Gegensatz zur DoD ist der Product Owner für die Einhaltung der DoR verantwortlich. |
| Developer | Die Verantwortlichkeit Developer in einem Scrum-Teams (➝) ist für die Erstellung und Lieferung von Produktinkrementen (➝) verantwortlich. Es besteht aus allen Fachleuten, die für die Lieferung des Potentially Shippable Code (➝) am Ende eines Sprints (➝) erforderlich sind, ist also crossfunktional (➝) zusammengesetzt. Developer agieren selbstmanagend, sie legen die Regeln für die Zusammenarbeit eigenständig fest und agieren autonom. |
| Dokumentation | Dokumentation ist auch in agilen Projekten notwendig und hilfreich. Es gelten jedoch vorrangig die Grundsätze des Agilen Manifests (➝). |
| Done | In Scrum unterscheiden wir zwischen »nicht fertig« und »fertig«. Ein Backlog Item (➝) gilt als »Done«, wenn alle Tasks (➝) erledigt sind und die Definition of Done (➝) erfüllt ist. |
| Dysfunktion | Als Dysfunktion werden Fehler oder Störungen in einem System, wie einer Organisation verstanden. Zum Beispiel wenn in einem Scrum-Team nicht offen miteinander kommuniziert wird, könnte dies auf fehlendes Vertrauen zurückzuführen sein. |
| Elevator Pitch | Unter einem Elevator Pitch wird die knappe Präsentation oder Vorstellung einer (Produkt-)Idee oder Dienstleistung mit allen positiven Merkmalen verstanden. |
| Empowerment | Unter Empowerment werden Maßnahmen verstanden, die darauf abzielen, die Autonomie und Selbstverwaltung eines Teams zu erhöhen, um die eigenen Interessen eigenmächtig und gestärkt vertreten zu können. |
| Emergent Architecture | (Auch: »Emergent Design«) Dieser Begriff verweist auf die iterative Entwicklung der Architektur in agiler Softwareentwicklung. In kleinen Stücken werden funktionierende Inkremente mit Geschäftswert (➝ Business Value) geliefert und nicht im Vorfeld eines Softwareprojekts geplant. |
| Empirismus | Der Empirismus geht davon aus, dass Wissen durch Erfahrungen entsteht und Entscheidungen auf der Grundlage von Fakten getroffen werden. Die empirischen Steuerung funktioniert in Scrum durch die transparenten Zyklen (➝ Sprint), in denen End-to-End Ergebnisse inspiziert und daraus abgeleitet Änderungen oder Verbesserungen adaptiert werden können. |
| Entwickler | Die Verantwortlichkeit Entwickler in einem Scrum-Team ist für die Erstellung und Lieferung von Produktinkrementen verantwortlich. Mit Entwickler sind alle Fachleute gemeint, die für die Lieferung des Potentially Shippable Code am Ende eines Sprints erforderlich sind, das Scrum-Team ist also crossfunktional zusammengesetzt. Entwickler arbeiten selbstorganisiert, sie legen die Regeln für die Zusammenarbeit eigenständig fest und agieren autonom. |
| Epic | Ein Epic ist ein sehr grobes Backlog Item (➝), das noch nicht in kleinere Backlog Items (➝) heruntergebrochen wurde und einen Geschäftswert (➝ Business Value) besitzt. Es ist in der Regel so umfangreich, dass es für das Scrum-Team (➝) nicht schätzbar ist. Der Product Owner (➝) nutzt oftmals Epics, um Ideen festzuhalten, die möglicherweise aber gar nicht umgesetzt oder zu Themen (➝) werden. |
| Estimation | Das Estimation ist Bestandteil des Backlog Refinement (➝). Es werden sämtliche Backlog Items (➝) hinsichtlich ihrer Komplexität eingeschätzt und beispielsweise mit einem Wert aus der (Scrum-)Fibonacci-Sequenz (➝) bewertet. Zu Beginn eines Projekts gibt es meist ein initiales Estimation, in dem alle zu dem Zeitpunkt bereits bekannten Backlog Items geschätzt werden. In vielen Teams findet in jedem Sprint (➝) Backlog Refinements (➝) statt, in dem neu hinzugekommene oder veränderte Backlog Items geschätzt werden. |
| Extreme Programming (XP) | Extreme Programming ist eine wenig formalisierte Methode zur Softwareentwicklung, bei der das Lösen einer Aufgabe im Fokus steht. Das Vorgehen basiert auf fortlaufenden Iterationen, dem Einsatz diverser bewährter Methoden zur Softwareentwicklung und folgt fünf zentralen agilen Werten (➝ Agile Manifesto): Kommunikation, Einfachheit, Respekt, Feedback und Mut. |
| Feature | Als Feature bezeichnet man die Fähigkeit eines Produkts oder einer Komponente, eine bestimmte Funktion oder Gruppe von Funktionen zu erfüllen. |
| Fibonacci-Sequenz | Die (Scrum-)Fibonacci-Sequenz wird im Backlog Refinement (➝) verwendet, um Backlog Items (➝) mit Komplexitätspunkten oder Story Points (➝) zu bewerten. Die angepasste Reihe lautet: 0,1, 2, 3, 5, 8, 13, 20, 40, 100. Mit zunehmendem Wert wird der Abstand zum Vorgänger und Nachfolger größer, da mit zunehmender Komplexität auch die Unsicherheit der Schätzung größer wird (➝ Planning Poker, ➝ Story Point, ➝ Team Estimation Game). |
| Flow | Der Begriff »Flow« wird nicht nur in Bezug auf den Scrum-Prozess (➝ Scrum) verwendet, sondern er beschreibt vor allem die individuelle Wahrnehmung beim fließenden Bearbeiten von Aufgaben (➝ Sustainable Pace). |
| Forecast | Beim Forecast handelt sich um die Vorhersage der Developer, welche Features (➝) voraussichtlich am Ende des Sprints fertiggestellt sein werden. |
| Funktionalität | ➝ Feature |
| Geschäftswert | ➝ Business Value |
| Größe | ➝ Size |
| How-to-demo | Ein kurzer Workflow, um dem Product Owner (➝) zu beweisen, dass das angeforderte Feature (➝) entsprechend der Akzeptanzkritieren umgesetzt wurde. |
| Impact Map | Die Impact Map ist eine strategische Planungstechnik bei der Aktivitäten, Maßnahmen, Ergebnisse oder Anforderungen einem konkreten Geschäftsziel zugeordnet werden. Diese Zusammenhänge werden in einer Impact Map oder auch Mind Map visualisiert. |
| Impediment | Ein Impediment ist ein Hindernis (➝ Blocker), das das Scrum-Team (➝) aktuell daran hindert, so effektiv und effizient wie möglich am Sprint-Ziel (➝) zu arbeiten. Impediments werden vom Scrum Master (➝) im Impediment Backlog (➝) mit dem Ziel gesammelt, diese schnellstmöglich zu beseitigen. |
| Impediment Backlog | Das Impediment Backlog ist eine öffentlich sichtbare Arbeitsliste des Scrum Masters (➝), in der alle Impediments (➝) aufgeführt sind. |
| Impediment Wall | Oft wird das Impediment Backlog (➝) öffentlich sichtbar an einer Wand aufgehängt, dies ist die Impediment Wall. |
| In Progress | Arbeitsschritt auf dem Scrum-Board (➝), der die aktuell durch die Developer (➝) bearbeiteten Tasks (➝) visualisiert. Die Tasks wandern von links nach rechts über das Scrum-Board über die Spalten »Open« (➝), »In Progress« und »Done« (➝). |
| Information Radiator | Information Radiators sind große, gut sichtbare, leicht verständliche und zu aktualisierende Informationen, die auf Post-its, Karten, Plakaten o. Ä. notiert sind und das Erinnern zu erleichtern bzw. Nachfragen zu vermeiden. |
| Inkrement | ➝ Produktinkrement |
| Inspect & Adapt | Das Scrum-Team (➝) prüft (Inspect) nach jedem Sprint (➝), wo es steht und was erreicht wurde. Sollte es Dinge geben, die zu verbessern sind, werden Maßnahmen zur Umsetzung entsprechender Veränderungen vereinbart (Adapt). Diese empirische Prozesskontrolle (➝ Empirismus) ist der wesentliche Kern für den Einsatz von Scrum. |
| INVEST | Gute User Stories (➝) entsprechen Qualitätskriterien, die durch das Akronym INVEST beschrieben werden. Sie sollten eigenständig existieren können (Independent), ohne starke Abhängigkeiten zu anderen Backlog Items. Sie sollten verhandelbar (Negotiable) sein, Wert (Valuable) für den Nutzer (➝ User) liefern, schätzbar sein (Estimatable), möglichst nur eine Anforderung enthalten (Small) und testbar (Testable) sein. |
| Kaizen | Ist eine Philosophie in deren Zentrum das Streben nach andauernder Verbesserung von Prozessen oder Produkten steht. |
| Kanban | Kanban ist ein Change Management Methode, das seine Ursprünge im Toyota-Produktionssystem (TPS) hat. Ziel ist es, die Durchlaufzeiten von Features (➝) zu erhöhen und die Anzahl paralleler Arbeit zu reduzieren. |
| Komfortzone | Die Komfortzone wird häufig als der Bereich beschrieben, in dem sich Menschen wohlfühlen. Sie spiegelt die Gewohnheiten und Rituale, aber auch das Wissen wider, das ein Mensch sich angeeignet hat. Alles Neue und Unbekannte fordert uns demnach dazu auf, den komfortablen Bereich zu verlassen. |
| Komplexität | Backlog Items (➝) werden nicht nach Aufwand, sondern nach ihrer Komplexität bewertet. Dabei werden sie in Beziehung zueinander gesetzt: »Story A ist (ist nicht) komplexer als Story B.« Backlog Items gleicher Komplexität bekommen die gleiche Anzahl von Story Points (➝). |
| Kunde | Kunde ist die Person (➝ Persona), die das Projektergebnis beauftragt hat und dafür bezahlt. Kunden sind häufig nicht (End-)Nutzer (➝ User). |
| Lean Management | Der Begriff Lean Management ist eine Management-Philosophie, die Denkprinzipien, Methoden und Verfahrensweisen zur effizienten Gestaltung der gesamten Wertschöpfungskette von Produkten umfasst. Scrum oder Kanban basieren auf den Prinzipien von Lean Thinking (➝). |
| Lean Thinking | Unter Lean Thinking werden die Prinzipien des Lean Management (➝) subsumiert. Lean Thinking stellt den Kunden zentral in den Mittelpunkt durch die Betrachtung der Wertströme. Dieses Ziel soll mit zufriedenen Mitarbeitern und geringer Verschwendung erreicht werden. |
| Lessons Learned | Neue Erkenntnisse aus einem Projekt werden dokumentiert und öffentlich zur Verfügung gestellt. Dies können positive oder negative Aspekte sein, die Verbesserungen oder Risiken beschreiben. Lessons Learned beziehen sich immer auf praktische Erfahrungen. Sie dienen dazu, zukünftig Fehler zu vermeiden und Erfolge wahrscheinlicher zu machen. |
| Minimum Marketable Feature (MMF) | Ein Minimum Marketable Feature ist die kleinstmögliche Menge an Funktionen, die für sich genommen vermarktbar ist. Software, die nur eines dieser Merkmale aufweist, hat einen Nutzen für den User (➝), für den dieser bezahlen würde. |
| Minimum Viable Product (MVP) | Das Minimum Viable Product ist die minimale Menge von Features, die notwendig sind, um herauszufinden, was ein Kunde möchte. Es ist eine Strategie, um schnelles und breites Feedback vom Kunden zu erzielen, ohne das Produkt bis zu seiner Marktreife auszuarbeiten. |
| MuSCoW | Die MuSCoW-Methode ist eine Technik zur Priorisierung, um Backlog Items (➝) grob in vier Kategorien einzuordnen: Must have, Should have, Could have, Won’t have. |
| Non Functional Requirement (NFR) | Unter Non Functional Requirements versteht man Zwangsmäßigkeiten wie beispielsweise die Aktualisierung eines zugrunde liegenden Frameworks, notwendige Skalierungsmaßnahmen oder Performance-Verbesserungen. |
| (End-)Nutzer | ➝ User, ➝ Persona |
| Offen | »Open« ist ein Status eines Tasks (➝) am Scrum-Board (➝), bevor er bearbeitet wird. In agilen Projekten unterscheidet man grundsätzlich zwischen »fertig« (➝ Done) und »nicht fertig«. »Open« sowie »In Progress« (➝) zeigen an, dass die Backlog Items (➝) noch in Bearbeitung sind. |
| Pair Programming | Dies ist eine Vorgehensweise aus dem Extreme Programming (➝). Zwei Developer sitzen gemeinsam an einer Aufgabe und finden Lösungen zusammen. Dadurch wird implizit ein Review, also eine Überprüfung im 4-Augen-Prinzip, durchgeführt ( ➝ Peer Review). |
| PDCA-Zyklus | Hinter Plan (P), Do (D), Check (C) und Act (A) verbirgt sich ein vierteiliger Problemlösungsprozess, der zur ständigen Verbesserung bei der Entwicklung von Produkten verwendet wird. |
| Peer Review | Ist eine Praxis aus der Softwareentwicklung, bei der der Autor einen oder mehrere Developer Inhalt und Qualität des Codes prüfen lässt (➝ Pair Programming). |
| Persona | Personas repräsentieren Bedürfnisse und Ziele einer Zielgruppe und machen eine nutzerzentrierte Entwicklung möglich. Sie spiegeln spezifische Personen wider, die Muster im Nutzerverhalten deutlich machen. |
| Pig | Als »Pigs« bezeichnet man die offiziellen und aktiven Teammitglieder eines Scrum-Teams (➝), die auch Beitragsrecht haben (im Gegensatz zu den ➝ Chicken) und involviert in die Lieferung des Produkts sind. |
| Pilot | Die Einführung von Scrum (➝) gelingt häufig am besten durch die Erprobung in einem Pilotprojekt. Die Projektbeteiligen helfen später bei der Verbreitung von Scrum im Unternehmen. |
| Planning | ➝ Sprint Planning |
| Planning Poker | Planning Poker ist eine Technik für die Schätzung von Backlog Items (➝) im Estimation (➝) oder während des Backlog Refinements (➝). |
| Potentially Shippable | Potentiell auslieferbare Produktinkremente (➝) sind das Ergebnis eines Sprints (➝), das der Definition of Done (➝) entspricht, voll funktionstüchtig ist und produktiv eingesetzt werden kann. |
| Prime Directive | Die »Prime Directive« gilt als Grundsatz für die Haltung und den Umgang miteinander. Es soll den Fingerzeig auf Einzelne oder Personengruppen verhindern. Es wird immer davon ausgegangen, dass jeder die beste Arbeit unter den gegebenen Voraussetzungen, seinen aktuellen Fähigkeiten, den vorhandenen Ressourcen in der jeweiligen Situation geleistet hat. |
| Priorität | Reihenfolge, in der die Backlog Items (➝) umgesetzt werden sollen, meist sortiert nach Geschäftswert (➝ Business Value). |
| Product Discovery | Eine Produktentwicklungsphase, in der eine Produktidee noch vor der Aufnahme in das Product Backlog (➝) ergebnisoffen dahingehend untersucht wird, ob es überhaupt Bedarf für das Produkt bei echten Nutzern gibt. Die Product Discovery ist keine Explorationsphase für Lösungsideen. Es kann (und sollte) vorkommen, dass Produktideen verworfen werden. |
| Product Backlog | Das Product Backlog ist eine Liste von Anforderungen, die alles beinhaltet, was für die Weiterentwicklung des Produkts notwendig ist. Das Product Backlog wird vom Product Owner (➝) sortiert, bereitgestellt, verantwortet und gemeinsam mit den Developern (➝) gepflegt. |
| Product Owner | Der Product Owner ist verantwortlich für den Produkterfolg. Er plant und steuert die Entwicklung in Scrum (➝). Er ist Owner des Product Backlog (➝), sortiert das Product Backlog und legt damit fest, welche Features (➝) zuerst realisiert werden (➝ Release). |
| Product Ownership | Mit diesem Begriff wird die Verantwortung des Product Owners (➝), »sein« Produkt weiterzuentwickeln und dabei die Perspektive der Benutzer (➝) einzunehmen, |
| Produktziel | Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum-Team als Ziel für die Planung zukünftiger Sprints dient. Das Produkt-Ziel ist das langfristige Ziel für ein Scrum-Team. Das Scrum-Team muss diese Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht. |
| Produktinkrement | Funktionalität, die während eines Sprints (➝) vom Scrum-Team (➝) entwickelt wurde (➝ Potentially Shippable). Produktinkremente zeichnen sich dadurch aus, dass sie getestet, ausreichend dokumentiert und einsatzfähig sind. |
| Projektparadoxie | Beschreibt das Phänomen, dass zu Beginn eines Projekts Aussagen über die Machbarkeit oder Dauer getroffen werden und damit zusammenhängende Entscheidungen, obwohl zu diesem Zeitpunkt das geringste Wissen vorherrscht. Um dieser Widersprüchlichkeit zu begegnen gibt es zwei Wege, die Scrum implizit mitbringt: 1. Durch das iterative Vorgehen können kleine Schritte gewählt werden (wie zum Beispiel der Bau von Prototypen (➝), um basierend auf diesen Erfahrungen Entscheidungen zu treffen. 2. Schnellere Lernzyklen und die enge kollaborative fachübergreifende Zusammenarbeit ermöglichen den Beteiligten früher wichtige Entscheidungen zu treffen. |
| Prototyp | Häufig wird in der agilen Produktentwicklung mit Prototypen gearbeitet, die eine erste funktionsfähige Lösung eines geplanten Produkts liefern (➝ MVP). |
| Pull-Prinzip | Das Scrum-Team (➝) bekommt keine Backlog Items (➝) zugewiesen, sondern nimmt sie sich eigenständig aus dem sortierten Product Backlog (➝). In traditionellen Projekten herrscht dagegen oft das Push-Prinzip, bei dem fremdbestimmt vorgegeben wird, woran eine Person (als nächstes) arbeiten soll. |
| Quality Assurance (QA) | Qualitätssicherung ist ein integraler Bestandteil jedes Scrum-Projekts. Sie wird nicht wie im traditionellen Projektmanagement (➝) üblich nachgelagert, sondern durch die Developer (➝) im Sprint (➝) durchgeführt. |
| Refactoring | Als Refactoring bezeichnet man die Restrukturierung von Quellcode, um die Lesbarkeit, Wartbarkeit und Erweiterbarkeit einer Software mittel- und langfristig zu erhalten, ohne dabei Funktionalität (➝ Feature) hinzuzufügen oder zu verändern. |
| Reference Item | Für einige Schätzmethoden wie z. B. Planning Poker (➝) wird zu Beginn ein Backlog Item (➝) als Reference Item festgelegt, das in der Regel relativ klein ist und von allen Beteiligten komplett verstanden und gleich bewertet werden kann. Neu zu schätzende Backlog Items werden in Bezug zum Reference Item geschätzt. |
| Release | Auslieferung der fertiggestellten (➝ Done) und vom Product Owner (➝) abgenommenen Produktinkremente (➝) an den User (➝). |
| Release-Burndown-Chart | Ist ein Burndown-Chart (➝), das für jeden Zeitpunkt eines Projekts anzeigt, wie viele Story Points (➝) bis zu einem Release (➝) noch umzusetzen sind. |
| Releaseplan(ung) | Sobald eine hinreichend stabile Velocity (➝) des Scrum-Teams (➝) vorliegt, können die Backlog Items (➝) entsprechend der Velocity im Product Backlog (➝) gruppiert und eine Aussage darüber getroffen werden, in welchem Sprint (➝) welche Funktionalität (➝ Feature) umgesetzt werden kann. Das Resultat ist ein Releaseplan. Dieser stellt allerdings nur eine Momentaufnahme dar, da er sich mit jeder Änderung am Product Backlog ändern kann und muss somit nach jedem Sprint aktualisiert werden. |
| Respekt | Der Wert jedes einzelnen Menschen steht im Vordergrund. In agilen Projekten ist Respekt einer der agilen Werte (➝ Agile Manifesto). |
| Schätzen | ➝ Backlog Refinement, ➝ Estimation |
| Scrum | Scrum ist ein agiles Rahmenwerk zur Entwicklung komplexer Produkte, das derzeit vor allem in der Produktentwicklung angewendet wird und aus wenigen Verantwortlichkeiten (➝ Scrum-Verantwortlichkeiten), Regeln (➝ Scrum-Events) und Artefakten (➝) besteht. |
| Scrum-Board | Das Scrum-Board ist ein Hilfsmittel des Teams während des Sprints (➝). Es handelt sich in der Regel um eine Fläche im Teamraum, die in vier Spalten aufgeteilt ist. In der ersten Spalte hängen die Sprint Backlog Items (➝), die anderen drei Spalten stellen die Status dar, die ein Task (➝) durchläuft: »Open« (➝), »In Progress« (➝) und »Done« (➝). Jedes Sprint Backlog Item wird in Tasks (➝) heruntergebrochen, die zu Beginn im Status »Open« stehen. Während des Sprints werden die Tasks von links nach rechts bis zum Status »Done« bewegt. |
| Scrum-Events | Als Scrum Events werden die Arbeitstreffen ( ➝ Sprint Planning, ➝ Daily Scrum, ➝ Sprint Planning, ➝ Sprint Retrospektive) bezeichnet. |
| Scrum Guide | Im Scrum Guide werden die Scrum-Regeln dokumentiert. Die aktuelle Version ist der Scrum Guide November 2020. |
| Scrum Master | Der Scrum-Master ist neben dem Product Owner (➝) und den Developern (➝) eine der drei Ergebnisverantwortlichen eines Scrum Teams (➝). Er sorgt für die Einhaltung der Scrum-Vorgaben, er beschützt das Scrum-Team (➝) während des Sprints (➝) vor allen störenden Einflüssen und er beseitigt alle Impediments (➝), die das Scrum-Team (➝) oder einzelne Teammitglieder bei der Verfolgung des Sprint-Ziels (➝) behindern. |
| Scrum of Scrums | Ist eine Synchronisation von Mitgliedern verschiedener Scrum-Teams (➝) im Rahmen eines skalierten Scrum-Projekts analog zu den Daily Scrums (➝) des Teams. Die Teilnehmenden des Meetings können variieren. Es sollte immer das Teammitglied teilnehmen, das am meisten zur aktuellen Lage beitragen kann. (Unter Scrum of Scrums versteht man nicht das Treffen der Scrum Master (➝) verschiedener Scrum-Teams.) |
| Scrum-Rollen | ➝ Scrum-Verantwortlichkeiten |
| Scrum-Team | Ein Scrum-Team setzt sich aus den Verantwortlichkeiten (➝ Scrum-Verantwortlichkeiten)Product Owner (➝), Scrum Master (➝) und Developer (➝) zusammen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Ein Scrum-Team sollte nicht größer als 10 Personen sein. |
| Scrum-Verantwortlichkeiten | In früheren Versionen des Scrum Guides (➝) wurden der Product Owner (➝), Scrum Master (➝) und Developer (➝) als Rolle beschrieben. Da dies dazu führte das Job Titel daraus gemacht wurden und eine starke Abgrenzung stattfand, wurde zu Verantwortlichkeiten gewechselt. |
| Selbstorganisation | Ein wesentliches Merkmal von Scrum-Teams (➝) ist ihre Selbstorganisation. Jedes einzelne Teammitglied übernimmt Verantwortung für den Gesamterfolg. Entscheidungen werden im Scrum-Team getroffen, alle einigen sich auf teaminterne Regeln und Arbeitsweisen. |
| Selected Product Backlog | Nachdem die Developer (➝) im Sprint Planning (➝) diejenigen Sprint Backlog Items (➝ Sprint Backlog) aus dem Sprint Backlog (➝) ausgewählt hat, wird die Gesamtheit dieser Sprint Backlog Items als Selected Product Backlog bezeichnet. |
| Servant Leadership | Ist eine Philosophie und die Umsetzung der »dienenden Führung« im Gegensatz zur »beherrschenden« Führung und beschreibt die Selbstverpflichtung einer Führungsperson, sich in den Dienst seiner Mitarbeitenden zu stellen. Ein Servant Leader befähigt andere Menschen zum eigenständigen Wachstum, um damit mehr Autonomie und Selbstorganisation zu erreichen. |
| Silver Bullet | Der Begriff wird häufig als Metapher dafür verwendet, dass etwas eine schnelle und effiziente Lösung auch für komplexe Problemstellungen herbeiführt, die extrem effektiv ist. |
| Single Wringable Neck | Ein Ausspruch, der deutlich machen soll, dass der Product Owner (➝) alleine verantwortlich für den Projekterfolg ist. |
| Size | Size ist die Größe eines Backlog Items (➝), dokumentiert in Story Points (➝). |
| SMART-Kriterien | SMART-Kriterien werden zur eindeutigen Definition von Zielen verwendet. SMART bedeutet: Spezifisch, Messbar, Akzeptiert, Realistisch und Terminierbar. |
| Smart Meeting | Standardmäßig geplantes Arbeitstreffen, bei dem kurzfristig entschieden wird, ob es stattfindet oder nicht. |
| Smell | »Smell« ist ein Synonym für etwas, das im Projekt nicht richtig läuft. Wenn beispielsweise jedes Teammitglied allein vor seinem Computer sitzt und nicht gesprochen wird, dann liegt förmlich in der Luft, dass ggf. zu wenig Pair Programming (➝) oder Kommunikation stattfindet. |
| Software Craftsmanship | Ist ein Ansatz, der die Fähigkeiten von Softwareentwicklern hervorhebt und betont, das Programmier-Handwerk in bester Art und Weise auszuüben. |
| Softwarearchitekt | In Scrum (➝) gibt es keine Rolle »Architekt«. Stattdessen sind alle Teammitglieder gemeinsam für die Softwarearchitektur verantwortlich. |
| Sprint | Als Sprint wird in Scrum (➝) eine Iteration bezeichnet, die typischerweise 1 – 4 Wochen dauert. Innerhalb eines Sprints wird die im Sprint Planning (➝) vereinbarte Funktionalität (➝ Feature) umgesetzt. Am Ende stehen Inkrement (➝) zur Verfügung, die funktionieren sollten. |
| Sprint Backlog | Im Sprint Planning (➝) werden aus dem Selected Product Backlog (➝) die einzelnen Tasks (➝) für die Sprint Backlog Items (➝) abgeleitet. Das Ergebnis bezeichnet man als Sprint Backlog, dessen Visualisierung auf dem Scrum-Board (➝) erfolgt. |
| Sprint-Burndown-Chart | In einem Sprint-Burndown-Chart werden auf der Y-Achse die Anzahl der im Sprint Planning (➝) festgelegten Tasks (➝) und auf der X-Achse die Arbeitstage des Sprints (➝) markiert. Jeden Tag werden am Ende des Daily Scrum (➝) die offenen Task-Karten am Scrum-Board (➝) durch die Developer (➝) gezählt und die Anzahl im Chart eingetragen. |
| Sprint Backlog Item | Als Sprint Backlog Item werden Anforderungen bezeichnet, die vom Product Owner (➝) für den aktuellen Sprint ausgewählt und von den Developern (➝) während des Sprints (➝) bearbeitet werden. |
| Sprint Planning | Das Sprint Planning findet zu Beginn eines Sprints (➝) statt. Es beinhaltet drei wesentliche Themenbereiche. Der Product Owner (➝) zeigt durch seine Auswahl der Sprint Backlog Items (➝), warum dieser Sprint wertvoll ist und wie dieser auf die Erreichung des Produkt-Ziels (➝) einzahlt. Im Austausch mit den Developern (➝) wird herausgefunden, was in dem aktuellen Sprint abgeschlossen (➝ Done, ➝ Inkrement) werden kann. Gemeinsam wird sich auf ein Sprint-Ziel geeinigt. Zuletzt wird durch die Developer entschieden, wie die Arbeit erledigt werden soll. Für jedes Sprint Backlog Item werden Task (➝) erstellt, die den Kriterien der Definition of Done (➝) erfüllen. |
| Sprint Retrospektive | Die Sprint Retrospektive dient der Identifikation von Verbesserungsmöglichkeiten und ist sehr wichtig für die Zusammenarbeit des Scrum-Teams (➝). Sie wird in der Regel nach jedem Sprint (➝) durchgeführt. Der Sprint und die Geschehnisse werden analysiert, und es werden Maßnahmen abgeleitet, um in folgenden Sprints besser zu werden (➝ Inspect & Adapt). |
| Sprint Review | Das Sprint Review findet am Ende eines jeden Sprints (➝) statt. Eingeladen sind alle Stakeholder (➝) des Projekts sowie alle Personen, die sich über den aktuellen Stand informieren möchten. |
| Sprint-Ziel | Das gesamte Scrum-Team (➝) erarbeitet ein Sprint-Ziel, dass den Stakeholdern (➝) verdeutlicht, warum der Sprint (➝) wertvoll für sie ist. Das Sprint-Ziel muss vor dem Ende des Sprint Plannings (➝) fertiggestellt sein. |
| Sprint Zero | Sprint Zero wird der initiale Sprint (➝) genannt. Er dient der Vorbereitung des Product Backlog (➝), dem Aufsetzen der Infrastruktur und der Klärung, wie das Scrum-Team (➝) zusammenarbeiten möchte. |
| Stakeholder | Als Stakeholder werden all Personen bezeichnet, die ein Interesse am Verlauf oder Ergebnis eines Projekts haben (wie z.B. Aktionäre, interne Abteilungen, Kunden, Lieferanten). |
| (Daily) Stand-up | ➝ Daily Scrum |
| Story | ➝ User Story |
| Story Card | Eine Story Card ist eine Visualisierung einer User Story (➝). Sie enthält neben der eigentlichen Story auch die Akzeptanzkriterien (➝). |
| Story Map | Eine Story Map ist eine zweidimensionale Visualisierung eines Produkts oder eines Release (➝). Die Epics (➝) werden auf einem Zeitstrahl angeordnet und in User Stories (➝) zerlegt. Auf diese Weise entsteht eine Karte (Map), die die Geschichte (➝ Story Card) eines Produkts oder eines Release erzählt. (➝ Walking Skeleton). |
| Story Point | Story Points sind die abstrakte Einheit, mit der die Komplexität (➝) eines Backlog Items (➝) bewertet wird. Sie stammen aus einer begrenzten Menge von Werten, wie bspw. der angepassten Fibonacci-Sequenz (➝), die ein Backlog Item im Backlog Refinement (➝) durch gemeinsames Schätzen der Developer (➝) zugewiesen bekommt. |
| Sustainable Pace | Das Konzept »Sustainable Pace« stammt aus dem Extreme Programming (➝) und sagt aus, dass Softwareentwickler nicht mehr als 40 Stunden pro Woche arbeiten sollen. Wenn es in einer Woche doch dazu kommen sollte, dann sollte die nächste Woche nicht weitere Überstunden enthalten. Dieses Konzept soll nicht nur verhindern, dass in schwierigen Projektphasen wie einem Release (➝) laufend Überstunden gemacht werden, sondern es soll auch die Performance und Kreativität der Personen durch eine ausgewogene Arbeitswoche sicherstellen. |
| Task | Im Sprint Planning (➝) legt das Scrum-Team (➝) die technischen Tasks fest, die zur Umsetzung der Sprint Backlog Items (➝) notwendig sind. Diese Aufgaben (Tasks) werden am Scrum-Board (➝) visualisiert. |
| Taskboard | ➝ Scrum-Board |
| TDD | Bei Test Driven Development (TDD) oder der testgetriebenen Softwareentwicklung werden die Tests vor der tatsächlichen Programmierung verfasst (➝ ATDD). |
| Team | ➝ Scrum-Team |
| Team Estimation Game | Das Team Estimation Game ist eine Technik zur Bewertung von Backlog Items (➝) mit Story Points (➝) im Backlog Refinement (➝) und stellt eine Alternative zum weitverbreiteten Planning Poker (➝) dar. |
| Team Member | Ein Mitglied des Scrum-Teams (➝). |
| Technical Debt | Technische Schulden sind die Konsequenz, die aus einer zu schnellen Entwicklung, unzureichenden Qualität und Softwarearchitektur resultieren (➝ Software Craftsmanship). |
| Themen | Themen, werden zur Strukturierung des Product Backlogs (➝) verwendet und gruppieren eine Menge zusammengehöriger Backlog Items (➝) zu einem bestimmten funktionalen Feature (➝). »Themes« werden manchmal auch Cluster oder Feature Group genannt (➝ Product Backlog, ➝ User Story). |
| Timebox | Die Timebox ist eine festgelegte Zeit für eine bestimmte Aktivität, wie z. B. ein Scrum-Event (➝). Eine Aktivität wird nach einer bestimmten Zeit beendet, auch wenn diese noch nicht inhaltlich abgeschlossen ist. Zur Timebox gehört neben dem festgelegten Ende auch der pünktliche Beginn (➝ Respekt). |
| T-Shaped | »T-Shaped« ist ein Ausdruck, der beschreibt, dass ein Wissensarbeiter über verschiedene Fähigkeiten neben seiner eigentlichen Professionalisierung verfügt. Der vertikale Strich eines »T« deutet auf die Tiefe des Wissens in einem Fachgebiet hin, während der horizontale Strich weitere Wissensgebiete kennzeichnet. |
| T-Shirt Size | Genau wie Story Points (➝) die Komplexität (➝) eines Backlog Items (➝) angeben, können auch T-Shirt-Größen für die Bestimmung der Komplexität genutzt werden. |
| Unit Tests | Von Developern (➝) geschriebene, meist automatisierte Tests, die die interne Codequalität sicherstellen. |
| User | Als (End-)Nutzer (➝) oder User bezeichnet man den Personenkreis (➝ Persona), der das Projektergebnis nutzt. Scrum (➝) stellt das Liefern von Funktionalität (➝ Feature) für einen User in den Vordergrund, nicht die Erfüllung von Aufgaben. Es ist eine bewährte Vorgehensweise, die Backlog Items (➝) aus Sicht des Nutzers zu beschreiben (➝ User Story). |
| User Story | Die in den Sprints (➝) umzusetzenden Anforderungen oder Funktionalitäten (➝ Features) werden meist in Form sogenannter User Stories geschrieben. Dazu wird die Sicht eines Users (➝) eingenommen und dessen Nutzung des Systems (Produkts) beschrieben. Ein Vorteil von User Stories ist, dass sie sowohl von den Fachbereichen als auch von den Technikern verstanden werden, da sie in Alltagssprache formuliert sind. |
| Velocity | Die Summe von Story Points (➝), die ein Scrum-Team (➝) in einem Sprint (➝) umgesetzt hat, bezeichnet man als die Velocity (für diesen Sprint). Über die Zeit pendelt sich die Velocity auf einen relativ stabilen Wert ein, der als »Team-Velocity« bezeichnet wird. Anhand der Velocity ist es möglich, dass Product Backlog (➝) in Blöcke zu unterteilen und somit einen Releaseplan (➝) zu erstellen. |
| Verteilte Entwicklung | Unter verteilter Entwicklung versteht man die Zusammenarbeit von Menschen oder Teams über Standorte oder Ländergrenzen hinweg. |
| Vision | ➝ Produkt-Ziel |
| Vorhersage | ➝ Forecast |
| Walking Skeleton | Bezeichnet eine minimale Implementierung eines Systems, das eine Funktion durch alle Systemschichten hindurch ausführen kann. Es muss nicht die finale Architektur beinhalten, aber sollte bereits die wichtigsten Architekturkomponenten verbinden. Architektur und Funktionalität (➝ Feature) können sich später parallel weiterentwickeln (➝ Story Map). |
| WAP | Widely Adopted Practices – Praktiken, die nicht zu Scrum (➝) gehören, sich aber in sehr vielen Scrum-Implementierungen durchgesetzt haben. Dazu zählen z. B. User Stories (➝), Story Points (➝) und das Backlog Refinement (➝). |
| Wasserfallmethode | Unter der Wasserfallmethode wird oftmals ein lineares Abarbeiten von Arbeitspaketen verstanden. Die einzelnen Phasen werden dabei als Kaskade dargestellt, die deutlichen machen soll, dass nach Beendigung einer Phase die Arbeit in nachgelagerte Phase überläuft. |
| Waste | Als Waste wird im Lean Management (➝) alles bezeichnet, was keinen Wert für den Kunden (➝) liefert. |
| Wissensarbeiterin | Der Begriff wurde von Peter F. Drucker geprägt und bezeichnet einen selbstständig arbeitenden Spezialisten eines Fachgebiets innerhalb einer Organisation. |
| XP | ➝ Extreme Programming |
| Zwei-Pizza-Team | Jeff Bezos, der Gründer von Amazon, prägte diesen Begriff. Seiner Meinung nach ist ein Team zu groß, wenn man es nicht mehr mit zwei Pizzas satt bekommt. |
