Nobody Knows What Done Looks Like on Your Project

The build is progressing. The team is hitting sprint goals. Stories are being signed off. And yet something feels unresolved.

Then UAT starts. A business user rejects something the delivery team considers finished. A release readiness conversation turns into an argument about whether the feature actually meets the original intent. Someone raises a gap that feels fundamental, and the team spends two hours debating whether it is a defect, a change request, or a misunderstanding.

Nobody is obviously wrong. They just had different pictures of what the end state was supposed to look like. And nobody made those pictures visible until the moment they collided.

That is a definition problem, not a delivery problem. And it has usually been travelling through the project unchecked for weeks.

Project clinic summary

Symptom:
UAT findings, sign-off delays, and release arguments suggest nobody agreed on what “done” actually means.

Likely causes:
Acceptance criteria describe system behaviour rather than business completion; “done” is assumed rather than stated; story, feature, and release completion are conflated; stakeholder sign-off is mistaken for shared definition.

BA move:
Make completion explicit at the story, feature, and release level. In writing. before it matters.

Why this hurts the project

A definition gap found during refinement costs a conversation. Found in UAT, it costs implementation time, retesting, updated training materials, delayed deployment decisions, and a dent in stakeholder confidence that is hard to repair.

The gap did not get more complicated. It just got more expensive.

There is also a predictable blame pattern. Delivery teams feel like the goalposts moved. Business stakeholders feel like delivery missed something obvious. Project leads get pulled into classification debates instead of readiness decisions. Everyone is frustrated, and nobody is entirely wrong.

This is the upstream condition that produces UAT surprises, stalled sign-offs, and scope arguments at release. Fix the definition gap and several of those problems shrink. Leave it and the project keeps generating the same friction at the same points in the cycle.

What this usually looks like in practice

The signals are usually visible well before UAT, if you know what to look for.

Stories are signed off in sprint reviews and reopened two sprints later. UAT findings keep arriving that feel less like defects and more like things nobody discussed. When someone asks “is this ready?”, the answer depends on who is in the room. Business users in UAT reject something as incomplete that the delivery team considers finished, and both sides have a reasonable case.

The acceptance criteria on those stories describe what the system does: the user can submit the form, the record is saved, the email is triggered. They do not describe what must be true for the business to consider this done. That distinction sounds minor. In practice, it is where most of the late surprises live.

Why it keeps happening

Acceptance criteria are output-focused, not outcome-focused. Describing system behaviour is not the same as stating the business condition. “The user can submit the form” tells you the button works. It does not tell you which users, in which state, under which conditions, with which validation in place. That gap is where UAT finds the things everyone assumed were obvious.

Done is assumed, not stated. Everyone in the room has a slightly different mental model of what the end state looks like. Nobody surfaces it because it feels implicit. It only becomes explicit when someone challenges it, usually at the worst possible moment.

The levels are not distinguished. A story being done, a feature being done, and a release being ready are three different things. A story can pass its acceptance criteria and still be part of a feature that is not complete. A feature can be functionally complete and still sit in a release that is not ready to go live. If nobody is distinguishing between these levels, the team is building toward a target nobody has written down.

Sign-off is mistaken for definition. A stakeholder who approves a story has confirmed they reviewed it. That is not the same as agreeing on what complete looks like. Signed-off vague requirements are still vague requirements.

Completion is only defined when it is disputed. Nobody surfaces the definition early because it feels unnecessary. Then a dispute arrives and everyone discovers they were picturing different things. By that point, the cost of closing the gap has multiplied.

Questions worth asking

When completion feels undefined, trace it back:

1. If you asked three different people on this project what “done” looks like for the current feature, would they give the same answer?
2. Do your acceptance criteria state what must be true for the business, or just what the system does?
3. Could a business user confirm a story is complete without any guidance from the delivery team?
4. Has anyone written down what the project needs to be true before it is ready to go live, covering not just functional completeness but data readiness, training, and support?
5. Are stories being signed off in sprint reviews and then reopened in UAT? If so, what actually changed?
6. When a UAT finding arrives, can the team quickly tell whether it is a defect, a missing requirement, or a misunderstood expectation?
7. Does the team distinguish between a story being done, a feature being done, and a release being ready?
8. Is there a written statement of what “fully working” means for the main capabilities this project is delivering?
9. When stakeholders sign off on a story, are they confirming the behaviour is correct, or confirming they reviewed the documentation?
10. Has anyone asked the business users what they would need to see to feel confident this is ready to go live?

