The 2026 Guide
Index

Backlog

A backlog is the single, prioritized list of work for a service: the features, fixes, and improvements still to do, ordered so the most valuable work comes first. The Government of Canada's digital standards put it plainly: keep a backlog and use it to set priorities. Every item traces back to a real user need, one person orders the list, and it is never finished, it is refined as the service learns and changes.

What good looks like

  • There is one backlog, a single ordered list of the work still to do, not the same work scattered across inboxes and spreadsheets.

  • One person, the product or service owner, is accountable for the order.

  • Every item traces back to a real user need, usually written as a short user story.

  • Priorities are set by impact on users, fit with goals, and effort, and are revisited regularly, not set once.

  • The backlog holds more than new features: support work and technical debt compete for the same slots.

  • A clear definition of done decides when an item is finished, and unfinished work goes back on the list rather than out to the public.

  • The backlog is kept in the open, where the team and users can see and shape what is prioritized.

  • It is never complete: it keeps being refined across the whole life of the service.

Inside a backlog

A backlog item usually takes this shape, here using a grant application service as the example:

As an organization applying for funding, I want to save a partly finished application so that I can come back and complete it later.

It's done when:

  • the applicant can save a draft and return to it
  • the applicant can see which sections are still incomplete
  • a saved draft is stored securely and tied to the applicant's account

The first line is the user story (who, what, and why), and the "it's done when…" list is its acceptance criteria, the test for when the item is finished. For more detail on writing items this way, Ontario's Service Design Playbook and the GOV.UK guide to writing user stories both use this format.

Why it matters

Without one prioritized list, the work gets driven by whoever asks loudest, and the important but undramatic things, the security fix, the accessibility gap, the thing users keep struggling with, never rise to the top. A good backlog is how a service keeps improving steadily after launch instead of stalling, which matters because the live years are the longest part of its life. The Government of Canada's standards ask teams to iterate and improve frequently and to be open about what they prioritize.

Whose job it is

Running a backlog is shared across the team, with each role holding a different part:

  • The product or service owner keeps the single list, orders it, and refines it; they decide what comes next.
  • The team (designers, developers, researchers) breaks items down, estimates them, and delivers them.
  • The business owner of the application makes sure there is a clear owner and that the priorities serve users and the service's goals.

A closer look

Comparison

Two ways to run a backlog

Pax

Meet Pax, a service manager. They ran the permit renewal service from one backlog:

  • kept a single, ordered list, every item tied to a user need
  • prioritized by impact and effort, using MoSCoW, and revisited the order each week
  • set a clear definition of done, so unfinished work went back on the list, not out the door

The result: steady, visible improvement, the important fixes got done, and everyone, including users, could see what was next.

What the backlog looks like in each phase

The backlog changes shape across the life of a service.

The backlog starts in discovery as a prioritized list of user stories drawn from user research. As building begins, the team works the top items first, and the first release delivers the most critical needs rather than everything at once. The order is set by impact and effort, and it is already expected to change.

Common questions

Further reading

For a broad how-to that ties the backlog together, the UK's Service Manual on agile delivery is the plainest overview. To see how a Government of Canada team decides what to work on next, design.canada.ca's continuous improvement guidance walks through choosing what to improve and measuring whether it worked. For writing the items themselves, Mike Cohn's guide to user stories gives the template, worked examples, and how to break an epic down. And to understand why a backlog should be run as a product rather than a project, Marty Cagan's Product vs Feature Teams explains why the owner should be set problems to solve rather than a fixed list to deliver.

See also

Assumptions this page makes

You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.