Eine Übersicht gängiger Metriken, Werkzeuge und Praktiken zur Bewertung und Abschätzung von Aufwänden in der agilen Produktentwicklung
Dieses Whitepaper stellt unterschiedliche Vorgehensweisen, Werkzeuge und Praktiken vor, um Dauer und Kosten von Entwicklungsvorhaben in komplexen Umfeldern abzuschätzen, und beleuchtet deren Vor- und Nachteile.
Prognosen helfen dabei, Entscheidungen zu treffen und Pläne zu modifizieren. Zugleich tun sich viele Unternehmen und Entwicklungsteam schwer damit, belastbare Schätzungen vorzunehmen und über Zeit anzupassen, wenn neue Erkenntnisse über Chancen und Risiken gewonnen werden.
Der erste Teil beleuchtet, warum Zeit bei komplexen Problemstellungen eine schwierige Schätzgröße ist, und welche Praktiken helfen können, unerwünschte Effekte abzumildern. Diese Werkzeuge werden für zeitbasierte Schätzungen vorgestellt: Ideale Tage und Drei- Punkt-Schätzungen.
Der zweite Teil widmet sich vergleichender Größenschätzungen, die in vielen agilen Setups eingesetzt werden. Hier werden diese Werkzeuge vorgestellt: Story Points, Velocity, Planning Poker, Affinity Estimation, Magic Estimation und Burndown Charts.
Der dritte Teil zeigt auf, wie empirische Daten genutzt werden können, um mittels stochastischer Verfahren die Eintrittswahrscheinlichkeit von Umsetzungs- und Lieferzeiten abgeleitet werden können. Die in diesem Abschnitt vorgestellten Werkzeuge sind: Lead Time, Cycle Time, Scatterplots und Monte Carlo Simulationen.
Erprobte Techniken für den Einsatz in der agilen Produktentwicklung mit Scrum
Der Scrum Guide definiert Scrum als leichtgewichtiges Rahmenwerk. Scrum ist bewusst unvollständig und schreibt nur sehr wenige Praktiken und Regeln vor. Damit folgt es dem Manifest für agile Softwareentwicklung, dessen Wertekanon Individuen und deren Interaktionen über festgeschriebene Prozesse und Werkzeuge stellt. Scrum Teams werden aktiv dazu ermuntert, immer wieder neue Werkzeuge und Praktiken auszuprobieren und in ihren Fundus an Scrum Werkzeugen zu integrieren. Durch die Auswahl und Evaluierung der für den jeweiligen Kontext geeigneten Tools, wird das Scrum Team in seiner Autonomie über den eigenen Arbeitsprozess gestärkt. Zugleich kann diese Freiheit Teams zunächst überfordern, die Scrum zum ersten Mal implementieren.
5 agile Werkzeuge, die Sie voran bringen
Die ersten Schritte in der agilen Produktentwicklung mit Scrum sind oft nicht leicht. Auf dieser Seite haben wir eine Auswahl an häufig verwendeten Werkzeugen und Praktiken zusammengestellt, die sich in vielen Kontexten als hilfreich erwiesen haben.
Personas
Ein Leitsatz agiler Produktentwicklung ist die Fokussierung auf die Kund:innen und ihre Bedürfnisse. Personas dienen dazu, diese im Entwicklungsprozess besser präsent und greifbarer zu machen. Dazu werden für die verschiedenen Zielgruppen, für die das Produkt einen Nutzen bieten möchte, archtypische Vertreter:innen erstellt. Personas verleihen der Kund:in einen Namen, Alter, Aussehen, Interessen und Hobbies, sowie eine Lebensgeschichte. Dadurch wird es einfacher, Anforderungen für diese Zielgruppe zu formulieren und Annahmen über mögliche Lösungen zu überprüfen.
3Cs für kreative Lösungsprozesse
Scrum würdigt die Expertise der Scrum-Team-Mitglieder. Das Scrum-Team sollte daher nicht als Umsetzungsfabrik für bereits vollends ausspezifizierte Lösungen misbraucht werden. Binden Sie möglichst viele Perspektiven bei der Kreation von Lösungsoptionen ein.
Ron Jeffries, Co-Author des Manifest für agile Softwareentwicklung, empfiehlt hier die 3C-Praktik. Die 3 Cs stehen für Card, Conversation und Confirmation. Diese Praktik können Sie sofort in Ihrem nächsten Refinement einsetzen:
Card: Schreiben Sie mit einem dicken Stift auf die Vorderseite eine Moderationskarte (A5), welches Problem Sie für eine bestimmte Persona lösen möchten. Bzw. welchen Nutzen Sie realisieren wollen. Halten Sie sich mit Details, die Sie sicher schon ausgearbeitet haben, bewusst zurück.
Conversation: Zeigen Sie die Karte Ihrem Team und relevanten Stakeholder:innen. Diskutieren Sie zusammen, welche Lösungsoptionen Ihnen dazu einfallen. Legen Sie sich nicht sofort auf die erste Option fest – fragen Sie das Team gezielt nach Alternativen. Beleuchten Sie gemeinsam Vor- und Nachteile der unterschiedlichen Vorschläge.
Confirmation: Einigen Sie sich auf eine Lösungsoption. Halten Sie auf der Rückseite der Karte die fachlichen Akzeptanzkriterien fest, die die Lösung bieten muss.
User Stories
Beschreiben die Einträge in Ihrem Product Backlog eher konkrete Umsetzungsideen und Lösungsstrategien als den erhofften Mehrwert für Nutzer:innen? Dann können User Stories dabei helfen Ihre Kund:innen besser in Ihrem Backlog zu repräsentieren. Eine User Story ist eine besondere Form, der Anforderungsdokumentation, die die Nutzer:in und den mit der Lösung verbundenen erhofften Mehrwert klar benennt. Dies gibt eine Orientierung während der Refinements und Umsetzung der Anforderung.
Hier erfahren Sie mehr über den Aufbau und Einsatz von User Stories.
User Story Maps
Eine User Story beschreibt eine einzelne Anforderung aus Sicht der Kund:in. Mit Hilfe von User Story Maps modellieren Sie das Erlebnis der Nutzer:innen für das Produkt oder relevante Teile des Produkts als Einheit. Dadurch wird es leichter, den roten Fadenüber die atomaren Bestandteile Ihres Produktes zu spannen und Usability und User Experience des Produkts zu steigern. Durch den Einsatz von User Story Mapping wird aus der Anforderungsliste Ihres Product Backlogs eine mehrdimensionale Karte. Dies hilft auch dabei, Minimal Viable Products (MVP) zu identifizieren und einzelne Anforderungen in Relation zu anderen zu priorisieren.
Hier erfahren Sie mehr über den Aufbau und Einsatz von User Story Maps.
Story Points & Velocity basierte Planung
Zeit ist eine schwierige Schätzgröße, da bei Schätzungen viele Variablen berücksichtigt werden müssen. Dazu zählt die Verfügbarkeit von Experten ebenso wie neue Chancen und Risiken, die sich während der Entwicklung ergeben. Viele agile Teams schätzen daher statt der Umsetzungsdauer den Umfang der Anforderungen. Als gängiste Schätzgröße gelten hier wohl Story Points. Die erwartete Entwicklungsdauer einer Anforderung wird dann über die bisherige Umsetzungsgeschwindigkeit (Velocity) abgeleitet.
Diese und weitere Verfahren für Prognosen in komplexen Umfeldern, stellen wir ausführlich in einem Whitepaper vor.
Coaching für Product Owner, Scrum Master und Führungskräfte
Sie haben Verantwortung als Product Owner oder Scrum Master übernommen, oder begleiten als Führungskraft ein Team, das Scrum neu eingeführt hat. Sie sehen große Chancen im Einsatz von Scrum, sind sich aber unsicher, ob Sie das volle Potential von Scrum für sich nutzbar machen können. Vielleicht haben Sie auch schon einiges an Erfahrung sammeln können und fragen sich, wie Sie Ihre Rolle noch besser ausfüllen können.
Rollencoaching setzt genau dort an, wo fixe Trainingsangebote keinen nennenswerten Mehrwert mehr bieten.
Wir beleuchten mit Ihnen Ihre ganz besondere Situation und reflektieren mit Ihnen Ihre Stärken und Potentiale. Gerne helfen wir Ihnen auch, Werkzeuge und Praktiken zu finden, die für Ihren Kontext besonders geeignet erscheinen, und bieten dazu gezielte Micro-Training-Sessions an, die Ihnen dabei helfen, deren Eignung zu prüfen und die Umsetzung in der Praxis zu realisieren.
Der kaiserliche Garten Higashi-gyoen ist ein traumhafter Ort in in Tokio. Damit diese besondere Anlage in ihrer Einzigkeit erhalten bleibt, setzt man ein sehr einfaches, wirkungsvolles Kanban-System zur Begrenzung der Besucher ein: Es werden an den Eingängen Plastikkarten je Teilnehmer ausgegeben. Wenn alle Karten verteilt sind – darf kein Besucher mehr herein. Somit wird der Andrang sanft begrenzt und der Garten geschont.
Und Sie … kennen Sie vielleicht einfache Kanban-Systeme in Ihrer Umgebung ???
Was bedeutet Kanban?
Kanban ist derzeit eine der gefragtesten Projektmanagement-Methoden – und bereits hier gibt es ein großes Missverständnis! Denn Kanban ist nicht einfach nur ein Projektmanagement-System oder gar nur ein schickes Kanban-Board, auf dem man seine Aufgaben mit Post-Its festhält. Kanban ist “evolutionäres Change-Management” – so beschreibt es David J. Anderson, der Kanban für die Software-Entwicklung modifiziert hat.
Die Geschichte von Kanban
Dabei ist Kanban wesentlich älter und bereits seit Jahrzehnten im Einsatz. Die Idee stammt aus Japan, genau gesagt vom Automobilkonzern Toyota: Um die Autoproduktion effizienter zu gestalten, führte man das sogenannte “Pull-Prinzip” ein. Denn Kanban heißt eigentlich übersetzt “Signalkarte”, diese “wandert” mit den entsprechenden Informationen durch das System und gibt die Impulse, wann das nächste Teil gefertigt werden soll.
Pull-Systeme
Dabei war es wichtig, dass erst ein neues Teil in den Workflow gerät, wenn das vorherige Teil fertiggestellt wurde, um die entsprechende Station nicht zu überlasten. Hat man also sein Werkstück vollendet, “zieht” man sich aus dem Ausgang der vorherigen Station ein neues, daher “Pull”-Prinzip. Statt so in den nachfolgenden Produktionsschritten immer weitere Teile in den Workflow zu drücken, bestimmte das “langsamstes” Glied in der Kette, wann es wieder weitergeht. Produziert wurde erst wieder, wenn der eigene Teile-Ausgang leer war.
Kanban in der Software-Entwicklung
Als David J. Anderson feststellte, dass es in der Software-Entwicklung immer wieder zu überlasteten Teams, unzufriedenen Kunden und vor allem zahlreichen Engpässen kam, wandte er Kanban-Prinzipien auf das Development an – mit einem durchschlagenden Erfolg. Teams wurden entlastet, die Entwicklung konnte mit deutlich weniger Fehlern in der gleichen Zeit abgeschlossen werden, was zu weitaus zufriedeneren Kunden führte. Das merkte natürlich auch das Management – und weitete Kanban auf mehr Entwickler-Teams aus
Die Kanban-Prinzipien
Ein wichtiger Bestandteil von Kanban sind die Kanban-Prinzipien. Diese helfen, Kanban besser zu verstehen und zu implementieren. Die Prinzipien sind:
1. Beginne mit dem, was du jetzt tust und dem, was du hast
Kanban möchte nicht alles komplett über den Haufen werfen oder wie Scrum direkt neue Prozesse einführen. Denn nicht immer ist das, was bereits gelebt wird, an sich “schlecht”. Daher ist es wichtig sich zunächst anzuschauen, wie die Prozesse funktionieren und wo es klemmt. Erst wenn man versteht, wie etwas funktioniert, kann man es verbessern.
2. Vereinbare evolutionäre, kleine Schritte
Kanban möchte nicht ein komplett neues System über Nacht einführen. Es geht darum, einzelne kleine Schritte zu mache, um so direkt Verbesserungen spürbar zu machen. Das Erhöht die Akzeptanz auf allen Ebenen: Die Mitarbeiter werden nicht mit einer neuen Methode überfordert, das Management muss nicht in teure Schulungen, neue Tools und Systeme investieren.
3. Fördere Führung auf allen Ebenen
Die Eigenverantwortung jedes Einzelnen ist bei Kanban gefragt. Hierarchie abbauen und Kommunikation stärken – mit Kanban werden die Entscheidungen jedes Mitarbeiters gestärkt, das Management kann sich so viel besser auf seinen wesentlichen Aufgaben konzentrieren.
4. Verstehe und fokussiere deine Kunden
Erst wenn ich die Prozesse meines Kunden verstehe, kann ich mich seinen Bedürfnissen anpassen. Egal ob intern oder extern: Der Kunde ist schließlich derjenige, der am Ende die Zeche zahlt. Ist ein Prozesse für den Kunden nicht nachvollziehbar oder bietet keinen Mehrwert, dann sollte er auch in Frage gestellt werde.
5. Manage die Aufgaben, nicht Menschen
Das Kanban-Team sollte sich weites gehend autark um die anstehenden Tasks kümmern. Daher sollte man nicht den Mitarbeitern sagen, was und wann sie eine Aufgabe zu erledigen haben – das wird vom Team selbst entschieden. Wichtiger ist hingegen, den Flow zu beachten und dafür zu sorgen, dass der Backlog entsprechend der umzusetzenden Aufgaben gefüllt ist.
6. Steigere deinen und den Wert deiner Kunden
Im Fokus sollte am Ende immer der Kunde stehen. Kanban sorgt dafür, dass Prozess effizient laufen, immer mit dem Blick darauf, dass am Ende der Kunde zufrieden ist und ein Produkt erhält, das seinen Ansprüchen entspricht. Das steigert letztendlich natürlich auch das Ansehen des entsprechenden Teams.
Bereit für Kanban?
Dann buchen Sie jetzt einen unserer Kanban-Trainings-Kurse und starten Sie evolutionäres Change Management in Ihrem Unternehmen.
Quellen & Ressourcen:
[ Buch ] David Anderson: “Kanban: Evolutionäres Change Management für IT-Organisationen”
Burn-down Chart Ein Burn-down Chart bildet die Menge unerledigter Arbeiten eines Sprints oder Releases ab. Die Zeit wird dazu auf der horizontalen Achse und die verbleibende Arbeit auf der vertikalen Achse dargestellt. Der Arbeitsfortschritt wird regelmäßig im Chart als (typischerweise fallende) Linie eingetragen. Der Arbeitsaufwand kann auf unterschiedliche Arten quantifiziert werden, wie zum Beispiel durch Anzahl der Aufgaben, geschätzte Entwickler-Stunden, aber auch Story Points oder Function Points. Das Burn-down Chart dient dem Scrum Team als Werkzeug zur Inspektion des Arbeitsfortschritts und kann auch gut zur Information der Stakeholder eingesetzt werden. Siehe auch Burn-up Chart.
Burn-up Chart Ein Burn-up Chart bildet die Menge erledigter Arbeiten eines Sprints oder Releases ab. Die Zeit wird dazu auf der horizontalen Achse und die kumulierte Arbeitsleistung auf der vertikalen Achse dargestellt. Der Arbeitsfortschritt wird regelmäßig im Chart als aufsteigende Linie eingetragen. Der Arbeitsaufwand kann auf unterschiedliche Arten quantifiziert werden, wie zum Beispiel durch Anzahl der Aufgaben, geschätzte Entwickler-Stunden, aber auch Story Points oder Function Points. Das Burn-up Chart dient dem Scrum Team als Werkzeug zur Inspektion des Arbeitsfortschritts und kann auch gut zur Information der Stakeholder eingesetzt werden. Siehe auch Burn-down Chart.
Daily Scrum Tägliches Scrum-Ereignis mit 15-minütiger Timebox für das Entwicklungsteam, um die Entwicklungstätigkeiten des Tages zu planen. Bei Planänderungen wird das Sprint Backlog aktualisiert. Siehe auch Scrum-Ereignisse.
Definition of Done Gemeinsames Verständnis über die Mindestanforderungen an ein Produktinkrement um veröffentlicht werden zu können. Die Definition of Done wird unter Berücksichtigung von Organisationsvorgaben vom Entwicklungsteam erstellt und gepflegt.
Development Team Englischer Begriff für Entwicklungsteam.
DoD Abkürzung für Definition of Done.
Emergenz Emergenz bezeichnet die Möglichkeit der Herausbildung von neuen Eigenschaften oder Strukturen eines Systems infolge des Zusammenspiels seiner Elemente. Scrum-Artefakte sind emergent; d.h. dass sie sich über Zeit verändern auf Grund der Erkenntnisse und Einsichten, die die beteiligten Akteure aus dem Umgang mit diesen ziehen. Siehe auch https://de.wikipedia.org/wiki/Emergenz
Empirie Bei der empirischen Prozesssteuerung wird nur die Vergangenheit als sicheres Faktum akzeptiert. Entscheidungen basieren auf Beobachtungen, Erfahrungen und Experimenten. Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz, Überprüfung und Anpassung.
Entwicklungsteam Eine Rolle innerhalb des Scrum Teams. Das Entwicklungsteam ist verantwortlich für die Planung und Durchführung aller notwendigen Entwicklungstätigkeiten zur Erstellung eines releasefähigen Produktinkrements (mindestens) am Ende eines jeden Sprints. Siehe auch Scrum-Rollen.
Forecast Englischer Begriff für Prognose.
Inkrement Siehe Produkt Inkrement.
Iteration Eine Iteration wird in Scrum Sprint genannt.
Product Backlog Das aktuelle Verständnis über die notwendigen Arbeiten zur Erstellung, Betrieb, Pflege und Weiterentwicklung eines Produkts. Das Product Backlog wird vom Product Owner verwaltet.
Product Backlog Grooming Nicht mehr verwendeter Begriff; ersetzt durch Product Backlog Refinement.
Product Backlog Refinement Regelmäßig durchgeführte Aktivität, bei der Product Owner und Entwicklungsteam Details zu Product Backlog Einträgen hinzufügen. Dieser Vorgang wurde in früheren Versionen des Scrum Guides auch als Product Backlog Grooming bezeichnet.
Product Owner Die Scrum-Rolle, die für die Maximierung des Werts eines Produkts verantwortlich ist. Product Owner formulieren die geschäftlichen und fachlichen Erwartungen an das Produkt und vertreten diese gegenüber dem Entwicklungsteam. Siehe auch Scrum-Rollen.
Produktinkrement Ein Stück fertiger Software, dass Funktionalität zu bereits früher fertiggestellten Inkrementen hinzufügt, wobei die Summe aller Inkremente zusammen ein ein Produkt formen.
Prognose Auswahl von Einträgen aus dem Product Backlog, die das Entwicklungsteam innerhalb eines Sprints für realisierbar erachtet.
Scrum Ein Rahmenwerk für die agile Entwicklung komplexer Produkte. Scrum wurde von Ken Schwaber und Jeff Sutherland entwickelt und 1995 der Öffentlichkeit vorgestellt.
Scrum Board Ein physisches Board zur Visualisierung des Sprint Backlogs. Scrum Boards sind ein optionales Werkzeug in Scrum.
Scrum Guide Die Definition von Scrum, geschrieben und zur Verfügung gestellt von Ken Schwaber und Jeff Sutherland, den Mitbegründern von Scrum. Diese Definition besteht aus den Rollen, Ereignissen, Artefakten von Scrum und den Regeln, die sie miteinander verbinden. Siehe auch https://www.scrumguides.org/.
Scrum Master Die Scrum-Rolle, die für Beratung, Coaching, Training und Unterstützung eines Scrum Teams und dessen Umfeld verantwortlich ist. Scrum Master stellen sicher, dass Scrum richtig verstanden und angewendet wird. Siehe auch Scrum-Rollen.
Scrum Team Ein selbstorganisierendes Team, bestehend aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master. Siehe auch Scrum-Rollen.
Scrum-Ereignisse Der Scrum Guide beschreibt 5 Ereignisse: Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive.
Scrum-Events Englischer Begriff für Scrum-Ereignisse.
Scrum-Roles Englischer Begriff für Scrum-Rollen.
Scrum-Rollen Scrum definiert drei Rollen: Product Owner, (Mitglied des) Entwicklungsteam und Scrum Master. Zusammen formen diese ein Scrum Team.
Scrum-Values Englischer Begriff für Scrum-Werte.
Scrum-Werte Grundwerte, die dem Scrum Rahmenwerk zu Grunde liegen: Selbstverpflichtung (Engagement), Mut, Fokus, Offenheit und Respekt.
Selbstorganisation Der Scrum Guide definiert Selbstorganisation als ein Managementprinzip, nachdem Teams ihre Arbeit autonom planen, organisieren und durchführen innerhalb klar definierter Grenzen und Zielsetzungen.
Sprint Ereignis mit feststehender maximal 1-monatiger Länge, das als zeitlicher Rahmen für die anderen Scrum-Ereignisse dient. Sprints werden nacheinander, ohne Zwischenräume, durchgeführt.
Sprint Backlog Eine Übersicht über die Menge zu erledigender Entwicklungstätigkeiten um ein Sprintziel zu erreichen. Das Sprint Backlog wird vom Entwicklungsteam verwaltet.
Sprint Goal Englischer Begriff für Sprintziel.
Sprint Planning Ein zeitgebundenes Scrum-Ereignis von maximal 8 Stunden, um einen Sprint zu starten. Während des Sprint Planning formuliert das Scrum Team ein Sprintziel, wählt Einträge aus dem Product Backlog aus, die auf dieses Ziel einzahlen, und erarbeitet ein Sprint Backlog, um das Sprintziel zu realisieren. Siehe auch Scrum-Ereignisse.
Sprint Retrospective Ein zeitgebundenes Scrum-Ereignis von maximal 3 Stunden, um einen Sprint zu beenden. Während er Sprint Retrospektive inspiziert das Scrum Team seine Arbeitsweise und Prozesse mit dem Ziel, Maßnahmen zur Optimierung dieser für den kommenden Sprint abzuleiten. Siehe auch Scrum-Ereignisse.
Sprint Review Ein zeitgebundenes Scrum-Ereignis von 4 Stunden oder weniger, um die Entwicklungsarbeit eines Sprints abzuschließen. Es dient dem Scrum-Team und den Stakeholdern dazu, das aus dem Sprint resultierende Produktinkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Siehe auch Scrum-Ereignisse.
Sprintziel Der (oft geschäftlich oder fachlich orientierte) Zweck eines Sprints. Auswahl und Menge der Entwicklungstätigkeiten eines Sprints können während eines Sprints angepasst werden, um das Sprintziel zu erreichen.
Stakeholder Personen mit Interesse an und Wissen über das Produkt, das vom Scrum Team entwickelt wird. Stakeholder helfen dem Scrum Team dabei das Produkt inkrementell zu erforschen und zu entwickeln.
Storypoint Auf der Fibonacci-Folge basierende Metrik, die verwendet wird, um die Größe von Arbeitspaketen relativ zu einander in Beziehung zu setzen. Vorhersagen über den Zeitpunkt der Fertigstellung können dann mit Hilfe der Velocity gemacht werden. Diese Praktik hat ihren Ursprung im Extreme Programming (XP) und kann in Scrum optional verwendet werden.
User Story Eine spezielle Form der Anforderungsdokumentation, oft in der Form „Als möchte ich , um zu erzielen“. Die User Story hat ihren Ursprung im Extreme Programming (XP) und kann in Scrum optional verwendet werden.
Velocity Anzahl von Storypoints, die ein Entwicklungsteam in den letzten Sprints (durchschnittlich) fertiggestellt hat. Diese Praktik hat ihren Ursprung im Extreme Programming (XP) und kann in Scrum optional verwendet werden.
Scrum ist streng genommen keine Methode, sondern ein Rahmenwerk, welches im Agilen Umfeld eingesetzt wird. Doch was bedeutet das genau? Bei Scrum geht es vorallem um die Selbstorganisation der Teams. Statt wie im klassischen Projektmanagement auf einen Projektmanager zu setzen, der alle Entscheidung für das Team trifft, sind bei Scrum alle Teammitglieder gleichberechtigt und können selbst darüber entscheiden, wie die Aufgaben, die für das Projekt entstehen, verteilt werden. Natürlich gibt es dafür auch Regeln, allerdings bilden diese den schon erwähnten Rahmen, an denen sich das Team orientieren kann. Die Scrum-Regeln sind relativ einfach und können zudem individuell an die Bedürfnisse und Gegebenheiten der Organisation und den Teams angepasst werden.
Was ist der Sprint?
Ein wichtiger Aspekt bei Scrum ist der Sprint. Er ist die wichtigste Zeiteinheit und gibt die Taktung vor. Meist wird eine Sprint auf zwei oder drei Wochen gesetzt – Varianten sind hier jedoch möglich. Wichtig dabei: Jeder Sprint muss immer gleich lang sein. Entschieden wird dann darüber, welche Aufgaben das Scrum-Team innerhalb dieser Zeit bewältigen kann – am Ende sollte ein release-fähiges Resultat stehen. Doch auch ein “Scheitern” ist vorgesehen: Ist das Sprint-Ziel nicht erreichbar, wird dies am Ende des Sprints besprochen und die Aufgaben entsprechend neu justiert. Anpassen an Gegebenheit, inspizieren der Arbeit und damit das Erkennen und Ausmerzen von Hindernisse – das ist agiles Arbeiten.
Was sind die Scrum-Rollen?
Jeder hat in Scrum seine Rolle – doch diese sind nicht wie im klassischen Projektmanagment fest durch den Jobtitel definiert. Es gibt im Grund nur drei Scrum-Rollen: Den Product Owner, den Scrum Master und die Teammitglieder. Das macht die Aufgabenverteilung übersichtlich und nimmt Komplexität. Überhaupt geht es bei Scrum vorallem um die Reduktion von Komplexität – damit sich jeder voll auf seine Aufgabe konzentrieren kann.
Was macht ein Product Owner?
Der Product Owner gibt im Scrum-Team die Vision des Projekts vor. Bei dieser Rolle geht es darum, die Aufgaben zu sortieren und zu strukturieren. Ein Product Owner entscheidet darüber, was der “Backlog”, also der gesamte Aufgabenkatalog beinhaltet, zudem ist die Priorisierung der Tasks ein wichtiger Aspekt. Bei den täglichen Meetings, den “daily Scrums” ist diese Rolle jedoch nicht vertreten – der Product Owner hat keinen Einfluss darauf, wie das Scrum-Team die Aufgaben angeht und kann auch nicht in den laufenden Scrum Prozess eingreifen.
Was macht ein Scrum Master?
Der Scrum Master für einen reibungslosen Ablauf im Scrum-Team. Er ist die kommunikative Brücke zum Product Owner und sorgt dafür, das alle Regeltermine zeitig begonnen und beendet werden. Dies vereinfacht die Meetings und Termin im Scrum-Team und sorgt dafür, das jeder im Scrum-Team weiß, wann welcher Termin ansteht.
Was macht das Scrum-Team?
Das Scrum-Team setzt operativ den festgelegten Backlog um. Dabei sucht das Scrum-Team die einzelnen Aufgaben selbst zusammen und entscheidet darüber, welche “Items”, also Teile des finalen Produkts es umsetzen möchte.
Was ist der Untschied zwischen Scrum und Kanban?
Scrum dient in der Software-Entwicklung dazu, klare Prozesse einzuführen, die Komplexität zu reduzieren und jeder Rolle zu ermöglichen, das beste Ergebnis zu liefern. Kanban hingegen ist “evolutionäres Change-Management” – hier werden die Prozesse nach und nach optimiert sowie angepasst.
Beim User Story Mapping werden die User Storys gezielt in einen Kontext gebracht. Der Scrum Guide beschreibt das Product Backlog als “eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll.” Flache Listen versperren aber oft den Blick auf das Große Ganze (engl. Big Picture) und schränken uns unnötig ein in der Exploration neuer Produktideen und der Release-Planung.
Abhilfe können hier User Story Maps schaffen, die das Product Backlog auf zwei Dimensionen erweitern:
Die horizontale Achse stellt aus Sicht der Nutzerinnen den zeitlichen Ablauf der verschiedenen Aktivitäten, Tätigkeiten und Interaktionen mit dem Produkt dar.
Auf der der vertikalen Achse werden mit zunehmender Komplexität alternative Abläufe und zusätzliche Funktionalitäten des Produkts abgebildet.
User Story Maps helfen uns also dabei unser Produkt aus Sicht unterschiedlicher Nutzerinnen und in mehreren Ausbaustufen zu betrachten und strukturiert mit Stakeholdern darüber zu sprechen.
Learning by doing
Neurowissenschaftliche Studien belegen, dass wir besser lernen, wenn wir Konzepte und Praktiken direkt zur Anwendung bringen. Daher laden wir Sie ein, User Story Mapping anhand eines praktischen Beispiels aus Ihrem Alltag direkt selbst zu erproben.
1. Schreiben Sie Ihre Story auf – Schritt für Schritt
Nehmen Sie einen Stift und einen Block Haftnotizzettel zur Hand. Denken Sie darüber nach, wie Sie heute morgen aufgewacht sind. Was war das erste, was Sie heute morgen getan haben? Schreiben Sie dies auf einen Haftnotizzettel. Ziehen Sie den Zettel vom Block und kleben ihn auf eine glatte Oberfläche, wie z.B. einen Tisch oder ein Fenster. Auf meinem Zettel stünde beispielsweise “Wecker abstellen”.
Überlegen Sie sich dann, was sie als nächstes gemacht haben. Schreiben Sie dies ebenfalls auf Klebezettel und kleben Sie diese neben den ersten Zettel. Auf meinen Zetteln stünde “aufstehen” und “ins Bad gehen”.
Fahren Sie so fort, bis Sie zu dem Punkt kommen, an dem Sie Ihre Morgenroutine beendet haben und bereit für Ihr Tageswerk sind. In meinem Fall: “Ins Auto steigen”.
Sie sollten nun eine ordentliche Sammlung Haftnotizen vor sich haben. Wenn nicht haben Sie wohl ein wesentlich unkompliziertes Leben als ich. Eventuell liegt es aber auch daran, dass wir auf unterschiedlichen Flughöhen, bzw. Detaillierungsgraden unterwegs sind. Manche sind hier sehr ausführlich, andere eher Ressourcen schonend, in dem sie viele Schritte zusammenfassen.
Von Alistair Cockburn stammt das Konzept der Zielebenen (engl. goal levels). Darin beschreibt er funktionale Tätigkeiten (engl. functional tasks) als in sich abgeschlossene Tätigkeiten; also Dinge, die man zu Ende bringt, bevor man etwas anderes anfängt. Ein Beispiel hierfür wäre die Tätigkeit “Duschen”, welche man vermutlich nicht unterbricht, um sich einen Kaffee zu holen und dann weiter zu duschen.
Diese funktionalen Tätigkeiten lassen sich in weitere kleinere Sub-Tätigkeiten (engl. sub-tasks) runterbrechen. Beim gewählten Beispiel “Duschen”: “Ausziehen”, “Duschvorhang zur Seite ziehen”, “in die Dusche treten”, “Wassertemperatur einstellen”, “Nassmachen”, “Einseifen”, und so weiter und so fort…
Ebenso lassen sich funktionale Tätigkeiten sinnvoll zusammenfassen. Unter der Zusammenfassung (engl. summary) “Morgenhygiene” gesellt sich die Tätigkeit “Duschen” zu anderen Tätigkeiten, die die Sozialverträglichkeit enorm steigern, wie “Zähneputzen”, “Haare kämmen” und “Rasieren”.
Für User Story Maps im Allgemeinen –und diese Übung im Besonderen– sollten Sie versuchen ihre Geschichte auf der Flughöhe funktionaler Tätigkeiten zu beschreiben, da diese eine hervorragende Basis für gute Gespräche über das Nutzererlebnis bieten. Schauen Sie daher noch mal über Ihre Haftnotizen – welche Sub-Tätigkeiten lassen sich in funktionale Tätigkeiten zusammenfassen? Welche Zusammenfassungen können in funktionale Tätigkeiten runtergebrochen werden?
2. Bringen Sie Ordnung in Ihre Geschichte
Wenn Sie dies nicht ohnehin schon gemacht haben, bringen Sie Ihre Geschichte nun in einen geordneten Ablauf von links nach rechts. Sprich: Sie beginnen links mit Ihrer ersten Tätigkeit am Morgen und enden rechts mit der letzten Tätigkeit, die Sie bereit macht für den Beginn Ihres Tagewerks. Tätigkeiten, die gleichzeitig passieren, dürfen Sie gerne übereinander stapeln.
In einer User Story Map wird diese Von-Links-nach-Rechts-Achse der Erzählfluss (engl. narrative flow) genannt.
Wenn Sie als Gruppe gemeinsam eine User Story Map erstellen und über die Reihenfolge diskutieren, bedenken Sie bitte, dass für unterschiedliche Menschen unterschiedliche Erlebnisse und Abläufe haben. Ich halte mich nicht einmal zuverlässig an meine eigene Morgenroutine. Vermutlich ist es auch nicht so wichtig, ob man zuerst einen Kaffee trinkt oder erst ein Brot schmiert. Über zwingende Abhängikeiten herrscht in der Regel schnell Einigkeit: Es erscheint logisch, dass man die Kaffeemaschine zuerst einschalten muss, ehe man sich einen Kaffee machen kann.
3. Berücksichtigen Sie alternative Abläufe
Fragen Sie sich nun:
Hatten Sie heute einen typischen Morgen?
Wie war gestern Ihr Ablauf am Morgen? Wie vor einer Woche?
Gibt es Tätigkeiten, die Sie nicht jeden Tag machen? Wie z.B. Frühsport, besondere Bedürfnisse von Lebenspartnerinnen, Kindern, Haustieren, usw.
Fügen Sie Variationen, alternative Abläufe und Details zu Ihrer User Story Map hinzu. Wenn einzelne nur Sinn ergeben, wenn verschiedene Personen und Akteuere beteiligt sind, können Sie diese gerne oberhalb ihrers Erzählflusses als eigene Haftnotizen dazukleben. Diese Akteure werden auch Personas genannt.
4. Fassen Sie ihre Map zusammen
Treten Sie nun einen Schritt zurück und betrachten Ihre User Story Map als Ganzes. Gibt es Tätigkeiten, die gemeinsam einen Sinn ergeben? Wie z.B. “Kaffee trinken”, “Müsli essen”, “Pausenbrot schmieren”; alles Tätigkeiten, die in der Küche stattfinden und als “Frühstücken” zusammengefasst werden können. Diese Aggregationen nennen wir Aktivitäten (engl. Activities).
Nehmen Sie andersfarbige Haftnotizen und ergänzen Sie Ihre User Story Map um zusammengefasste Aktivitäten. Diese bilden das Rückgrat (engl. Backbone) der Erzählung. Das Rückgrat hilft dabei den Gesamtkontext im Auge zu behalten und erleichtert dadurch die Gespräche und Diskussionen über das Produkt.
Tipp: Wenn Sie nur eine Sorte Haftnotizen haben, können Sie die Haftnotizen um 45 Grad drehen, um die Aktivitäten von den Tätigkeiten zu unterscheiden.
5. Fokussieren Sie sich auf spezifische Ergebnisse
Stellen Sie sich nun folgende Situation vor: Es beginnt ein neuer Tag. Doch diesmal werden Sie nicht wie sonst geweckt. Sie haben verschlafen! Sie haben nur 5 Minuten Zeit bis Sie das Haus verlassen müssen.
Schreiben Sie das Ziel “in 5 Minuten das Haus verlassen” auf ein Post It und kleben Sie es links oben neben Ihren Erzählfluss.
Identifizieren Sie die Tätigkeiten, die Sie immer noch machen, wenn Sie nur 5 Minuten Zeit haben. Fügen Sie gegebenenfalls weitere Tätigkeiten hinzu, die sie stattdessen tun. (So könnte beispielsweise “Extra viel Deo auftragen” zahlreiche Tätigkeiten aus der Rubrik “Morgenhygiene” ersetzen…)
Platzieren Sie Tätigkeiten, die Sie nicht tun, wenn Sie nur 5 Minuten Zeit haben, tiefer in Ihrer User Story Map.
Sie haben dadurch den einfachst denkbaren Ablauf Ihrer Morgenroutine modelliert. Würden wir hierbei über ein Produkt sprechen, wäre dies das sogenannte Minimum Viable Product (MVP), also die kleinste funktionale Version unseres Produktes. Oder das erste Release, wenn Sie so wollen.
Identifizieren Sie nun weitere Ausbaustufen: Was würden Sie zusätzlich in Ihren Morgenablauf integrieren, wenn Sie 10, 20 oder 30 Minuten Zeit haben?
Die fertige User Story Map
Sie haben nun die Bausteine einer User Story Map kennengelernt und –da Sie natürlich unserer freudlichen Einladung gefolgt sind– das Konzept in Ihrem Langzeitgedächtnis verankert, in dem sie es direkt zur Anwendung gebracht haben. Es kann dennoch nicht schaden, noch mal alle Elemente zusammenzufassen:
Der Erzählfluss (engl. narrative Flow) bildet das Erlebnis der Nutzerinnen von links nach rechts chronologisch in Form von funktionalen Tätigkeiten (engl. functional Tasks) ab.
Zusammenhängende Tätigkeiten werden zu Aktivitäten (engl. Activities) zusammengefasst. Diese bilden das Rückgrat (engl. Backbone) Ihrer Erzählung.
Sind verschiedene Aktivitäten für verschiedene Akteure relevant, machen wir dies durch Personas deutlich.
Auf der vertikalen Achse bilden wir die Komplexität unserer Geschichte, bzw. unseres Produktes ab: Ganz oben stehen die Tätigkeiten, die für die kleinste, funktionale Ausbaustufe notwendig sind. Dies ist das laufende Skelett (engl. walking skeleton) unserer Geschichte. Darunter gruppieren wir Varianten, Alternativen und zusätzliche Details, die notwendig sind, um weitere erwünschten Ergebnisse zu realisieren.
Einsatzszenarien – Wie Sie User Story Maps anwenden
User Story Maps helfen dabei, sich auf die Bedürfnisse und das Erlebnis des Nutzers (engl. user experience) zu fokussieren. Dadurch laufen Sie nicht gefahr, dass Ihr Product Backlog lediglich aus (vermeintlichen) Lösungen und Liefergegenständen besteht.
Journey Maps
Sie können User Story Maps nutzen, um ein besseres Verständnis für die Probleme und Bedürfnisse Ihrer Nutzer zu erfahren. Dazu modellieren Sie eine User Story Map, die den Ist-Zustan abbildet; also wie Kunden und Nutzer ein spezifisches Szenario aktuell erleben. Diese Art Map bezeichnet Jeff Patton als Jetzt- der Journey Map.
Journey Maps eignen sich auch sehr gut, um die Kundensicht im bekannten Business Model Canvas, bzw. Value Proposition Canvas zu erarbeiten.
Später-Maps
In Form von Später-Maps (engl. later maps) modellieren Sie anschließend die Zukunft, also wie Ihr Produkt oder Service Kunden und Nutzern dabei hilft, ihre Probleme und Bedürfnisse besser zu adressieren.
Mit Hilfe von User Story Maps behalten Sie dabei die gewünschten Ergebnisse (engl. outcome) im Blick. Treten die gewünschten Ergebnisse bereits in frühen Ausbaustufen ein, können Sie Ihr Budget auf andere Ergebnisse umlenken. User Story Maps in Verbindung mit einem iterativ-inkrementellen Entwicklungsansatz, wie z.B. Scrum oder Extreme Programming, helfen also dabei das agile Prinzip “Einfachheit –die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell” umzusetzen, in dem es dabei hilft Ergebnisse zu maximieren und Arbeit (engl. Output) zu minimieren.
Ein positiver Nebeneffekt dabei ist, dass dies auch die Effektivität (engl. impact) des Unternehmens steigern kann; sprich Sie positionieren sich besser in Ihrem Marktsegment und erzielen mehr Umsätze.
User Story Mapping – Workshop
So setzen Sie User Story Maps als Werkzeug in Ihren Workshops ein. Bedenken Sie dabei, dass User Story Maps ein Kommunikationswerkzeug sind. Nutzen Sie die Maps, um sich mit Nutzern, Stakeholdern und Entwicklern über Ihr Produkt zu unterhalten. Entwerfen Sie die User Story Map nicht alleine im stillen Kämmerlein.
Umreißen Sie das Problem: Welche Nutzergruppe hat welches Bedürfnis und warum wollen wir dafür eine Lösung finden?
Überfliegen Sie das große Bild: Erstellen Sie eine User Story Map. Konzentrieren Sie sich dabei auf das große Bild; sprich: bleiben Sie im Erzählfluss indem Sie die X-Achse Ihrer Map in die volle Breite ziehen. Gehen Sie nicht zu sehr ins Detail; halten Sie die Y-Achse Ihrer Map flach.
Gehen Sie auf Erkundungstour: Füllen Sie nun die Lücken. Welche unterschiedlichen Nutzergruppen gibt es noch? Welche alternativen Abläufe und Bedürfnisse gilt es zu berücksichtigen? Was kann alles schiefgehen?
Identifizieren Sie die Ausbaustufen: Es gibt immer mehr zu tun, als Ihr Budget erlaubt. Fokussieren Sie sich auf Ihre Produkt- und Unternehmensziele. Identifizieren Sie, was in in einer ersten, minimalen Ausbaustufe enthalten sein soll. Und in einer zweiten, dritten, …
Minimieren Sie Risiken: Was sind die größten Risiken? Und wie können wir mit Hilfe von kleinen Experimenten schneller lernen und diese Risiken adressieren, bzw. minimieren? Kann das Minimal Viable Product (MVP) aus Schritt 4 vielleicht nicht doch noch etwas kleiner geschnitten werden, so dass wir früher Feedback erhalten und schneller lernen können?
Planen Sie die Entwicklung: Nachdem Sie nun wirklich alles entbehrliche aus Ihrer ersten Ausbaustufe entfernt haben, haben Sie identifiziert, was sie wirklich zu tun haben. Schneiden Sie dies in Entwickler-freundliche Happen und legen Sie los.
