월간 → 2주 스프린트 전환

추정이 정확하면 주기 길이는 상관없다 — 어차피 맞으니까추정이 어려울수록 계획은 자주 빗나가고, 그래서 짧게 끊어 빨리 잡아야 한다

• 데일리 = “어제/오늘/블로커”만 — 문제 해결이 아니라 막힌 것 드러내기, 바쁘면 슬랙 스레드로 대체
• 회고에선 PM이 말을 줄이고 팀이 먼저 말하게 — 겸업 SM의 최대 함정

계획을 꽉 채우지 않는 게 핵심 — 운영을 맡은 특화 인력은 처음부터 일감을 적게
“7일치 주고 운영까지”가 아니라 “4일치만” 배정 → “운영 때문에 못 했다”는 말이 사라짐

※ 위 숫자는 예시 — 실제 운영 부담을 측정해 채워야 함(아래 미결 항목)

• 5일 초과 티켓은 무조건 분할 — 못 쪼개면 에픽, 스프린트마다 조각으로
• 티켓은 “결제 완성”이 아니라 “이번: 결제 API 스펙+코어” / 다음: “예외처리+연동+테스트”
• 리뷰에서 “진행 중”이 아니라 “여기까지 됐다”를 보여줄 수 있게

파이프라인 — 이번 스프린트 프론트는 지난 스프린트 백엔드 완성분을 붙임, 항상 “완성된 API”라 대기 없음
API 계약을 코드보다 먼저 확정하면 mock으로 병렬 착수까지 가능

남는 절반은 부채 상환 — 유휴는 리스크가 아니라 “부채 갚을 여유 자원”, 상시 대기 백로그를 미리 세팅:

• CI/CD 자동화 — 수동 배포 부담을 없애는 1순위 후보
• 디자인시스템 미완 P0 — 토큰 정리 + CI lint
• 어드민 성능 최적화 — 번들 ~3.2MB
• E2E 테스트 · 사장님 앱 UX 개선

※ 3주치 빅뱅 배포는 위험 — 가능하면 기능 플래그로 안전한 부분부터, 단 통째로만 나가야 하는 건 인정

1. 가용일 계산 — 운영·회의 뺀 “진짜 개발 가능일” (보통 10일 중 6~7일)
2. 운영 반영 — 특화 인력의 가능일을 낮게 고정
3. 큰 백엔드부터 — 5일 초과는 “이번 목표 지점”으로 분할
4. 프론트는 지난 스프린트 결과물 — 파이프라인
5. 프론트 남는 칸 — 부채 백로그로 채움
6. 가용일 넘게 담지 않고 멈춤 — 가장 중요, 넘기면 무조건 깨짐

• CI/CD 자동화 — 수동 배포 자체가 부채, 자동화 시 고정 배포일도 불필요, 프론트 여유의 1순위 투입처
• 버스 팩터 1 해소 — “그 사람만 운영 가능”은 시한폭탄, 문서화 + 풀스택 전환자 인수인계
• 프론트 가동률 데이터 — 2~3스프린트 돌려 감이 아닌 숫자로 재배치 판단