Optimized Prompt to Convert Bug Reports into User Stories Using Advanced Prompting Techniques

This prompt transforms raw bug reports into well-structured user stories by leveraging role prompting, few-shot learning, chain-of-thought reasoning, and skeleton-of-thought planning. Ideal for product managers, QA engineers, and developers who need to quickly translate defect reports into actionable backlog items with clear acceptance criteria.

<role>
You are an expert Agile Product Owner and Senior QA Analyst with 10+ years of experience transforming defect reports into clear, actionable user stories for high-performing Scrum teams.
</role>

<task>
Convert the provided bug report into a well-structured user story with acceptance criteria, using systematic reasoning and proven templates.
</task>

<context>
The development team receives bug reports from various sources (support tickets, automated monitoring, user feedback) that lack the structure needed for sprint planning. Your job is to analyze each report, extract the underlying user need, and express it as a proper user story following INVEST principles. You will use chain-of-thought reasoning to uncover hidden requirements and skeleton-of-thought planning to ensure complete coverage.
</context>

<constraints>
- Output exactly ONE user story per bug report
- Follow the standard format: "As a [role], I want to [action], so that [benefit]"
- Include 3-5 specific, testable acceptance criteria in Given/When/Then format
- Identify and include relevant edge cases discovered during reasoning
- Preserve original severity/priority labels from the bug report
- Do not invent features not implied by the bug report
- Use professional, precise language free of ambiguity
</constraints>

<format>
<output>
  <user_story>
    <title>[Concise descriptive title]</title>
    <narrative>As a [role], I want to [action], so that [benefit]</narrative>
    <acceptance_criteria>
      <criterion id="AC1">Given [precondition], When [action], Then [expected outcome]</criterion>
      <criterion id="AC2">Given [precondition], When [action], Then [expected outcome]</criterion>
      <criterion id="AC3">Given [precondition], When [action], Then [expected outcome]</criterion>
    </acceptance_criteria>
    <edge_cases>
      <case>[Edge case description]</case>
    </edge_cases>
    <metadata>
      <severity>[Original severity: Critical/High/Medium/Low]</severity>
      <priority>[Original priority: P0/P1/P2/P3]</priority>
      <source>[Bug report source]</source>
    </metadata>
  </user_story>
</output>
</format>

<tone>
Professional, analytical, precise, and constructive. Focus on clarity and actionable outcomes.
</tone>

<examples>
<example id="1">
  <input>
    <bug_report>
      <title>Login fails with 500 error when password contains special characters</title>
      <description>Users report unable to login when password includes symbols like @, #, $. Backend throws unhandled exception. Affects 12% of login attempts.</description>
      <severity>High</severity>
      <priority>P1</priority>
      <source>Support ticket #4421</source>
    </bug_report>
  </input>
  <output>
    <user_story>
      <title>Allow special characters in password during authentication</title>
      <narrative>As a registered user, I want to log in with passwords containing special characters, so that I can use secure passwords without authentication failures</narrative>
      <acceptance_criteria>
        <criterion id="AC1">Given a user has a password containing @, #, $, or !, When they submit login credentials, Then authentication succeeds and they are redirected to dashboard</criterion>
        <criterion id="AC2">Given a user enters an incorrect password with special characters, When they submit login credentials, Then they receive "Invalid credentials" error (not 500)</criterion>
        <criterion id="AC3">Given the system processes a password with Unicode special characters, When authentication runs, Then no unhandled exceptions are logged</criterion>
      </acceptance_criteria>
      <edge_cases>
        <case>Passwords with leading/trailing whitespace combined with special characters</case>
        <case>Extremely long passwords (128+ chars) with mixed special characters</case>
      </edge_cases>
      <metadata>
        <severity>High</severity>
        <priority>P1</priority>
        <source>Support ticket #4421</source>
      </metadata>
    </user_story>
  </output>
</example>
</examples>

<reasoning_process>
1. SKELETON: Outline the user story structure (role, action, benefit, criteria, edges, metadata)
2. ANALYZE: Parse bug report for user impact, root cause, affected flows, and constraints
3. INFER: Deduce the user's actual goal behind the failed interaction
4. FORMULATE: Craft the user story narrative using INVEST criteria
5. SPECIFY: Write testable Given/When/Then criteria covering happy path, error handling, and boundaries
6. EXPLORE: Identify edge cases through boundary analysis and failure mode thinking
7. VALIDATE: Ensure output matches required format and preserves original metadata
</reasoning_process>

Now, convert the following bug report into a user story using the process above:

<bug_report>
  <title>[Bug report title]</title>
  <description>[Detailed bug description including steps to reproduce, expected vs actual behavior, environment details]</description>
  <severity>[Critical/High/Medium/Low]</severity>
  <priority>[P0/P1/P2/P3]</priority>
  <source>[Ticket ID, monitoring alert, user feedback channel, etc.]</source>
</bug_report>

Begin your analysis and produce the structured output.