Project Backlog Template: Capture Requests, Prioritize Work, and Choose What’s Next

A project backlog is a list of possible work that you review before committing it to your schedule. A useful backlog records what was requested, why it matters, what is still unclear, and the next decision.

The template below works for freelancers, founders, and small teams managing client requests, product improvements, or internal projects.

Its most important rule: adding a request to the backlog does not promise that you will do it.

Use the backlog to decide. Put selected work into your daily plan when you are ready to act.

Copy-paste project backlog template

Copy this into a spreadsheet, document, or the tool you already use to manage work.

Project: [Project name]
Goal: [The outcome this project should achieve]
Backlog owner: [Person responsible for reviewing requests]
Review schedule: [For example, every Friday]
Last reviewed: [Date]

For requests that need more context, add this detail block beneath the table or inside the relevant item:

Backlog item details

ID and title: [B-001: Short, specific title]

Requested by: [Person, client, or team]

Date captured: [Date]

Problem: [What is happening now?]

Evidence: [A concrete example, observation, screenshot, or relevant note]

Desired result: [What should be different?]

Done when: [Conditions you can check]

Dependency or blocker: [What must happen first?]

Deadline: [A real deadline and its reason, or “None”]

Open questions: [What you still need to know]

Decision and reason: [What you decided and why]

Next review: [Date or a specific condition that triggers another review]

The table helps you scan. The detail block helps you make a sound decision.

Filled example: a small client website project

This fictional example shows a freelancer managing requests after a website launch.

Project: Northstar Studio website improvements
Goal: Make it easier for potential clients to understand the service and submit an inquiry
Backlog owner: Project lead
Review schedule: Friday afternoon

Notice that the form issue is ready for investigation, not automatically ready for a fix. Its cause and implementation effort are still unknown.

The animation is captured without becoming an immediate commitment.

The translation request needs a decision about audience and ownership before anyone estimates the full project.

Example item detail

ID and title: B-001: Investigate inquiry-form failures

Requested by: Client

Problem: The client reports that some visitors cannot submit the inquiry form.

Evidence: Two reported failures. Browser, device, and exact steps still need confirmation.

Desired result: Visitors can submit a valid inquiry and receive a clear confirmation.

Done when: The reported problem is reproduced or investigated, the cause and proposed action are documented, and any agreed fix passes the relevant submission checks.

Dependency or blocker: Access to form settings and a test recipient.

Deadline: No fixed deadline; investigate next because the reported issue affects the project’s main goal.

Decision and reason: Ready for investigation. Confirm the cause before promising a fix or delivery date.

Next action: Ask for the affected device and browser, then test the form.

This level of detail prevents a vague request from turning into an assumed scope of work.

What each backlog field is for

Request or improvement

Describe a problem or desired change that someone can understand without reading the entire conversation.

“Improve onboarding” is too broad.

“Explain the next step after a customer submits the intake form” gives you something to examine.

If the request contains several separate outcomes, split it before estimating.

Expected benefit

Connect the request to a person or project goal.

Useful benefits include reducing repeated support questions, removing a handover problem, or helping a client complete a specific action.

Avoid treating assumptions as proven results. Write “may reduce confusion” when you have a reasonable hypothesis, and record the evidence you would need to check it.

Effort estimate

Start with broad estimates if exact hours would be guesswork.

Define the categories for your own team. For example:

• Small: A contained change with few unknowns.
• Medium: Several steps or some coordination.
• Large: Work that should be broken down further.
• Unknown: Investigation is needed before estimating.

These labels are relative to your work. They are not delivery promises.

Decision

Use a small set of decisions:

• Clarify: Important information is missing.
• Ready: Clear enough to consider for scheduling.
• Later: Understood, but not worth selecting now.
• Declined: Not being pursued, with a reason recorded.

“Ready” means eligible for selection. It does not mean scheduled.

Once you select an item, record where its active work is tracked so it does not remain an ambiguous duplicate.

Owner

The owner is responsible for moving the item toward its next decision.

That person may need to get an answer, estimate the work, or confirm a dependency. They do not have to be the eventual implementer.

Next action

Make this a step someone can take.

“Discuss” is weak. “Ask the client which three categories the filter needs” is useful.

A request with no clear next action often needs clarification before it needs prioritization.

How to prioritize the backlog

For a small backlog, start with judgment and a few consistent questions.

1. Check for work that needs immediate attention

A confirmed operational problem may need a response before the regular review.

Assess its actual impact. A request arriving in an urgent tone is not enough to establish urgency.

2. Compare requests against the project goal

Ask which item most directly supports the outcome you agreed to achieve.

