Recently, I wrote an article about Story Map in agile development. The article describes the story mapping technique in detail and you will know the followings:
- Story Map Definition
- Building Blocks in a Story Map
- Personas
- Backbone
- Walking Skeleton
- Release Planning with a Story Map
- Story Map vs Product Backlog
- A Practical Story Map (Hands-on Example)
You can read this article here:
The Big Picture with Story Map in Agile Development
[ To read all posts in Agile Asanas series, use this link. ]
To answer that, you need to know the differences between these two – story map and (product) backlog.
Let’s check them one by one.
It’s not an exclusive list, there can be others as well, some of which I’ve noted in the conclusion part of this article.
Difference - 1: Story Map gives the big picture of the product or solution that you are building, Product Backlog doesn’t.
The product backlog has all the items listed that you are to be delivered in a product – features, stories, bugs, fixes to be done, improvements etc. While working with this artifact, the team members don’t get the big picture – the big picture of what they are building in a sequence of steps. Usually the team members work on tasks (stories broken down to tasks) and hence, it’s not easy for them to see the big picture.
Story map on the other hand helps everyone in the team and also the customer to see the big picture.
As noted in the previous linked article, with a story map you don’t miss the forest for the trees.
The big picture tells the story of the entire system/product/solution you and your team are building.
Difference - 2: Story Map is a two-dimensional (2D) visual structure, where the product backlog is a one-dimensional (1D) non-visual one.
Because the story map is a visual structure, everyone can see what is being worked-upon visually and how the system is built. It's just one single snapshot on the wall or electronic board.
Also, because it’s visual it shows the workflow of the system and gives a context to the discussion while writing stories. After all, stories are primarily about communication.
The backlog shown above is a graphical one for your understanding. In real-time, it will be a one-dimensional figure in an excel sheet or any software tool such as MS Project or Atlassian Jira or any other.
Difference - 3: Story Map on its own acts as product prioritization technique, whereas the Product Backlog does not.
There are quite a few product backlog prioritization techniques that a Product Manager or Product Owner can follow, while refining the backlog. Some of them are: simple schemes (e.g., high, medium, low), monopoly money, Kano method, MoSCoW method etc.
You can read more on various product prioritization techniques here:
Product Prioritization Techniques in Agile Development
With a story map, as you are building your backbone or walking skeleton, you are actually tacitly prioritizing! Do remember that the backlog gives you the Minimum Viable Product (MVP) - the minimum set of capabilities needed to deliver the product or solution or service. Without prioritization, you just can’t have it. Can you?
Similarly, as you build the skeleton part of the backlog, you are also having the Minimum Marketable Features (MMF) – the set of features that makes the product minimally functional. Again, here too, prioritization is involved.
Going further, as you – the product owner/manager – chalk out the release strategy with the project manager and team members, you will be again doing prioritization, i.e., which one will go into the first release, which will go into the next and so on.
Difference - 4: With a Story Map, you can easily show the dependencies, whereas with Backlog, you can’t.
As we just saw, the story map is a 2D one, whereas the product backlog is a flat one. How will you show dependencies in a flat structure?
Story map doesn’t have this limitation. In fact, you can directly draw the dependencies on the wall or board (electronic or not) where you are building the story map. This brings in a lot of discussion among the team members and stakeholders, which is one thing I really like. Story map being about shared communication and shared understanding helps the team in this aspect.
Dependencies are key in any project. Ask any manager who has really worked in any project. Solving dependencies takes a lot of time for the project manager. With a story map, you are doing it in front of everyone and from the beginning.
Difference - 5: With a Story Map, you can determine which part is missing in the system, whereas it’s not the case with Product Backlog.
The story is told by a stakeholder or use from left-to-right in a sequence of steps - each step being an activity (or epic). This sets the narrative flow.
Under each activity (or epic), we have a set of tasks (or stories) decomposed from the respective epic. These stories are placed vertically from top-to-bottom.
Product Backlog is not represented in a sequence of steps and then each step broken down further vertically, because it’s a flat structure. Hence, it won’t be easy to determine which one went missing from the customer’s perspective to build a system or solution.
Difference - 6: Tracing and Monitoring of a story can happen with the Story Map, whereas with the Product Backlog you can’t do so easily.
The backbone in a story map has the epics which are basically a sequence of steps. The backbone also can have a couple of levels of its own if the sequence of steps is too large in number. You can roll-up from the lower-level to the higher-level.
Below the backbone, we have the walking skeleton, which describes each step in more detail, i.e., in the (user) story format.
Hence, if you or your team member wants to trace or monitor a particular story (which is under an epic or feature), you can do so easily.
Difference - 7: If there are a large number of stories, then the Story Map can take a huge space, which is not usually the case with the Product Backlog.
Now, this one goes against the Story Map! If there are a very large number of stories, then the story map can be a very big space in your working area. Sometimes it can even run into multiple walls if you are using a physical space or can run into pages and pages if you are using an electronic tool.
I won’t say this constraint applies to the Product Backlog, though a backlog can also be very big in size. However, because it’s one-dimensional and flat, it won’t be as acute as the case for a very large story map.
Conclusion
There are many other things one can derive when you compare the story map with the product backlog. For example, with a story map, you can decide which one needs more or less analysis as you proceed with your development and this can be done in a visual way. I’ve also noticed a drawback with story maps, i.e., a large story map can take much space.
Another thing I’ve noticed is that many (not few!) product managers or owners don’t understand the concept of story map properly and mess it up.
So, first understand the concept of story map well. Also, do note that it can have variations. For product managers, the ONLY way to understand is to do it yourself and take feedback from your team members. Then decide which one to go for – Story Map or Product Backlog or a combination of both (which I’ve noted also in the linked first article).
References:
[1] New Book: I Want To Be An ACP: The Plain and Simple Way To Be A PMI-ACP, 2nd Edition, by Satya Narayan Dash
[2] Article: The Big Picture with Story Map in Agile Development, first published by MPUG, written by Satya Narayan Dash[3] User Story Mapping – Discover the Whole Story, Build the Right Product, by Jeff Patton with Peter Economy
Agile Asanas Series:
You May Also Like:
- Book for PMI-ACP Exam Prep: "I Want To Be An ACP"
- Book for PMI-PMP Exam Prep: "I Want To Be A PMP"
- Book for PMI-RMP Exam Prep: "I Want To Be A RMP"
- Book for PMI-CAPM Exam Prep: "I Want To Be A CAPM"
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.