{"id":158,"date":"2021-05-01T08:00:21","date_gmt":"2021-05-01T08:00:21","guid":{"rendered":"https:\/\/www.roederconsulting.net\/?p=158"},"modified":"2026-01-04T02:26:11","modified_gmt":"2026-01-04T02:26:11","slug":"user-story-map-mal-anders","status":"publish","type":"post","link":"https:\/\/www.roederconsulting.net\/?p=158","title":{"rendered":"User Story Map mal anders"},"content":{"rendered":"\n

Das Tool User Story Map ist sehr beliebt f\u00fcr die Darstellung von User Stories und der Abfolge von Userinteraktionen. Hierbei bietet es die M\u00f6glichkeit, User Workflows visuell und systematisch zu beschreiben. Die User Story Map unterst\u00fctzt das Backlogmanagement und stellt Sachverhalte vereinfacht, visuell und transparent dar. Weiterhin kann es f\u00fcr die Definition des MVP (Minimal Viable Product) verwendet werden. User Story Map hat viele St\u00e4rken und einige Schw\u00e4chen[1].<\/a> Speziell bei prozessualen Tasks, die ganzheitliche Prozesse aus einer Systemsicht \u00fcber Anwendungsgrenzen hinaus beschreiben, k\u00f6nnen User Story Maps Grenzen in der \u00dcbersichtlichkeit bzw. Anwendbarkeit eine Herausforderung darstellen.<\/p>\n\n\n\n\n\n\n\n

Ein Blick in die Toolkiste des klassischen Requirementsmanagements und der Gesch\u00e4ftsprozessmodellierung kann hier helfen. F\u00fcr diese Darstellung wird traditionell das Modell einer Wertsch\u00f6pfungskette verwendet[2].<\/a> Folgende Grafik gibt eine m\u00f6gliche Darstellung eine User Story Map als Gesch\u00e4ftsprozess wieder:<\/p>\n\n\n\n

\"\"
Abbildung 1 \u2013 Gesch\u00e4ftsprozessdiagramm<\/figcaption><\/figure>\n\n\n\n

Die oben dargestellte Grafik unterteilt die Gesch\u00e4ftsprozesse in diverse systemische Aktoren, welche durch die Swimlanes visualisiert wird. Weiterhin zeigt die Grafik, dass der Gesch\u00e4ftsprozess in diverse Prozessschritte zerlegt werden kann. Aufgrund der besseren Verst\u00e4ndlichkeit wurde sich daf\u00fcr entschieden, weitere Elemente aus der Ereignisgesteuerten Prozesskette (EPK)[3]<\/a> zu verwenden. W\u00e4hrenddessen bei der oben gew\u00e4hlten Darstellung die Userinterkation in den Hintergrund tritt, tritt die Systeminteraktion in den Vordergrund. Bei dem oben gew\u00e4hlten Prozess gibt es tats\u00e4chlich nur eine User Interaktion am Anfang des Prozesses. Alles Weitere soll automatisiert ohne Benutzerinteraktion im System von verschiedenen Gesch\u00e4ftsprozessschritten in verteilten Anwendungen bearbeitet werden.<\/p>\n\n\n\n

Jeder Prozessschritt ist in eine oder mehrere User Stories (US) unterteilt. Hierbei wurde darauf geachtet, dass die erste User Story bereits prototypisch den jeweiligen Prozessschritt ausf\u00fcllt. Weitere User Stories haben dann den jeweiligen Prozessschritt komplettiert. Weiterhin l\u00e4sst sich erkennen, dass Prozessteile f\u00fcr den ersten MVP als \u201eOut of Scope\u201c gekennzeichnet wurden. Folgende Tabelle zeigt, wie der zu entwickelnde Gesch\u00e4ftsprozess beispielhaft in einem Backlog aussehen kann:<\/p>\n\n\n\n

User Story<\/th>Sprint<\/th>Release Version<\/th><\/tr><\/thead>
US1<\/td>S1<\/td>MVP<\/td><\/tr>
US3<\/td>S1<\/td>MVP<\/td><\/tr>
US4<\/td>S2<\/td>MVP<\/td><\/tr>
US5<\/td>S2<\/td>MVP<\/td><\/tr>
US6<\/td>S2<\/td>MVP<\/td><\/tr>
US2<\/td>S3<\/td>MVP<\/td><\/tr>
US10<\/td>S3<\/td>MVP<\/td><\/tr>
US7<\/td>Not planned<\/td>Release Candidate 2<\/td><\/tr>
US8<\/td>Not planned<\/td>Release Candidate 2<\/td><\/tr><\/tbody><\/table>
Tabelle 1 – Backlog<\/figcaption><\/figure>\n\n\n\n

Oben aufgef\u00fchrtes Backlog versucht einen Querstich durch den Prozess als erste H\u00fcrde zu nehmen. Dies bedeutet, der Prozess funktioniert bereits End2End nachdem User Story 1-6 vollst\u00e4ndig implementiert wurden. Weiterhin wurde bereits im ersten Sprint versucht darauf zu achten, dass der Prozess ausf\u00fchrbar ist. Auch wenn der Prozess unvollst\u00e4ndig nach dem ersten Sprint ist, gibt dies bereits wertvolle Informationen und Feedback die f\u00fcr die weitere Entwicklung verwendet werden k\u00f6nnen. Weiterhin wird ersichtlich, aus welchen User Stories sich der MVP zusammensetzt und der logische Aufbau des Backlogs ergibt sich aus dem Zusammenhang mit der Prozessgrafik. Dar\u00fcber hinaus werden US7, US8 bereits f\u00fcr zuk\u00fcnftige “Release Candidates” aufgef\u00fchrt. Diese sind als eine weitere Automatisierungsstufe in dem zu entwickelnden Gesamtprozess angedacht.<\/p>\n\n\n\n

Das Beispiel zeigt, dass es verschiedene Varianten gibt, um eine Visualisierung des Backlogs zu erreichen. Weiterhin k\u00f6nnen auch klassische Methoden des Requirementsengeneering mit agilem Backlogmanagement verbunden werden. Die gew\u00e4hlte Methode zur Visualisierung sollte nicht zu detailliert sein, da dies zu einem erh\u00f6hten Aufwand bei der \u00c4nderung durch neue Informationen und Feedback f\u00fchrt. Das Wichtige ist, dass die gew\u00e4hlte Methode f\u00fcr eine bessere Verst\u00e4ndlichkeit des Backlogs sorgt, zu der Transparenz des Backlogs beitr\u00e4gt und Abh\u00e4ngigkeiten innerhalb des Backlogs aufdeckt bzw. visualisiert. Dadurch kann das Selbstmanagement und Agilit\u00e4t gef\u00f6rdert werden und zu besseren Sprintergebnissen f\u00fchren.<\/p>\n\n\n\n

\n\n\n\n

[1]<\/a> Vgl. https:\/\/de.wikipedia.org\/wiki\/Ereignisgesteuerte_Prozesskette<\/p>\n\n\n\n

[2]<\/a> Vgl. https:\/\/www.it-agile.de\/wissen\/agiles-produktmanagement\/story-mapping\/<\/p>\n\n\n\n

[3]<\/a> Vgl. https:\/\/de.wikipedia.org\/wiki\/Wertsch%C3%B6pfungskettendiagramm<\/p>\n","protected":false},"excerpt":{"rendered":"

Das Tool User Story Map ist sehr beliebt f\u00fcr die Darstellung von User Stories und der Abfolge von Userinteraktionen. Hierbei bietet es die M\u00f6glichkeit, User Workflows visuell und systematisch zu beschreiben. Die User Story Map unterst\u00fctzt das Backlogmanagement und stellt Sachverhalte vereinfacht, visuell und transparent dar. Weiterhin kann es f\u00fcr die Definition des MVP (Minimal<\/p><\/div>\n

Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":294,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[34],"tags":[3,28],"class_list":["post-158","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-owner","tag-backlog","tag-de"],"_links":{"self":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts\/158","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=158"}],"version-history":[{"count":25,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts\/158\/revisions"}],"predecessor-version":[{"id":293,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts\/158\/revisions\/293"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/media\/294"}],"wp:attachment":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=158"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=158"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=158"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}