Refinement That Actually Refines: Turning a Story Into Something Buildable

The output of refinement is not an estimate. It is a list of decisions that were open at the start and are closed at the end, plus the questions that remain with a name and a date against each. A session that produces a number and leaves the ambiguity intact has refined nothing, and the ambiguity will return during the sprint at roughly ten times the cost.

Refinement is the cheapest moment in the delivery cycle to find out that a story is not buildable. Everyone in the room, nothing built yet, no sunk cost, no pressure. The same discovery made on day four of the sprint costs a developer’s half-finished work and a conversation that now has a schedule attached to it.

Most refinement sessions do not use that advantage. They review a story, someone says it looks fine, a number is agreed, and the team moves on with three unexamined assumptions each. This is about running the other kind, and it is largely an analyst responsibility because the analyst brings the material. The specification craft underneath it is in From Vague BR to Functional Requirements.

Who is in the room and what do they each ask?

Three roles, three genuinely different questions. The names vary and the ceremony does not matter; the coverage does.

Role	The question they own	What they catch
Analyst	What must it do, and why does the business need it?	Missing rules, wrong assumptions about intent, scope that does not serve the goal
Developer	How would this be built, and what does it cost?	Hidden complexity, system constraints, dependencies, the thing that touches everything
Tester	How would we prove it works, and what happens when it does not?	Untestable criteria, missing edge cases, absent failure paths

Drop any one and the gap it would have caught surfaces later. Drop the tester, which is the most common, and you discover in the test phase that half the acceptance criteria cannot be verified. Drop the developer and you commit to something whose cost nobody assessed. Drop the analyst and the team builds something reasonable that does not serve the business need.

The tester’s question is the one analysts most often under-value and it is the highest yield in the room, because “how would we prove that?” is a question that instantly exposes vague criteria. If nobody can answer it, the story is not ready, whatever else was agreed. That is working with QA applied thirty minutes earlier than usual.

What do you bring?

Refinement is not the place to do your analysis. It is the place to test it against two other perspectives. Bringing a story title and hoping the discussion produces the content is the single biggest cause of sessions that overrun and decide nothing.

Bring four things.

The business rule, stated. Not the goal, the rule. “Payments above the customer’s daily limit require approval” is a rule. “Improve payment controls” is a goal and cannot be refined.

The edge cases you already resolved. You have thought about the null, the zero, the duplicate, and the amendment. Say what you decided. This is generous rather than presumptuous: it shows your work and lets the room challenge it, and it stops the session rediscovering questions you already answered.

The data. What is the threshold, which currencies, what volume, how large is a realistic file. Vagueness here is where two testers write two different tests and two developers build two different behaviours.

The decision you need. Say it explicitly: “I need to know whether we reject or route to repair, because it changes the operations process.” A session with a named decision to make usually makes it. A session without one drifts.

How do you split a story without knowing the code?

The most useful skill in refinement, and the one analysts most often believe requires technical knowledge. It does not. You can split on the business axes you already own.

By business rule. One rule per story. “Validate the payment” becomes limit checking, then account status, then sanctions, then currency eligibility. Each delivers a real control and each is independently testable.

By data variant. One currency first, then the rest. One payment type, then the others. Domestic before cross-border. This is the highest value split in payments work, because the second variant almost always reveals that the first design assumed something.

By happy path then exceptions. Build the payment that works, then the rejection handling, then the return, then the recall. Genuinely valuable, and it comes with a warning: exception handling is where most of the real work lives, so a team that ships the happy path and deprioritises the rest has shipped a demo. Split it this way to sequence the work, never to quietly drop the second half.

By interface. The API before the screen. Operations can use a manual tool while the interface is built, and the API is the part other systems depend on.

By manual before automated. The first version routes an exception to a queue a human works; the second version automates the common case. Ships value in weeks instead of months and tells you which cases are actually common.

None of these require knowing how the system is built. All five produce slices that deliver something on their own, which is the only test of a good split that matters. If a slice delivers nothing until its siblings arrive, you have divided the work rather than split the story, and you have gained nothing but a longer board.

What does ready actually mean?

Definition of ready is usually a checklist on a wiki that nobody reads. The version that works is a question you ask out loud at the end of the discussion, and the answer takes thirty seconds.

