Product Backlog Examples and a Template

A good product backlog example is short, ordered and honest about why each item sits where it does. The three below each hold nine items for one product: a SaaS invoicing app, a mobile class-booking app and an internal expenses tool. Every item has a type, a one-line reason and a rough size, and each list is followed by the reasoning behind its order, because the order is the part of a backlog that takes judgement. A template to copy comes after them.

What a product backlog is, in one paragraph

The 2020 Scrum Guide↗ (opens in a new tab) calls the Product Backlog “an emergent, ordered list of what is needed to improve the product” and the single source of work for the team. Two words matter. Ordered means there is a first item and a last item, not five items all marked high. Emergent means the list changes as you learn, so it is never finished. The Product Goal, the longer-term target the team plans against, lives in the Product Backlog too, which is why each example below starts with one. The wider idea, and why a backlog should be read and pruned, is in the backlog glossary entry.

What each item needs

Items near the top need enough detail to start. Items near the bottom need only enough to remind you what the idea was. The Agile Alliance glossary↗ (opens in a new tab) makes the same point: items vary in size and detail depending on how soon the team will work on them. In the examples, each item carries four things:

• A title that names the outcome, not the technique: “Pay an invoice by card”, not “Stripe integration”.
• A type: feature (something new), enhancement (a change to something that exists) or bug (something broken).
• A reason, in one line, for its place in the order.
• A rough size, XS to XL, where XL means it has to be split before anyone starts it.

Example 1: a SaaS invoicing app

Product Goal: small firms get paid within 14 days of sending an invoice, without chasing by hand.

1. Bug: invoice totals round VAT per line, not per invoice (S). Customers are sending wrong invoices today.
2. Feature: pay an invoice by card from the invoice email (L). The single biggest step towards the goal.
3. Feature: automatic reminder 3 days after the due date (M). Replaces the manual chasing the goal names.
4. Enhancement: show “viewed” and “paid” status on the invoice list (S). Cheap, and tells users the first two items worked.
5. Feature: partial payments (M). Asked for by the largest customers; needed before card payments feel complete.
6. Enhancement: reminder wording editable per customer (S). Follows item 3; worth little until reminders exist.
7. Feature: export paid invoices to accounting software (L). Valued, but not part of getting paid faster.
8. Enhancement: dark mode (M). Popular request, no link to the goal.
9. Feature: multi-currency invoices (XL). Split it before it moves up; today it is a placeholder.

Why this order: a bug that produces wrong invoices goes first because it damages trust in everything else. Items 2 and 3 serve the goal directly. Item 4 is small and makes the effect of 2 and 3 visible, so it rides along. Everything from item 7 down is real demand that does not move the goal, and sits below the line on purpose.

Example 2: a mobile class-booking app

Product Goal: members book, cancel and rebook a gym class in under 30 seconds on their phone.

1. Bug: the app crashes when a class is full and the member taps Book (S). Hits the busiest classes, at the busiest times.
2. Feature: join a waiting list for a full class (M). Turns the crash above into the outcome people wanted.
3. Enhancement: one-tap cancel from the booking confirmation (S). Late cancellations block others from booking.
4. Feature: push notification when a waiting-list place opens (M). Makes item 2 worth having.
5. Enhancement: remember the member’s usual classes on the home screen (M). Removes three taps from most bookings.
6. Bug: times show in the phone’s time zone, not the gym’s, when travelling (S). Real, but affects few members.
7. Feature: add a booked class to the phone calendar (S). Useful, weakly linked to the goal.
8. Feature: book for a friend (L). Needs guest accounts; worth a separate conversation.
9. Feature: in-app personal training sales (XL). A different goal; kept only so the request is not lost.

Why this order: items 1, 2 and 4 are one story told in three steps, so they stay together near the top. The time-zone bug is a bug, but ordering is about value and risk, not about type, and it affects few people, so an enhancement that helps everyone sits above it. Item 9 belongs to a different Product Goal; the Scrum Guide says a team fulfils or abandons one Product Goal before taking on the next, so it waits.

Example 3: an internal expenses tool

Product Goal: every expense claim in a 60-person firm is approved or rejected within two working days.

