Dieses Projektmanagement Glossar liefert eine schnelle Übersicht über die wichtigsten Begriffe aus den Themenbereichen Agilität, Skalierungs-Frameworks und Projektmanagement, wie sie auch hier im Blog verwendet werden.
A
Agile Coach: Sorgt für das richtige Verständnis agiler Praktiken, ist erfahren darin, Teammitglieder effektiver zu machen und Prozesse für die Organisation zu verbessern. Ein Agile Coach ist Moderator:in und Facilitator:in – ähnlich wie die Rolle Scrum Master im Scrum-Framework.
Agile Release Train (ART): Im Skalierungs-Rahmenwerk SAFe® ein dauerhaftes Team aus mehreren agilen Teams, das zusammen mit seinen Stakeholdern innerhalb eines zusammenhängenden Themenbereichs inkrementell eine oder mehrere Lösungen entwickelt, bereitstellt und betreibt.
Agile Triangle: Das klassische Dreieck der drei Einschränkungen (fester Umfang, berechnetes Projektbudget und Zeit) wird sozusagen „auf den Kopf gestellt“, wodurch der Umfang gelieferter Ergebnisse flexibel und verhandelbar wird. Stattdessen werden feste Zeitvorgaben, basierend auf Iterationsrhythmen und möglicherweise einer Deadline, gesetzt.
B
Burn-down Chart: Ein Diagramm, das den Arbeitsaufwand zeigt, der voraussichtlich in der Abarbeitung eines Backlogs verbleibt. Die Zeit wird auf der horizontalen Achse und die verbleibende Arbeit auf der vertikalen Achse angezeigt.
Burn-up Chart: Ein Diagramm, das den Umfang der abgeschlossenen Arbeit anzeigt. Die Zeit wird auf der horizontalen Achse und die abgeschlossene Arbeit auf der vertikalen Achse angezeigt.
C
CCC für User Storys: User Storys sollten kurz genug sein, um auf eine auf eine Karte (Card) zu passen. Sie sollten außerdem als Grundlage für eine Konversation dienen, und sie sollten transparent machen, wann eine Bestätigung (Confirmation) vorliegt, dass sie abgeschlossen sind (also Details, Akzeptanzkriterien enthalten).
Chief Product Owner (CPO): Rolle, die in Jeff Sutherlands Skalierungs-Rahmenwerk ‚Scrum at Scale‘ die Gesamtstrategie und -vision beibehält. Alle anderen agilen Praktiken und Muster des CPO folgen denen von Product Ownern in Scrum.
Communities of Practice (CoPs): Menschen mit gemeinsamen Interessen an einer bestimmten technischen oder geschäftlichen Domäne, die sich zu diesen Themen in Gruppen organisieren. Sie arbeiten in diesen Themengruppen regelmäßig zusammen, um Informationen auszutauschen, ihre Kompetenzen zu verbessern und aktiv an der Weiterentwicklung und dem Austausch ihres Domänenwissens zu arbeiten.
Continuous Integration: Softwareentwicklungs-Prinzip, aus dem Framework ‚Extreme Programming‘: Sobald die Arbeit an einer Aufgabe abgeschlossen ist, wird das Ergebnis früh und häufig in das Gesamtsystem integriert. Nach jeder solchen Integration müssen Tests im System erfolgreich durchlaufen.
Control Limits: Werkzeug aus dem Bereich der Statistik und Qualitätskontrolle, das auch im Projektmanagement Anwendung findet. Sie werden genutzt, um Variabilität in Prozessen zu analysieren und sicherzustellen, dass diese innerhalb eines akzeptablen Bereichs bleibt. Sie können in eigenen Kontrolldiagrammen dargestellt oder in anderen Diagrammen eingezogen werden, so etwa auch in einem Burn-down Chart oder in Fehlermessungen, um z.B. Abweichungen von gewünschten Bearbeitungszeiten oder von der gewünschten Anzahl Fehler im Produkt früh zu erkennen.
Cross-functional team: Ein funktionsübergreifendes Team besteht aus Individuen mit unterschiedlichen fachlichen Spezialisierungen. Es wird funktionalen Teams vorgezogen, da Silos reduziert und die Selbstorganisation gefördert werden.
Crystal Family of Methods: Ein Framework, das die Kritikalität eines Projekts und die Teamgröße mithilfe einer farbcodierten Matrix bewertet, um die passende Vorgehensweise auszuwählen. Crystal Clear ist für kleine, agil arbeitende Teams geeignet.
Cumulative Flow Diagram (CFD): Ein Kanban-Diagramm, das den Feature-Backlog, die laufenden Arbeiten und die abgeschlossenen Features im Laufe der Zeit kumulativ darstellt. Es wird verwendet, um Engpässe zu erkennen und zu beseitigen.
Cycle Time (CT): Lean-Metrik: die durchschnittliche Zeit, die benötigt wird, um Arbeit vom Beginn der Bearbeitung einer Anforderung bis zur Veröffentlichung abzuschließen. Je kürzer, desto besser, solange die Qualitätsstandards eingehalten werden. Begrenzung der Work in Progress oder Erhöhung des Durchsatzes können die Cycle Time reduzieren.
D
Daily Scrum: 15-minütiges Scrum-Event, das jeden Tag für die Developer:innen stattfindet. Das Daily Scrum findet an jedem Tag des Sprints statt. Dabei planen die Developer:innen die Arbeit für die nächsten 24 Stunden. Dies optimiert die Zusammenarbeit und Leistung im Team, indem die Arbeit seit dem letzten Daily Scrum überprüft und die noch bevorstehende Sprint-Arbeit prognostiziert wird. Das Daily Scrum findet jeden Tag zur gleichen Zeit und am gleichen Ort statt, um die Komplexität zu reduzieren.
Daily Standup: Ein Synchronisationsereignis in Kanban und ähnlich in Scrum (dort als Daily Scrum bezeichnet), bei dem sich die Developer:innen über den täglichen Fortschritt abstimmen und bei Bedarf neu planen.
DEEP Backlog: Ein guter Product Backlog ist Detailed Appropriately, Estimated, Emergent und Prioritized (im angemessenen Grad detailliert, geschätzt, neueste Erkenntnisse berücksichtigend und priorisiert). Mehr zu Deep Backlogs.
Definition of Done: Ein gemeinsames Verständnis von allgemeinen Erwartungen, die ein Entwicklungsergebnis erfüllen muss, um produktiv genutzt werden zu können. Es erhöht die Transparenz und hilft bei der Planung des benötigten Aufwands für Arbeit – eine längere DoD braucht auch mehr Zeit, um sie zu erfüllen. Wird von agilen Teams erstellt und verantwortet.
Defect Rate: Die Anzahl der bei und nach der Entwicklung gefundenen Fehler in einem Produkt sollte gemessen und verfolgt werden. Eine höhere Rate kann mehr Defekte oder eine bessere Erkennung bedeuten, daher ist es wichtig, auch die Defect Detection Rate zu überwachen (wie gut sind wir beim Erkennen von Fehlern, wie viele bleiben unerkannt?).
Design Thinking: Ein Ansatz, der vom Designunternehmen IDEO entwickelt wurde. Er fördert Kreativität bei der Entscheidungsfindung durch einen Prozess aus Erfahrung, Ideenfindung und Prototyping mit starker Einbindung der Nutzer.
Developer:in: Jedes Mitglied eines Scrum-Teams, das sich dazu verpflichtet, in jedem Sprint einen Aspekt eines nutzbaren Inkrements umzusetzen.
DevOps: ein Ansatz, der die Zusammenarbeit von Entwicklung (Development) und IT-Betrieb (Operations) fördert, um Software schneller, zuverlässiger und mit höherer Qualität bereitzustellen.
Dreyfus Skill Acquisition Model: Schritte, die eine Person beim Erlernen neuer Fähigkeiten durchläuft: Einsteiger, Anfänger, Kompetent, Erfahren, Experte. In einem agilen Team sollten zumindest einige Personen über die Fähigkeiten verfügen, die notwendig sind, um lieferbare Inkremente zu erstellen – und mindestens erfahren in diesen Fähigkeiten sein. Sie sollten ihr Wissen mit dem Team teilen.
Dynamic System Development Method (DSDM): Ansatz aus den frühen 1990er-Jahren, um IT-Projekte agiler durchzuführen, mit explorativen Projektphasen und iterativen Aspekten.
E
Earned Value Management (EVM): Eine klassische Methode zur Messung der Projektleistung, die Umfang, Zeit und Kosten integriert, um den Fortschritt zu überprüfen, Abweichungen vom Plan zu messen und Maßnahmen zu ergreifen. Häufig in Kombination mit einer Work Breakdown Structure (WBS) verwendet.
Entwicklungs-Standards: Ein gemeinsamer Satz von Umsetzungs- und Technologiestandards, die Entwickler anwenden, um lieferfähige Software-Inkremente zu erstellen.
Emergenz: Der Prozess des Entstehens oder des Bekanntwerdens neuer Tatsachen bzw. neuer Erkenntnisse, der unerwartet zu Tage tritt.
Empirismus: Die Philosophie, dass alles Wissen aus Erfahrung und Beobachtungen entsteht.
Escaped Defects: Defekte, die vom Kunden nach der Auslieferung gemeldet werden. Diese sollten verfolgt werden, um Möglichkeiten zur Prozessverbesserung zu identifizieren.
Evidence-Based Management (EvBM): Beinhaltet das Treffen von Entscheidungen auf Basis harter Fakten darüber, was tatsächlich funktioniert. Es umfasst eine Reihe von Metriken zur Messung des Produktwerts, z. B. Current Value, Time to Market und Ability to Innovate.
Executive Action Team (ETA): Nach dem S@S-Framework in großen Organisationen eine höhere Abstraktionsebene über der SoS-Ebene. Das ETA befasst sich mit Hindernissen, die vom Scrum of Scrums Master nicht gelöst werden können.
Executive Meta Scrum (EMS): Nach dem S@S-Framework ein Event, bei dem sich Chief Product Owner mit Führungskräften und wichtigen Stakeholdern treffen, um Prioritäten zu setzen, Budgets zu ändern oder Teams neu auszurichten.
Extreme Programming (XP): Agiles Framework, das ähnlich wie Scrum ein Projekt in kleinere Iterationen aufteilt; nutzt Release-Planung, User Storys und Velocity. 13 Kernpraktiken wie Refactoring und Pair Programming. Mehr zu Extreme Programming.
F
5 Whys: Eine Technik, bei der die Frage „Warum (ist das passiert)?“ fünfmal gestellt wird, um die Schichten von Symptomen abzutragen und die eigentliche Grundursache eines Problems zu finden. Entwickelt von Taiichi Ohno bei Toyota.
Feature: Eine Funktion oder eine Arbeitseinheit, die nach ihrer Fertigstellung den Endbenutzern einen Mehrwert bietet.
Feature Breakdown Structure (FBS): Eine Zerlegung des Arbeitsumfangs für ein Produkt in Features, Epics, Storys und Tasks (aus dem agilen Framework ‚Feature-Driven Development‘). Wird in agilen Ansätzen häufiger verwendet als eine klassische Work Breakdown Structure (dt. Projektstrukturplan), bei der Budgets und Zeitpläne auf Arbeitspakete verteilt werden und damit der Umfang fixiert wird.
Feature-Driven Development: Ein iterativer und inkrementeller Softwareentwicklungsprozess, der sich an funktionaler, für den Kunden wertvoller Funktionalität (Features) orientiert. Feature-Driven Development wird hauptsächlich in der agilen Softwareentwicklung eingesetzt. Es basiert auf dem Prinzip, nach Features zu planen, zu entwerfen und zu entwickeln, und organisiert Teams in funktionsübergreifende Feature-Teams (nicht in einzelne Komponenten-Teams).
Fishbone-Analyse: Ein Ansatz von Kaoru Ishikawa zur Problemlösung, bei dem ein Diagramm in Form einer Fischgräte gezeichnet wird, das das Problem und seine möglichen Ursachen darstellt, damit diese in ihrer Vielfalt genauer untersucht werden können.
Flow: bezeichnet in Lean und Kanban das ungehinderte, gleichmäßige Fließen von Arbeit durch einen Prozess. Ziel ist es, Reibungsverluste wie Engpässe, Wartezeiten oder unnötige Unterbrechungen zu minimieren, damit Arbeit möglichst schnell und effizient von der Idee bis zum Ergebnis durchläuft.. Ein Team sollte seinen Flow finden und schützen. In einem Kanban-System fließen Aufgaben (z. B. User Storys) durch Spalten wie „To Do,“ „In Progress“ und „Done.“ Wenn eine Spalte blockiert ist (z. B. zu viele Aufgaben „In Progress“), wird der Engpass analysiert und behoben, um den Flow wiederherzustellen.
Forecast (Vorhersagen von Funktionalitäten): Die Auswahl von Einträgen aus dem Product Backlog, die Entwickler für die Umsetzung in einem Sprint für machbar halten.
G
Guilds: Im Spotify-Modell eine Gruppe von Arbeitnehmern mit demselben Fachwissen und/oder den gleichen Interessen. Bezieht die gesamte Organisation mit ein.
I
Increment: Agiles Artefakt, das die vollständige und wertvolle Arbeit definiert, die von den Developer:innen während eines Sprints geleistet wird – insofern also die Arbeitsergebnisse enthält. Die Summe aller Inkremente bildet ein Produkt.
Internal Rate of Return (IRR): Interner Zinsfuß etwa eines Projekts – also was dieses spätestens nach Beendigung „abwirft“ bzw. wie rentabel es ist. Projekte mit einer höheren Internal Rate of Return (IRR) sind finanziell attraktiver.
INVEST criteria für User Storys: User storys sollten sein: Independent – unabhängig von anderen Storys im Backlog, Negotiable – flexibel und nicht als fixiertes Detail betrachtet werden, Valuable – einen klaren Mehrwert für den Nutzer bieten, Estimable – Einschätzbar in Aufwand und Umfang sein, Sized Appropriately oder Small – klein genug, um in kurzer Zeit umgesetzt zu werden, Testable – mittels klarer Akzeptanzkriterien in ihrer Erfüllung überprüfbar sein. Das Ziel dieser Kriterien ist es sicherzugehen, dass User Storys in einem Backlog immer leicht umsetzbar und für alle verständlich sind.
J
Just-in-time (JIT): Ein Lean-Ansatz, bei dem Materialien genau dann geliefert werden, wenn sie für die Produktion oder den Weiterverkauf benötigt werden. In der Wissensarbeit bedeutet Just-in-Time-Planung, dass Arbeit erst dann im Detail geplant wird, wenn sie bald durchgeführt werden soll. Höher priorisierte Backlog-Elemente erhalten dabei mehr Aufmerksamkeit und Detailgenauigkeit als weniger priorisierte.
K
Kaizen (jap): Kontinuierliche Verbesserung der Prozesse, die alle Beteiligten einbezieht.
Kanban (jap.): „Karte“ oder „sichtbarer Eintrag“ – bezieht sich auf ein System zur Steuerung des Arbeitsflusses in einer Fabrik oder einem Wissensarbeitsteam zu steuern, zu visualisieren und zu organisieren, und somit auf eine Methode. Kanban beginnt mit einem bestehenden Prozess und lässt diesen sich weiterentwickeln. Es basiert auf Selbstorganisation, Pull-Prinzipien und WIP-Limits (Work in Progress).
Kano Model: Ein von Noriaki Kano entwickeltes Modell, das hilft, Kundenpräferenzen zu verstehen. Das Kano-Modell berücksichtigt Eigenschaften eines Produkts oder einer Dienstleistung, die in Bereiche wie Grundfaktoren, Begeisterungsfaktoren und Leistungsfaktoren unterteilt werden. Es kann verwendet werden, um Backlog-Elemente zu klassifizieren und Begeisterungsmerkmale (Exciters/Delighters) in ein MVP (Minimum Viable Product) aufzunehmen.
Kohärenz: Die Qualität der Beziehung zwischen bestimmten Product Backlog-Elementen, die es wert sein kann, als Ganzes betrachtet zu werden.
L
Lean Manufacturing / Production: Ein Ansatz, der darauf abzielt, die höchstmögliche Produktivität und Gesamtqualität kosteneffizient zu erreichen, indem unnötige Schritte im Produktionsprozess eliminiert und kontinuierlich Verbesserungen angestrebt werden. Geprägt als Toyota Production System (Taiichi Ohno). Kontinuierliche Verbesserung und die Beseitigung von Verschwendung stehen im Mittelpunkt.
Little’s Law: Beschreibt eine mathematische Beziehung zwischen Durchsatzrate, Cycle Time und der Menge an Work in Progress (WIP).
M
Minimum Business Increment (MBI): Ein Konzept aus dem Toolkit Disciplined Agile von PMI: ein Increment, das auf einer bestehenden Struktur oder einem Produkt aufbaut und diesem neuen Mehrwert liefert.
Minimum Marketable Feature (MMF): Eine kleine, in sich geschlossene Funktion, die schnell entwickelt werden kann und dem Nutzer einen bedeutenden Mehrwert bietet.
Minimum Viable Product (MVP): Ein Konzept aus dem Lean Startup, das ein minimalistisches Produkt beschreibt, mit dem Unternehmer und Entwickler grundlegende Konzepte einer Idee testen und validieren sowie Kundenfeedback sammeln können.
Mockup: Das ursprüngliche Design oder die Idee, die entweder auf dem Bildschirm angezeigt oder in gedruckter Form präsentiert wird. Mockups ermöglichen es dem Kunden, zu sehen, wie das Endprodukt aussehen soll.
MoSCoW technique: Eine Priorisierungstechnik aus DSDM für User Storys im Backlog: Welche Features sind Must-haves, Should-haves, Could-haves, Won’t-haves this time?
N
Net Present Value (NPV): In der BWL die Summe der Barwerte der erwarteten zukünftigen Cashflows aus einer Investition, abzüglich der Kosten dieser Investition. Angewendet im Projektmanagement ist ein Projekt mit einem höheren Net Present Value (NPV) finanziell attraktiver.
Nexus: Ein Framework der Organisation Scrum.org, das agile Ansätze für größere Projekte skaliert. Mehrere Teams arbeiten dabei am selben Product Backlog, koordiniert durch das Nexus Integration Team, das die Anwendung von Nexus und Scrum koordniniert, coacht und überwacht. Dabei ist es für dieses Team wichtig, für transparente Verantwortlichkeit der Integration zwischen den Scrum-Teams zu sorgen.
P
Payback Period: Die Zeitspanne, die erforderlich ist, damit eine Investition ausreichend Cashflows generiert, um ihre Anfangskosten auszugleichen. Projekte mit einer kürzeren Amortisationszeit sind finanziell attraktiver.
Pair programming (Praktik aus XP): Bezieht zwei Programmierer:innen an einem einzigen Arbeitsplatz ein und bringt sie zusammen. Während einer den Code schreibt, beobachtet der andere aktiv, achtet auf mögliche Fehler und denkt gleichzeitig über den Gesamtansatz nach. Fördert Kreativität und Wissensaustausch.
Persona: Fiktive Vertreter realer Nutzer oder Nutzertypen, die eingesetzt werden, um eine benutzerzentriertere Entwicklung zu ermöglichen. User Storys können für bestimmte Personas geschrieben werden.
PI Planning: Ein kadenzbasiertes Face-to-Face-Event und der Herzschlag des Agile Release Train (ART).
Planning Poker: Eine konsensbasierte Technik zur Schätzung, die hauptsächlich verwendet wird, um den Aufwand oder die relative Größe von Storys oder Aufgaben in der Softwareentwicklung zu ermitteln. Dabei stellt jemand die Story vor, und alle Schätzenden (z. B. Entwickler:innen) geben gleichzeitig ihre Schätzungen, wie Story Points, ab. Wenn es Abweichungen gibt, werden diese diskutiert, und der Vorgang wird wiederholt.
Program Increment (PI): Eine Timebox, in der ein Agile Release Train (ART) inkrementell Wert liefert.
Product Backlog: Ein Scrum-Artefakt, das aus einer sortierten Liste derjenigen Arbeiten besteht, die für eine Produktentwicklung, -pflege und -wartung ausgeführt werden müssen.
Product Backlog Refinement: Die Aktivität in einem Sprint, durch die der Product Owner und die Entwickler dem Product Backlog mehr Granularität hinzufügen.
Product Goal (Produkt-Ziel): Beschreibt einen zukünftigen Zustand des Produkts, der als Ziel für das Scrum-Team dienen kann.
Product Owner: Rolle in Scrum, die für die Maximierung des Wertes eines Produkts verantwortlich ist.
Prototype: Ein vollständiges funktionsfähiges Modell, das verwendet wird, um ein Designkonzept zu testen, tatsächliche Beobachtungen zu machen und erforderliche Anpassungen vorzunehmen.
R
Ready: Ein gemeinsames Verständnis zwischen dem Product Owner und den Entwicklern hinsichtlich des gewünschten Beschreibungsgrades von Product-Backlog-Einträgen.
Refactoring: Überarbeitung, Neuorganisation und Umstrukturierung eines Teils eines Systems, um dessen Qualität zu erhöhen.
Refinement: Siehe Product Backlog Refinement
Relative sizing / relative Schätzung: Die Schätzung der Größe einer Funktion oder User Story, basierend auf der Größe einer anderen. Ein Beispiel ist die Übung, eine Gruppe von User Storys von der schwierigsten bis zur einfachsten oder von der höchsten bis zur niedrigsten Komplexität zu ordnen, ohne eine absolute Schätzung vorzunehmen. Psychologisch fällt Menschen diese Art der Schätzung leichter als die absolute (es ist einfacher zu sagen „diese Aufgabe ist kleiner als jene“ im Gegensatz zu „für diese Aufgabe brauche ich 3 Tage“).
Release Train Engineer (RTE): In SAFe ein Coach für den Agile Release Train (ART) und somit eine Art Integrations-Scrum-Master.
Return on Investment (ROI): Der Prozentsatz der Gesamtkosten einer (Projekt-)Investition im Verhältnis zum erzielten Gewinn aus dieser Investition (den Nutzen, den das Projekt liefert). Ein Projekt mit einem höheren ROI ist finanziell attraktiver.
Retrospektive: Agile Teams überprüfen und passen regelmäßig ihre Prozesse, Tools und Teamdynamik an. Die Definition of Done kann in diesem Event aktualisiert werden. Mehr zu Retrospektiven hier.
Root-cause analysis (RCA): Ermittelt die zugrunde liegende Ursache von unerwünschten Ereignissen; wird nach einem Vorfall eingesetzt, um die Hauptursache aufzudecken. Grundregel: Verstehe immer die Ursache eines Problems, bevor du versuchst, es zu lösen.
S
Scaled Daily Scrum: Nach dem S@S-Rahmenwerk koordinieren im Scaled Daily Scrum Mitglieder der Scrum-of-Scrum Teams (Vertreter:innen der einzelnen agilen Teams) ihre tägliche Arbeit und Abhängigkeiten untereinander sowie aktuelle Hindernisse und Blocker.
Scrum: Ein gängiges Framework für die agile Entwicklung komplexer Produkte. Teams planen und erledigen ihre Arbeit in kurzen Iterationen, den sogenannten Sprints. Diese schaffen eine regelmäßige Taktung für die weiteren Events und dienen der Anwendung empirischer Prinzipien.
Scrum@Scale (S@S): Ein agiles Vorgehensmodell von Jeff Sutherland zur Skalierung von Scrum über mehrere Teams und Organisationsebenen.
Scrum Board: Ein physisches Board zur Visualisierung von Informationen für und durch das Scrum-Team.
Scrum Guide™: Die Definition von Scrum, geschrieben und bereitgestellt von Ken Schwaber und Jeff Sutherland unter scrumguides.org.
Scrum Master: Rolle innerhalb eines Scrum-Teams, die für die Anleitung, das Coaching, das Training und die Unterstützung eines Scrum-Teams verantwortlich ist.
Scrum Team: Ein selbstmanagiertes Team, bestehend aus Scrum Master:in, Product Owner:in und Developer:innen.
Scrum-Werte: Diese lauten Commitment, Fokus, Offenheit, Respekt und Mut und sind für jedes Scrum Team verpflichtend als Werte-Ideal, nach dem immer gestrebt werden sollte.
Selbst-Management: Scrum-Teams sind funktionsübergreifend und selbstverwaltend.
Shu Ha Ri: Ein Fortschreiten eines Teams oder auch einzelner Mitglieder durch verschiedene Stufen: Shu = Befolgen oder Schützen, Akzeptieren der Regeln, Ha = Ablösen oder Abweichen, Abweichen von den Regeln, Ri = Verlassen oder Trennen, Eigene Regeln erstellen. Ein agiles Team benötigt mindestens einige Personen auf der Ri-Stufe.
Spikes: („Durchstich“:) Explorative Aufgaben, die in einer Iteration durchgeführt werden, um Unsicherheiten bezüglich einer Situation, eines Risikos, der zu verwendenden Technologie usw. zu verringern. Sie führen nicht direkt zu Features, tragen aber dazu bei, diese in Zukunft zu erstellen. Sollten bei Bedarf Teil des Product Backlogs sein, um Unsicherheiten zu reduzieren.
Spotify-Modell: Ein Modell, das kein klassisches Skalierungs-Framework darstellt, sondern eine Momentaufnahme aus dem skalierten agilen Unternehmensumfeld von Spotify.
Squads: Agile Teams als Basis des Spotify-Modells, vergleichbar mit einem Scrum Team.
Sprint: Scrum-Begriff für eine Iteration – ein zeitlich begrenztes Ereignis von bis zu vier Wochen, in dem Arbeit geplant, abgeschlossen und in einem Review mit Stakeholdern überprüft wird, um deren Feedback einzuholen. Der Sprint sollte mit einer Sprint-Retrospektive abgeschlossen werden, um teamintern Prozesse, Tools usw. zu analysieren und Verbesserungen für den nächsten Sprint zu finden.
Sprint-Backlog: Scrum-Artefakt, das einen Überblick und Transparenz über die Entwicklungsarbeit zur Erreichung des Ziels eines Sprints bietet.
Sprint-Ziel: Ein kurzer Ausdruck des gemeinsam anvisierten Ziels für eines Sprint, wird bei jeder Sprintplanung vom Team gemeinsam festgelegt und danach täglich verfolgt.
Sprintplanung: Scrum-Event, um gemeinsam in einen neuen Sprint zu starten.
Sprint-Retrospektive: Scrum-Event, um einen Sprint gemeinsam zu beenden und Verbesserungen zu planen.
Sprint-Review: Scrum-Event, um die Entwicklungsarbeit eines Sprints abzuschließen.
Stakeholder: Personen, die an einem Produkt interessiert sind und deren Interessen durch das Produkt beeinflusst werden (sie haben einen „Anspruch“ darauf). Dazu können Kunden, Sponsoren, Endbenutzer, Manager und beteiligte Abteilungen, Geschäftsleute, juristische Personen, im Bauwesen auch Anwohner und viele andere gehören.
System Demo: Ein Event in SAFe, das am Ende eines Entwicklungs-(PI-)-Zyklus eine integrierte Sicht neuer Features für alle Interessierten und Beteiligten bietet.
T
Task: Eine Arbeitseinheit, die erledigt werden muss – die kleinste Arbeitseinheit, die idealerweise im Iterations-Backlog zu finden ist und während der Iterationsplanung (siehe Just-in-Time-Planung) geplant wird.
Technische Schulden: Der in der Regel unvorhersehbare Aufwand für die Wartung des Produkts.
Test-Driven Development: Eine Methode der Softwareentwicklung, ursprünglich aus XP – Testfälle werden vor der eigentlichen Entwicklung der Software erstellt und oft automatisiert. Schritte: Neuen Test schreiben, der zunächst fehlschlägt, Code schreiben, bis der Test erfolgreich durchläuft, Code bereinigen (Refactoring), wiederholen.
Theory of Constraints: Ein Managementansatz, beschrieben von Eliyahu M. Goldratt, der die Bedeutung des Umgangs mit Einschränkungen hervorhebt und darauf abzielt, Engpässe zu identifizieren und zu beseitigen.
Timebox: Ein Prinzip, dass Ereignisse zeitlich begrenzt (mit einer maximalen Dauer) sein sollten, um danach weiterzugehen, Prokrastination und Chaos zu begrenzen sowie Disziplin und Gewohnheit zu entwickeln, sich daran zu halten und das Beste aus ihnen herauszuholen. Alle Scrum-Events, einschließlich des Sprints, sind zeitlich begrenzt.
Trade-off Matrix: Eine von Jim Highsmith (im Buch „Agile Project Management“) vorgeschlagene Matrix, bei der Stakeholder entscheiden müssen, ob sie Fixierungen eher bei Zeit, Budget oder Umfang wünschen. Basierend darauf wird festgelegt, welche der drei als notwendig definiert werden und was flexibel bleibt. Eine Alternative zum Agile Triangle, häufig von DevOps-Teams eingesetzt.
Tribes: Eine Gruppe von Squads, die am gleichen Produkt oder miteinander in Verbindung stehenden Produkten arbeiten.
Tuckmans Modell der Teamentwicklung: Laut Bruce Tuckman durchlaufen Teams typischerweise diese Phasen: Forming (Formierung), Storming (Konfliktphase), Norming (Normierungsphase), Performing (Arbeitsphase), Adjourning (Auflösungsphase). Achtung: Ein Team fällt in die Forming-Phase zurück, wenn neue Mitglieder hinzukommen.
U
User Story: Eine kleine, prägnante Beschreibung einer Funktionalität oder Qualität, die erforderlich ist, um einem bestimmten Stakeholder Wert zu liefern. Häufig ein Eintrag im Product Backlog eines agilen Teams. Mehr zu User Stories.
V
Value Stream Mapping: Eine grafische Darstellung des Value Streams (Wertstroms), also der Wertschöpfung für Stakeholder durch einen Prozessfluss. Sie dient der Analyse, wo im Prozess Schritte Wert hinzufügen oder nicht. Wird verwendet, um Verschwendung zu identifizieren. Mehr dazu hier.
Velocity: In der agilen Entwicklung bezeichnet die Menge an Backlog-Elementen, die während einer Iteration in funktionsfähige Inkremente umgesetzt wird. Ein Team kann seine Velocity nachverfolgen und beschützen, um zu einem nachhaltigen Arbeitsrhythmus zu gelangen. Sie sollte in der Planung jeder Iteration berücksichtigt werden.
W
Walking Skeleton: Ein Produktentwicklungsansatz, bei dem eine vollständige Systemstruktur erstellt wird, jedoch mit nur minimaler Funktionalität.
Wideband Delphi Technique: Wideband-Delphi ist eine gruppenbasierte Schätztechnik, die verwendet wird, um den Arbeitsaufwand und die benötigte Zeit zur Fertigstellung eines Projekts zu bestimmen. Dabei geben die Teammitglieder anonym Schätzungen für jede Funktion ab, und die anfänglichen Schätzungen werden in einem Diagramm dargestellt. Anschließend diskutiert das Team die Faktoren, die ihre Schätzungen beeinflusst haben, und führt eine zweite Schätzrunde durch. Dieser Prozess wird so lange wiederholt, bis die Schätzungen der einzelnen Mitglieder nahe beieinander liegen und ein Konsens für die endgültige Schätzung erreicht werden kann.
Wireframe: Eine Abbildung oder eine Reihe von Abbildungen, die die funktionalen Elemente einer Website oder Seite darstellen, typischerweise zur Planung der Struktur und Funktionalität einer Website verwendet. Oft in Schwarz-Weiß und als einfache Skizze gehalten.
Work Breakdown Structure (WBS): Ein klassisches Projektmanagement-Tool, dt. Projektstrukturplan: eine hierarchische Zerlegung des gesamten Arbeitsumfangs, der vom Projektteam durchgeführt werden muss, um die Projektziele zu erreichen und die erforderlichen Ergebnisse zu liefern. Mehr zum Projektstrukturplan hier.
Work in Progress / Process (WIP): Ein Status, der bedeutet, dass Aktivitäten begonnen haben, aber noch nicht abgeschlossen sind. Er wird häufig als Status für Storys, Incidents, Probleme, Änderungen, Backlog-Items, Aufgaben usw. verwendet. Work in Process (WIP) sollte begrenzt werden, um den Fokus zu bewahren und Engpässe zu vermeiden. In Scrum wird WIP bei jeder Sprint-Planung für den jeweiligen Sprint schon allein durch die Auswahl an geeigneten Backlog-Einträgen begrenzt.
