A product backlog is one of the fundamental components of agile development. It’s a living breathing list of all the work items you could do that would add value to your customer or help you achieve your goal. By definition, it’s the responsibility of the product owner to build and maintain the product backlog when working in an agile team, but it’s important that everyone understands how it works and contributes to its upkeep.You’re either reading this because:

1. You’re a product owner or scrum master
2. You’re working in an Agile team
3. You’re none of the above but simply want to utilise this Agile tool to get more effective in your own personal task management

Well the fact is that the steps to creating your first product backlog doesn't change, and they don’t become any more or less complicated based on what role you’re playing…Creating a product backlog is actually pretty simple in theory.But - the challenge will come based on your circumstances, and whether you’re creating a product backlog for a team of 200 to market the next Olympic games or simply a product backlog for yourself to buy Christmas presents for your family.The steps are the same for both, but the time and collaborative effort required to build and maintain these two example backlogs will differ greatly. So whether you’re person A and you need to launch your new team and build the product backlog for a new piece of software, or you’re person C and you just want to learn a new skill - these steps will help you both.If you’re pressed for time and this is as far as you read, just remember:Highest value and lowest effort at the top, lowest value and highest effort at the bottom.

Step 1: Before you go any further… Identify your objectives

This is surprisingly tough to do. We’re always so keen to get stuck into the work, make ourselves busy and feel like we’re working at any cost. It’s human nature right?Well there’s an Agile principle we need to remember before we begin:

Simplicity–the art of maximising the amount of work not done–is essential.

Before we begin creating a product backlog, we need to clarify the objective of this backlog. More specifically, who is the customer that will be receiving value from this backlog and what does value look like to them.In essence, what’s the point of this particular backlog?If you’re a product owner leading an agile team, you will probably know this. Your customer might be an end user or even an internal stakeholder, and you should be able to articulate what is valuable to them. Write this down, and keep it handy in a mission statement or even craft some objectives and key results (OKRs) for your team.If you’re simply planning on trying out a backlog for personal development or task management, go through the same steps and ask yourself ‘what am i trying to accomplish’ or ‘what will success look like’.The reason we’re doing this is because a backlog has to be built and prioritised based on the value it adds to the customer, and before we can do that we need to understand what value means. If you haven’t understood this step, you could blitz through every item on your backlog in record time only to discover that you were working on the wrong stuff…Clarify your objective. Write down your goals.Proceed to step 2.

Step 2: Write down all your tasks

At this stage you’re going to be in one of two camps:

1. You’re launching a project/team/backlog from scratch
2. You’re tackling an existing project/set of tasks

For the first camp

This step is going to be obvious, but you simply need to brainstorm all the initiatives that would add value to your customer or help you achieve your goal. You could be quite structured and start with high level objectives and work down to the more bite-size tasks, or you could just go wild and just write down all the initiatives that come to mind. Just capture these initiatives.

For the second camp

This step might actually be very therapeutic in itself. Spend some time writing down all the current tasks and initiatives that you’ve got floating around in your project, or in your personal to-do list, and really take the time to exhaust all your sources so that you’ve captured absolutely everything (e.g. go back through emails, go through your calendar, go through your notebooks, go through meeting minutes).There’s a whole bunch of other weird and wonderful methods to ideating the items within your backlog, such as customer journey mapping, design thinking, PI planning and more - but for the purposes of this guide I’m going to keep it simple and leave it at this. Just write down all the initiatives or tasks you could undergo that would add value to your customer or help you reach your objective.Now you can move onto step 3.

Step 3: Turn those tasks into User Stories

You’ve got a list of tasks. These could be on scraps of paper taken from to-do lists from the last few weeks, or a new neat list typed into excel for your new project. Either way, you’ve got a bunch of tasks or initiatives in front of you that are going to help you add value to your customer in some way, or help you achieve your goal.We’re now going to use a little tool to help standardise the articulation of these tasks: we’re going to write them as user stories.

What in the world is a User Story?

Glad you asked. A user story is simply a way of writing a task from the perspective of the person who’s ultimately going to benefit from the completion of that task. It goes like this:As a… *insert customer or end-user* I want to… *insert functionality*So that… *insert purpose*Let’s say your team is responsible for all the point-of-sales material in a coffee shop chain, and you need to create new signs for the price board. Your user story might look like this:As a customer, I want to see a list of coffee drinks and their prices at the counter, so that I can decide what drink I want to order and make that purchase.Sometimes it doesn’t make sense to write it from the perspective of the end-user. That’s totally OK. If the customer is an internal stakeholder or maybe even yourself, just write it like that. You’re still getting clarity on what you’re doing and why it matters.

A couple of really great benefits to writing a user story.

Firstly, you get instant clarity on who your customer is, what you’re trying to do and why it matters. If someone new had to pick up this task then it would give them all the important information in a few lines.Secondly, it is deliberately brief and does not prescribe HOW the task is to be tackled. This is super important. If your colleagues or team members are the ones picking up these items from the backlog in the future then they will be best placed to decide how to do the job - you’re just giving them the situation and the direction. In summary, you’re standardising the articulation of your backlog items. What was a jumbled pile of ideas, initiatives and tasks is now a uniform collection of user stories that clearly tell you who the item benefits, what they need to be able to do and why it’s important they can do it.You’re looking good now. Progress to step 4.

