Folgende Agile Werte sind Bestandteil der agilen Entwicklung:

Offenheit, Respekt, Fokus, Commitment und Mut. 

Die agile Softwareentwicklung basiert auf einem Fundament an Werten, die 2001 als „Manifesto for Agile Software Development“ – kurz: Agile Manifesto, oder auf deutsch: Agiles Manifest – veröffentlicht wurden. Das Agile Manifest wurde von Fachleuten der Softwareentwicklung verfasst und das Agiles Manifest besagt:

„Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans weiterlesen“

Akzeptanz Kriterien sind fachliche definierte Anforderungen, welche eine User Story/ ein Feature/ oder ein Produkt zum Zeitpunkt der Abnahme erfüllen muss, damit es als erledigt gilt.

Ein Burndown Chart ist ein beliebtes Scrum-Tool zur Überwachung der Teamleistung und des Projektfortschritts. Es gibt mehrere verschiedene Arten von Burndiagrammen: Sprint Burndown Chart, Release Burndown Chart, Product Burndown Chart.

Das Daily Scrum findet innerhalb des Sprints  jeden Arbeitstag statt und dauert nicht länger als 15 Minuten. Es ist time-boxed. Es dient dem Entwicklungsteam dazu, sich abzustimmen und gegenseitig zu informieren. 

In der Regel beantwortet jedes Teammitglied folgende 3 Fragen:

• Was wurde seit dem letzten Daily Scrum erreicht?
• Was wird bis zum nächsten Daily Scrum erledigt?
• Welcher Hindernisse gibt es?

Die Fragen können auch variieren.

Die Definition of Ready (DoR) ist eine Liste von Kriterien, die an die Product Backlog Items/ User Stories gestellt werden und die erfüllt seien müssen, damit sie in einem der nächsten Sprints berücksichtigt werden können. Nur Product Backlog Items/ User Stories mit dem Status „READY“ dürfen in einen Sprint.

Die Definition of Done beinhaltet die Kriterien, die erfüllt sein müssen, damit eine Feature/ eine User Story als „fertig/done“ bezeichnet werden kann. Sie ist allgemein gültig für alle Features/ User Stories und wurde vom Product Owner und dem Entwicklungsteam akzeptiert.

Design Thinking ist ein Kreativprozess zur Ideenfindung. Es ist ein Ansatz, der zum Lösen von Problemen und zur Entwicklung neuer Ideen führen soll und sich dabei am Nutzer orientiert. Ziel ist es Lösungen zu finden, die aus Anwendersicht überzeugend sind. 

Das Entwicklungsteam ist eine der drei zentralen Rollen in der agilen Software-Entwicklungsmethode Scrum und ist für die Lieferung der Produktfunktionalitäten, in der vom Product Owner gewünschten Reihenfolge, verantwortlich. Die Teams bestehen normalerweise zwischen 3-9 Personen. Sie organisieren sich selbst und entscheiden eigenständig darüber, wie die zu erledigenden Aufgaben am besten erledigt bzw. bewältigt  werden. Ein Entwicklungsteam muss fähig sein, das Ziel eines Sprints ohne größere äußere Abhängigkeiten durch andere Teilnehmer zu erreichen. 

Ein Epic ist eine High-Level-Anforderung, daher kann sich sein Umfang im Laufe der Zeit ändern. Sie werden auch oft als Platzhalter für neue Ideen genutzt, die noch nicht vollständig ausgearbeitet wurden. Später werden Sie dann in kleinere User Stories herunter gebrochen, die dann ausgearbeitet und genau definiert werden.

Die Fibonacci Folge ist eine spezifische Zahlenfolge (1, 1, 1, 2, 3, 5, 8, 13, 21, 34…), bei der die nächste Zahl in der Folge durch Addition der beiden vorhergehenden Zahlen in der Folge abgeleitet wird. Eine modifizierte Version der Fibonacci Folge ist eine gängige Folge, die bei der Durchführung von Relativgrößenschätzungen von Product Backlog-Items verwendet wird.

Der Begriff „Inkrement“ stammt aus dem Lateinischen und bedeutet ins Deutsche übersetzt „vergrößern“. In Scrum ist ein Inkrement das erwartete, potenziell lieferfähige möglichst releasebare Ergebnis eines Sprints.

Ein Imediment ist ein Hindernis etwas zu tun. In agilen Kontext wird es verwendet, um ein Problem oder einen Blocker zu beschreiben, der ein Team oder eine Organisation daran hindert, Scrum auf effektive Weise durchzuführen.

