Story map or flat backlog?

Question

I struggle on creating good visualization/tracking for my scrum project and are therefore considering several alternatives. One interesting concept is Story Mapping. Do you have any input on using a story map instead of a flat backlog?

Answer 1

As described in the article you linked the Story Mapping concept was a result of changing something that did not work well for them. All teams are different and the best thing you can do (in my opinion) is to pick one thing that you (the team) thinks looks promising and try it out for a sprint and talk about it again at the next retrospect. Make adjustments and, try some more and revisit at the retrospect again and so on.

Answer 2

As ever with Scrum, do the least that you think you need. Too much documentation can become impossible to maintain and will just tie you down.

That said: in a previous role where we had around 15 Scrum teams we had a "war room" where the stories were mapped on a wall-sized whiteboard.

Most of these stories were "epics", as there was an assumption that the individual Scrum teams would break them down into smaller, more manageable stories later.

Initally, no time estimates were associated with these epics, as the objective of the map was to identify the dependencies between the epics and get a rough idea of which team would be best placed to do which epic.

In following iterations we worked out the time estimates and started to pencil in where they would sit in each team's backlog. This led to some shuffling around of the stories but on the whole the initial guess was about right.

By two or three sprints after we had started the "war room" became harder to maintain so we shifted back at that point to an Excel spreadsheet with the epics listed sequentially. However, by that time the product owners and customers had internalised the project plan so there wasn't any need to maintain it.

Answer 3

Story mapping is a great planning technique, but I would not use the story map per se for tracking. I would use the Features/Scenarios identified on the map as buckets of functionality, and I would use parking lot charts to show progress on each feature. A good idea here is to identify the minimal functionality necessary for shipping each feature (of course those should be the highest priority stories for that feature), and put a line on the parking lot chart for each feature that shows when that minimal amount of functionality has been implemented. This is a clear way of showing exactly where the product is to external stakeholders.