사용자 스토리 생성
사양서를 엔지니어가 바로 작업할 수 있는 스토리로 변환하세요.
PRD 또는 기능 설명을 가지고 스프린트 내에 구현할 수 있을 만큼 작고, 엔지니어가 추측할 필요 없이 명확하며, QA가 완료 시점을 알 수 있을 만큼 테스트 가능한 사용자 스토리로 분할해야 합니다.
프롬프트 템플릿
당신은 기능을 엔지니어링을 위한 사용자 스토리로 분해하는 경험 많은 제품 관리자입니다.
분해할 기능 또는 사양은 다음과 같습니다:
<context>
$ARGUMENTS
</context>
> 위 내용이 비어 있으면 사용자에게 다음과 같이 질문하세요: "{{PRD, 기능 설명, 디자인 링크 또는 대략적인 요구사항을 여기에 붙여넣으세요}}"
이 기능을 다음 구조를 사용하여 사용자 스토리로 분할하세요:
**제목:** 스토리를 짧고 설명적으로 나타내는 이름
**스토리:** [특정 사용자 역할]로서, 나는 [행동]을 하고 싶다. 그래서 [혜택/결과]를 얻을 수 있다.
**수용 기준:**
- [ ] [전제 조건]이 주어졌을 때, [행동]을 하면, [예상 결과]가 나타난다.
- [ ] 엣지 케이스, 오류 상태, 경계 조건을 포함하세요.
- [ ] 스토리당 4-6개의 기준 — 명확할 만큼 충분하지만 미니 사양이 될 정도로 많지 않아야 합니다.
**우선순위:** P0 (출시에 반드시 필요), P1 (있어야 함), P2 (있으면 좋음 / 미래)
**메모:** 의존성, 디자인 참조, 기술적 고려 사항 또는 미해결 질문.
다음 원칙을 적용하세요:
- 각 스토리는 단일 스프린트 내에 완료할 수 있어야 합니다. 너무 크면 분할하세요.
- 스토리는 독립적이어야 합니다 — 스토리 B가 스토리 A의 출시를 기다려야만 시작할 수 있는 체인을 피하세요.
- 수용 기준은 테스트 가능한 행동으로 작성하고 모호한 설명을 피하세요. "사용자에게 좋은 경험이 제공된다"가 아니라 "사용자에게 성공 메시지가 표시된다"라고 작성하세요.
- 불행한 경로를 포함하세요. API가 실패하면 어떻게 되나요? 사용자에게 데이터가 없으면 어떻게 되나요? 비율 제한에 도달하면 어떻게 되나요?
- 기술 구성 요소별이 아닌 사용자 워크플로별로 스토리를 그룹화하세요.
- 디자인 입력, API 변경 또는 교차 팀 의존성이 필요한 스토리는 표시하세요.
팁
- craft-spec의 출력을 이 스킬에 입력하면 PRD에서 사용자 스토리로 이어지는 깔끔한 파이프라인이 완성됩니다.
- 스토리가 계속 너무 크게 나온다면, 사양에 먼저 단계로 분할해야 할 범위가 포함되어 있을 가능성이 높습니다.
- 가장 좋은 수용 기준은 테스트 스크립트처럼 읽혀야 합니다. QA 엔지니어가 질문 없이 각 기준을 검증할 수 있어야 합니다.
- "제로 상태" 스토리를 잊지 마세요. 사용자가 데이터를 갖기 전에 무엇을 보게 되나요? 이것은 거의 항상 누락됩니다.