In the example, inquiry-form reliability is closely connected to receiving inquiries. A decorative change has a weaker connection.

That does not make visual work unimportant. It explains the current order.

3. Resolve unknowns that block a decision

Sometimes the best next action is a short investigation.

If an item might be valuable but nobody understands its scope, schedule a bounded clarification task. Decide what you need to learn before implementation begins.

4. Consider effort and dependencies

A small improvement with a clear benefit may be a sensible next choice.

A larger item may still deserve priority if it unlocks other work. Record the dependency rather than relying on everyone to remember it.

5. Select only what fits

Compare the candidate work with the time and obligations already on your schedule.

Choosing three items does not create capacity for three items. If only one fits, select one.

Move selected work into a daily plan

A backlog becomes useful when it changes what you do next.

For each selected item:

1. Define the next executable task.
2. Choose a realistic working date.
3. Keep its backlog ID in the task or notes.
4. Record the selection in the backlog.
5. Return with the result or remaining question.

For example:

Backlog item: B-003: Add a portfolio filter.

Selected task: Ask the client to approve the portfolio categories.

Working date: Tuesday.

Result to record: Approved categories, unresolved questions, and whether implementation is ready to estimate.

You have made progress without pretending the entire feature is ready to build.

How to use this backlog in SelfManager.ai

SelfManager organizes work in dated tables and supports pinned tables, notes, comments, and daily planning. A practical setup is one pinned table for the project backlog, with selected actions placed on the dates you intend to work on them.

Treat the template’s fields as a writing structure. You can put the short request in a task row and keep its ID, benefit, decision, and open questions in notes or comments. This does not require assuming the app has dedicated columns for every template field.

For example:

• Keep “Client website backlog” pinned.
• Capture B-003 with its request and missing information.
• Add “B-003: confirm portfolio categories” to Tuesday’s work.
• Record the answer and update the backlog decision.

If requests are scattered across messages, start with one project in SelfManager’s seven-day trial. Build the backlog, then choose a realistic next action for tomorrow.

Use AI to clarify requests before scheduling

SelfManager supports AI conversations about tables and AI planning with an editable preview. These can help you examine recorded work before committing a plan.

Try this prompt with the relevant context:

Review this project backlog against the stated project goal. Identify unclear requests, possible duplicates, missing dependencies, and items that need investigation. Suggest up to three next actions. Explain your reasoning. Do not invent deadlines, estimates, client approval, or evidence.

Check the suggestions yourself, particularly when a request affects scope or another person’s commitment.

A clearer list is useful. The decision remains yours.

A short weekly backlog review

Give the review a defined purpose: leave with an updated list and a realistic next choice.

Use this sequence:

1. Add requests that arrived elsewhere.
2. Merge duplicates.
3. Clarify the most important unknowns.
4. Update decisions after recent work.
5. Select what fits the next working period.
6. Record what you are postponing or declining.

For “Later” items, add a reason to reconsider them.

“Review after the client supplies the translated copy” is more useful than an unexplained date that keeps moving.

Remove requests that no longer matter. Keeping every idea active makes the list harder to trust.

Common backlog mistakes

Turning every request into a commitment. Capture first, decide second, schedule third.

Using priority labels without reasons. Record what makes the item worth doing now.

Giving every idea a deadline. Use deadlines for actual constraints.

Keeping investigation hidden inside implementation. Make uncertainty visible before promising delivery.

Leaving completed work in the candidate list. Update the backlog when the active task produces a result.

Copying the entire backlog into each new week. Bring forward selected actions, not every possibility.

Start with one project

Capture the requests you already have, clarify the most important unknown, and select one next action.

In SelfManager, keep that project backlog available as a pinned table and put selected work on the dates where you intend to do it.

The goal is to make your next decision easier while keeping the remaining requests visible.

Frequently asked questions

What is a project backlog template?

It is a reusable structure for recording possible project work, its expected benefit, open questions, and the decision about what happens next.

How is a backlog different from a to-do list?

A backlog contains work you might select. A daily to-do list contains actions you intend to work on during a particular day. Keeping the distinction helps prevent every idea from appearing overdue.

What should a small project backlog include?

Start with the request, expected benefit, effort estimate, decision, owner, and next action. Add evidence, completion criteria, dependencies, and genuine deadlines when the item needs them.

How often should I review a backlog?

A weekly review is a reasonable starting point for many small projects. Adjust the frequency to how quickly requests arrive and how often priorities change. Handle genuinely urgent problems when they arise.

Can I use this backlog template in SelfManager?

Yes. Use a pinned project table for the backlog, keep supporting details in notes or comments, and place selected actions on their working dates. The template fields are a manual structure rather than a claim that every field is a dedicated app column.