Produktentwicklung am Beispiel des Scrum Flows in 25 Schritten erklärt

„Wir machen jetzt Scrum!“ Diesen Satz hört man häufig, wenn Unternehmen ihre Produktentwicklungsprozesse agil gestalten wollen. Doch was steckt hinter diesem Ansatz und wie funktioniert der Scrum Flow überhaupt? Eine Frage, mit der sich viele Projektbeteiligte, welche bislang nur wenig bis gar keine Erfahrung mit Scrum haben, oft schwertun.Macht sich auch in dir gerade das Gefühl von Überforderung breit, weil du nicht weißt, wo du anfangen sollst? Den Scrum Flow zu verstehen ist dabei eine Sache, ihn zu erklären eine ganz andere. Die nachfolgenden 25 Schritte sollen dir dabei helfen, eine gedankliche Struktur zu schaffen, an der du dich im Arbeitsalltag orientieren kannst. Den Scrum Flow gekonnt erklären? Für dich ab sofort kein Problem!

Der Scrum Flow

1. Am Anfang steht der Product Owner (PO) mit einer Idee. Sein Ziel ist es immer, ein Produkt auf den Markt zu bringen, welches sowohl sinnstiftend für den Nutzer als auch gewinnbringend für die Organisation ist.2. Eine Produktidee alleine reicht aber nicht aus. Man braucht ein genaues Bild davon, was man erreichen möchte – die „Vision“.3. Dieses Bild, die „Vision“, hat einen Rahmen und dieser Rahmen spiegelt den Kontext wider.4. Der Kontext ist insofern wichtig, da sich die Produktvision immer in einem Rahmen bewegt, welcher durch die Organisation vorgegeben wird (z. B.: Passt die Produktvision zur Unternehmensvision/dem Geschäftsmodell? Werden regulatorische Anforderungen eingehalten?)5. Der PO ist zudem für den Return on Investment (ROI) verantwortlich. Er steht in engem Kontakt mit dem Auftraggeber und berücksichtigt dessen Interessen, da dieser das Projekt finanziert.6. Zurück zur Vision! Diese sollte möglichst mitreißend und motivierend sein. Warum? Weil der Product Owner ein Team braucht, das mit ihm gemeinsam an der Umsetzung dieser Produktvision arbeiten möchte („Prinzip der Freiwilligkeit“).7. Und hier kommt das Entwicklungsteam ins Spiel. Das crossfunktional aufgestellte Expertenteam ist Teil des Scrum-Teams, welches durch sein Können für die praktische Umsetzung und die Qualität des Produkts verantwortlich ist (z. B. Fachleute, Developer und Tester).8. Das Entwicklungsteam bildet dabei den Link zum User. Es geht darum, in fest definierten Zyklen Feedback zum Produkt einzuholen und dieses in die weitere Entwicklung einfließen zu lassen.9. Damit die intensive Zusammenarbeit zwischen dem PO und dem Entwicklungsteam gut funktioniert, wird das Scrum-Team durch den ScrumMaster (SM) vervollständigt. Seine Hauptverantwortung liegt darin, dass das Scrum-Team insgesamt produktiv arbeiten kann und die Scrum-Regeln eingehalten werden.10. Der SM arbeitet dabei kontinuierlich mit dem Management zusammen, da das Management für die Entwicklung und die Verbesserung von Strukturen und Richtlinien in der Organisation verantwortlich ist.11. Zurück zur Vision! Nun muss sich der PO Gedanken darüber machen, welche Nutzerbedürfnisse durch das Produkt adressiert werden sollen. Kurzum: Welche Funktionalitäten müssen wir liefern, die auf unsere Vision einzahlen und gleichzeitig einen Nutzen für unsere Nutzergruppe schaffen?12. Dazu schreibt der PO, entweder alleine oder gemeinsam mit dem Entwicklungsteam, erste User Storys (US). Diese User Storys werden in einem Product Backlog erfasst. Da der PO für den ROI verantwortlich ist, priorisiert er diese nach dem jeweiligen Nutzenwert.13. In einem nächsten Schritt führt das Entwicklungsteam eine erste initiale Schätzung des priorisierten Backlogs durch. Das Entwicklungsteam beurteilt dabei, wie viel Funktionalität/Mehrwert eine US bringt (Es wird nicht der Aufwand geschätzt, da dieser vom Erfahrungsschatz und Können der jeweiligen Person abhängig ist). Als Ergebnis der Schätzung liegen nun sämtliche, mit Story Points bewertete US vor.14. Der PO erstellt nun einen initialen Release Plan, indem er die US entlang einer Zeitachse in die Sprints verteilt, in denen diese voraussichtlich bearbeitet werden. Der Release Plan ermöglicht eine Vorschau bzw. Prognose, in welcher Zeit welche Funktionalität geliefert werden kann. Hierin ist vermerkt, wann voraussichtlich genug Funktionalität entwickelt wurde, um einen Release durchzuführen.15. Wichtig ist, dass genug US vorliegen, die innerhalb eines Sprints erledigt werden können, damit der erste Sprint beginnen kann. Das Ziel an dieser Stelle ist nicht eine monatelange Planung, sondern so schnell wie möglich mit der Entwicklung loszulegen, um rasch Feedback zum Produkt generieren zu können.16. Ist der erste initiale Release Plan erstellt, können wir nun von der strategischen Ebene (strategische Planungsebene) auf die taktische Ebene wechseln, auf der die tatsächliche Produktentwicklung in Form von Sprints vonstattengeht.17. Das erste Meeting auf der taktischen Ebene ist das Sprint Planning 1 (SP1). In diesem ersten Sprint Planning wird die Frage geklärt, was im bevorstehenden Sprint erledigt werden soll. Der PO erläutert sein Ziel für den Sprint und erklärt konkret, was er sich unter den einzelnen US vorstellt. Das Entwicklungsteam stellt Fragen und entwickelt ein Gefühl dafür, was es in diesem Sprint bearbeiten kann.18. Am Ende des SP1 steht das Commitment des Entwicklungsteams. Dieses Commitment ist ein „Akt der Freiwilligkeit“, weshalb das Entwicklungsteam bei seiner Entscheidung nicht durch den PO beeinflusst werden darf. Es ist Aufgabe des ScrumMasters, darauf zu achten, dass diese Regel nicht verletzt wird. Das Ergebnis ist das Selected Product Backlog.19. Das nächste Meeting ist das Sprint Planning 2. Hier bespricht das Entwicklungsteam, wie die einzelnen US, welche für den gegenwärtigen Sprint committet wurden, umgesetzt werden sollen. Es entstehen erste konkrete Tasks, welche auf dem Taskboard festgehalten werden.20. Im Laufe des Sprints gibt es ein tägliches Synchronisationsmeeting, das Daily Stand-up Meeting. Hier organisiert sich das Entwicklungsteam selbst und jedes Mitglied erläutert kurz und knapp, welchen Task es gestern erledigt hat, welchen Task es am aktuellen Tag erledigen möchte und welche Impediments (Hindernisse) es gibt. Ziel ist es, den Austausch im Team zu fördern, Entwicklungsfortschritte transparent zu machen und Impediments direkt zu identifizieren.21. Der SM hört beim Daily Stand-up Meeting aufmerksam zu und nimmt die Impediments in sein Impediment Backlog auf. Seine Aufgabe ist es, dass alle Impediments, welche außerhalb der Verantwortlichkeiten des Entwicklungsteams liegen, gelöst werden. Hierzu steht er in engem Kontakt mit dem Management, da dieses die Entscheidungsgewalt über organisationsinterne Strukturen und Richtlinien hat. Indem der SM die Impediments gemeinsam mit dem Management löst, kann der Wandel zur agilen Organisation stetig vorangetrieben werden.22. Am Ende des Sprints wird das vom PO abgenommene Produktinkrement vom Entwicklungsteam im Review vorgestellt. Das Review ist ein öffentliches Meeting, an dem jeder teilnehmen kann. Im Kern geht es darum, dem Kunden sowie dem Nutzer das fertige Produktinkrement vorzustellen und Feedback zu bekommen. Dieses Feedback wird vom PO im Product Backlog als neue US aufgenommen.23. Direkt darauf folgt die nicht öffentliche Retrospektive. Dieses Meeting ist das Herzstück des Scrum-Prozesses, denn das Scrum-Team analysiert hierbei den eigenen Arbeitsprozess. Es geht darum, herauszufinden, wie das gemeinsame Arbeiten verbessert werden kann, um im nächsten Sprint noch produktiver zu werden. Die Impediments werden nach Wichtigkeit und Nutzen priorisiert und es wird geklärt, ob diese im Verantwortungsbereich des Teams oder der Organisation liegen. Letztlich werden (konkrete) Verbesserungsmaßnahmen abgeleitet.24. Während des Sprints, der optimalerweise eine Woche dauert, findet das Backlog Refinement statt. Hierbei geht es primär darum, das Product Backlog mithilfe der gewonnenen Erkenntnisse aus dem Review (Kundenfeedback) zu aktualisieren. Die bereits vorhandenen User Storys werden überprüft und gegebenenfalls geschnitten (eine US wird in kleinere US unterteilt). Völlig neue User Storys werden vom PO vorgestellt und durch das Entwicklungsteam wiederum initial geschätzt. Bereits vorhandene User Storys werden in der Schätzung angepasst.25. Dabei folgt der Scrum Flow dem Zyklus Plan-Do-Check-Act (Deming Cycle), welcher eine kontinuierliche Optimierung von Produkt und Prozess ermöglicht.

Auf den Punkt gebracht.

Die 25 Schritte des Scrum Flows machen deutlich, worum es bei der agilen Produktentwicklung geht. Es geht um das permanente Liefern von fertigen Produktinkrementen und darum, möglichst schnell Feedback zu generieren, um Produkte stets auf die Bedürfnisse des Kunden auszurichten. Der PO hat dabei eine besonders wichtige Position inne, denn er ist für die Value Proposition des Produktes verantwortlich. Er muss den Markt kennen, ihn verstehen und er muss wissen, was sich der Endnutzer des Produktes wirklich wünscht, ohne dabei die Wirtschaftlichkeit des Produktes aus den Augen zu verlieren.