Claim Your
Product Coins
It feels like yesterday when I first sat in front of my product backlog. I saw a lot of lines with cryptic titles, ticket numbers, and different colors. I was completely overwhelmed and didn’t know what to do. If you felt or feel the same, I recommend you continue reading. I want to share how I started and what lessons I learned with user stories and epics that help me manage my backlog today.
Let’s have a look at the definition of a backlog:
“…the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product…” (Link to source)
There are different opinions about who “owns” the backlog (the Product Manager or the whole squad). It's not something I spend a lot of time dwelling on. I’ve managed 12 different team backlogs over the course of 7 years as PM, as well as multiple backlogs in my job as a Product Coach. After many sprints and projects, I came to the conclusion that it’s most important that:
Everyone knows what the priorities are, and commits to building a great product 🚀
As Product Manager, you’ll drive the backlog activities and its items, called product backlog items or PBIs.
I’d like to share some simple steps on how to set up your product backlog and PBIs so you can build awesome products. I’ll describe a basic structure you can use as well as a couple of examples and mistakes I’ve made to help you start off better than I did back then.
“Is it a bug or a feature?” “Do we need a user story or a task?” “Should we do some research and create spikes?” “Wait, is that tech debt?” “Should we create a follow-up deployment task?” “Is this an epic or a story?”
These are only some of the questions I’ve answered over time. And that’s fine because it’s part of the job. That doesn’t mean I’m the only one who answers these questions within a squad. However, I have learned that while preparing and planning a project the questions you need to answer related to issue types are simpler.
One key takeaway for me is the better I structure myself, the better I’ll structure my backlog. Let’s look at two basic issue types and how to start preparing a project with them. In most of my previous companies, the Product and Engineering departments used the project management and issue-tracking tool Jira. In the following section, I’ll refer to Jira but you can apply everything to other tools or even a physical board.
I usually start with an epic. We can call it a feature, a bigger project, an initiative, or just an issue that collects the work of mutual areas. You can link all other issues to the epic to keep track of every task that’s related to a project. It’s not only about the linking though. I use an epic to collect all relevant information related to the project/topic.
In most cases, I try to cover high-level goals (not detailed solutions) to reflect the (business) value. Open-formulated features are beneficial because the whole organization, especially the Design and Engineering departments, can think about a solution. I prefer this over dictating solutions through one (product) person. The epic helps my team to understand the goal and together we work out how we can get there. If a feature is very clear, like a change due to legal requirements, I make the epic as detailed and precise as possible.
A user story (short: story) is a collection of requirements that are detailed enough for Software Engineers to implement. Stories are a breakdown of the bigger scope of an epic. Instead of working on the whole big feature, you break it down into smaller pieces. The goal is to iterate in smaller increments and deliver software and value in smaller chunks. I follow the INVEST guidelines (defined by Bill Wake) when I write stories which means they are:
Note: You can’t always apply all points to a story due to complexity, cross-team dependencies, etc. That’s fine but we always aim for it.
Let’s look at a past project that I’ll simplify.
Example Project:
Imagine we want to build a SaaS eCommerce solution like Shopify. One important feature we need is the ability for customers to manage/CRUD* their products to be able to sell those later via their Online Shop.
We want to enable our customers to create products in a simple web interface.
*CRUD = Create/Read/Update/Delete
Disclaimer: Product discovery, early team involvement, MVP definition, and prioritization are excluded in this example. I’ll mainly focus on development preparation. Everything related to a rollout plan and marketing strategy will be discussed in a separate post.
Going forward, I’ll explain how I structure my epics by focusing on the user. Most of this can be applied to a story.
Make sure that you put together half a sentence for an epic/feature title. From time to time, you’ll have many projects on the go, and members from other teams or even stakeholders will look at your backlog.
Here are two bad examples of how I wrote titles back then:
How I would write it today:
The benefit of spending 30-60 seconds more on the title definition will help you and your agile software development team later to not get lost in a jungle of badly defined epics. On top of that, it’s very important to already define a scope within the title. If the title of an epic would for example be called: “Create products” that could mean anything. In this case, the scope would become very fuzzy and you wouldn’t be able to find a clear “end”. Keep in mind: It's always about the user experience!
Think about how your team would react if you’d tell them:
vs.
Another note:
Well-defined epics and user stories can help you later create automated release notes and save time. (article coming soon)
An epic should be introduced with a short explanation. The following points can help to cover most of the relevant information:
Here are two versions you can use as a template (inspired by Mike Cohn, one of the contributors to the Scrum software development method).
In the beginning, I used template 1. Now I use the second and enhance it with more information like usage data, research outcomes, etc. If you are planning bigger projects that are not clear or need research, a design sprint, or something else you can use the Lean UX approach to define problem statements and hypotheses you want to prove. (more about that coming soon).
If you're looking for a comprehensive guide to better manage your backlog, check out 👉 this read 📝
Here I focus on everything that’s relevant to achieving your goals:
“In God we trust, all others bring data.” - W Edwards Deming
Always think about how you want to measure success or keep track of progress. This helps me and my teams to work towards a clear goal and to be able to react quickly if the numbers are off track.
I always define at least two types of KPIs:
You can read more about KPIs here: 7 Product KPIs that make all the difference
Notes give you the freedom to add relevant side information (like long-term plans, stakeholders involved, and any other information you want to add) that aren’t necessarily goals or outcomes. They help the team to not forget the vision/bigger picture and provide background for the epic itself.
You can use the open questions field to note all unanswered questions during the refinement of the epic. It’s also a good parking lot for action items, like doing more research, getting missing numbers, etc.
Whenever you’ve answered these questions, make sure you remove them and add the answers to the ticket, or add a comment to show your team the progress.
That’s the basic template I use for my epics. If you’ve prepared a high-level “plan” it’s time to break it down…
How differently do I define stories vs. epics 🤔
It’s almost the same just in a smaller scope! Instead of goals/outcomes, we define “Acceptance Criteria” (short: AC). These are criteria that need to be fulfilled before you mark a ticket/story as “Done” or ready to be deployed for production (production = live system). All ACs have the same priority. (Source: Mike Cohn)
For notes and open questions, you can apply the same rules you do for the epic.
Let’s say we want to build a button on a page called “Create a product”. A user story could look like this:
I haven’t added a design. The position or button color should come from the design specs and can be exchanged during the implementation between the Developers and the Product Designer. If you want, you can add them to the AC, although, I try to only add points to the AC that aren’t obvious (that’s a hint to not add too many ACs).
Are all INVEST criteria fulfilled? We can argue that the story has a dependency because the product creation modal isn’t in place. Now you and your team have two options:
If you go with option A you can’t finish the story until the modal is ready. That’s why we usually go with option B, to reduce dependencies and too much “work in progress”.
The agile motto is:
“Start finishing. Stop starting.” - Chuck Durfee
If you want to learn more about backlog management, user stories, and epics feel free to listen to this podcast episode:
A product backlog is a prioritized list of all the work needed to deliver a successful product. It includes features, enhancements, bug fixes, tasks, and requirements that are necessary to meet the product needs and align with the product vision. The backlog serves as a dynamic roadmap, continuously updated to reflect changes in market demands, customer feedback, and strategic priorities.
In contrast, a user story is a concise, informal description of a specific feature or functionality from the end-user's perspective. It focuses on the user's needs and the value they will gain, helping the development team understand what to build and why. User stories are the individual items that populate the product backlog, providing detailed insights that guide the team in creating an effective product that resonates with its users.
I believe that epics and user stories are great tools to get started with a project. After the high-level work is done, I sit down together with my team and break down the work further. Usually, we do it in a backlog grooming session. I’ve been applying this way of writing epics and stories for more than 3 years now, and I’m really keen to hear how you do it! Tell me on Linkedin.
