5 exercises on reading user stories in depth — identify scope, analyse acceptance criteria, spot missing information (auth gaps, error states), and understand Definition of Done.
User story anatomy
As a [persona] — who the feature serves
I want to [goal] — the action or capability they need
So that [benefit] — the business or user value delivered
Acceptance Criteria — testable conditions that define "it works"
Out of Scope — explicit exclusions to prevent scope creep
Definition of Done — checklist before the ticket can be closed
0 / 5 completed
1 / 5
📖User Story DASH-312
TICKET: DASH-312
Type: Story
Priority: Medium
Epic: DASH-200 (Analytics Dashboard — Q2)
Title: Export dashboard data to CSV
User Story:
As a business analyst,
I want to export the current dashboard view to a CSV file,
so that I can perform further analysis in Excel without manually copying data.
Acceptance Criteria:
AC1. An "Export to CSV" button appears in the top-right corner of the dashboard
AC2. Clicking the button exports only the data currently visible in the dashboard
(respecting active filters and date range)
AC3. The CSV file is named: dashboard-export-YYYY-MM-DD.csv
AC4. The export includes all columns displayed in the current view, in the same order
AC5. Large datasets (up to 100,000 rows) must export within 10 seconds
AC6. The export button is disabled and shows a loading spinner while the export is in progress
Out of Scope (explicitly excluded):
- Export to Excel (.xlsx) format
- Scheduled/automated exports
- Export of hidden or filtered-out columns
Definition of Done:
- Unit tests cover CSV generation logic
- E2E test verifies: filter data → click export → file downloaded with correct rows
- Tested on Chrome, Firefox, Safari (latest)
- UX reviewed and approved by product designer
Read the user story. A developer proposes also adding an "Export to Excel (.xlsx)" format since it shares most of the same logic. Based on the ticket, should this be included?
No — "Out of Scope" sections are explicit exclusions; ignore them at your own risk.
The story explicitly lists: "Export to Excel (.xlsx) format" as out of scope. This is not an oversight — product managers and business analysts include "Out of Scope" sections precisely to prevent scope creep.
Why product managers exclude things explicitly:
xlsx generation requires a different library (e.g., SheetJS) — different dependency and complexity
The sprint was scoped for CSV only — adding xlsx would require re-estimating the story points
There may be a separate ticket (not yet created) for xlsx in a future sprint
What to do instead: Raise a new ticket (e.g., DASH-390: "Export dashboard to Excel (.xlsx)") and link it to DASH-312. This keeps the current story deliverable on schedule and the future work tracked.
Scope creep vocabulary:
gold-plating — adding unrequested features
scope creep — the gradual expansion of a project beyond its agreed boundaries
out of scope — explicitly excluded; requires a separate ticket
story points — effort estimate that scope additions affect
2 / 5
📖User Story DASH-312
TICKET: DASH-312
Type: Story
Priority: Medium
Epic: DASH-200 (Analytics Dashboard — Q2)
Title: Export dashboard data to CSV
User Story:
As a business analyst,
I want to export the current dashboard view to a CSV file,
so that I can perform further analysis in Excel without manually copying data.
Acceptance Criteria:
AC1. An "Export to CSV" button appears in the top-right corner of the dashboard
AC2. Clicking the button exports only the data currently visible in the dashboard
(respecting active filters and date range)
AC3. The CSV file is named: dashboard-export-YYYY-MM-DD.csv
AC4. The export includes all columns displayed in the current view, in the same order
AC5. Large datasets (up to 100,000 rows) must export within 10 seconds
AC6. The export button is disabled and shows a loading spinner while the export is in progress
Out of Scope (explicitly excluded):
- Export to Excel (.xlsx) format
- Scheduled/automated exports
- Export of hidden or filtered-out columns
Definition of Done:
- Unit tests cover CSV generation logic
- E2E test verifies: filter data → click export → file downloaded with correct rows
- Tested on Chrome, Firefox, Safari (latest)
- UX reviewed and approved by product designer
Acceptance Criterion AC5 states: "Large datasets (up to 100,000 rows) must export within 10 seconds." What type of requirement is AC5, and why is it important to include it in the ticket?
AC5 is a non-functional (performance) requirement — it constrains how the feature performs.
Requirements are divided into:
Functional requirements — what the system does: "export button appears", "CSV named dashboard-export-YYYY-MM-DD.csv". These define behaviour.
Non-functional requirements (NFRs) — how the system performs: speed, reliability, security, scalability. AC5 is an NFR: it says the export must complete within 10 seconds for up to 100k rows.
Why including NFRs in tickets matters:
Without AC5, a developer might implement a synchronous CSV export that blocks the UI and times out for large datasets — technically "working" but unusable in production
A 10-second target tells the developer to use streaming/chunking or a background job approach from the start
QA can write a specific performance test: load 100k rows, trigger export, assert completion within 10s
TICKET: DASH-312
Type: Story
Priority: Medium
Epic: DASH-200 (Analytics Dashboard — Q2)
Title: Export dashboard data to CSV
User Story:
As a business analyst,
I want to export the current dashboard view to a CSV file,
so that I can perform further analysis in Excel without manually copying data.
Acceptance Criteria:
AC1. An "Export to CSV" button appears in the top-right corner of the dashboard
AC2. Clicking the button exports only the data currently visible in the dashboard
(respecting active filters and date range)
AC3. The CSV file is named: dashboard-export-YYYY-MM-DD.csv
AC4. The export includes all columns displayed in the current view, in the same order
AC5. Large datasets (up to 100,000 rows) must export within 10 seconds
AC6. The export button is disabled and shows a loading spinner while the export is in progress
Out of Scope (explicitly excluded):
- Export to Excel (.xlsx) format
- Scheduled/automated exports
- Export of hidden or filtered-out columns
Definition of Done:
- Unit tests cover CSV generation logic
- E2E test verifies: filter data → click export → file downloaded with correct rows
- Tested on Chrome, Firefox, Safari (latest)
- UX reviewed and approved by product designer
The "As a business analyst, I want to... so that..." format describes the persona, goal, and benefit. What missing information would a developer most reasonably ask about before starting implementation?
Authentication and authorisation on the export is a genuine gap — the story does not address it.
The story describes a "business analyst" as the persona but does not specify:
Should unauthenticated users be able to export? (Very likely: no — dashboards show business data)
Are there role-based restrictions? (e.g., only Analyst and Admin roles can export)
Should the export respect data visibility rules? (e.g., user A cannot export data that user B owns)
Why this matters for implementation: If an engineer implements the CSV export endpoint without an auth check, any user (or malicious party) who discovers the URL could download the full dataset. This is a security vulnerability.
Good questions to ask before starting:
"Does the export require the user to be logged in?"
"Are there role restrictions on who can export?"
"Should the exported data be filtered by the current user's permissions?"
Other common gaps in user stories:
Error states (what if export fails?)
Empty state (what if no data matches the filter?)
Rate limiting (can a user trigger 100 exports per minute?)
TICKET: DASH-312
Type: Story
Priority: Medium
Epic: DASH-200 (Analytics Dashboard — Q2)
Title: Export dashboard data to CSV
User Story:
As a business analyst,
I want to export the current dashboard view to a CSV file,
so that I can perform further analysis in Excel without manually copying data.
Acceptance Criteria:
AC1. An "Export to CSV" button appears in the top-right corner of the dashboard
AC2. Clicking the button exports only the data currently visible in the dashboard
(respecting active filters and date range)
AC3. The CSV file is named: dashboard-export-YYYY-MM-DD.csv
AC4. The export includes all columns displayed in the current view, in the same order
AC5. Large datasets (up to 100,000 rows) must export within 10 seconds
AC6. The export button is disabled and shows a loading spinner while the export is in progress
Out of Scope (explicitly excluded):
- Export to Excel (.xlsx) format
- Scheduled/automated exports
- Export of hidden or filtered-out columns
Definition of Done:
- Unit tests cover CSV generation logic
- E2E test verifies: filter data → click export → file downloaded with correct rows
- Tested on Chrome, Firefox, Safari (latest)
- UX reviewed and approved by product designer
AC6 states: "The export button is disabled and shows a loading spinner while the export is in progress." Why is this acceptance criterion included — what problem does it prevent?
TICKET: DASH-312
Type: Story
Priority: Medium
Epic: DASH-200 (Analytics Dashboard — Q2)
Title: Export dashboard data to CSV
User Story:
As a business analyst,
I want to export the current dashboard view to a CSV file,
so that I can perform further analysis in Excel without manually copying data.
Acceptance Criteria:
AC1. An "Export to CSV" button appears in the top-right corner of the dashboard
AC2. Clicking the button exports only the data currently visible in the dashboard
(respecting active filters and date range)
AC3. The CSV file is named: dashboard-export-YYYY-MM-DD.csv
AC4. The export includes all columns displayed in the current view, in the same order
AC5. Large datasets (up to 100,000 rows) must export within 10 seconds
AC6. The export button is disabled and shows a loading spinner while the export is in progress
Out of Scope (explicitly excluded):
- Export to Excel (.xlsx) format
- Scheduled/automated exports
- Export of hidden or filtered-out columns
Definition of Done:
- Unit tests cover CSV generation logic
- E2E test verifies: filter data → click export → file downloaded with correct rows
- Tested on Chrome, Firefox, Safari (latest)
- UX reviewed and approved by product designer
The Definition of Done includes: "UX reviewed and approved by product designer." What does this requirement imply about the development process for this ticket?
Definition of Done (DoD) is a checklist — every item must be complete before "Done" can be declared.
The DoD is a Scrum concept: a shared team agreement on what "done" means for any ticket. It typically includes:
Code written and reviewed (PR approved)
Tests written and passing
Deployed to staging/test environment
Product/design review signed off
Documentation updated (if required)
What "UX reviewed and approved by product designer" means in practice:
The developer implements the feature (button position, spinner, disabled state)
The designer reviews it in the staging environment (or a Figma prototype comparison)
The designer either approves or raises a list of changes (e.g., "button should be secondary colour, not primary")
Only after designer approval can the ticket move to "Done"
Why DoD exists: Without a DoD, "done" means different things to different people. One developer says "done" when code is written; another says "done" when it is deployed to production. DoD removes ambiguity.