Building Your First Product Backlog: A Starter Approach and Template

A product backlog is the single list of everything a team might do to improve a product. Done well, it answers a simple question at any moment: what should we work on next, and why?

The Scrum Guide (November 2020) defines it as "an emergent, ordered list of what is needed to improve the product." Two words in that sentence matter most for beginners. Emergent means the list will change as you learn. Ordered means it is a sequence, not a pile of items all marked high priority.

This guide gives you a starter approach you can use in a few hours, plus a plain template you can set up in a spreadsheet, a whiteboard or any task tool.

Step 1: Start with a goal

Before you list anything, write down what the product is for. The Scrum Guide calls this the Product Goal and says it "describes a future state of the product which can serve as a target for the Scrum Team to plan against."

Keep it to one or two sentences. For example, imagine a five-person bakery adding online ordering. Its goal might be: regular customers can order and pay for pickup online without calling the shop. Every item you add later should help reach that goal, or it probably belongs somewhere else.

Step 2: Capture everything in one place

Gather the people who know the product and its users. Spend an hour writing every idea, request, known problem and must-have on separate notes or rows. Do not debate or judge yet. Include items from emails, support requests and old to-do lists so nothing lives in a second, hidden backlog.

Then group duplicates and drop anything that clearly does not serve the goal. Expect a messy first list. That is normal.

Step 3: Write clear items and check them against INVEST

Many teams write backlog items as user stories. The GOV.UK Service Manual suggests this format:

• As a... (who is the user?)
• I need/want/expect to... (what does the user want to do?)
• So that... (why does the user want to do this?)

It also recommends adding "a few acceptance criteria for each story," written as a list beginning with "it's done when." For the bakery, one story might read: as a regular customer, I want to choose a pickup time when I order, so that my order is ready when I arrive. It's done when the customer can pick from available times, and the time appears on the order the staff sees.

User stories are not required. Plain descriptions work too, as long as each item says who benefits and how you will know it is finished.

Bill Wake's INVEST checklist, first published in 2003, is a quick test for good backlog items. A good item is:

• Independent: it can be scheduled and built in any order.
• Negotiable: it is not a fixed contract; details are worked out together.
• Valuable: it is valuable to the customer.
• Estimable: the team can size it well enough to rank and schedule it.
• Small: Wake notes stories "typically represent at most a few person-weeks worth of work."
• Testable: you could write a test for it.

Items near the top of your list should pass all six. Items near the bottom can be rougher.

Step 4: Order the list

Now put the items in a single sequence. The Scrum Guide gives this responsibility to the Product Owner, who "is one person, not a committee" and "may represent the needs of many stakeholders."

There is no single correct method. A practical starter approach is to ask four questions of each item near the top:

1. How much does it move us toward the Product Goal?
2. Does it reduce a big risk or answer an open question early?
3. Does other work depend on it?
4. Roughly how big is it compared with its value?

Place the item that best answers those questions first, then repeat. Ties are not allowed; someone has to decide which comes first.

Step 5: Refine the top, leave the bottom rough

The Scrum Guide describes refinement as breaking items down and adding detail such as "description, order, and size," and it notes that "The Developers who will be doing the work are responsible for the sizing." Items that "can be Done by the Scrum Team within one Sprint are deemed ready for selection."

So focus your effort. Make the top items clear and small enough to finish in one sprint or cycle. GOV.UK advises splitting any large story or epic "into smaller stories that can be completed within an iteration." Leave lower items as one-line placeholders. Detailed specs for work you may never do are wasted effort.

A starter template, described

Set up a table with these columns:

• Order: a number showing the item's position.
• Title: a short name a newcomer would understand.
• Story or description: who benefits, what they need, and why.
• Acceptance criteria: a short "it's done when" list.
• Rough size: a team estimate such as small, medium or large, or whatever sizing your team prefers.
• Status: idea, refined or ready.
• Notes: links to designs, questions, dependencies.
• Date added: helps you spot items that have sat untouched for months.

For the bakery, the first rows might be: show the menu with prices online; let customers place an order; let customers choose a pickup time; take card payment; send an order confirmation. Only the first two or three would be refined in detail at the start.

Keeping the backlog healthy

• Review the order regularly, at least once per sprint or cycle.
• Delete items nobody will do. A short, honest backlog beats a long, aspirational one.
• Revisit the Product Goal when learning changes the picture.
• Keep one backlog per product, not one per person.

Once the top of your backlog is ready, you can plan work with it. Our guide to running your first sprint picks up from here.

Key takeaways

• Start with a one or two sentence Product Goal.
• Capture everything in one list, then remove items that do not serve the goal.
• Write items with a clear user, need, reason and "it's done when" criteria.
• Order the list into a single sequence; one person makes the final call.
• Refine only the top items in detail and prune the rest regularly.

Sources

• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020)
• GOV.UK Service Manual, Writing user stories
• Bill Wake, INVEST in Good Stories, and SMART Tasks (August 17, 2003)
• GOV.UK Service Manual, Agile tools and techniques