Last week, we were discussing some good practices around product backlogs with product folks.
I tend to see a product backlog as a small garden. As a product manager, you need to take care of your garden. To nurture it regularly, to remove weeds, to grow promising seeds into nourishing plants.
Here are a few thoughts and practices on backlog gardening.
The product backlog must be clear. It reveals an intention, what you want to achieve to solve a user pain point. A teammate should understand it in one blink.
Have you ever heard about "code smells"? The negative feeling you have, as a software engineer when you look at a codebase or piece of code.
Your gut feeling tells you something is wrong. But you need to dig a bit to understand what makes you uncomfortable. The same applies to a product backlog.
Huge backlog, hundreds of items, a patchwork of intentions, not well organized, no clear prioritization.
On the backlog size, more than a few dozen of user stories create a too big cognitive load. When working on one large product or several products, create several backlogs will help.
Camille F., product director in our team, has an excellent practice of naming a backlog with the expected goal. For instance, "Boost the adoption of YouNameIt".
Using an explicit name creates a strong shared understanding with the team, reminding why we're doing things.
Creating a dedicated backlog, we reduce the temptation to pile up hundreds of unrelated items. Then, the systematic use of Epics or Tags helps to describe smaller steps to reach the goal.
These Epics can relate to the scenarios of a user story mapping. This story map is a powerful and visual way to refine the appropriate scope to deliver business value to your users.
The backlog needs to be consistent. Whatever we're using a format or another for user stories, it should be the same everywhere.
My favorite practice for the preparation and slicing of user stories is through regular review and collaboration with the tech team. Sitting on a weekly or bi-weekly basis and refining the stories together.
There are plenty of ways to slice some value. What matters here is to do it with one (or several) tech mates who will help to slice it conveniently for the team. It also helps to avoid under or over slicing. And it reinforces a common understanding.
In my definition, a strong slicing represents a few days of work for a story for the team (at max). Healthy slicing practice supports continuous integration, making everything easier.
We usually don't need to have hundreds of detailed user stories in advance. But the next milestone scope must be clear and accurate enough. It allows the team to anticipate any potential difficulties. Or to figure out the amount of work to achieve.
Having at least the few upcoming weeks of prepared backlog content is critical for a product manager. Without this, you fall into reactive mode. It becomes challenging to have enough good time with the customers. You're not available for other teams. You have not enough time to think about the next problems to tackle.
Last but not least, the prioritization must be crystal clear; it may evolve with the learning and user feedback. But, it should draw a clear path.
A product backlog is a communication and collaboration tool. It's a living document. It requires regular grooming and cleans up, with a lot of discipline and attention.
My dear backlog gardeners, I wish you some pleasant gardening and harvesting sessions with your teams.