Writing Clear Work Items: Stories, Acceptance Criteria and Done

How business teams can turn vague requests into clear work using user stories, acceptance criteria, the INVEST check and a shared Definition of Done.

Agileaf · Last reviewed October 22, 2026 · 6 min read

"Update the onboarding process." "Refresh the website." "Sort out the vendor contracts." Requests like these land on business teams every week. Each one sounds clear to the person who wrote it, and each one hides a dozen questions: for whom, by when, how much, and how will we know it's finished?

Agile teams in software developed simple habits for turning vague requests into clear pieces of work: user stories, acceptance criteria, and a shared definition of "done." None of these depend on code. They work just as well for a recruiting campaign, a policy update or a month-end close task.

This guide explains each habit, where it came from, and how to adapt it for business work without drowning in paperwork.

Why Work Items Go Wrong

Most unclear work items fail in one of three ways:

The purpose is missing. The team knows what to do but not why, so it can't make sensible trade-offs.
The finish line is fuzzy. Work bounces back and forth because the requester had something different in mind.
The item is too big. "Launch the new benefits program" sits in progress for months, and nobody can tell whether it's on track.

The practices below tackle each of these in turn.

User Stories: Who, What and Why

Martin Fowler describes user stories as "chunks of desired behavior" used to break a large amount of work into smaller pieces for planning. He credits Kent Beck with introducing the term as part of Extreme Programming, to encourage a more conversational style of gathering requirements than long written specifications.

A common format, as Fowler notes, is "As a … I want … so that …" The "as a" names who wants it, "I want" describes what, and "so that" explains why. Fowler points out that the "so that" part gives important context, helping the team move from what the customer thinks they want to what they actually need.

Here are hypothetical business examples:

As a new hire, I want my laptop and accounts ready on my first morning so that I can start training on day one.
As a regional sales manager, I want a one-page summary of last quarter's returns by product so that I can decide which lines to discuss with customers.
As a volunteer coordinator, I want shift reminders sent two days in advance so that fewer shifts go unfilled.

The template is a tool, not a rule. Some work, such as "renew the liability insurance policy," doesn't benefit from a persona. What matters is that the item states who benefits and why.

Card, Conversation, Confirmation

Ron Jeffries, co-author of the book Extreme Programming Installed, described three critical aspects of a user story in a 2001 article: Card, Conversation, and Confirmation.

Card: the written item is only a token. In Jeffries' words, it has "just enough text to identify the requirement, and to remind everyone what the story is."
Conversation: the real requirement is communicated by talking, over time, between the people asking and the people doing.
Confirmation: the agreed checks that show the work meets the need. Jeffries calls this the acceptance test.

For business teams, this is a useful corrective to two opposite habits: the one-line request with no discussion, and the ten-page brief nobody reads. Keep the card short, talk it through, then write down how you'll confirm it's right.

Writing Acceptance Criteria

Acceptance criteria are the "confirmation" part: specific conditions that must be true for this particular item to be accepted. Good criteria are:

Observable: someone other than the author could check them.
Outcome-focused: they say what must be true, not how to do the work.
Agreed before work starts: so they guide the work rather than judge it afterward.

A simple checklist works for most business items. For the new-hire story above:

Laptop is imaged, labeled and on the new hire's desk (or shipped) by 5 p.m. the day before the start date.
Email, chat and HR system accounts are active and tested.
A welcome message with first-day schedule has been sent.

For items with rules or conditions, some teams use the Given-When-Then style. Fowler describes it as an approach developed by Daniel Terhorst-North and Chris Matts as part of Behavior-Driven Development. "Given" describes the starting situation, "When" the action, and "Then" the expected result. A hypothetical finance example: Given a vendor invoice under the approval threshold that matches a purchase order, when it is submitted, then it is routed straight to payment without manager review.

A Quick Quality Check: INVEST

Bill Wake, who developed the INVEST acronym, explained it in a 2003 article on the qualities of good stories. Translated for business work:

Independent: can be done in any order, without waiting on other items where possible.
Negotiable: captures the essence; details are worked out together.
Valuable: delivers something a customer or stakeholder actually values.
Estimable: understood well enough to judge roughly how big it is.
Small: Wake wrote that stories typically represent at most a few person-weeks of work, and that some teams restrict them to a few person-days.
Testable: Wake notes that writing a story carries an implicit promise that you understand it well enough to write a test for it.

If an item fails the "testable" check, Wake suggests it may not be clear enough, may not reflect something valuable, or the requester may need help defining success.

Splitting Big Items

Large items are where most delays hide. Wake's advice for software applies well beyond it: slice so that each piece delivers something valuable on its own, rather than splitting by activity.

Suppose a hypothetical HR team is asked to "launch the new benefits portal." Splitting by activity gives "write content," "configure portal," "train staff," none of which helps employees until all are done. Splitting by value might give: "Employees at one office can view their current benefits," then "employees at one office can change dental coverage," then expand to all offices. Each slice can be tested with real people and adjusted.

The Scrum Guide calls this ongoing work refinement: "breaking down and further defining Product Backlog items into smaller more precise items."

Acceptance Criteria Versus the Definition of Done

These two ideas are easy to confuse. Acceptance criteria are specific to one item. A Definition of Done applies to every item of a given kind.

The Scrum Guide describes the Definition of Done as "a formal description of the state of the Increment when it meets the quality measures required for the product." It says the definition creates transparency by giving everyone a shared understanding of what was completed, and that an item that doesn't meet it cannot be released or even presented at the Sprint Review.

A hypothetical marketing team's Definition of Done for any published piece might include:

Proofread by someone other than the author.
Links and forms tested.
Images have alt text.
Required brand or legal approvals recorded.
Final files saved in the shared drive.

Write it once, post it near your board, and revise it in retrospectives. For a broader look at boards and pulling work, see our guide to Kanban for any team.

Key takeaways

A clear work item states who benefits, what is needed and why; the "so that" clause guides trade-offs.
Treat the written item as a reminder of a conversation, then record how you'll confirm the work is right.
Acceptance criteria should be observable, outcome-focused and agreed before work begins.
Use INVEST as a quick check, and split big items into thin slices that each deliver value.
Keep a separate, team-wide Definition of Done for quality steps that apply to every item.

Sources

Spotted something out of date? Let us know.