Reading time: 10 min.

A Backlog Tells You What Might Be Built. Business Context Tells You Why.

In a refinement session a while ago, I asked what I thought was an easy question about an item near the top of the backlog. Why is this one here?
The room went quiet. The Product Owner said it had come in as a stakeholder request. Someone else remembered it being mentioned in a demo. The item was well written; the template was followed: it had a role, a need, a value statement, and acceptance criteria. Nobody could tell me what would be different in the business if we built it. That is the failure mode I want to talk about, because it is not a writing problem. Every story in that backlog followed the template correctly.

A user story cannot carry the reason the initiative exists

A user story tells us what someone needs and why it is valuable to them. That is all it is designed to do. It does not tell us why the initiative was funded, what business problem it was meant to solve, or which outcomes matter most.  So when a team starts at the backlog, it starts one level below the decision that created the work. What accumulates is a collection of reasonable-sounding features, each defensible on its own, with no shared basis for deciding which ones matter. The connection has to be established somewhere else, before the first story is written.

Start with the problem, not the solution

Consider a medical clinic where patients arrange appointments by telephone. Reception staff spend a large part of the day answering appointment calls. Patients wait on hold, often during the exact hours they are at work themselves. The clinic is considering online appointment booking. It is tempting to frame the initiative as: we need an online appointment system. But that is already a solution, and once it is written down that way, every subsequent conversation is about the system rather than the problem.

A better starting point is what is actually wrong:

Patients depend on telephone contact to arrange appointments, which creates waiting time for patients and significant administrative effort for reception staff.

That is something we can analyze. Online booking may well be part of the answer. So might a call-back service, an appointment reminder that reduces rebooking, or a triage change that removes a category of calls entirely. Framing the problem first keeps those options open long enough to compare them.

Goal, objective, and measure

Once the problem is understood, we can say what should improve.

• A goal expresses direction. For the clinic: make arranging appointments more convenient for patients while reducing administrative effort at reception.
• An objective makes that direction specific enough to argue about. Not “enable more self-service” but something closer to: enable at least 60 percent of eligible routine appointments to be arranged without reception involvement within six months of launch.
• The measures then fall out of the objective rather than being invented alongside it. Percentage of eligible appointments booked through self-service, target 60 percent within six months. Number of appointment-related calls handled by reception, target 40 percent reduction in the same period.

Notice what this does to the conversation. The question is no longer what functionality the appointment system should contain. It becomes what would help us reach these outcomes. That is a much better basis for a product decision, and it is a question a developer or tester can contribute to as easily as a Product Owner.

Stakeholders come in early, not after the analysis is finished

Stakeholder identification should not wait until the goal, objective, and measures are settled. It should start as soon as we have an initial understanding of the problem, because stakeholders are how we find out whether our understanding is wrong.

At the clinic, the obvious stakeholders are patients, reception staff, doctors and nurses, clinic management, administrative staff, and IT support. The useful part is not the list. It is that these groups do not see the same problem.

Patients care about access and convenience. Reception staff would like fewer repetitive calls, but they are also the people who will handle every exception the system cannot, and they know which situations those are. Doctors have a different concern entirely: if patients book their own appointments, will they choose the right type and the right length? Management is looking at cost and service quality together.

That last perspective, the one about appointment types, is the kind of thing that changes an objective. If self-service booking increases the rate of misbooked appointments, a reduction in calls is not a win. You find that out by talking to doctors early, not by reading it in a defect report later. Stakeholder analysis is not a box to complete. It starts early and keeps informing the problem definition as understanding develops.

From people to needs to stories

Once we understand the landscape, we can look more closely at the people who will use the service. This is where personas earn their place.

Anna is 38, works full time, and finds it difficult to call the clinic during opening hours. What is she trying to achieve?

I want to arrange a routine appointment at a time that fits my schedule without waiting on the telephone.

That is still a need, not a solution. The distinction matters because needs are more stable than the ideas we have about how to meet them. The need survives a change of platform, a change of vendor, and a change of Product Owner.

