BA Playbook
First Time Writing a User Story
How to turn a vague request into a story people can actually build and test.
Surya · August 15, 2026 · 8 min read · 17 practices
For New and aspiring Business Analysts writing their first user story, Junior BAs still finding their process, Product Owners writing their own stories and Delivery team members learning how requirements get written.
Someone says: "Can you create a Jira story for this?" You say sure. Then you open Jira. Blank description box. And a very simple question becomes surprisingly difficult: what exactly am I supposed to write here? If this is your first user story, start here. Because the biggest mistake is thinking you need to invent something clever. You don't. Here's the one thing to remember before anything else: a story is ready when someone else can understand it without you sitting beside them. Everything below exists to get you to that point — it's the test you're building toward, not just an item on a checklist at the end. And the mechanical part — "As a... I want... so that..." — takes twenty seconds to write. Everything else is the actual work: uncovering what that sentence should say. A user story is not something you invent. It is something you uncover. Let's do one together, from a vague request to a complete story a developer and a tester could both work from.
01Step 01
The request that already sounds like a story
"We need a download button for monthly statements" is easy to rewrite as a story. That's the trap.
Step 01
The request that already sounds like a story
"We need a download button for monthly statements" is easy to rewrite as a story. That's the trap.
The flow
Compare
What you could write immediately
As a customer, I want a download button, so that I can download my statement.
What's actually true
We don't understand the requirement yet — treat the request as a clue, not a spec.
Why it helps
That first version technically looks like a user story. It just isn't one yet. Don't write it down until you've asked a few questions first.
02Step 02
Separate the problem from the solution
A button is a proposed solution. Ask what problem it solves before you ask how it should work.
Step 02
Separate the problem from the solution
A button is a proposed solution. Ask what problem it solves before you ask how it should work.
The shift
Why it helps
Stakeholders pitch solutions because that's the language they have — "we need a button" is easier to say than "we need a process." Your job is to find the problem underneath the pitch.
03Step 03
Name the specific user
"Customers" is still too broad to design for. Not users — which users.
Step 03
Name the specific user
"Customers" is still too broad to design for. Not users — which users.
At a glance
- Retail customers?
- Corporate clients?
- Advisers?
- Internal operations users?
Why it helps
A retail banking customer checking their own statements has different needs than a support agent checking on someone else's behalf. Vague user types produce vague stories — suppose the answer turns out to be "retail banking customers using online banking": now you know who you're designing for.
04Step 04
Pin down the actual outcome
What does the user walk away with once this works?
Step 04
Pin down the actual outcome
What does the user walk away with once this works?
For the download button, it's not "a download" — it's "a copy of my statement for my own records." That distinction shapes format, retention, and access rules later. Maybe the full answer is: "They need to keep copies of their monthly statements for tax, loan and personal record purposes." Now you have the value — and the basic user story almost writes itself.
Why it helps
A story without a real outcome behind it is just a rewritten feature request. This is the piece that makes the "so that" line true instead of decorative.
05Step 05
Write the first version — and know you're not finished
The three-line story is the headline. The useful requirement lives underneath it.
Step 05
Write the first version — and know you're not finished
The three-line story is the headline. The useful requirement lives underneath it.
Why it helps
This is a perfectly reasonable user story. It's also not done. Everything from here is what turns a headline into something a team can actually build and test.
As a retail banking customer, I want to download my monthly account statements, so that I can keep copies for my personal records.
06Step 06
Add just enough context
Someone opening this ticket three months from now should understand why it exists.
Step 06
Add just enough context
Someone opening this ticket three months from now should understand why it exists.
Why it helps
You don't need to write an essay. Just give the next person enough that they don't have to track you down and ask "why are we doing this again?"
Customers can currently view recent account activity online, but older monthly statements must be requested through customer support. This creates unnecessary support requests and delays customers who need statements for record keeping.
07Step 07
Capture the business rules
The operational constraints that shape the feature — independent of any single acceptance criterion.
Step 07
Capture the business rules
The operational constraints that shape the feature — independent of any single acceptance criterion.
At a glance
- Customers can access statements for the previous 24 months.
- Statements are generated monthly.
- Only statements belonging to the logged-in customer can be accessed.
- Statements are available as PDF files.
Why it helps
None of this appeared in "we need a download button." This is why the conversation matters more than the template — a form only captures what you thought to ask about.
08Step 08
Write acceptance criteria that actually hold up
This is where most stories fail in practice, so treat it as its own discipline, not a formality.
Step 08
Write acceptance criteria that actually hold up
This is where most stories fail in practice, so treat it as its own discipline, not a formality.
At a glance
- AC1 — Given the customer is logged into online banking, when they open the Statements section, then available monthly statements from the previous 24 months are displayed.
- AC2 — Given a statement is available, when the customer selects Download, then the corresponding statement is downloaded as a PDF.
- AC3 — Given a customer requests a statement that does not belong to their account, when the request is made, then access is denied.
Checklist
- One assertion per criterion — if the "Then" clause joins two unrelated outcomes with an "and," split it into two ACs
- Make the "Then" observable and testable, not aspirational
- Write the negative and boundary cases, not just the happy path
- Avoid encoding UI decisions as acceptance criteria unless the interaction itself is the requirement
Why it helps
Now development has something concrete, QA has something testable, and you have something you can actually validate.
09Step 09
Write the unhappy paths
This is where beginner stories often stop too early.
Step 09
Write the unhappy paths
This is where beginner stories often stop too early.
Checklist
- What if the statement hasn't been generated yet?
- What if the PDF service is unavailable?
- What if there are no statements for that month?
- What if the customer has multiple accounts?
- What if the statement download fails?
Why it helps
You won't need a requirement for every imaginable scenario. But you should at least know which ones matter before development starts guessing.
10Step 10
Document the data requirements
What information does this feature actually need?
Step 10
Document the data requirements
What information does this feature actually need?
At a glance
- Customer ID
- Account ID
- Statement month
- Statement year
- Document ID
- File format
- Statement availability status
Why it helps
You're not trying to design the database. You're making sure everyone agrees on the information the feature depends on.
11Step 11
Expose the dependencies
The screen may be simple. The feature might not be.
Step 11
Expose the dependencies
The screen may be simple. The feature might not be.
At a glance
- Document Management Service
- Customer authentication
- Statement generation process
- Statement retrieval API
Why it helps
You don't need to solve all of them inside your story. You do need to know they exist before someone commits to a delivery date.
12Step 12
Draw the scope boundary explicitly
This takes thirty seconds and saves a surprising amount of confusion later.
Step 12
Draw the scope boundary explicitly
This takes thirty seconds and saves a surprising amount of confusion later.
At a glance
- Emailing statements to customers
- Statements older than 24 months
- Changing the statement PDF format
- Generating ad-hoc statements
Why it helps
Now if someone later says "I thought we were emailing them too," you have somewhere to point.
13Step 13
Know when to split it
A story that can't ship as a single unit of work isn't one story — it's several wearing a trench coat.
Step 13
Know when to split it
A story that can't ship as a single unit of work isn't one story — it's several wearing a trench coat.
Compare
One story
Customers can download statements, view them on mobile, and staff can generate them ad hoc — all in the same ticket.
Several stories wearing a trench coat
A web flow, a mobile flow, and a staff-facing exception process are three different interfaces and three different conversations.
Checklist
- By rule variation — does the same action behave differently under different business rules?
- By data source — if part of the story depends on data or a system that isn't ready, that part is a separate story
- By interface — a web flow and a mobile flow for the same outcome are usually two stories
- By happy path vs. exception handling — complex exception handling that needs its own design conversation should be split out
Why it helps
The gut check: if you can't describe the acceptance criteria in under a minute, or the story has more than about five to seven ACs, it's very likely two stories.
14Step 14
Keep your open questions visible
Don't hide unresolved questions in your notebook. Write them down instead of guessing.
Step 14
Keep your open questions visible
Don't hide unresolved questions in your notebook. Write them down instead of guessing.
At a glance
- Should statements for closed accounts remain accessible?
- Are joint accounts included?
- Is the 24-month retention period configurable?
Why it helps
A requirement with visible questions is much safer than a requirement pretending everything is already known.
15Step 15
The complete Jira story
Here's what "we need a download button" turned into.
Step 15
The complete Jira story
Here's what "we need a download button" turned into.
The hardest part wasn't writing As a... I want... So that... — that took about twenty seconds. The real work was understanding everything around it.
Why it helps
The template helps. But the questions create the requirement — this is the difference between rewriting a request and actually understanding one.
TITLE Allow customers to download monthly account statements CONTEXT Customers can currently view recent account activity online, but older monthly statements must be requested through customer support. BUSINESS PROBLEM Customers cannot independently access previous monthly statements, creating unnecessary support requests and delays. USER STORY As a retail banking customer, I want to download my monthly account statements, so that I can keep copies for my personal records. BUSINESS RULES 1. Statements are available for the previous 24 months. 2. Only statements belonging to the authenticated customer can be accessed. 3. Statements are provided in PDF format. 4. Statements are generated monthly. ACCEPTANCE CRITERIA AC1 Given the customer is logged in When they open the Statements section Then available monthly statements for the previous 24 months are displayed. AC2 Given a statement is available When the customer selects Download Then the corresponding PDF is downloaded. AC3 Given the requested statement does not belong to the authenticated customer When the request is made Then access is denied. DATA REQUIREMENTS Customer ID Account ID Statement period Document ID Statement status DEPENDENCIES Document Management Service Authentication service Statement retrieval API Statement generation process OUT OF SCOPE Email delivery Statements older than 24 months PDF redesign Ad-hoc statement generation OPEN QUESTIONS Are joint accounts included? Should statements remain accessible after an account closes? Is the 24-month period configurable?
16Step 16
Six mistakes I'd avoid on a first story
All six show up constantly, and all six are easy to catch before they ship.
Step 16
Six mistakes I'd avoid on a first story
All six show up constantly, and all six are easy to catch before they ship.
At a glance
- Writing the solution as the requirement — pause and ask what they're actually trying to accomplish.
- Making the story enormous — if it can't reasonably be built, tested and understood as one change, split it.
- Writing technical implementation too early — describe the business behaviour, let the implementation conversation happen with the people building it.
- Forgetting the unhappy path — a story that only describes success hasn't described the feature yet.
- Assuming everybody understands your story — hand it to someone who wasn't in the meeting and see if their interpretation matches yours.
- Writing acceptance criteria that describe a feeling — "intuitive" or "easy" isn't testable; describe the observable outcome instead.
Why it helps
Most of these aren't hard to fix. They're just easy to miss on your first few stories, before catching them becomes a habit.
17Step 17
Build your own readiness checklist
Before you call a story ready, run it against this.
Step 17
Build your own readiness checklist
Before you call a story ready, run it against this.
Checklist
- I understand the actual problem, not just the requested solution
- I know who the specific user is
- I understand the outcome they need
- The story describes value, not just a feature
- Business rules are captured
- Acceptance criteria are testable, single-assertion, and include negative cases
- Failure paths and exceptions are considered
- Data expectations are understood
- Dependencies are visible
- Scope boundaries are explicit
- Open questions are visible, not buried in my head
- Someone can understand this story without me in the room
Why it helps
A story that passes this list is a story someone else can pick up, build, and test without needing you in the room.
MY FIRST USER STORY CHECKLIST [ ] I understand the actual problem, not just the requested solution [ ] I know who the specific user is [ ] I understand the outcome they need [ ] The story describes value, not just a feature [ ] Business rules are captured [ ] Acceptance criteria are testable, single-assertion, and include negative cases [ ] Failure paths and exceptions are considered [ ] Data expectations are understood [ ] Dependencies are visible [ ] Scope boundaries are explicit [ ] Open questions are visible, not buried in my head [ ] Someone can understand this story without me in the room
The blank Jira box gets easier once you stop asking "What should I write?"
and start asking "What do I still need to understand?"
A user story is not something you invent. It is something you uncover. Writing "As a... I want... So that..." takes twenty seconds. Everything before it is the actual work.
Take this with you
Starter User Story Template
CONTEXT What happens today? Why does this change exist? BUSINESS PROBLEM What problem are we solving? USER STORY As a... I want... So that... BUSINESS RULES 1. 2. 3. ACCEPTANCE CRITERIA Given... When... Then... (include at least one negative or boundary case) EXCEPTIONS What happens when the normal flow fails? DATA REQUIREMENTS What information is needed? DEPENDENCIES Which systems, teams or services are involved? OUT OF SCOPE What are we deliberately not doing? OPEN QUESTIONS What still needs an answer?
Get new playbooks first.