Building Your Project Backlog


The project backlog is another way to refer to project scope. In this video with our host Devin Deen, Scrum Master, you’ll find out how to build a project backlog to prioritize tasks in both Agile and traditional Waterfall projects.

Here’s a shot of the whiteboard for your reference!

Building Project Backlog

In Review: Building the Project Backlog

In this video, Devin explained that “product backlog” is a term that’s used commonly in Agile projects but also relevant to projects being managed with Waterfall methodology, as well. The term refers to everything that can be done by the team in order of priority: in other words the project scope.

Devin discussed:

  • Establishing the requirements;
  • Considering the cost of each item and the perceived value to customers; and
  • Prioritizing the requirements, focusing on the ones that your users will use and that you can realistically deliver.

He also provided some colorful examples to illustrate these points, particularly if you’re a farmer in Des Moines.

Pro Tip: As Devin said, the key takeaway is that when you’re building your product backlog to make sure that you have a very clear vision and that you have an ordered set of prioritized requirements. Check out these backlog grooming tips for help.

We hope you’ve enjoyed hearing these tips for creating a product backlog for your project.

Thanks for watching!

Video Transcription

Hi, thank you for joining me. I’m Devin and today we’re going to talk about Building the Product Backlog. Now, “Product Backlog” is a term that’s often used in Agile projects, but it’s also relevant to the traditional Waterfall projects that we are more used to delivering our projects and products in.

What it refers to is effectively everything that can be done by the team, ever, in order by priority. Or in other terms, it’s a scope of a project. What’s important when you’re building your product backlog is to make sure that you have a very clear vision and that you have an ordered set of prioritized requirements.

Let’s start by using an example. Now, if I have a vision of building a car, you can build anything from a Corvette through to a Mini Cooper, or perhaps a pickup truck. So, when I’m forming the vision of a car, it’s important to define that car in terms of who’s going to use it, what are they going to use the car for, and why do they want to have the features of that car.

So let’s say take for an example a farmer, outside of Des Moines, who wants to have a car that he can use to transport his feed for cattle at the end of the day. He’s going to obviously have a pickup truck. But let’s say that the person who’s going to have that car is a commuter outside a suburban Chicago. And then they want to use that car to drop off the kids on their way to work every morning, so they can have an efficient commute into work. Well, if that’s the case for that vision, then instead of having a pickup truck, you’re obviously going to get a minivan.

When you’re forming that vision, when you start getting those requirements together, it’s important to group them in terms of how much is going to cost to deliver an item. So relative to one another, is it expensive, or is it less expensive? Is it a big item to deliver, or a smaller item to deliver? And then of course, the perceived value that you think your customers are going to get out of that particular requirement or feature.

These are the items that you want to focus on delivering first, those items that are of low-cost and higher value. It’s important to remember the Pareto rule as well when you’re delivering and developing your product backlog. Most of your users are actually going to get 80% of the value of your product from 20% of those features. So again, that’s why a prioritized list of requirements or user stories is really important when you’re forming that product backlog.

You’re thinking about your product backlog and about those user requirements, really what you’re looking to do is to develop the items or features that are right here in the middle of this Venn diagram. The items that are really cool to do, the ones that you’re passionate about, the ones that you can actually make in the time frame that you’re given, and the ones most importantly that your users are going to use, or that you can sell if you’re developing a product. So it’s those items right there.

Let’s do an example that most people are familiar with. Let’s talk about getting married. Now, if I was getting married, there’s a list of things that are important to me as a married couple. Certainly want to have some invitations, maybe a church, definitely some wedding rings, and obviously the bride and groom are really important.

Let’s take a user’s story such like this. Let’s say that [we’re] a bride and groom and I want to get married, with my immediate families and close friends, pay for the wedding ourselves, so that I can start life out debt-free. Well, if that’s the case for my vision then certainly the priority of these requirements are going to change.

So with the user story that I just described, where your bride and groom want to get married, pay for the wedding themselves so they can start life debt-free, they might have a different set of priorities for those requirements. Starting with themselves, of course, the bride and groom and ending up, perhaps at the band level. And, if they actually distill it down to the fundamental parts of their wedding ceremony on what they want to achieve, they might actually just stop right here, right there after church.

And in fact, if I were them, I might go to Vegas to achieve that.

For your work, your way, come try us out at

Related Posts

Deliver your projects
on time and under budget

Start planning your projects.

Start free trial