Translating user story success criteria into report requirements
Key Takeaway
Turn each acceptance criterion into a plain requirement, then map that requirement to a report setting. Watch two settings closely: the report type decides which records come back, and the dashboard's running user decides whose access controls what viewers see.
A user story says who needs something, what they need and why. Its acceptance criteria are the agreed test of when the story is done. When the need is a report or dashboard, the consultant turns the story and its criteria into specific report settings. Those settings cover which records and fields to use, how to filter, group, summarize and show them, and who can see the results.
User stories
A user story describes a user's need in simple, non-technical language: who the user is, what they need and why.
Grace is a wealth advisor. She spends every Friday morning copying client balances into a spreadsheet for her weekly review. Her user story could read: "As a wealth advisor, I want a report of my clients' balances that runs on its own every Friday, so that I can spend Friday mornings calling clients." The who is the wealth advisor. The what is a report that runs automatically. The why is more time with clients.
An undefined "who" in a user story leaves the team unsure of that user's motivations and needs, so the story will not produce the intended result. Build a list of defined personas before you write stories. Use those personas when you write, build and test.
A good user story is testable, which means anyone on the project team should understand it well enough to write acceptance criteria for it. A story that fails any INVEST check probably needs a rewrite.
While you write user stories, don't assume how they will be implemented, such as which components or services they will affect. The development or implementation team makes those decisions during its planning meetings.