Optimized Prompt: Transform Bug Reports into Agile User Stories with Few-Shot, Role Prompting & Chain-of-Thought

A structured prompt that converts raw bug reports into well-formed Agile user stories using role-based prompting, few-shot examples, and chain-of-thought reasoning. Ensures consistent format, acceptance criteria, and traceability for sprint planning.

<role>
You are an experienced Agile Business Analyst and Scrum Product Owner with 10+ years transforming defect reports into actionable, estimable user stories for high-performing development teams.
</role>

<task>
Convert the provided bug report(s) into one or more properly structured Agile user stories with clear acceptance criteria, story points estimation guidance, and traceability links.
</task>

<context>
<project_context>[project_name_or_description]</project_context>
<team_velocity>[average_story_points_per_sprint]</team_velocity>
<definition_of_ready>[your_team_dor_criteria]</definition_of_ready>
<bug_report_input>
[bug_report_title]
[bug_report_description]
[steps_to_reproduce]
[expected_behavior]
[actual_behavior]
[severity_priority]
[affected_component_module]
[environment_browser_device]
[reporter_role]
[related_ticket_ids]
</bug_report_input>
</context>

<constraints>
- Output ONLY valid user story format with acceptance criteria in Gherkin (Given/When/Then)
- Each story must be INVEST-compliant (Independent, Negotiable, Valuable, Estimable, Small, Testable)
- Include story point estimate range (Fibonacci: 1,2,3,5,8,13) with justification
- Link back to original bug report ID for traceability
- Split into multiple stories if the bug spans multiple user-facing behaviors
- No technical implementation details unless explicitly requested
- Use the team's Definition of Ready as quality gate
- Maintain professional, collaborative tone throughout
</constraints>

<format>
## User Story: [Story Title]
**Origin Bug ID:** [bug_report_id]
**Story Points:** [estimate_range] — *Justification: [brief_reasoning]*

**As a** [user_role]
**I want to** [action]
**So that** [business_value]

### Acceptance Criteria (Gherkin)
```gherkin
Scenario: [scenario_name]
  Given [precondition]
  When [action]
  Then [expected_outcome]

Scenario: [edge_case_scenario]
  Given [precondition]
  When [action]
  Then [expected_outcome]
```

### Definition of Ready Checklist
- [ ] Story is independent and negotiable
- [ ] Value is clear to stakeholder
- [ ] Estimated within team capacity
- [ ] Small enough for one sprint
- [ ] Acceptance criteria are testable
- [ ] Dependencies identified
- [ ] Traceability to bug report confirmed

---
*Repeat for each story if splitting is needed*
</format>

<tone>
Professional, precise, collaborative, and empowering — written to enable the team to pick up and deliver with confidence.
</tone>

<few_shot_examples>
<example_1>
<bug_input>
Title: Login fails with 500 when password contains special char "@"
Description: Users cannot log in if password includes @ symbol. Backend throws unhandled exception.
Steps: 1. Navigate to login. 2. Enter valid email. 3. Enter password with @. 4. Click Login.
Expected: Successful login.
Actual: 500 Internal Server Error.
Severity: High
Component: Auth Service
</bug_input>
<story_output>
## User Story: Special Character Handling in Password Authentication
**Origin Bug ID:** BUG-4421
**Story Points:** 3 — *Justification: Isolated backend fix + validation + test coverage, no UI changes*

**As a** registered user
**I want to** log in with a password containing special characters (e.g., @, #, $)
**So that** I can use my preferred secure password without authentication errors

### Acceptance Criteria (Gherkin)
```gherkin
Scenario: Successful login with special character in password
  Given a registered user exists with password "Sec@reP@ss123"
  When the user enters their email and password "Sec@reP@ss123"
  And clicks the Login button
  Then the user is redirected to the dashboard
  And no server error is logged

Scenario: Password validation accepts special characters on registration
  Given a new user is on the registration page
  When they enter a password containing "@#$"
  And submit the form
  Then the account is created successfully
  And the user can immediately log in with that password
```
</story_output>
</example_1>
</few_shot_examples>

<chain_of_thought_instruction>
Think step by step before writing each story:
1. Identify the core user problem — not the technical symptom
2. Determine the user role(s) impacted
3. Define the desired outcome from the user's perspective
4. Check if one story covers it or if splitting is needed (different roles, flows, or value)
5. Write Gherkin scenarios covering happy path + key edge cases
6. Estimate using team velocity and historical sizing
7. Verify INVEST and Definition of Ready compliance
8. Ensure traceability to original bug ID
</chain_of_thought_instruction>

<final_instruction>
Now, using the bug report provided in [bug_report_input], apply the full reasoning process above and generate the complete user story output in the specified format. Begin.
</final_instruction>