On LinkedIn: “Can anyone please suggest online story mapping software where we can divide release into sprints and provide high level estimates.” 1/8
Actual story mapping (as described by @jeffpatton in “User Story Mapping” [amzn.to/3iiUDsr]) has nothing to do with any of that. Start by reading Jeff’s book so you can understand what story mapping actually is. 2/8
Next, it appears as if you’re working for a waterfall organization, coming up with a big up-front plan for a large release with estimates, milestones, and all the other dysfunctions of waterfall planning. Agile doesn’t work that way. 3/8
Identify the single most important story. Build it. Get feedback. Adjust (which usually involves modifying your story map). Given that the map is a dynamic thing that’s changing constantly, “high level estimates” are a complete waste of time. 4/8
“Divid[ing] a release into Sprints” is fundamentally anti-agile in any event. The approach assumes that you’ll march through a big plan (and implies some sort of “failure” if you don’t execute that plan as planned). 5/8
However, central to Agile is: “ Responding to change over following a plan.” 6/8
Backlogs are dynamic, changing continuously as new information comes in (in response to feedback from releases, among other things). IMO, the best way to do that is to hard limit its size to a couple Sprints max. The Story Map is your backlog, so keep it small. 7/8
