Creating a Product Backlog from scratch (Part 1)

As we know, Product Backlog is an essential element of Scrum. I would say, whenever you are building a product, you should have some form of a Product Backlog present.

In this latest video, I’d like to walk you through creating an actual Product Backlog from scratch for an example product.

BTW, this is part 1 of this topic. In the next video, I will be working with the same Product Backlog and the same tools for Sprint Planning to have a complete overview of the topic.

I have chosen a product that is easy enough to understand so that you can relate to it: an online educational hub about Scrum. I specifically say “hub” because I don’t want to limit it to, say, just a website with information. I want to give it a bit more creative freedom.

I’ll pay the role of the Product Owner for this product.

While I would love to go in more details on this topic, I can’t cover everything. So in this exercise we will assume that we have a defined customer persona and a product vision, we have collected the information from stakeholders and customers, and all the ground work has been done.

I also want to make it as visual as possible, so I am using an online tool to show you how a creation of a Product Backlog could look like in real life with a real Scrum Team. I have decided to use a great online tool from my friends at ZenHub. But, of course, there are other tools, like Jira and Azure DevOps for example that technically have similar functionality. Though every tool will have it plusses and minuses.

Anyway, long story short, watch the video to see how I create a Product Backlog from scratch.

Product Backlog Recap

Just to give you an overview of what I talked about in the video and the steps you can take when creating a Product Backlog from scratch

1. The Product Goal

Firstly, before we go into the actual Product Backlog, we need to understand what the goal is. And this step is often skipped which is a big mistake.

Of course, to be able to craft a good Product Goal you need to identify some other things first: the product vision, your customer persona, your success metrics and criteria.

And I think the metrics are an absolute must if you want your goal to be tangible.

2. The Epics

A popular term used is “Epics” for high level work items. Basically, it’s the work that is too big to fit into one Sprint.

When you start out with a backlog from scratch, it really helps to start high level without going into too much detail right away.

Then after you have a clear understand of the work on the “epic” level, you can start splitting work.

3. The Features and Enablers

I specifically don’t use the word “user stories” here as I want to step away from a practice many teams use, and instead focus on the meaning itself. Plus, not everything is a user story 😉

There will be different types of work we will add into the Product Backlog. But most likely it will start with features and enablers.

Features are practically functionality that will allow the users to perform certain actions or get certain information. These bring value to the customers immediately, it’s visible.

Enablers represent work that we have to do to be able to build the features. These don’t immediately or visibly deliver value to our customers, but they are necessary. I refer to them as non-functional requirements in the video.

4. Sprint Planning

We are creating a Product Backlog to be able to start the work. It doesn’t have to be fully defined. It just have to be enough to start sprinting.

I am not covering the Sprint Planning in this video (as it would be waaaaayy too long). So stay tuned for the next video where I walk you through an example Sprint Planning using the Product Backlog I created.

I hope you learned something new in this video and in this article.

And what are your favorite tools for Product Backlog management?