Now the story has somewhere to stand:

As a patient, I want to book an available routine appointment without contacting reception, so that I can arrange it at a convenient time.

And two questions have answers. Which user need does this support? Anna’s need to arrange care around a working day. Which objective does it serve? Self-service booking of eligible routine appointments, with a knock-on effect on call volume. That is a line of sight: business objective, user need, user story.

The refinement test, and what happens when an item fails it

Here is where this becomes usable rather than philosophical. Imagine someone proposes: as a patient, I want to choose a personalized theme for my appointment dashboard so that the portal reflects my preferences. There is nothing wrong with the idea. But ask the two questions. Which significant user need does it address? Which objective does it help us reach?

Compare it with: As a patient, I want to cancel an appointment online so that I do not have to call reception when my plans change. Cancellation is a call. Removing calls is the objective. The connection takes one sentence.

The honest part of this is what you do with the items that fail the test. Most of them are not deleted. Some are security, regulatory, or technical work that serves a constraint rather than an objective, and the right answer is to record which constraint, in the same place you would record an objective. Some are genuinely good ideas aimed at an outcome nobody has articulated yet, which is a signal that an objective is missing rather than that the item is worthless. And some are there because a senior person asked for them, which is a legitimate reason to build something and an illegitimate reason to pretend it is driven by value. The test does not decide for you. It makes the decision visible.

When nobody can tell you the objective

All of this assumes the context exists. Often it does not. The initiative arrives already shaped as a solution, the business case is a slide nobody can find, and the Product Owner is as much a recipient of the decision as you are. You can still reconstruct it, and it is some of the most valuable work a business analyst does.

Start with the money. Something justified this spend, and whoever approved it had a reason, even an unwritten one. Ask what would have happened if the initiative had been refused. The answer is usually the problem statement. Then propose rather than ask. People who cannot produce an objective on request can almost always react to a wrong one. Write down your best guess at the problem and a measure you think matters, take it to the sponsor, and let them correct you. Being corrected is the goal.

Look at what is already measured. Most organizations track more than they use. Call volumes, handling times, cancellation rates, and complaint categories are often sitting in a report somewhere, which means a baseline exists even if nobody has connected it to this initiative. And write down what you settle on, even provisionally, in a place the team can see. A stated objective that turns out to be wrong is more useful than no objective at all, because it can be challenged.

Why this matters more in Agile, not less

Agile teams make decisions continuously. New information appears, constraints emerge, stakeholders learn what they actually need, and some ideas quietly stop being important. A specification written months earlier cannot make those decisions.  Business context can. When the team understands the problem, the goal, and the measures, it has a basis for evaluating things nobody anticipated. The question shifts from whether something was in the original scope to whether it helps achieve the outcome. That is what makes change cheap to evaluate instead of expensive to argue about. It also gives the Product Owner, the analyst, the developers, and the testers the same reference point. Everyone knows not just what is being built, but what it is supposed to change.

A trace, not a sequence

It is tempting to draw the whole thing as a chain: context, problem, goal, objective, measure, stakeholders, personas, needs, stories, acceptance criteria. The chain is accurate and the arrow is misleading, because it suggests you work through it once, left to right. Read it instead as a trace. You can enter at any point, and in practice you often enter in the middle, holding a solution somebody has already decided on. What matters is that every item in the backlog can walk upward and arrive somewhere real. If a story cannot reach a need, and the need cannot reach an objective, you have found a gap in the analysis rather than a badly written story.

So before asking what user stories we should write, ask what we are trying to change, who is affected, what outcome we want, and what those people actually need. Only then decide what belongs in the backlog. A backlog tells the team what might be built. Business context explains why it is worth building.

Which leaves one question I have skipped past here, and it is the one that causes the most trouble in practice: how specific should an objective be before it is useful? Set it too loosely and it justifies anything. Set it too tightly and it becomes a target people manage rather than an outcome they pursue. That is worth a post of its own.