If several of these point the same direction, the project is not dealing with messy delivery. It is carrying a definition gap that has been building since the work was scoped.

The IT Project Problem Diagnostic Checklist includes a UAT Readiness section and a Requirements Health section. Use them to check whether your project’s completion expectations are clear enough before UAT surfaces the gaps for you.

What the BA can do

Write a completion statement for each major feature. A completion statement is one to three sentences describing what “fully working” means for this capability, written in business language, specific enough that a business user could confirm or deny it without prompting from the delivery team. It is not a technical specification. It is the answer to: what would a business user need to see to know this is done? Get it agreed before UAT begins.

Rewrite acceptance criteria as business conditions, not system behaviours. For any story where the criteria describe what the system does rather than what must be true for the business, rewrite them. The test is simple: could a business user read this and know whether it passed, without being told by a developer? If not, the criteria are not doing their job.

Make the three levels explicit and visible. For the work currently in flight, write down what done means at each level. Story-level: this specific behaviour works, for this user, in this condition. Feature-level: this capability is complete and a business user could confirm it independently. Release-level: the project is ready to go live, covering functional completeness, data readiness, training, and support. These do not need to be long. They need to exist and be agreed by the people who will later be asked to confirm them.

Surface the release completion criteria before UAT starts. Ask directly: what must be true before this goes live? Write the answers down. Cover the functional criteria, the data requirements, the training that needs to be in place, and the support readiness. This becomes the release readiness checklist. It turns the go / no-go conversation from a negotiation into a confirmation.

Run a “could you confirm this is done?” check. For any story or feature where you are uncertain whether done is clearly defined, hand the acceptance criteria to a business user and ask whether they could confirm it is complete based on what is written. If they cannot, the criteria are not clear enough. Revise them before the work goes into development, not after it comes out of UAT.

Common mistakes

Writing longer acceptance criteria without making them sharper. Length is not the same as clarity. A long list of vague conditions is still vague.

Defining done at the story level but not at the feature or release level. Well-written story criteria are necessary. They are not sufficient. Surprises often arrive at the feature or release level, where nobody wrote anything down.

Treating shared understanding as a substitute for written completion. The team may genuinely agree on what done looks like at the start of a sprint. That agreement does not survive delivery pressure, a personnel change, or a new stakeholder joining mid-project.

Confusing “signed off” with “defined”. A stakeholder who approves a story with vague acceptance criteria has not confirmed completion. They have approved the ambiguity.

FAQ

Is this the same as the Scrum Definition of Done?
Related but different. A team’s Definition of Done typically covers technical completeness: tested, reviewed, merged. That matters. This article is about business completion — does the work deliver what the business needs, and has anyone made that explicit? Both are important. They are not the same thing.

How do I raise this without sounding like I am criticising the team?
Name it as a project risk, not a team failure. The gap is usually structural: nobody made completion explicit because nobody was asked to. A useful opening: “Before UAT starts, I want to make sure we have written down what done looks like at the feature level, so there are no surprises when the business users get in.” That is a practical proposal, not an accusation.

What if the business stakeholders cannot articulate what done looks like either?
Then you have found the real problem early, which is better than finding it in UAT. Work through it together. Ask concrete questions: what would they need to see to feel confident this is ready? What would cause them to say it is not ready? Those answers become the completion criteria.

Can this be fixed mid-delivery, or does it need to wait for the next project?
It can be fixed mid-delivery. Start with the next feature entering UAT. Write the completion statement before testing begins. Rewrite the acceptance criteria for stories still in development. Surface the release readiness criteria now, even if the release is weeks away. You cannot undo the ambiguity in already-built work, but you can stop it compounding.

What to do next

Pick one feature currently in flight. Ask one question: could a business user confirm this is done, based on what is written, without any coaching from the delivery team?

If the answer is no, that is where to start. Write the completion statement. Rewrite the acceptance criteria. Make the release readiness criteria visible. Do it before UAT begins, not after UAT surfaces the gap.

The project is not short of effort. It may be short of explicit completion. Those are different problems with different fixes.

If completion ambiguity is already building on your project, the IT Project Problem Diagnostic Checklist can help you see where else it may be accumulating before it becomes a release argument.