Story Map: Landkarte für Anforderungen im Softwareprojekt

Wenn Sie ein neues Softwareprojekt starten, machen Sie sich natürlich Gedanken über die Anforderungen an die Software. Welche Features sollen in meiner Online Community enthalten sein? Und welche haben noch Zeit? Dank agiler Methoden muss nicht alles ausspezifiziert werden – wir kennen heute noch nicht die Features, die wir in fünf Monaten benötigen.

Das agile Product Backlog zeigt Ihnen in linearer Reihenfolge, welche Features realisiert werden sollen. Doch sind Sie sich auch sicher, dass die Features zu den Bedürfnissen Ihrer Nutzer passen?

Mit der Story Map bekommen Sie ein Instrument an die Hand, mit dem Sie Anforderungen entlang der Nutzerbedürfnisse definieren und priorisieren. Sie ist als lebende Landkarte Ihrer Anforderungen zu verstehen. Lassen Sie uns gemeinsam einen näheren Blick darauf werfen, was die Story Map darstellt.

Aufbau einer Story Map

Wie Sie dem nachfolgenden Beispiel entnehmen können, ist die Story Map ein hochinteraktives Instrument, bei dem Sie idealerweise viel Bürowand (oder entsprechendes Flipchart/Whiteboard Papier), die obligatorischen PostIts und Flipchart-Marker verwenden. Im Rahmen eines (mehrtägigen) Workshops, in dem man sich auch der Produktvision, den Personas sowie der Value Proposition der Software nähert, wird die Grundlage für die Anforderungen an die Software gelegt.

Das Spannende dabei ist, dass Sie anhand dieser Struktur eine nutzerzentrierte Orientierung darüber bekommen, welche Features benötigt werden. Darüber hinaus lassen sich die Features in einzelne Feature-Sets (zB MVP, MMP, MMF1, MMF2, …) unterteilen, so dass klar ersichtlich ist, welche Features für das erste Release benötigt werden und welche später kommen können.

Gemeinsam mit dem Kunden erschließen wir uns die fachliche Domäne, indem wir uns entlang der Benutzerbedürfnisse orientieren. Dazu ist die Story Map auf der vertikalen Achse in die nachfolgenden Bestandteile unterteilt.

Aktoren

Aktoren sind die eigentlichen Nutzer des Systems. Sie können hierfür durchaus Personas benennen, jedoch ist es sinnvoller, die Gruppierungen davon zu verwenden. Es ist also besser, den „Community Manager“ und „Plattform Administrator“ zu benennen als die Personas „Knecht Ruprecht“ und „Max Mustermann“.

Ziele

Jeder Aktor der Software verfolgt bestimmte Ziele, die wir auf Basis von Annahmen (oder Befragungen der Nutzer) identifizieren. Die Ziele eines Community Managers könnten „Foren betreuen“ und „Mißbrauch verfolgen“ lauten, wohingegen der Plattform Administrator zum Beispiel die Ziele „Admin Accounts verwalten“ und „Systemeinstellungen definieren“ hat.

Aktivitäten

Ausgehend von jedem Ziel eines jeden Aktors lassen sich Aktivitäten definieren. Es handelt sich hierbei um eine Aufspreizung, die aus den Zielen folgen. Um das Ziel „Foren betreuen“ auf einer Community Plattform zu erreichen, möchte der Community Manager folgende Aktivitäten durchführen:

• Forenbeiträge editieren
• Foren administrieren
• Themes einstellen

Für das Erreichen des Ziels „Mißbrauch verfolgen“ könnte es diese Aktivitäten geben:

• Benutzer sperren
• Shitstorms erkennen können

Features

Anhand der Aktivitäten lassen sich nun Features definieren und auf der Story Map anordnen. Dabei lässt sich die Story Map im Bereich der Features vertikal noch unterteilen, zum Beispiel in MVP (Minimum Viable Product), MMP (Minimum Marketable Product) sowie MMF1, MMF2 (Feature-Set 1, Feature-Set 2).

Jetzt werden Sie auch den Vorteil bei der Verwendung von PostIts erkennen: durch diese interaktive Form können gemeinsam mit dem Kunden die Priorisierung der Features geändert und den einzelnen Feature-Sets zugeordnet werden.

Dazu gehen Sie wie folgt vor: ausgehend von den einzelnen Aktivitäten werden die Features definiert. Für die Aktivität „Forenbeiträge editieren“ könnte es also folgende Features geben:

• Forenbeitrag löschen
• Forenbeitrag ändern
• Forenbeitrag verschieben

Die Aktivität „Benutzer sperren“ enthält möglicherweise folgende Features:

• Nutzeraccount inaktiv schalten
• Callcenter benachrichtigen
• Nutzeraccount reaktivieren

Nachdem Sie die Features für die einzelnen Aktivitäten „good enough“ definiert haben, ordnen Sie diese entsprechend an. Beantworten Sie dabei immer die Frage: Welches Feature benötige ich für dieses Feature-Set? Für den Start Ihrer Online Community könnte es also ausreichen, dass der Community Manager in der Aktivität „Benutzer sperren“ den Nutzeraccount inaktiv/aktiv schalten kann, eine Benachrichtigung an das Callcenter kann jedoch in einem späteren Release erfolgen.

Story Map als lebendes Dokument

Die Story Map ist als lebendes Dokument zu sehen. Dank agiler Methoden wissen wir jetzt noch nicht, was in der fernen Zukunft sein wird. Also wird unsere Story Map zu Beginn etwas „leichtgewichtig“ aussehen, je nach Umfang und Komplexität des Projekts. Sie wissen, welche Features Sie zum Start benötigen und welche in den späteren Releases kommen werden. Und während des Projektverlaufs werden die Anforderungen, Ziele und Aktivitäten immer wieder besprochen und weiter ergänzt und geändert.

Idealerweise belassen Sie die Story Map im Projektraum. Eine elektronische Verwaltung (zB via Google Docs) funktioniert auch, ihr geht jedoch die hohe Interaktivität zwischen Product Owner und Team verloren.

Unser Beispiel habe ich als Google Docs zur Verfügung gestellt (mit diesem Link auch zum Ändern). Mehr Informationen zu Story Mapping finden Sie auf leanagilechange.com.

Welche Erfahrungen haben Sie mit Story Mapping gemacht?