Skill Hub — Business Analysis

User Story Refinement Working Skill

Turn backlog items that are too large, vague, or unbounded into sprint-ready stories with acceptance criteria, boundaries, and dependencies.

What this skill is for

This skill takes an existing user story or backlog item — written by a product owner, stakeholder, or team member — and transforms it into a structured, implementable unit. It adds acceptance criteria, identifies hidden assumptions, maps dependencies, defines boundaries, and splits stories that are too large for a single sprint. The output is a Story Brief that a development team can estimate, a tester can verify, and a product owner can defend.

When to use this skill

Sprint planning when a story is rejected as "too big" or "not ready."
Backlog refinement when acceptance criteria are missing, ambiguous, or untestable.
A story touches multiple systems (SAP, CRM, middleware) and no one knows who owns which part.
A stakeholder adds a "quick fix" to an existing story that doubles its scope.
An integration story lacks clarity on which system validates which field.
A data migration story says "move everything" without specifying cutoff, deduplication, or validation.

Real work situations

"As a sales rep, I want to create a customer in the system"

A raw story from a sales manager lacks detail on which fields are mandatory, which system creates the record (SAP S/4 vs MDG vs CRM), what validation rules apply, and what happens when a duplicate exists. Refinement must split this into: create business partner in MDG with tax validation, replicate to SAP S/4 sales area, and handle duplicate account group detection. Without refinement, developers build a UI that bypasses MDG governance and loads invalid data into SAP.

"The system should handle returns"

A product owner writes a one-line story for the returns process. Missing: the actor (customer service rep or warehouse clerk?), the trigger (customer request or goods receipt?), the boundary (does it include credit memo creation or just the return order?), and the acceptance criteria (what status must the return order reach before finance is notified?). Refinement must produce a use case-level breakdown with clear actor and system boundaries, splitting credit memo creation into a separate story if it crosses into FI.

"Improve order processing speed"

A stakeholder asks to "make order processing faster." The raw story lacks a metric (from what baseline to what target?), a system boundary (SAP VA01? IDoc processing? E-commerce checkout?), and a scenario (all order types or just standard ZOR?). Refinement must reframe the story as: "Reduce average SAP S/4 sales order creation time (VA01) for standard order type ZOR from 45 seconds to under 10 seconds for orders with 20 line items or fewer, measured under peak load conditions." Without this, the team optimizes the wrong layer and misses the real bottleneck.

Inputs required

Raw user stories or backlog items from the current sprint or product backlog.
Sprint context: team velocity, sprint goal, and known capacity.
System documentation showing which systems, transactions, and fields are involved.
Business rules or validation logic that constrain the story.
List of known dependencies: other stories, system upgrades, external APIs, data availability.
Stakeholder availability to confirm boundaries and acceptance criteria.
Non-functional requirements: performance, security, compliance constraints.

Questions to ask

What is the smallest version of this story that still delivers value to the user?
What must be true before this story can start: data readiness, system availability, another story completed?
Which system owns the data creation, and which system owns the validation?
What happens when the happy path fails: missing data, duplicate record, system timeout?
Who will confirm this story is done, and what will they look at?
What is explicitly not included in this story? What would a reasonable person assume is included but should not be?
If this story were completed in two days instead of two weeks, what would be cut?
Which fields, tables, or transactions must be present for this story to execute correctly?

Working method

Read the raw story. Identify the actor, the need, and the intended outcome. If any are missing, flag the story as unready.
Identify missing elements. Check for: acceptance criteria, boundaries, dependencies, assumptions, non-functional requirements, and owner.
Split if the story is too large. If it touches multiple systems, spans multiple process steps, or cannot be completed in one sprint, split it into smaller stories that each deliver a coherent increment.
Write acceptance criteria. Use Given/When/Then format. Include at least one normal case, one boundary case, and one error case.
Identify dependencies. List other stories, systems, data, or decisions that must be ready before this story can be implemented or tested.
Surface hidden assumptions. Document what the story assumes about data quality, system behavior, user knowledge, or external conditions.
Define boundaries. State what is in scope and what is out of scope for this story. Link boundaries to business rules and process ownership.
Package into a Story Brief. One brief per refined story. Include the refined statement, acceptance criteria, dependencies, assumptions, boundaries, and estimation notes.
Validate with the product owner. Walk through the brief and confirm that the refined story still matches the original intent.

