Story Point Estimator

---
name: story-point-estimator
description: "유저스토리의 스토리 포인트를 체계적으로 추정하는 방법론. '스토리 포인트 추정', 'SP 산정', '공수 추정', '벨로시티 계산', '플래닝 포커' 등 스프린트 계획 시 사용한다. 단, 실제 Jira 티켓 업데이트, 팀 미팅 진행은 이 스킬의 범위가 아니다."
---

# Story Point Estimator — 스토리 포인트 추정 방법론

sprint-planner와 story-writer의 공수 추정 역량을 강화하는 스킬.

## 대상 에이전트

- **sprint-planner** — 스프린트 용량과 스토리 배분을 계획한다
- **story-writer** — 유저스토리 작성 시 복잡도를 평가한다

## 피보나치 스케일 기준표

| SP | 복잡도 | 불확실성 | 노력 | 기준 예시 |
|----|--------|---------|------|----------|
| 1 | 매우 낮음 | 없음 | 수시간 | 텍스트 변경, 설정값 수정 |
| 2 | 낮음 | 매우 낮음 | 반나절 | 간단한 UI 컴포넌트 추가 |
| 3 | 보통 | 낮음 | 1일 | CRUD API 1개, 간단한 화면 |
| 5 | 중간 | 보통 | 2-3일 | 복잡한 비즈니스 로직, 외부 API 연동 |
| 8 | 높음 | 높음 | 1주 | 새 기능 모듈, 인증 시스템 |
| 13 | 매우 높음 | 매우 높음 | 1-2주 | 아키텍처 변경, 대규모 리팩토링 |
| 21+ | 분해 필요 | - | - | 스토리가 너무 큼 → 분해 필수 |

## 복잡도 평가 차원

### 3차원 평가 모델

```
최종 SP = max(기술 복잡도, 도메인 복잡도, 불확실성)

1. 기술 복잡도
   - 코드 변경 범위 (파일 수, 레이어 수)
   - 기술 난이도 (알고리즘, 동시성, 보안)
   - 테스트 난이도 (엣지 케이스, 통합 테스트)

2. 도메인 복잡도
   - 비즈니스 규칙 수
   - 예외 처리 시나리오
   - 이해관계자 승인 필요 여부

3. 불확실성
   - 기술 스파이크 필요 여부
   - 외부 의존성 (API, 라이브러리, 인프라)
   - 요구사항 명확성
```

## 벨로시티 계산

```
벨로시티 = 스프린트에서 완료한 SP 합계

안정적 벨로시티 산출:
  - 최근 3-5 스프린트 평균
  - 이상치(극단값) 제거 후 평균
  - 또는 중앙값 사용

예시:
  Sprint 1: 32 SP
  Sprint 2: 28 SP
  Sprint 3: 35 SP
  Sprint 4: 15 SP (휴가 등 이상치)
  Sprint 5: 30 SP

  평균(이상치 제거): (32+28+35+30)/4 = 31.25 SP
```

## 스프린트 용량 계산

```
스프린트 용량 = 벨로시티 × 가용률

가용률 계산:
  총 인일 = 팀원 수 × 스프린트 일수
  비가용 = 휴가 + 교육 + 회의 + 온콜
  가용 인일 = 총 인일 - 비가용

  가용률 = 가용 인일 / 총 인일

예시:
  팀 5명 × 10일 = 50 인일
  휴가 3일 + 회의 5일 = 8일
  가용: 42일 → 가용률 84%
  
  용량 = 31 SP × 0.84 ≈ 26 SP

버퍼:
  안정된 팀: 용량의 80% 계획 (20% 버퍼)
  새 팀/불확실: 용량의 70% 계획 (30% 버퍼)
```

## 유저스토리 분해 기준

```
13 SP 이상이면 분해 필수:

분해 전략:
1. 워크플로우 단계별 분해
   "사용자가 결제한다" →
   - 결제 수단 선택
   - 결제 정보 입력
   - 결제 처리
   - 결제 확인

2. 데이터 변형별 분해
   "다양한 형식 지원" →
   - JSON 지원
   - CSV 지원
   - XML 지원

3. 사용자 유형별 분해
   "사용자가 로그인한다" →
   - 이메일 로그인
   - 소셜 로그인
   - SSO 로그인

4. CRUD별 분해
   "상품 관리" →
   - 상품 목록 조회
   - 상품 등록
   - 상품 수정
   - 상품 삭제

5. Happy/Sad Path 분해
   - 정상 흐름
   - 에러 처리
   - 엣지 케이스
```

## 추정 편향 방지

```
1. 앵커링 효과 방지
   → 동시 공개 (플래닝 포커 방식)
   → 가장 높은/낮은 추정자가 근거 설명

2. 낙관 편향 방지
   → "최악의 경우" 시나리오 고려
   → 테스트/리뷰/배포 시간 포함

3. 파킨슨 법칙 방지
   → SP는 시간이 아닌 복잡도
   → "2일"이 아닌 "3 SP"

4. 기준점 정렬
   → 팀 공통 기준 스토리 유지
   → "로그인 API = 3 SP" 같은 앵커
```

## 산출물 템플릿

```markdown
## 스토리 포인트 추정 결과

### 벨로시티: [N] SP/스프린트
### 가용 용량: [N] SP (버퍼 [M]% 포함)

### 추정 결과
| 스토리 | 기술 | 도메인 | 불확실 | SP | 비고 |
|--------|------|--------|--------|-----|------|

### 스프린트 배분
| 스프린트 | SP 합계 | 스토리 목록 |
|---------|---------|------------|
| Sprint 1 | 26/31 | [목록] |
| Sprint 2 | 28/31 | [목록] |
```