스프린트 계획

2주 스프린트 계획 세션은 최대 2~4시간이어야 합니다. 구조는 세 부분으로 나뉩니다: (1) 검토 — PM은 정제된 백로그에서 우선순위가 지정된 스프린트 목표를 제시하고, 각 항목을 전략적 목표와 연결합니다. (2) 규모 측정 및 약속 — 엔지니어링 팀은 스토리 포인트 또는 T-셔츠 사이즈를 사용하여 노력을 추정하고, 의존성을 식별하며, 팀 속도(velocity)를 기반으로 현실적인 스프린트 범위에 약속합니다. (3) 작업 분해 — 선택된 사용자 스토리는 담당자가 지정된 하위 작업으로 분해됩니다. Product Ops는 모든 항목에 승인 기준, 디자인이 완료되고 의존성이 의식 전에 해결되었는지 확인하여 계획 회의가 정의되지 않은 작업으로 인해 지연되는 것을 방지합니다.

스프린트 속도(velocity)는 팀이 스프린트당 완료하는 평균 스토리 포인트 수로, 롤링 윈도우(일반적으로 3~6 스프린트)를 통해 계산됩니다. 이는 스프린트 계획의 주요 역량 입력값입니다. 팀은 과거 평균 속도(velocity)를 초과하지 않는 범위에 약속합니다. Product Ops는 시간 경과에 따른 속도(velocity) 추세를 추적하고 이상 징후를 조사합니다(현저한 하락은 범위 확장(scope creep), 기술 부채 또는 사기 문제를 나타낼 수 있으며, 현저한 상승은 과소평가를 나타낼 수 있습니다). 속도(velocity)는 또한 출시일 예측에도 사용됩니다. 남은 총 백로그 포인트를 평균 속도(velocity)로 나누면 예측 가능한 납기 기간을 얻을 수 있습니다.

Product Ops는 스프린트 계획을 효율적이고 신뢰할 수 있게 만드는 지원 기능입니다. 책임은 다음과 같습니다: '스프린트 준비 완료' 백로그 유지 관리(티켓 초안 작성, 승인 기준 작성, 디자인 첨부, 의존성 문서화), 의식 진행 및 시간 관리, 역량 추적기 유지 관리(PTO, 인터뷰 및 온콜 로테이션 고려), 스프린트 목표 및 약속 문서화, 그리고 스프린트 후 약속된 작업과 완료된 작업을 비교하는 회고 분석을 통해 후속 조치. Product Ops가 이러한 오버헤드를 처리하지 않으면, 엔지니어와 PM은 전략적 논의 대신 행정 업무를 처리하며 계획 회의를 보내게 됩니다.