Story map or flat backlog? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

开发者_运维百科

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this 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?

---

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.

---

Tobias here are two other perspectives on story mapping: John Walpole of Twitter shares their experience with story maps and I also wrote a primer on story mapping.

---

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.

---

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.