Artikel teilen:

Ein Product Backlog für eine Lösung kann sehr schnell mehr als 100 User Stories umfassen. Es muss aber nicht zwangsläufig erst über die Zeit auf diese oder größere Mengen an Einträgen wachsen. Auch in  frühen Phasen, insbesondere, wenn eine bestehende Lösung abgelöst werden soll, können die Anforderungen schon von Beginn an zahlreich sein. Wer kennt nicht den Satz: „Wir brauchen das, was die alte Lösung kann und noch zusätzlich diese Liste an Anforderungen.“

Wünschenswert ist in solchen Fällen, ein Backlog strukturieren zu können. Eine lange, flache Liste ist schwierig zu erfassen, unser Gehirn arbeitet gerne mit Clustern/Vernetzung. Dafür können User Stories ähnlich einer Landkarte gruppiert und geordnet werden.

Was ist eine Story Map und wobei hilft sie?

Eine Story Map arrangiert User Stories zu einem Modell, das hilft, die Funktionen der Lösung zu verstehen und Lücken im Backlog aufzudecken. Zudem ermöglicht sie das Planen von ganzheitlichen Releases, die den größtmöglichen Geschäftswert für Nutzer mit jedem Release bieten (Jeff Patton’s The New User Story Backlog Is a Map).

Ein wichtiger Aspekt bei der Arbeit als Product Owner ist die Frage: wie verschaffe ich meinen Stakeholdern oder Nutzern schnell einen Überblick, was die Lösung und insbesondere ihre Inkremente leisten wird? Mit einem Backlog in Form einer flachen Liste ist dies schwierig aufzuzeigen, die Darstellungsebene für den Überblick auf die gesamte Lösung und ihre Bereiche fehlt.

Für eine neue Lösung kann Gruppieren hilfreich sein, um Bereiche oder Themen mit fehlender Abdeckung zu erkennen. Beim Gruppieren ordnet man User Stories beispielsweise nach Funktionalität oder auch Epics/Themes. Ich verwende gerne Epics und verstehe diese dann als größer gefasste User Story. Die Blöcke lassen sich ebenfalls durch Sortieren von links nach rechts priorisieren.

Die große Stärke einer Story Map ist nach dem Gruppieren das einfache Schneiden von Release-Versionen. Sind die Stories geschätzt und ist die Geschwindigkeit des Teams bekannt, können so auch zukünftige Sprints grob vorgeplant werden.

Der Produkt Owner kann in der Diskussion mit Stakeholdern besprechen, welche Features aus den Themenbereichen zuerst umgesetzt werden sollen und eine Reihenfolge festlegen. Hierbei kann für jede Funktionalität, aber auch übergreifend ein lauffähiges Inkrement zusammengestellt werden, das hinreichend „Business Value“ für den Product Owner und die Stakeholder generiert.

story-map-by-sprint

 

Story Maps in JIRA

Ein hilfreiches Plugin für JIRA ermöglicht das Gruppieren und die Release-Planung nach oben genanntem Prinzip direkt im JIRA Agile Board. User Stories aus dem Backlog können Epics zugeordnet werden. So wird anhand dieser Gruppierung eine Story Map dargestellt. Stories können auf Versionen oder Sprints verteilt werden. Für eine vorausschauende Planung in JIRA ist die Story Map eine sehr nützliche Ansicht auf das Backlog. Ich setze diese Ansicht sehr gerne in Backlog Refinements oder zur Release Planung mit Stakeholdern ein.

story-map-in-jira

Lizenzen zu Plugins oder auch Atlassian Produkten können über uns als Atlassian Solution Partner bezogen werden. Sprechen Sie uns gerne hier an.

Diese Artikel könnten Sie auch interessieren:

Okt 10, 2022

AIM ist Xray Certified Partner

Seit 2016 unterstützen wir mit Xray unsere Kunden mit Workshops und Trainings für Teams mit unterschiedlichem Wissens...
Consent Management Platform von Real Cookie Banner