Story Mapping — MIRO
Product manager guide to collaboration
A typical scenario that a PM usually sees in routine life is where they do backlog grooming and story pointing with the team before every sprint starts and once the sprint starts, the scrum team picks up the groomed stories. JIRA is used across the world by numerous companies to accomplish the same task.
But do we agree that at times the scrum team is barely aware of what is going on in the current sprint or what is going to come in the next sprint?
The next sprint scenario is visible because the PM had already groomed those stories two weeks ahead. Otherwise, the team is oblivious to the scope of the product that they are building. Most of us will argue the scope can be reviewed with the team and can be explained, which should be incorporated in the process.
But a humongous scope, which was explained at the beginning of the quarter, neither can be remembered nor be explained repeatedly.
The idea is to make people feel invested in the product. When people recognize something, they invest themselves, which leads to the betterment of the product itself.
Why?
- If the scrum teams recognize the scope and the bigger objective, with the skill set they possess, they can add their own technical opinions and possibilities, which can be helpful in making the product better.
- There are fewer defects in the product, as the scrum team understands the bigger picture, and solely not build for acceptance criteria, but for the future view.
A trivial example from my experience:
We were developing an RTE component. RTE is a rich text editor. RTE had few features like font color, indent/outdent, inline height, etc., built by someone else in the team. I asked my dev guy to build a font size capability within an RTE. I tested it, and the font size was working perfectly fine. But when I started applying font color or indent/outdent to the font size, the font size capability started breaking. I raised a bug saying that font size is not working fine when I have applied line-height to it. To which he replied it is not part of AC. He was right, it was not part of AC. But such things you can only find out while building that feature. One should always come back to PM or raise the concern so that there are no surprises. Lack of understanding of the bigger picture led the dev person to solely concentrate on what was given to him.
Alas, I created another story — this time clearly stating that each feature should work fine with each other.
What is a story mapping technique?
It is a matrix created by the product manager along with the entire team, where the product manager adds epics, features, and stories for the upcoming quarter and provides a holistic view of the scope to the entire team on a high level. The Product Manager explains why we are doing this and how it will aid the growth of the product.
Now that we understand the why and what of the story mapping. Let us get into the how of it.
These are my personal guidelines, feel free to play around to see what suits you best.
Guidelines for creating Story Mapping
#1 Create User Personas
The first step is to understand for whom we are building this product. It is important to identify those customer types in the beginning so that team is aware of these personas and stays customer-centric while building the product. The customer can change from one quarter to another. They can be added or removed.
#2 Color Coding
The PM creates the color-coded stickers, which are to be used while creating story mapping. This helps the scrum team clarify what exactly are they looking at — is it a story or epic or feature or spike.
#3 Backbone
The first step towards understanding the scope is to be aware of the epics that we would be taking up as a team in the upcoming quarter. A product can be broken down into any number of epics. We might end up working with the two-three epics every quarter instead of all of them. Few examples of epics like Account creation, Search, Cart & Checkout, etc.
#4 Sub-Features
The second step is to identify the features under an epic. So every epic is further divided into features. Again, we might not take up all features, but only a few that are of vital importance to the quarter. We include features under an epic.
#5 User Stories
The user story doesn’t require an introduction. These are set of instructions that cover the scope of the work to be taken within a sprint. Refer here to understand — how to write user stories as a PM.
The typical way for any product manager is to create stories in JIRA and include all the details. But now, as we are working on the story mapping technique, how about exploring MIRO for it. MIRO provides the ability to create a story inside it and push those stories from MIRO into JIRA.
They are technical and non-technical stories. PM and the dev team can collaborate and can include their respective stories, presenting a pleasanter view to both.
#6 Release
Throughout the quarter, you would have a couple of releases — A release is where a piece of code is moved to production, or, one can say, goes live. We should arrange these user stories as per the release.
Finally, a story map is like a working agreement, which is available to everyone throughout the quarter and anyone can go back at any point in time and see what was committed or if anything, has changed.
