Nutzung einer Story Map zur Verwaltung des Product Backlogs

Die Verwaltung des Product Backlog und damit aller Anforderungen, die an ein Produkt gestellt werden, ist neben der Formulierung und Kommunikation der Produktvision eine weitere, wichtige Aufgabe des Product Owners. Gerade bei nicht-trivialen Produkten und Problemstellungen, für deren Einsatz Scrum ja prädestiniert ist, geht die Übersicht bei den Anforderungen gerne mal verloren. Teilweise versinkt der Product Owner geradezu in der Masse an User Stories, Ideen und Anforderungen, wenn die in Scrum traditionell zur Strukturierung verwendete, eindimensionale Listendarstellung des Product Backlogs genutzt wird.

Alternativ kann eine sogenannte Story Map, erfunden von Jeff Patton, zur Verwaltung und Strukturierung des Produkt Backlogs verwendet werden. Eine Story Map ist, wie der Name es schon verrät, eine zweidimensionale Repräsentation des Product Backlogs. Wie genau Sie diese gewonnene, weitere Dimension nutzen, bleibt grundsätzlich erst einmal Ihnen überlassen. Oft werden als weitere Organisationsebene sogenannte Epics, also “übergroße” User Stories oder sogenannte Themes, also Oberthemen oder Schlagworte, nach denen sich User Stories gruppieren lassen, verwendet.

Die Nutzung einer Story Map hat neben der besseren Übersicht noch sehr viele weitere Vorteile (und die folgende Liste ist sicherlich nicht vollständig):

• Das “Große Ganze” bleibt jederzeit sichtbar.
• Die gewonnene Übersicht trägt zu einer treffsicheren Release Planung bei.
• Gerade bei Projekten mit mehreren Product Ownern oder gar ganzen Scrum Teams können logisch zusammenhängende Einheiten identifiziert und von den unterschiedlichen Teams bearbeitet werden. Reibungsverluste – insb. an “Nahtstellen” – können minimiert werden.
• Priorisierungen können auf einem höheren Abstraktionsgrad durchgeführt werden; diese Tatsache ist gerade bei Priorisierungsmeetings mit der Geschäftsleitung und/oder Bereichsleitern hilfreich, da User Stories teilweise bereits zu detailliert für die Priorisierung durch ein Management-Team sind.
• Konzeptionell bisher “unterbelichtete” Aspekte der Applikation werden schnell sichtbar und lenken die Aufmerksamkeit des Product Owners auf ebenjene konzeptionelle Lücken.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.