Decision rules

If a story has no acceptance criteria, it is not ready for sprint planning.
If a story touches more than one system and there is no integration contract, split the story or add a dependency on contract definition.
If a story describes a solution ("add a button"), separate the underlying need from the proposed implementation.
If a story cannot be completed within one sprint, split it. The split must be vertical (end-to-end slice) rather than horizontal (layer by layer).
If a dependency has no owner or delivery date, the story is at risk — flag it before commitment.
If a stakeholder asks to add scope during refinement, require a formal decision: swap out existing scope, extend the sprint, or create a new story.
If acceptance criteria contain implementation instructions ("use table X"), rewrite them as outcomes ("data is available in table X").

Deliverables

Story Brief — One per refined story. Contains refined statement, acceptance criteria, dependencies, assumptions, boundaries, and estimation notes. See template below.
Dependency List — Table of dependencies with owner, status, and risk level.
Assumptions Log — List of assumptions with validation plan and risk if false.
Sprint Ready Checklist — Per-story verification before commitment.

Templates

Story Brief (compact)

---
artifact: Story Brief
id: STORY-001
source: Backlog item | Stakeholder request | Incident
status: draft | refined | ready | committed
---

## Refined story statement


## Acceptance criteria
### Normal case
Given <precondition>
When <action>
Then <expected outcome>

### Boundary case
Given <precondition>
When <action>
Then <expected outcome>

### Error case
Given <precondition>
When <action>
Then <expected outcome>

## Dependencies

- Dependency: <description> | Owner: <name> | Status: <status> | Risk: <level>

## Assumptions

- Assumption: <description> | Validation: <method> | Risk if false: <impact>

## Boundaries
### In scope


### Out of scope


## Estimation notes


## Product owner

Quality checklist

Every story has at least one acceptance criterion written in Given/When/Then format.
Every story has a named product owner who can confirm intent.
Dependencies are identified with owner and expected delivery date.
Assumptions are separated from facts and have a validation plan.
Boundaries are stated explicitly: what is in scope and what is out of scope.
Stories are sized to fit within one sprint.
No acceptance criterion contains implementation detail or solution design.

Common mistakes

Refining without splitting. Consequence: the story is too large for a sprint, carries hidden work, and fails to deliver at the review boundary.
Adding implementation detail instead of acceptance criteria. Consequence: the team is constrained to a specific technical solution that may be suboptimal.
Skipping boundary definition. Consequence: stakeholders assume scope that was never agreed, leading to mid-sprint scope creep and estimation failure.
Ignoring dependencies until the sprint starts. Consequence: the team discovers on day two that the API is not ready or the data is missing, blocking progress.
Treating assumptions as facts. Consequence: the story fails because the assumed data quality or system behavior does not match reality.

Weak output vs Strong output

Weak output — Generic story with no structure

A weak AI output restates the raw story with vague qualifiers and no actionable detail:

Refined story: As a user, I want the system to process orders faster so that I can work better.

Acceptance criteria:

The system should be fast.

The system should handle errors gracefully.

The system should be user-friendly.

Dependencies: None identified.

Owner: TBD.

Why this is weak: No metric for "fast." No boundary for which order types or systems. No owner. No testable criteria. No next action. A developer cannot build against this, and a tester cannot verify it.

Strong output — Sprint-ready Story Brief

A strong AI output produces a copy-paste-ready artifact with specific evidence, boundaries, and next actions:

---
artifact: Story Brief
id: STORY-O2C-042
source: Backlog refinement — sales ops request
status: refined
---

## Refined story statement
As a sales operations specialist, I want SAP S/4 to block outbound delivery creation (VL01N) for customers with exceeded credit limits so that unauthorized shipments do not occur.

