A Backlog Is Not a Plan

I like a backlog. It is a useful place to keep customer requests, half-formed ideas, bug reports, and work we are not ready to pursue.

A backlog is inventory. It answers: what could we do?

A plan answers a harder question: what will we change now, why is this the right move, and what do we expect to learn from it?

Teams get stuck when those two things blur together. The backlog becomes a list of moral obligations, and the sprint becomes an attempt to make everybody less unhappy. The team stays busy while avoiding the choice.

TL;DR

For every near-term item, write:

1. The change we are making.
2. Why it matters now.
3. The evidence that will tell us whether it helped.
4. What we are deliberately not doing yet.

If the team cannot answer those questions, the item belongs in the backlog for now.

Why a Long Backlog Feels Like Progress

Backlogs create comfort because they acknowledge work. Teams write down customer requests, reliability problems, and good ideas so they do not disappear.

The trouble begins when writing something down feels like deciding to do it.

Soon, the team is looking at fifty legitimate items with no shared answer to the question that matters this week: which one creates the most useful movement now?

That question requires judgment. The team has to say no, not now, or not until we know more.

The Four-Line Plan

You do not need a giant roadmap document to make a real plan. Start with four lines. A Now, Next, Later roadmap can hold the horizon; this is the test for what belongs in the now column.

The change

Describe the smallest useful change someone can use or inspect. Avoid project names and vague verbs.

Instead of “improve onboarding,” write “let new users invite their first teammate during setup.”

Why now

Name the constraint, customer question, or business reason. This forces the team to explain why the work deserves attention now.

For example: “New users reach value more slowly when they set up alone, and the support team keeps hearing the same question.”

The evidence

Decide which evidence will influence the next decision. It could be behavior, a support signal, lead time, or a measured reduction in manual work.

You do not need a perfect metric. You need evidence the team will review.

What waits

Name the adjacent work you are choosing to postpone. This shows that the team has seen the broader problem and chosen a focused first move.

A Before-and-After Example

Here is a typical backlog item:

Improve customer notifications.

Here is a plan:

Change: Send a clear confirmation email when a customer submits a request.

Why now: Customers are opening duplicate support tickets because they cannot tell whether a request was received.

Evidence: Fewer duplicate tickets and fewer “did this go through?” messages over two weeks.

What waits: Preference settings, templates, and a full notification center.

The second version gives engineering, product, and support a shared definition of useful progress. It also gives them permission not to build the notification center yet.

Revise the Plan With Evidence

Review the evidence, then expand the change, stop, or choose a different next step.

Keep the backlog as a place for possibilities. Use the plan to make one useful choice. Then make that choice visible enough to learn from it. A short weekly update is a good way to show the change, the evidence, and the next move without turning the plan into a status ritual.

If the next move is still unclear, Dakic’s services start with the question, constraint, or technical seam that needs an honest answer.