Ready means the team could start without being blocked. Concretely:

• The business rule is stated, not implied
• The edge cases you know about have answers
• The data and thresholds are specific
• The acceptance criteria are testable, meaning the tester in the room can say how they would prove each one
• Dependencies are identified, especially on other teams
• Nobody is holding an unanswered question that would stop them starting

That last one is the whole checklist compressed. Ask it directly: “Is anyone holding a question that would stop you starting this?” The silence or the answer tells you everything, and it takes less time than reading the checklist.

Two things ready does not require, and confusing them causes real damage. It does not require every detail resolved, because some questions can only be answered once work begins and pretending otherwise produces analysis paralysis. And it does not require the design to be settled, since how to build it is the developer’s decision and refinement is not the place to make it for them.

What goes wrong?

Five failure modes, each with a specific fix.

Refining too far ahead. Detailed analysis of work that gets reprioritised, rewritten, or cancelled. One to two sprints of ready work is the usual balance: enough to absorb a surprise, not so much that you are specifying a future that has not arrived.

Estimation theatre. The session exists to produce numbers, so it produces numbers, and the discussion that would have made them meaningful is skipped for time. The tell is a session where nothing was written down except an estimate. Fix it by capturing decisions in the story as you go, so the artifact of the meeting is the decisions rather than the number.

The silent room. One or two people talk and everyone else waits. Silence is usually not agreement, it is people who have not read the story or do not want to look slow. Directly asking the quiet tester “how would you prove this one?” reliably surfaces more than a general call for questions.

The story refined three times. It comes back every session, everyone recognises it, nothing changes. This always means a decision is missing and nobody owns it. The fix is to stop refining it and go and get the decision, with a name and a date, because further discussion is not what it needs.

No record. A genuinely good session where the decisions live in six people’s memories. Two weeks later the developer implements a version of what was agreed and the tester tests a different one. Write the decisions into the story while the session is happening. This is the least glamorous item on the list and it prevents more rework than the other four combined.

A worked example

The story on the board says: “Support pacs.008 payments.”

That is not a story, it is a programme, and refining it as written produces an estimate somewhere between three weeks and a year. Work it with the material you have.

State the rule and the goal. What must the system do, and why now? Suppose the driver is a scheme migration deadline and the need is to send and receive customer credit transfers on the new format.

Find the axes. By data variant: which currencies, which corridors, domestic or cross-border. By direction: inbound and outbound are different work. By path: submission, status handling, rejection, return. By rule: the field validations are a set, not one thing.

Produce the slices. Outbound single-currency domestic submission with the happy path. Then inbound status handling. Then rejection handling with the correct reason codes. Then returns. Then the remaining currencies and corridors. Each ships something demonstrable and each is testable on its own.

Name the decisions you need. What happens to a payment that fails validation at submission, reject or repair. Which reason codes are in scope for the first release. Whether the ultimate parties are populated. Each of those is a business decision, each blocks a slice, and each takes ten minutes with the right person and three weeks if it goes onto a list.

Check ready on slice one only. The rest can wait. Refining all six now is exactly the too-far-ahead failure, because slice one will teach you something that changes slices two through six.

That whole exercise takes forty minutes and it converts a programme-sized unknown into a sequence with named decisions. The deliverable templates that capture the output are in Real-World BA Deliverables.

The takeaway

Refinement is the cheapest moment to discover that work is not buildable, and the output is decisions closed rather than a number agreed. Bring the business rule stated, the edge cases you already resolved, the specific data, and the decision you need from the room.

Make sure three questions get asked: what and why, how and what it costs, and how we would prove it. The third is the highest yield and the most often missing. Split stories on the business axes you own, by rule, data variant, happy path then exceptions, interface, or manual before automated, and check each slice delivers something alone. Treat ready as one question asked out loud rather than a checklist filed away.

Then write the decisions down while the session is running, because the most common way a good refinement session is wasted is that nobody recorded what was agreed.

Start with From Vague BR to Functional Requirements for the analysis you bring into the room, and Real-World BA Deliverables for the story and criteria templates, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Agile, Requirements, Collaboration, Delivery