1. Bug: approvers are not emailed when a claim is submitted on a Friday evening (S). Claims sit unseen all weekend.
2. Feature: approve or reject from the email, without signing in (M). The main delay is approvers not opening the tool.
3. Enhancement: a daily digest of claims waiting more than one day (S). Directly measures the goal.
4. Feature: delegate approvals while on leave (M). The second most common cause of delay.
5. Enhancement: photo of the receipt required before submit (S). Stops claims bouncing back for missing receipts.
6. Feature: finance can see the average approval time per team (M). Lets the firm check the goal is being met.
7. Enhancement: mileage calculator (M). Asked for by the sales team; unrelated to approval time.
8. Feature: corporate card import (L). Valuable next year; dependent on the bank’s export.
9. Enhancement: rename “claim” to “expense” throughout (XS). Nobody minds much; one line so it is not asked again.

Why this order: an internal tool’s users cannot choose another product, so their pain shows up as delay rather than as churn. Items 1 to 4 each remove a known cause of delay. A tiny item like 9 can stay at the bottom indefinitely; its job is to record that the request was heard.

A product backlog template to copy

Plain text is enough. Keep the goal at the top, number the items so the order is explicit, and draw a line where your confidence runs out.

# Product backlog: <product name>
Product Goal: <one sentence: the future state you are aiming at>
Last reordered: <date>, by <name>

## Ready (top of the list)
1. <type>: <outcome title> (<size>)
   Why here: <one line>
   Done when: <two or three checks>
2. ...

## Next (rough, will be refined)
6. <type>: <outcome title> (<size>) - why here: <one line>
7. ...

## Later (placeholders only)
- <type>: <title> - asked for by <who>

## Removed this month
- <title> - why: <duplicate / obsolete / won't do>

A product backlog item, written out

Here is item 2 from the SaaS example as it would look when it reaches the top and is ready to be worked on. How to write the story line itself is covered in the user story template, and the checks in acceptance criteria examples.

Feature: Pay an invoice by card from the invoice email (L)

Problem: most invoices are paid by bank transfer, and only after
one or more reminders. Customers ask for a "pay now" button.

Why here: the most direct step towards "paid within 14 days".

Done when:
- The invoice email has a Pay now link that opens a card form.
- A successful payment marks the invoice Paid and emails a receipt.
- A failed payment leaves the invoice unpaid and says why.

Not included: partial payments (item 5), refunds.

Note the last line: saying what an item does not include is the cheapest way to stop it growing.

Keeping it short and ordered

• Order, do not rank by label. Scrum’s own revision notes↗ (opens in a new tab) record the change from a “prioritized” to an “ordered” Product Backlog in 2011. A position is a decision; “high” is a mood.
• One product, one list, one person accountable for the order. In Scrum that is the Product Owner; others change the order by persuading them.
• Refine the top, not the whole list. Detail on item 40 is waste; it will change before anyone reaches it.
• Delete, and say why. A request that will never be built is kinder closed than left to age. If it matters, it will be asked for again.
• Split anything that is too big to finish in one go before it reaches the top.
• Write the Product Goal first. Without it every item looks equally important, and the order becomes a popularity contest.

How often to do that tidying, who should be in the room and what to bring is covered in backlog refinement.

The same backlog on a fenbs board

On fenbs the product backlog is the To Do lane. Next Up holds what you have committed to next, and In Progress and Completed hold the rest. Each task is a feature, enhancement or bug, which matches the types above, and takes a priority from 1 (most urgent) to 10 and an optional size from XS to XL, where XL means split it.

• To load a list like the ones above, use Add many beside + New task and paste it. Lines starting bug:, feature: or enhancement: set the type, and indented lines under an item become its note. Everything is previewed before it is created.
• Priority gives the rough bands. For the exact order, drag the cards: on a team board the Shared order is what everybody sees, and on a personal board it is called Custom.
• A task’s note holds the problem and its plan holds how the work will be done, so the “why here” and “done when” lines have somewhere to live.
• When an item leaves the backlog without being built, move it to Completed and choose how it ended: Won’t fix, Duplicate, Cannot reproduce or Obsolete. It keeps its ref and its history, and it does not count as delivered.
• Copy as Markdown gives you the whole board as text, in the order each lane is showing.

What fenbs does not have, so you are not surprised: no epics, no story points, no sprints and no fields for a Product Goal. Write the goal into the board’s AI context, where people and assistants both read it, and group related items with a project or category.