sprint-plan

name	sprint-plan
description	스프린트/사이클 계획을 짠다 — 캐리오버 확인, 가용 용량 산정(팀원·PTO·회의), 스프린트 골 1~2개, P0 vs 스트레치 선별, 태스크 등록까지. "스프린트 계획 짜줘 / 이번 사이클 뭐 넣지 / 스프린트 플래닝 / 다음 스프린트 정리 / 용량 얼마나 돼" 요청 시.

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

스프린트 계획 (Sprint / Cycle Planning)

스프린트는 "이번에 진짜 끝낼 수 있는 것"만 담는 게임이다. 다 넣으면 다 못 끝낸다. 순서대로 좁혀간다.

1. 지난 스프린트 캐리오버 확인

• pm-copilot project --status 로 지연·미완·블로커부터 본다.
• 넘어온 일은 이번 용량에서 먼저 뺀다. 왜: 안 끝난 데는 이유(공수 과소평가·블로커)가 있고, 새 일 위에 또 쌓으면 또 밀린다.
• 캐리오버가 용량의 30%를 넘으면 경고: "지난 스프린트가 과적재였습니다. 원인부터 짚죠."

2. 가용 용량 산정 (사람 수 아님, 실가용 시간)

• 팀원 수 × 스프린트 일수 − (PTO·공휴일 + 회의·온콜·리뷰). 이걸 사람 말로 계산해 보여준다.
• 예: "개발 3명 × 10일 = 30인일. PTO 4일, 회의·리뷰 20% 제하면 실가용 ≈ 20.8인일."
• PTO·회의 정보가 없으면 지어내지 말고 "PTO/휴가 있으신 분? 정기회의 몇 시간?" 물어 "확인 필요"로 둔다.
• 신규 합류·컨텍스트 스위칭이 있으면 용량을 보수적으로. 첫 스프린트는 특히 낮게 잡는다(코칭).

3. 스프린트 골 1~2개

• 태스크 목록이 아니라 "이 스프린트가 성공하면 무엇이 참이 되는가" 한 문장.
• 예: "결제 실패율을 X%→Y%로 낮춘다." 골은 최대 2개. 3개부터는 초점이 흐려진다고 직설한다.
• 골마다 왜 지금 이게 최우선인지 근거를 붙인다(지표·고객 요청·기한). 근거 없으면 표시.

4. 백로그에서 P0 vs 스트레치 선별

• 골에 직접 기여하는 것 = P0(반드시). 나머지는 스트레치(여유 되면).
• 우선순위 근거가 흐리면 [[prioritize]]로 RICE/ICE 점수화 → 왜 이 순서인지 설명.
• 과적재 경고: P0 공수 합 > 실가용 용량이면 멈춘다. "P0가 용량을 X인일 초과 — 뭘 뺄지 정하죠." 남기지 말고 잘라낸다.
• 각 태스크가 한 스프린트 안에 끝나는 크기인지 확인. 크면 쪼개고, 애매하면 개발자에게 공수 확인(추정임을 명시).

5. 태스크 등록 (초안 → 검토 → 등록)

• 확정 전까지는 초안으로 제시하고, 사람이 P0/스트레치·담당·마감을 검토·결정한다.
• 승인되면 등록: pm-copilot project --add "결제 재시도 로직" --owner 이개발 --due 2026-08-05 --deps "API정책확인"
• 데이터는 ~/.pm-copilot/data에 쌓인다. 등록 후 --status로 블로커·의존을 한 번 더 검증.

원칙

• 왜. 넣은 이유·뺀 이유·용량 계산을 전부 사람 말로 남긴다. 숫자만 던지지 않는다.
• 근거. 용량·공수·지표는 확인된 값 우선, 없으면 "확인 필요" — 지어내지 않는다.
• 반자동. 계획은 AI 초안, 결정은 사람. 스코프 컷은 반드시 사람이 승인.
• 코칭. 신입에겐 "왜 캐리오버를 먼저 빼는지", "왜 골이 2개 이하인지"를 짧게 설명해 다음엔 스스로 짜게 돕는다.
• 계획 확정 뒤 큰 그림은 [[roadmap]], 데일리 진행은 [[project]]로 이어간다.