Step 4: Give them relative effort and value

You might remember at the beginning I mentioned that if nothing else, remember: highest value and lowest effort at the top, lowest value and highest effort at the bottom.Well, now we’re going to give our user stories relative effort and value.

Effort

There’s a few ways you can capture effort, and if you’re working in a proper agile team and really want to get the most out of your backlog then I’d absolutely recommend using story points to capture relative effort, and we’ve got a whole guide to story points here .However, for the purposes of this guide we’re going to go super simple and use t-shirt sizes.XS / S / M / L / XLHopefully this is fairly self explanatory, but we’ve got five different rankings for effort ranging from extra-small to extra-large. Effort is a combination of time, complexity, uncertainty, and the key to assigning effort is that it’s all relative to your backlog.What does that mean?Relative effort means that you’re assigning an effort rating based on how it compares to other items in the same backlog. How do I do it?Take the item that you believe is the least effort in your backlog and label that XS. Now find the item that is the most effort in your backlog and label that XL. Now everything else must fall within those two, and so you can move through the other items and ask yourself:“Is this next item more or less effort than the previous item? Is the difference in effort enough to give it the next effort label up/down?”Once you’ve been through your backlog items in this fashion, you should find that you’ve got a reasonably good spread across XS, S, M, L, XL. If your backlog items are weighted towards one size, then you might want to go back through and ask yourself the same questions again to see if you can get a bit more of a relative scale. If all your items or L or XL then you might want to break them down into two smaller items.I’ll let you use your initiative, but keep it simple and try not to get too worked up about getting the estimates perfect. It’s just an estimation after all.

Value

Same as effort, there’s different ways you can estimate value and it very much depends on your customer and objectives. You might be able to define value in a very quantitative way such as revenue, new users, sales conversions or even customer feedback scores, however it might not be viable to get this data at this stage, and the chances are that as product owner you’ll need to make a judgement call (a.k.a. an educated guess).Remember, we’re using agile methods here and we’re all about testing and learning in small iterations. Once you’ve delivered a few user stories from your backlog you’ll be able to gather some data on what value it’s added, and your value estimation for future backlog items will get better and better.If we wanted to go really simple, you could simply estimate value using 1 (low value) through to 5 (high value). It doesn’t matter too much what scale you use, but you probably want it to be different from your effort scale and keep it equally straightforward.So, that’s value.Again, use your initiative and don’t get too worked up about getting the estimate perfect. What’s important is that there’s relative sizing within your backlog i.e. you have a good idea as to which items are likely to add more value vs. those which are likely to add less value. That’s all.

Step 5: Prioritise and proceed

At this stage you should have:

• A list of tasks that add value to your customer or help you reach your objective
• Those tasks written as user stories
• Each user story given a relative effort estimation
• Each user story given a relative value estimation

Now we’re going to pull it all together into a prioritised backlog that is ready for action.Again, we’re looking for highest value and lowest effort at the top, then as we move down the backlog we finish with lowest value and highest effort at the bottom.Starting with value, put all the 5 (highest value) items at the top, then work down to 1 (lowest value at the bottom). Now, just look at those 5’s and re-order them with the XS items at the top and the XL items at the bottom. Then move onto the 4’s and do the same. Continue until you’ve done the 1’s and your backlog is now prioritised all the way through.This is where some product owner intuition comes into play, because you might have a user story which is “value 5 / effort XL” sat just above a user story which is “value 4 / effort XS”, and actually you might decide that actually the 4/XS user story needs to go above the 5/XL because the 4/XS is still very valuable and perhaps a ‘quick win’ that could really benefit the project. There’s no rulebook here and the product owner is ultimately responsible for making these priority calls. The reality is that this estimation and prioritisation will become easier as you practice, because you’ll be collecting data and feedback that validates your estimates.This is it. From here you can pull user stories from the top of your backlog and start changing the world (or smashing your to-do list in style).Wrapping UpSome key closing thoughts for you as you embark on building your product backlogs:If you’re the product owner for a team, it’s really worthwhile bringing them in on this process and asking them to collaborate with you on the backlog. If they’re doing the work, it’s critical that they estimate the effort. If they have knowledge on the expected value of certain user stories, it’s vital you bring them in on that value estimation. The more the team feel they’ve collaborated with you on building the backlog, the more bought in they’ll feel when tackling the work (and the better results you’ll get).The product backlog is a living, breathing artefact that requires constant refinement and attention. As you take items from the backlog and complete them, you’ll get feedback from your customer and you’ll probably want to adjust your course based on that feedback.This is where truly great product-ownership comes into play - ensuring that the other backlog items are kept up-to-date and prioritised so that whatever you, or your team, are pulling off the top of that backlog is the next most important item given what you now know about your customer or your objective.And finally, in light of the effort required to keep your product backlog in good shape as you move forward, it’s very advisable to keep your backlog as simple as possible. Use a simple tool that you can access easily (post-its on the wall are still meta) and avoid too many complicated labels, tags, categories or estimation models. If it’s just for yourself, you’ll thank yourself later for keeping things simple.If it’s for your team, they’ll thank you straight away for keeping things simple.