cycle time 기반 shipping velocity 진단 설계하기(Design a shipping velocity diagnosis using cycle time)

Story point보다 cycle time이 항상 낫다

Story point는 느리게 반응하고, 게임화되기 쉽고, 팀 간 비교도 불가능합니다. Cycle time, 즉 first commit부터 production까지 걸리는 시간은 측정 가능하고, 비교 가능하며, throughput과 직접 연결됩니다. GitHub의 developer productivity 연구는 cycle time을 delivery health의 가장 신뢰할 수 있는 선행지표로 봅니다. Atlassian의 agile metric 가이드는 더 직설적입니다. Story point velocity는 팀 내부 ritual에 가깝고, cycle time은 실제 측정값입니다.

이 프롬프트의 작동 방식

이 프롬프트는 cycle time을 단계별(commit→PR, PR→review, review→approved, approved→merged, merged→deployed)과 작업 유형별로 나누어 병목을 보이게 만듭니다. 핵심 신호는 p90/median 비율입니다. Median이 숨기는 긴 꼬리를 p90이 드러냅니다. 마지막 정량화 단계는 병목이 아닌 곳을 고치는 잘못된 intervention을 막아 줍니다.

언제 사용할까

• 리더십이 "우리는 느리다"고 말하고, 당신은 근거가 필요할 때
• Shipping frequency가 떨어졌는데 원인이 불분명할 때
• 새 engineering leader가 변화 전에 baseline을 만들고 싶을 때
• CI/CD 개편이 논의 중인데 ROI 근거가 필요할 때
• 팀이 체감보다 velocity가 더 건강하다는 점을 증명하고 싶을 때

흔한 함정

• Median cycle time만 보는 것. Median은 긴 꼬리를 숨깁니다. 실제로 일이 막히는 곳은 p90입니다.
• 가장 시끄러운 단계를 고치는 것. 시끄러운 단계(예: CI 시간)가 병목일 가능성은 의외로 낮습니다. 최악의 p90/median 비율을 보세요.
• 팀 간 cycle time 비교. Cycle time은 같은 팀 내에서 시간에 따라 보는 건 유효하지만, 팀 간에는 work mix가 교란 변수입니다.

참고 자료

• GitHub Developer Research — GitHub
• Agile Metrics — Atlassian
• The Pragmatic Engineer — Gergely Orosz
• Kanban — Atlassian