Werkzeuge für agile Produktentwicklung

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:

1. 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.
2. 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.
3. 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.