Structuring your Product Management backlog using Monday.com
A step-by-step guide to get you up and running in an hour
Disclaimer: I don’t have any affiliation to Monday.com. The reason I wrote this article is that it took me a while to understand the best practices on using Monday.com for managing my work. It was also difficult to find answers to the questions that I encountered, and there were no step-by-step articles to create what I wanted.
What I want to achieve
In my role as product manager I lead a software development team. We develop and maintain several applications on our online platform. Since not every application is maintained by one team, we need to align our feature development across products. My primary goal: I want to be able to deal with incoming request for features, or bugs, and to be able to plan work in an easy, understandable way.
I want to plan work in an easy, understandable way
Our work is structured in Epics and User Stories. Epics are small packages of work that have a specific end-goal. An example of an Epic could be: “Give users the option to send out messages of type X via Channel Y”. Under this Epic we list the work items, or User Stories that need to be developed. Every User Story is always picked up by one developer and contains a clearly specified step to contribute to the epic. An example of a User Story in this case could be: “Allow the user to request Channel Y”. User Stories are always linked to developments in one product.
Epics and User Stories are the bread and butter of our work. They also create a hierarchy between the different tasks to be done and indicate when we have delivered new value to our customers.
In order to deliver our work we use 2-week sprints. Since we have people with different capabilities and interests in our team, and we manage multiple products we most of the time cannot fully focus on a single epic. We prioritize the most important epics (how we do that, you can read here) and pick up the most important stories from that epic.
That means that our sprints are a mixture of stories relating to different epics and different products.
To get a grip on this development flow I’m using 4 different boards:
- I use one board to list the products that I manage. That board will act as a source to link epics and stories to products.
- I use one board to create my sprints. That board contains the timeline for sprints and will contain the sprint goals. I also link the products on which I have development work planned in that board.
- I use one board to list my epics. Those epics will describe the feature to be added. I also use this board to add a business case and prioritize development. Epics are linked to one or multiple products. Epics are also planned to one or multiple sprints.
- I use one board to plan user stories. This is basically the overview of work that has been done. Every user story maps to an epic and to a product. User stories (ideally) should map to 1 sprint.
We will setup these boards also in that order as that allows us to directly create the correct dependencies.
Why do you set it up like this?
I create separate boards for various reasons:
- You can give every board a unique focus. Through linking columns you can actually map the dependencies and relations between items. The Product board gives you a high level overview. The Sprint board helps you to roadmap when features are expected. The Epic board supports you in prioritizing development. The User story board plans the actual work to be done for the development team.
- As product manager you will need to work on different boards at different moments in time. You may need to give a monthly update about product performance, which you can do from the product board. Or if you are making a roadmap you can do that from the board of epics. If you are planning work with the development team, you can work from the board of user stories. Adding work items or bugs can be done directly on the board of user stories.
- All the boards need to have different columns that are not relevant for other boards. Therefore you want to create a board for all items that share the same characteristics. This will give you most freedom to actually document the information you need.
Set up your Products board
The first step to set up the structure in Monday.com is to create a table with the products that you manage. In case you manage a single product, you may want to list certain segments or screens of your product.
Depending on the type of product that you have you may want to add certain details to the table. You may for example want to add a hyperlink to the product (if it is a web-based product), or to your internal product catalog. You could also add some financials here. Think about the revenue this year, last month, or something similar. You may want to add usage statistics like the total number of active users. It may also be good to clarify where in the product lifecycle this product is. This will give you the most important details ready at hand when someone asks for them and allows you to compare products to each other.
By putting al this information it is easy to create a simple product dashboard. You could for example create some Graph views to display usage statistics vs. financials.
Furthermore, we will use this table to link our planning to the specific products. Every product name will act as a linking pin.
Set up your Sprints board
The next step is to plan your Sprints. You can probably plan those some time ahead. Typically sprints are time-boxed, so you can already generate some for the next quarter, half year, or full year ahead. Make sure that you also add a ‘Timeline’ column so you can map the start and end date of every sprint. This gives you the opportunity to generate a timeline visual. I also add a status column in which I indicate which sprints have been completed, which is active, and which is upcoming. This makes filtering in different views easy (you typically only want to look at work that is still to be done). I also add a column with the sprint goal. This is a textual description of what I hope to achieve per sprint. You can later refine the sprint goal as you get closer to the actual sprint, but it will give you a high-level overview of what work you can do when.
Finally, you can add a column that you link to your product board. You can then define which products you want to work on in a sprint.
Once you have linked Products to your Sprints you will have the option to actually filter on Products. That is convenient to quickly look up when work for certain products is planned.
Once you’ve done this you have the essentials to start filling the actual work content: your Epics and User stories.
Set up your Epics
I like to work with Epics. An Epic for me is a part of a development or product that delivers value. It needs to be a complete feature. Something is only worthy of an Epic if it is releasable in itself.
I prioritize the importance of Epics using a simple method. I give a rating to the direct business value, the urgency, the opportunity it enables and divide that by the amount of work.
The board of Epics contains three types of information in the table. In the first place it contains planning information. This if for example the status (is it on the backlog, in progress, paused, or completed), timeline planning (when are we starting on this and when do we expect to deliver it), and relationship to the sprints board setup earlier.
Secondly it contains prioritization information. What is the business value, urgency, opportunity and development estimation. This is automatically calculated into a WSJF column. This higher the WSJF the higher priority this epic should be.
Finally the board also contains meta level information. This is the relationship to which products are affected, which stakeholders are involved, if this contains work for specific customers or market segments and any tags. Those columns make it easier to search and filter epics.
Once you have set up this board you can easily create a timeline to show when you expect to deliver certain features. The board also helps you to prioritize and evaluate importance of certain features. This is the board where you do most of your actual planning work.
Set up your User stories
The last board is relevant if you also want to plan and track the actual delivery of work through Monday. If you have other tools such as JIRA, GitLab, Trello, or any software alike for tracking development you may want to add links to those tools in your Epics board.
I create two groups on this board. One group for User stories. This is work that we plan as part of Epics and are sub-items to deliver a certain feature. The other group contains Bugs. This is work that is reported by customers or colleagues and we need to fix. The reasons that I put User stories and Bugs on the same board is that they have equal priority, and should always be assessed in the same way. For the remainder of this article I will refer to User stories, but this also counts for Bugs. All User stories contain a description that communicates to the development team what has to be made. I generally specify what the expected outcome is, and what is explicitly in scope, or explicitly out of scope. Others may use different strategies.
Beside a description I also track status information on the board: is this ticket on the backlog, in progress, blocked, or done. If it is in progress then who is working on it. Furthermore this also gives the option to add a judgement to a User story: is this something that is a must have (or a must ‘fix’ for a bug), or more something to delight customers and not a hard requirement.
Finally in order to plan and assign work there is an estimation column, and an actual column. These help us to plan work and gain insight into our planning accuracy. The last two columns link the User story to a product or an Epic. Those are convenient for filtering and searching through a large set of tickets.
If you feel like it you may also want to add a column with the Sprints. This can be convenient if you want to plan ahead.
Once you have set this board up I would recommend you to create two forms. One form can be used to create new User stories. It’s rather simple and convenient to request the correct information from someone that is entering work items. Using a form you can write some additional information of what you expect people to fill out. The same applies to bugs.
Some final thoughts
With four simple boards you have a simple layout to plan your work as a product manager. Every board has a key focus on a specific aspect of your work. By separating these concerns in different boards you will not be overwhelmed by irrelevant information.
You are free to add more columns that are relevant to your line of business. Keep in mind that less information to fill out makes it easier in daily use. We all know that we are busy, and never have time to properly plan work. Don’t fall into the trap of thinking that Monday.com will solve all our problems of workload. It can make it more manageable though. However, you have to restrict what you fill out and focus on what is necessary to have.
It took me a while to figure out the best way to use Monday.com in my daily work. I hope that with this setup you are ready to kickstart your work and can speed up your learning curve. If you have any feedback, tips or suggestions I’m happy to hear those.
A final note
I think Monday.com is a great tool. However — the linked columns have serious shortcomings. It’s not possible (at least not at the moment, and not to my knowledge) to actually use those linked columns are key items in other views. For example: if you try to map which epics relate to which products, you cannot do this from the Epics board. You can filter on the product column, but not use to create a structured view.
Enjoyed this article?
Please find my other articles under my profile! If you join Medium.com now you support thousands of independent writers around the world.
About Remco
Remco Magielse is a product manager at CM.com. CM.com is a high tech company focusing on Conversational Commerce in The Netherlands. He has worked as a system engineer and product manager at Philips Hue. Remco has gained his Ph.D. on the dissertation titled ‘How to design for adaptive lighting environments: Embracing complexity in design’. He writes articles about product and software development, and the hard- and soft-skill required for product management. He is passionate about innovation and has contributed to approximately 50 patents.
