Eigentlich dachte ich, das Thema Story Map ist so fest im (agilen) Methoden-Kanon verankert, dass man dazu nicht mehr viel sagen muss. Ich selber habe bereits 2011 einen Artikel dazu in der iX geschrieben und das Instrument in Vorträgen vorgestellt. Wir haben Story Maps inzwischen in einigen Trainings integriert, da es ein einfaches, aber hilfreiches Instrument ist, um einen Überblick über die funktionalen Anforderungen zu erarbeiten und stimmige Releases zu schneiden. Oder wie mir kürzlich eine ehemalige Teilnehmerin unsere Trainings zum Agilen Requirements Engineering berichtete: Das verstehen auch unsere Manager.
Insofern war ich schon überrascht, dass gerade auf einer großen Konferenz der Raum die Zuhörer nicht fasste, als es um Story Maps ging. Das war zwar überraschend, aber ist doch erfreulich, wenn das Interesse an dem Thema noch wächst.
Anscheinend hat auch Boris Gloger dieses Interesse wahrgenommen und nun ein Erklärvideo dazu veröffentlicht. Nachdem er sich bereits letztes Jahr in einem Vortrag über Story Maps als agile Form der Gantt-Charts lustig gemacht hatte, war ich darüber doch sehr überrascht und habe mir dieses Video tatsächlich angeschaut. Und – ich traute meinen Ohren und Augen nicht: Was Boris Gloger da erzählt, hat aber auch gar nichts mit Story Maps zu tun. Für ihn ist das praktisch nur eine andere Form des Product Backlogs und ein reines Planungsinstrument.
Das ist ein fundamentales Missverständnis: Die Story Map ist zunächst mal ein Analyse-Instrument, mit der wir die Abläufe beschreiben, die wir mit dem zu entwickelnden System unterstützen wollen. Die horizontale Zeitachse steht für den zeitlichen Ablauf der zu unterstützenden Abläufe, nicht für Abfolge der Umsetzung. Erst wenn wir mittels der Story Map ein fachliches Verständnis entwickelt haben, legen wir mit der Release-Planung eine Planungssicht darüber, wobei die horizontale Anordnung weiterhin eine fachliche ist, keine Umsetzungsreihenfolge.
Wer hier die analytische und planerische Sicht munter durcheinander wirft, mag ja immer noch etwas Interessantes machen, aber nicht das, was gemeinhin Story Map genannt wird.
In einem Punkt hat Boris Gloger aber schon Recht, wer es genauer wissen will, kann das in einem Buch nachlesen. Ich empfehle da „User Story Mapping“ von Jeff Patton. Der hat hat sich das mit den Story Maps nämlich mal ausgedacht. Wem das zu trocken ist, kann das natürlich auch in unseren Seminaren selber ausprobieren, z.B. hier.
Hallo. In Ihrem Beitrag steht aus meiner Sicht sehr viel richtiges, allerdings steht ein Satz im Widerspruch zu Veröffentlichungen von Jeff Patton selber.
„Die horizontale Zeitachse steht für den zeitlichen Ablauf der zu unterstützenden Abläufe, nicht für Abfolge der Umsetzung. Erst wenn wir mittels der Story Map ein fachliches Verständnis entwickelt haben, legen wir mit der Release-Planung eine Planungssicht darüber, wobei die horizontale Anordnung weiterhin eine fachliche ist, keine Umsetzungsreihenfolge.“
Ja, die horizontale Achse gibt zunächst die Sequenz in der „Erzählung“ der fachlichen Abläufe wieder. Aber Jeff Patton schlägt selber auch vor, horizontal von links nach rechts und dann von oben nach unten umzusetzen. Nachzulesen in folgendem Artikel, unter der Überschrift „Keep your map displayed to communicate the big picture“
https://jpattonassociates.com/the-new-backlog/
Ja, das kann man so machen, da hat Jeff Patton natürlich recht. Aber dann folgen wir bei der Umsetzung der Erzählung, also dem Prozess. Daher sehe ich auch keinen Widerspruch.
Wenn wir uns jedoch dazu entscheiden, bei der Umsetzung nicht in der Abfolge der Erzählung vorzugehen – wozu es zuweilen gute Gründe gibt -, wären wir schlecht beraten, nun die Story Map in die Umsetzungsreihenfolge zu bringen und die Erzählung zu zerstören. Das würde nach meinem Verständnis der Idee der Story Map, wie Jeff Patton sie in dem Artikel beschreibt, widersprechen.
Das sehe ich genauso.