## Acceptance criteria
### Normal case
Given a customer with an open credit limit of 50,000 EUR and current exposure of 48,000 EUR
When a new standard order (ZOR) of 5,000 EUR is created and delivery is attempted
Then the system blocks delivery creation with status "Credit block" and routes the case to the credit controller worklist (UKM_CASE)

### Boundary case
Given a customer with exceeded credit limit
When an emergency order marked "Express" under 1,000 EUR is created
Then the system allows delivery with a warning, logs to audit, and notifies the credit controller within 15 minutes

### Error case
Given a customer with missing credit segment (UKM_BP)
When a delivery is attempted
Then the system blocks delivery, logs error "Credit segment missing," and routes to the MDG data steward

## Dependencies
- Dependency: Credit limit update job runs every 4 hours | Owner: Basis team | Status: planned | Risk: medium
- Dependency: UKM_CASE worklist configuration complete | Owner: SD consultant | Status: in progress | Risk: low

## Assumptions
- Assumption: Customer credit limits are maintained in FD32 and replicated to UKM_BP in real time.
  Validation: Check UKM_BP for 10 sample customers before sprint start. | Risk if false: blocks will be incorrect.
- Assumption: Emergency orders are flagged by order reason code "EXP" in VBAK-AUGRU.
  Validation: Confirm with sales ops that this code is used consistently. | Risk if false: boundary case cannot be tested.

## Boundaries
### In scope
- Standard order type ZOR
- Delivery creation via VL01N and VL10
- Credit block status and routing to UKM_CASE

### Out of scope
- Credit memo creation or billing block logic
- Customer master creation or MDG change requests
- Other order types (ZOR2, ZCR)

## Estimation notes
- 8 story points. Complexity: medium. Integration with UKM_CASE requires SD-FI alignment.

## Product owner
- Maria Chen, Sales Operations Manager

Why this is strong: It names the actor, the system, the transaction, the order type, the specific threshold, the routing destination, and the boundary cases. It includes dependencies with owners and a validation plan for assumptions. A developer can build it, a tester can verify it, and the product owner can sign off.

Agent instructions

AI Prompt Pattern

"You are a backlog refinement assistant. You receive a raw user story and the following context: [system name, involved transactions, sprint length, team velocity, known constraints]. Produce a Story Brief with: Refined Story Statement (As a/I want/so that), Acceptance Criteria (Given/When/Then for normal, boundary, and error cases), Dependencies (with owner and status), Assumptions (with validation method), and explicit Boundaries (in scope and out of scope). If information is missing, flag it. Do not add implementation detail. Do not invent owners or system names."

When using this skill, an AI agent must:

Gather system context before refining. Know which transactions, tables, and systems are involved before writing acceptance criteria.
Use Given/When/Then format for all acceptance criteria. Be specific about preconditions, actions, and outcomes.
Split stories that touch multiple systems or process steps. Vertical slices only.
Flag missing information instead of guessing. If an actor, owner, or field name is unknown, state it as an open question.
Separate the need from the proposed solution. If the raw story says "add a button," ask what problem the button solves.
Produce one Story Brief per story. Do not bundle multiple stories into one brief.
Do not write acceptance criteria that contain implementation instructions. Criteria state what must be true, not how to build it.
Link to Atlas diagnostics when stories relate to SAP processes. For example, credit management stories should reference SAP Credit Management Diagnostics.

Related skills

Related Atlas pages

Order to Cash — Process context for O2C user stories.
SAP Process Audit — Diagnostic context for process-related story boundaries.

Verification status and limitations

This skill is a public working interpretation of user story refinement practices. It is not official Scrum Guide or BABOK documentation. It focuses on enterprise and SAP contexts where stories must account for system boundaries, integration dependencies, and data governance.

Known limitations: the skill assumes the raw story exists and that the product owner is available for validation. In environments with no product owner or no backlog discipline, this skill cannot create readiness from chaos. It does not cover formal requirements engineering or model-driven specification methods.