Zu den Sprint-Grundlagen gehören die drei Teile eines Sprints:

• Sprint-Planung (Sprint Planning)
• Sprint-Entwicklung (Sprint Development)
• Sprint Überprüfung & Nachbereitung (Sprint Review & Sprint Retrospektive)

Ein Sprint ist eine Timebox oder ein Zeitraum, der die Zeit für die Fertigstellung der Arbeit festlegt. Er kann von zwei Wochen bis zu einem Monat dauern (unter fortgeschrittenen Praktikern werden kürzere Zeiträume jedoch immer beliebter).

Das Sprint Planning beginnt damit, dass der Product Owner die zu erledigende Arbeit aus dem Product Backlog auswählt. Das Product Backlog ist die Liste der Arbeiten, die nach ihrer Wichtigkeit geordnet sind, entweder für die laufende Verbesserung oder für die Fertigstellung eines neuen Produkts. Das Team prüft die Stories und wählt dann aus, welche Arbeiten es im Laufe des Sprints erledigen kann. Dieser Prozess wird durch den Scrum Master erleichtert, der sich nicht an der Arbeit beteiligt, sondern sich darauf konzentriert, das Team mit guten Prozessen und Best Practices zu befähigen, schnell zu arbeiten. Der endgültige Satz an Stories sollte ein zusammenhängendes „Produktinkrement“ bilden, das das Team am Ende des Sprints vorweisen kann.

• Input: Product Backlog der vom Product Owner priorisierten Stories
• Prozess: Überprüfung und Auswahl der Stories für den Sprint
• Ergebnis: Sprint Backlog der Stories, zu deren Fertigstellung sich das Team bis zum Ende des Sprints verpflichtet

Die Sprint-Entwicklung beginnt mit dem täglichen Standup (Daily Scrum). Daily Scrums sind Selbstberichte des Teams über die Arbeit, die sie an diesem Tag erledigen werden. Dies geschieht in der Regel an einer Kanban-Tafel oder einem anderen großen visuellen Informationsmedium. Das Team öffnet jeweils nur ein paar Stories und arbeitet Story für Story, um die Arbeit zu analysieren, zu erstellen und zu testen. Das Ergebnis am Ende des Sprints ist ein auslieferungsfähiges Inkrement, das dem Product Owner präsentiert werden kann. Die Besprechungen werden vom Scrum Master moderiert, und der Product Owner entscheidet, ob eine Story vollständig ist und den Anforderungen der Stakeholder entspricht.

• Input: Sprint Backlog der Stories, zu deren Fertigstellung sich das Team bis zum Ende des Sprints verpflichtet
• Prozess: Tägliche Berichterstattung und Ausführung für jeweils einige wenige Stories: Design, Umsetzung, Testen und Abschließen
• Ergebnis: Ein auslieferungsfähiges Produktinkrement, das vorgeführt werden kann

Sprint Retrospektive und Sprint Review sind Zeremonien, die dazu dienen, Feedback zu erhalten und kontinuierliche Verbesserungen im Team voranzutreiben. Der erste Schritt ist das Sprint Review, bei dem der Product Owner den Stakeholdern das Produktinkrement aus dem Sprint vorstellt. Dies ist eine Gelegenheit, die Zustimmung und das Feedback der Stakeholder einzuholen, damit das Team weiß, dass es mit der Produktausrichtung auf Kurs ist. Der Product Owner kann auch Feedback dazu einholen, was im nächsten Sprint umgesetzt werden soll. Die Sprint Retrospektive oder „Retro“ ist die zweite Zeremonie, mit der ein Sprint abgeschlossen wird. Bei der Retro geht das Team in einen Raum, um zu bewerten, wie der Sprint gelaufen ist, und um Verbesserungsmöglichkeiten für den nächsten Sprint zu ermitteln. Die besten Sprint Retros werden in Form von Spielen durchgeführt, um den Input des gesamten Teams zu fördern und Verbesserungen schnell zu identifizieren.

