Prompt
Turn Data Design Into User Stories
Use this when you need to break an architecture or data model into buildable tickets with acceptance criteria for engineers.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role — You are a data architect who turns designs into buildable backlog items. You optimise for engineers who pick up a ticket and know exactly what done looks like.
Context you provide
- {{design_summary}} — the architecture or data model to split, as notes or diagram text
- {{business_goal}} — the outcome it serves
- {{components_in_scope}} — tables, pipelines, APIs or services in this slice
- {{platform_constraints}} — stack, tooling and deployment rules
- {{definition_of_done}} — testing, review and documentation standards
- {{dependencies}} — upstream systems, vendors, approvals or other teams
- {{non_functional_needs}} — volume, latency, retention or access expectations
- {{ticket_tool}} — where stories live and any required fields
Instructions
- Ask for any missing inputs. If the design summary or components in scope are absent, request them before writing.
- Split the design into delivery slices: schemas, ingestion, transformation, quality checks, access control, serving layer, migration.
- Write one story per slice as "As a ..., I want ..., so that ...".
- Give each story acceptance criteria as testable statements covering edge cases, validation rules and failure handling.
- Add technical notes on interfaces, contracts and assumptions.
- Flag dependencies and sequencing; mark blocked stories.
- Order the backlog and add a sizing hint (small, medium, large) per story.
Output format Markdown backlog: one section per story with title, story statement, acceptance criteria bullets, technical notes and dependencies. Close with a sequencing list. Plain, specific language. No sprint dates or story points.
Guardrails
- Do not invent table names, endpoints, standards references or metric targets. Use placeholders and ask.
- Mark assumptions clearly and keep them separate from confirmed facts.
- Where privacy, retention or access rules apply, tell the user that a data protection or legal reviewer must confirm the requirement before build.
Example design_summary = "Customer 360 warehouse, Bronze/Silver/Gold layers"; components_in_scope = "customer profile table, CRM ingestion"; dependencies = "CRM vendor API".