Ursprünglich wurde Kanban für die Automobilindustrie von Toyota entwickelt und stammt aus Japan.

Das Wort „Kanban“ ist auch japanisch und bedeutet so viel wie Signalkarte. Es setzt sich aus den beiden Begriffen kan (=visualisieren) und ban (=Karte) zusammen. 

Kanban ist eine Methode in der Softwareentwicklung, bei der die Anzahl paralleler Arbeiten limitiert wird. Man spricht hier von dem Work in Progress (WiP). Das Ziel ist es kürzere Durchlaufzeiten zu erzielen und Probleme, insbesondere Engpässe, schneller sichtbar zu machen.

Das Kano-Modell ist ein Modell zur Priorisierung von Kundenwünschen.

Es wurde nach Noriaki Kano, ehemaliger Professor an der Universität Tokio, benannt und basiert auf seiner Analyse zu  Kundenwünschen von 1978. Er leitete von dieser Studie ab, dass Kundenanforderungen unterschiedlicher Art sein können. Das Kano-Modell hilt dabei, die Wünsche und Erwartungen von Kunden aufzunehmen, so dass sie bei Entwicklung bzw. Weiterentwicklung von Produkten einbezogen werden können.

Folgende Qualitätskriterien werden in der KANO Analyse berücksichtigt:

• Basismerkmale
  Starke Unzufriedenheit, wenn diese Funktionalitäten nicht da sind.
• Leistungsfaktoren
  Zufriedenheit garantiert, wenn diese Wünsche umgesetzet werden.
• Begeisterungselemente
  Dauerhaft hohe Zufriedenheit, wenn diese Funktionen geboten werden, selbst bei steigenden Ansprüchen.
• Neutrale Faktoren
  Können vernachlässigt werden – um unnötigen Aufwand zu vermeiden.

Die KANO-Analyse hilft dabei sich auf die Dinge zu fokussieren, die den größten Beitrag zu einer höheren Nutzer- und Kundenzufriedenheit leisten und so langfristig Erfolg sichern.

Large Scale Scrum (LeSS) ist eine Austellung von Rahmenwerken, Leitlinien und Vorschlägen für Experimente, die helfen sollen Scrum für eine große Anzahl von Teams zu skalieren. LeSS ist wie Scrum dazu gedacht, die Produktentwicklung hinsichtlich Agilität zu optimieren.

Die Lean Startup Methode veränderte fundamental die Art der Entwicklung von neuen Produkten und Services. Sie wurde von Eric Ries entwickelt und  2011 veröffentlichte er ein Buch zu dem Thema  The Lean Startup, welches die Grundlage für diese Methode ist. Diese Methode verändert die Art und Weise, wie Unternehmen aufgebaut und neue Produkte eingeführt werden und sie ermöglicht Anpassungen am Produkt vorzunehmen und schnell auf Veränderungen des Marktes zu reagieren.

Minimum Viable Product (MVP), bedeutet wörtlich übersetzt ein „minimal überlebensfähiges Produkt“ und steht für die erste minimal funktionsfähige Iteration eines Produkts.