• Input: Lieferbares Produktinkrement, das vorgeführt werden kann
• Prozess: Demonstrationen und Spiele, um das Feedback zum Produkt und zu den Teamprozessen zu erleichtern
• Ergebnis: Feedback über die Richtung des Produkts und Maßnahmen zur Verbesserung des nächsten Sprints

Das Eiserne Dreieck (Iron Triangle) hilft zu erklären, wie die verschiedenen Projektmanagementmethoden aufeinander abgestimmt sind. Das Eiserne Dreieck umfasst:

• Umfang (Scope): die zu erledigende technische Arbeit
• Zeitplan: die Gesamtzeit für die Durchführung der Arbeit
• Budget: die Gesamtkosten des Projekts in Euro

Alle Aspekte des Eisernen Dreiecks sind Einschränkungen und Kosten für die Organisation. Ein längerer Zeitplan bedeutet eine Verzögerung des Projektnutzens und Kapitalbindung. Ein höheres Budget bedeutet mehr Geld oder investiertes Kapital. Ein größerer Umfang bedeutet ein größeres Produkt, das von der Organisation unterstützt oder gewartet werden muss. Dies sind alles Formen von Kosten und schränken ein, wie die Arbeit erledigt werden kann, wenn sie festgelegt sind.

Es gibt drei Arten des Projektmanagements: agil, traditionell und lean.

• Agil: variabler Umfang bei festem Budget und Zeitplan
• Traditionell: variiert das Budget gegen einen festen Umfang und Zeitplan
• Lean: variiert den Zeitplan (oder die Lösungszeit) gegenüber einem festen Umfang und Budget

Die Ziele und Anforderungen der einzelnen Methoden sind entscheidend für das Verständnis des Stellenwerts der einzelnen Methoden im Arsenal des Projektmanagers:

• Agil: Ziel ist Schnelligkeit (frühe Versionen schnell liefern), und erfordert Vertrauen, um den Umfang für eine schnelle Wertlieferung zu minimieren
• Traditionell: Ziel ist Effizienz (bester Preis), und erfordert Effizienz, um die niedrigsten Kosten innerhalb des Zeit- und Budgetrahmens zu liefern
• Lean: Ziel ist Innovation (Problemlösung) und erfordert Fachwissen zur Minimierung der Lieferzeiten

Falsche Vergleiche zwischen verschiedenen Projekttypen gibt es zuhauf. Oft hört man als Einwand gegen die Anwendung von Agile, dass kritische Elemente wie Design, Tests oder Dokumentation fehlen. Das ist alles falsch. In der Tat muss jedes Projekt die folgenden Elemente aufweisen, um erfolgreich zu sein:

• Charta
• Plan
• Dokumentation
• Entwurf
• Prüfung

Denken Sie daran, dass wir den Umfang variieren, um genau das zu erreichen, was der Kunde braucht, damit wir weder Zeit noch Geld verschwenden. Das ist die Stärke der Variation des Umfangs. Sie ist schnell und begrenzt die Verschwendung, indem sie die Arbeit auf ein Minimum Viable Product (MVP) reduziert, das die Projektziele (in der Charta) erfüllt. Um dies zu erreichen, braucht jedes agile Projekt:

• Gemeinsame Vision Robust gegenüber Veränderungen (kann den Umfang variieren und das Ziel nicht aus den Augen verlieren)
• Vollständige Teams (Kunde + funktionsübergreifendes Team)
• Inkrementelle Lieferung (Lernen durch Tun und Verwendung kleiner „Sprints“)
• Kontinuierliche Integration und Tests (Teams testen die Inkremente, um sicherzustellen, dass sie funktionieren)

Scrum, SAFe oder Disciplined Agile sind allesamt Rahmenwerke, die bei der Definition von Rollen und Prozessen zur Skalierung und Umsetzung der agilen Methodik helfen. Sie bieten eine gemeinsame Sprache. Die Methode bleibt jedoch dieselbe.