# BA User Story Template

> Use this as a toolbox, not a form. Include only the sections that help remove ambiguity.

## User Story

**As a:**  
[role]

**I want:**  
[capability]

**So that:**  
[business outcome]

## Context

[What happens today?]

## Problem

[Why does it matter?]

## Expected Behaviour

[What should happen after the change?]

## Acceptance Criteria

### AC1

**Given** [condition]  
**When** [event/action]  
**Then** [expected behaviour]

### AC2

**Given** [condition]  
**When** [event/action]  
**Then** [expected behaviour]

## Business Rules

- BR-01:
- BR-02:

## Data Requirements

- **Data:**
- **Source:**
- **Validation:**
- **Fallback behaviour:**

## Dependencies

- 

## Assumptions

- 

## Out of Scope

- 

## Open Questions

- 

## Decisions

- **Decision:**
- **Owner:**
- **Reason:**

---

## Before You Move It to Ready

- [ ] Do we know **who** needs this?
- [ ] Do we understand **why**?
- [ ] Is the expected behaviour clear?
- [ ] Can QA test it?
- [ ] Are important business rules visible?
- [ ] Do we know the relevant systems and data?
- [ ] Are dependencies visible?
- [ ] Are assumptions written down?
- [ ] Is out-of-scope clear?
- [ ] Are open questions visible?
- [ ] Do we know who owns key decisions?

**Remember:** A good user story is not the requirement. It is the container for the conversation that turns a requirement into something buildable.