Der grundlegende Gedanke bei der Erstellung eines MVP`s ist es, ein Produkt möglichst schnell mit nur den nötigsten Funktionen für den Kunden zu erstellen, um mit minimalem Aufwand möglichst schnell handlungsrelevantes Feedback zu erhalten.

Nonfunctional Requirements (NFRs) beschreiben Systemattribute wie Sicherheit, Verlässlichkeit, Leistung, Wartungsfähigkeit, Skalierbarkeit und Nutzbarkeit. Sie dienen als Rahmenbedingungen für das Produkt über die verschiedenen Backlogs / funktionelle Anforderungen hinweg.

Der englische Begriff Objectives and Key Results (OKRs) bezeichnet eine Management Methode, die die Ziele des Unternehmens mit den Zielen des einzelnen Mitarbeiters verknüpft und damit einen klaren Fokus für Aktivitäten der nächsten drei Monate setzt. Es ist also ein Rahmenwerk zur Zielsetzung (Objectives) und Messung von Ergebnissen (Key Results).

OKRs werden unter anderen von Unternehmen wie  Google, Twitter und LinkedIn genutzt.

In Scrum versteht man unter dem Product Backlog die gesammelten Anforderungen an ein Pordukt/ eine Software, die entwickelt werden soll. Zuständig für den Product Backlog ist der Product Owner, der diesen ständig weiterentwickelt und pflegt. Die Anforderungen werden kontinuierlich weiterentwickelt und es handelt sich daher um eine dynamische Liste.

Die kontinuierliche Pflege und Weiterentwicklung des Product Backlogs wird als Product Backlog Refinement bezeichnet. Es ist ein regelmäßiger Prozess, bei dem Product Owner und Entwicklungsteam das Backlog aktualiseren.

Ein Ziel des Backlog Refinement ist es, die höher priorisierten Anforderungen im Backlog so detailiert vorzubereiten, dass sie dafür geeignet sind in einer der nächsten Sprint Plannings aufgenommen zu werden.

Der englische Begriff Canvas bezeichnet eine Leinwand. Hinter den Canvas verbirgt sich die Idee anhand eines vorgegebenen Rasters auf einer „Leinwand“ in graphisch, visueller Form z.B. ein Geschäftsmodell zu entwickeln. Es handelt sich dabei um eine Art Mischung aus Strukturierung, Visualisierung und Storytelling.

Mit einem Product Canvas werden alle Prozesse der Produktentwicklung übersichtlich auf einer Seite dargestellt. Dadurch ist es jedem, der an der Produktentwicklung Beteiligten,  jederzeit möglich, sich über den aktuellen Zustand des Planungsprozesses zu informieren.

Das Product Canvas ist eine von Roman Pichler entwickelte Methode aus dem Agilen Projektmanagement.

Ein Product Evolution Map ist ist ein „Plan“, wie das Produkt im Laufe der Zeit in Bezug auf Qualität, Angebote, Technologie usw. weiterentwickelt werden lann, um seinen Zweck besser zu erfüllen.

Der Product Owner ist eine der zentralen Rollen im Scrum Prozess neben dem Scrum  Master und dem Entwicklungsteam.

Diese Definition baisert auf  dem Scrum Guide von Jeff Sutherland und Ken Schwaber, den Entwicklern des Scrum Frameworks.

Der Product Owner ist für die Wertmaximierung des Produkts und die Arbeit des Entwicklungsteam verantwortlich. Er ist die einzige Person, die für das Management des Product Backlogs zuständig ist und dafür die Rechenschaft trägt. Der Product Owner ist eine einzelne Person und kein Komitee. Die Rolle des POs kann auch nicht zwischen mehreren Personen aufgeteilt werden, die sich beispielsweise phasenweise abwechseln.

Eine Product Vision beschreibt die übergreifende langfristige Mission eines Produkts. Die Produkt Vision ist ambitioniert und kommuniziert, wohin das Produkt gehen soll und was es langfristig erreichen soll.

Die Vision soll als Leitfaden für alle an der Entwicklung eines Produkts beteiligten Interessengruppen (Produktteam, Business Development, Marketing usw.) dienen, so dass jeder weiss, was mit diesem Produkt erreicht werden soll und was das Ziel des Produkts ist.

Ein gutes Beispiel für eine prägnante Vision ist die Vision von Google  „Den Zugang zu den Informationen der Welt mit einem Klick zu ermöglichen“.

Planning Poker ist eine Methode zur relativen  Aufwandsschätzung.

Meist wird diese Form der Aufwandsschätzung von agilen Software-Entwicklungs-Teams verwendet, um abschätzen zu können, welchen ungefähren Aufwand eine bestimmte User Story in Anspruch nehmen wird.

Der Release Plan ist ein übergeordneter Plan für mehrere Sprints (z.B. drei bis zwölf Iterationen) und wird während der Release-Planung erstellt. Es handelt sich um einen Plan, welche Features wann implementiert werden sollen.

Um einen Release-Plan zu erstellen, sollten die folgenden Dinge verfügbar sein:

• ein priorisiertes und geschätztes Scrum Product Backlog
• ungefähre/ geschätzte Velocity des Scrum Teams

Ein Release Burndown Chart gibt einen Überblick über den Release-Fortschritt, indem es die verbleibende Arbeitslast, oft auch als Restaufwand in Scrum bezeichnet, am Ende eines jeden Sprints gegen die ideale Arbeitslast (oder Aufwand) aufzeichnet. Der Aufwand kann in Stunden, Tagen oder Storypunkten gemessen werden. Es liegt in der Verantwortung des Scrum-Masters, das Release Burndown Chart mit dem tatsächlichen Fortschritt am Ende eines jeden Sprints zu aktualisieren, bevor der nächste Sprint beginnt.

Das Scaled Agile Framework (SAFe) ist ein offenes Framework, um Lean- und agile Methoden unternehmensweit in großen Organisationen umzusetzen. 

Spikes repräsentieren Aufgaben (tasks) wie Forschung, Untersuchung, Exploration und Prototyping. Ihr Zweck besteht darin, das notwendige Wissen zu erlangen, um das Risiko eines technischen Ansatzes zu verringern, eine Anforderung besser zu verstehen oder die Zuverlässigkeit von Schätzungen (Story Estimates) zu verbessern.

Ein Sprint in Scrum ist eine zeitlich definierte Iteration von gleichbleibender Dauer. 

Ein Sprint besteht aus folgenden fünf Aktivitäten:

• Sprint Planning: Planung des Sprints
• Daily Scrum: tägliches Meeting des Development Teams
• Umsetzen der Backlog Items für das Inkrement
• Sprint Review: Präsentation der Ergebnisse des Sprints, das entwickelte Inkrement
• Sprint Retrospektive: Analyse und Bewertung des Vorgehens während des Sprints und Planung von Verbesserungsmaßnahmen

Das Sprint Backlog enthält die Features User Storys, die im jeweiligen Sprint erledigt werden sollen. Ergänzt werden den Features User Storys weitere Details, die das Development Team benötigt, um das Sprintziel (Sprint Goal) zu erreichen.

Das Sprint Burndown Chart visualisiert, wie viel Arbeit zum aktuellen Zeitpunkt im Sprint noch erledigt werden muss.

Das Sprint Planning ist ein Meeting im Scrum-Framework, bei dem das Team die Product Backlog-Items bestimmt, an denen es während des kommenden Sprints arbeiten wird, und seinen ersten Plan zur Fertigstellung dieser Product Backlog-Items bespricht. Am Sprimt Planning nimmt das Scrum Team teil, also der Scrum Master, der Product Owner und das Development Team.

Im Sprint Review amd Ende des Sprints präsentatiert das Entwicklungsteam dem Product Owner und allen interessierten Stakeholders die Ergebnisse des Sprints also das entwickelte Inkrement. Des weiteren sammelt es Feedback (Meinungen, Verbesserungsvorschläge, Lob und Kritik) ein.

Die Sprint Retrospektive findet nach der Sprint Review und vor der nächsten Sprint Planung statt. In der Retrospektive diskutiert das Team rückblickend den soeben zu Ende gegangenen Sprint und überlegt sich, was weshalb gut oder schlecht gelaufen ist und was man tun könnte, um den nächsten Sprint produktiver und/oder angenehmer zu machen. Es also ist im Grunde genommen ein Verbesserungsmeeting“.Die Prinzipien „INSPECT/ inspizieren“ und „ADAPT/ anpassen“ spielen eine Schlüsselrolle in der Retrospektive. An der Retrospektive nehmen der Product Owner, der Scrum Masterund alle Mitglieder des Entwicklungsteams teil.

Der Scrum Master ist eine von 3 Rollen die es in Scrum gibt. Er trägt die Verantwortung für den Scrum-Prozess und dessen korrekte Implementierung. Eine seiner Hauptaufgaben ist es dafür zu sorgen. daß das Team möglichst effektiv und ungestört arbeiten kann. Des weiteren sorgt er dafür, dass allen Beteiligte die Scrum – Theorie, Praktiken, Regeln und Werte verstehen lernen. Er ist also der Coach, der Mentor und Berater des Teams.

Als Stakeholder (auch Anspruchsgruppen) werden alle Personen und Gruppen  bezeichnet, die von den Aktivitäten in diesem Fall von eimen Produkt eines Unternehmens direkt oder indirekt betroffen sind 

Eine User Story ist ein Werkzeug um Funktionalitäten an das System aus der Sicht des Anwenders zu beschreiben. Die User Story soll die Brücke zwischen Entwicklung und Kunden bilden. Das Ziel einer User Story ist es immer, einen Mehrwert für den Kunden zu schaffen.

User Story Mapping ist Technik die  agiles Team bei der Erstellung seines Product Backlogs unterstützt. Die Story Map erfasst die „Customer Journey“ eines Kunden mit dem Produkt, so dass stets der Kundenfokus erhalten bleibt. Story Mapping startet mit den Aufgaben (User Tasks)  die aus Benutzersicht zu erledigen sind.

Die Erstellung der Story Map als Team stellt sicher, dass die Teammitglieder vom Beginn der Entwicklung bis zur laufenden Auslieferung neuer Releases auf der gleichen Seite sind.