How_to_use_this_template
📖 How to use this template
A product backlog is one ordered list of everything your team might build, kept in priority order. This template gives you the structure, the fields and the rituals that keep it from turning into a graveyard of good intentions.
- Duplicate this project into your own organization (dropdown next to the project name, then
Duplicate) - Delete the sample items, keeping the five sections
- Rename the Sprint options to your own cadence and the Feature Area options to your product's real surfaces
- Add your first items to 📥 Intake — New Requests, then run a triage session and promote, park or close each one
1. The five sections
Sections are the readiness ladder. An item moves down the list as it gets clearer, and up the ladder as it gets closer to being built.
| Section | What lives here | Rule of thumb |
|---|---|---|
| 🚀 Ready for Development | Refined items with a user story, acceptance criteria, an estimate and an owner | Keep 1.5 to 2 sprints' worth here, no more |
| 🔍 Needs Refinement | Agreed direction, still missing a spec, a design, an estimate or a decision | Groom weekly |
| 🐞 Bugs & Tech Debt | Defects and maintenance work | Reserve about 20% of each sprint |
| 📥 Intake — New Requests | Raw asks from sales, support and users. Nothing here is committed | Triage weekly, then promote, park or close |
| 🧊 Icebox — Someday / Maybe | Good ideas with no owner and no date | Review once a quarter |
Only the top section carries dates and estimates. Everything below it stays deliberately cheap to maintain — that is the point of a backlog, not a to-do list.
2. The fields
Status — the workflow, left to right:
To-do → Ready for Dev → In progress → In review → Completed
Two extras: Blocked for work waiting on something outside the team, and Won't do for decisions you want on record so the same request stops resurfacing.
Priority — Quire's built-in Low / Medium / High / Urgent. Priority answers "which first", not "how big".
Sprint — Sprint 24 / 25 / 26 for committed work, Backlog for anything not yet scheduled, Icebox for parked ideas. Rename the sprints to match your own cadence.
Story Points — Fibonacci: 1, 2, 3, 5, 8, 13. Anything over 13 is not an estimate, it is a warning that the item needs splitting.
Feature Area — the part of the product it touches. Useful for spotting that one area has quietly eaten three sprints.
Impact Area — the outcome you expect: Activation, Retention, Revenue, Performance, Support Load, Security. If nobody can name one, the item probably belongs in the Icebox.
Customer Requests — how many customers actually asked. Sorting on this column ends a lot of opinion-based arguments.
Spec Ready — the Definition of Ready checkbox. Nothing enters a sprint unchecked.
3. Views
Table view is the working view. Sort by Priority, then Customer Requests, and scan the Story Points column for anything unestimated in the top section.
Board view, grouped by Status, is for the daily standup.
Timeline view works once dates are on the Ready for Development items.
Two sublists narrow the noise:
- 🎯 Current Sprint — what the team committed to this sprint
- 📌 Next Sprint — the tentative plan, reviewed at planning
4. Definition of Ready
An item may only move into 🚀 Ready for Development when all of the following are true:
- It is written as a user story: As a [who], I want to [what], so that [why]
- Acceptance criteria are listed and testable
- It is estimated at 8 points or fewer, or split until it is
- A designer has signed off on anything user-facing
- Dependencies are identified and not blocking
- Spec Ready is checked
5. Definition of Done
- Acceptance criteria pass in staging and in production
- Tests are written and CI is green
- Documentation and release notes are updated
- The success metric is instrumented, so you can tell later whether it worked
- The customers who requested it have been told it shipped
6. The rituals
Weekly triage (30 min, PM plus tech lead). Empty the Intake section. Every item gets promoted to Needs Refinement, parked in the Icebox, or closed as Won't do. An item that has sat in Intake for a month is an answer, not a queue.
Weekly refinement (60 min, whole team). Take the top items from Needs Refinement, add acceptance criteria and estimates, check Spec Ready. Stop when Ready for Development holds about two sprints of work.
Sprint planning (60 min). Pull from the top of Ready for Development until you hit your velocity. Do not skip down the list for easy wins — if something further down deserves to go first, reorder the backlog instead.
Quarterly Icebox review (30 min). Delete what you will never build. A backlog nobody trusts is worse than no backlog.
7. Making it yours
- Delete the sample tasks, keep the five sections.
- Rename the Sprint options to your cadence, or switch them to month names if you don't run sprints.
- Adjust the Feature Area options to your product's real surfaces.
- Replace the assignees with your own team.
- Add your first ten items to Intake and run a triage session. Don't try to author a perfect backlog in one sitting — the order matters more than the completeness.
8. Three ways backlogs fail
It becomes a wish list. Hundreds of items, none ordered. Fix: force a single ordered list and cap Ready for Development at two sprints.
Everything is high priority. If more than a third of your items are High or Urgent, priority has stopped meaning anything. Fix: sort by Customer Requests and Impact Area, then re-rank honestly.
Estimates never get revisited. A 3-point item that has been in progress for two weeks was not a 3. Fix: name it in standup and re-estimate rather than quietly letting it slide.