사용자 스토리(user story)를 위한 강력한 수락 기준(acceptance criteria) 작성하기

Description

팀이 스프린트(sprint) 시작 시점에 수락 기준(acceptance criteria) 대신 테스트 케이스를 작성하고 있고, QA에서 표면화되는 이슈의 상당수가 사전에 합의되지 않은 범위 모호함에서 비롯됩니다. 이 프롬프트는 단일 스토리에 대한 명확한 수락 기준 — 테스트 가능한 통과/실패 조건, 엣지 케이스(edge case), 부정 기준(negative criteria) — 을 작성하여, 릴리즈 시점이 아닌 코드 시작 전에 팀이 '완료'에 합의하도록 합니다.

{{team_name}} 팀이 스프린트 플래닝 전에 사용자 스토리(user story)에 대한 강력한 수락 기준(acceptance criteria)을 작성하도록 돕는 시니어 프로덕트 매니저(product manager)로 행동하세요.

Story: {{user_story}}
Feature context: {{feature_context}}
Out-of-scope hints: {{out_of_scope}}

## Step 1 — 스토리 형식 확인
스토리가 표준 형식을 따르는지 검증하세요. 누락이 있다면 먼저 다시 작성하세요:
"As a [user], I want [capability] so that [outcome]."

user, capability, outcome 중 하나라도 모호하면 기준을 작성하기 전에 먼저 수정하세요. 약한 수락 기준은 거의 항상 약한 기저 스토리에서 비롯됩니다.

## Step 2 — 규칙 기반 기준 (체크리스트)
핵심 해피 패스를 다루는 6–10개의 테스트 가능한 조건을 작성하세요. 각 조건은 다음을 충족해야 합니다:
- 독립적으로 통과/실패 (한 항목에 두 테스트를 끼워 넣는 복합 절 금지)
- 팀 전체가 이미 공유하는 어휘 사용 (새 용어 금지)
- 범위 내 동작만 다룸 — HOW가 아닌 WHAT을 기술

형식:
- [ ] [Condition 1]
- [ ] [Condition 2]
- [ ] ...

## Step 3 — 시나리오 기반 기준 (Given / When / Then)
가장 위험도가 높은 2–3개 사용자 경로에 대해 Given/When/Then 시나리오를 작성하세요:

**Scenario 1: [name]**
- Given [precondition]
- When [user action or system event]
- Then [observable outcome]

전제 조건이나 결과가 정당하게 두 부분으로 구성된 경우에만 "And" 절을 추가하세요. 상태 변화의 타이밍이나 순서가 정합성을 결정할 때 Given/When/Then을 사용하세요.

## Step 4 — 엣지 케이스(edge case)와 부정 기준(negative criteria)
QA 또는 프로덕션에서 표면화될 가능성이 가장 높은 3–5개 시나리오를 나열하세요:
- 빈 값 / null 입력
- 최대 경계값 (길이, 개수, 파일 크기)
- 권한 거부 / 미인증
- 네트워크 실패 / 부분 저장
- 동시 편집 / 레이스 컨디션

이어서 엔지니어링이 조용히 범위를 확장하지 않도록 명시적인 "Out of scope for this story" 항목 2–3개를 작성하세요. 명확한 out-of-scope 목록은 충실한 in-scope 목록보다 더 많은 버그를 막습니다.

## Step 5 — Definition of Done 확인
팀의 상시 Definition of Done(테스트 작성, 문서 업데이트, 텔레메트리 출시, 접근성 점검)을 스토리가 여전히 충족하는지 확인하세요. 수락 기준은 스토리별이고, DoD는 상시 기준선입니다. 둘 다 충족되어야 합니다.

## Step 6 — 공통 이해 사인오프
스토리가 스프린트에 진입하기 전에 합의해야 하는 사람을 명시하세요:
- 엔지니어링 리드
- 디자이너
- QA
- 스토리의 user 역할에 언급된 모든 이해관계자(stakeholder)

사인오프가 산출물을 문서에서 계약으로 전환합니다.

## Output
1. 표준 형식으로 정돈된 사용자 스토리
2. 규칙 기반 체크리스트 (6–10줄)
3. 2–3개의 Given/When/Then 시나리오
4. 엣지 케이스 + 부정 기준
5. 명시적인 out-of-scope 목록
6. 사인오프 담당자
7. 미해결로 남으면 이 스토리에서 가장 큰 버그를 유발할 단 하나의 모호함

Customize This Prompt