생산성 향상 측정
Velocity는 “이 팀이 스프린트마다 실제로 어느 정도까지 일을 처리할 수 있는지”를 숫자로 표현한 값입니다.
1. 개념을 더 직관적으로 풀어서
스프린트를 “배송 박스”라고 보면, Velocity는 “이 팀이 박스 하나에 평균 얼마나 담을 수 있는지”를 말하는 숫자입니다.
스토리 포인트는 개별 업무(티켓)의 난이도·규모를 상대적으로 점수화한 값이고, Velocity는 “완료된 포인트의 합계”입니다.
즉, “우리 팀은 2주에 보통 50pt 정도는 무난히 처리한다”라는 과거 실적의 평균값이 Velocity입니다.
2. 더 구체적인 예시 3가지
기본 예시
2주 스프린트, 티켓 포인트와 완료 여부:
로그인 개선: 5pt (완료)
결제 오류 수정: 8pt (완료)
신규 대시보드: 13pt (완료)
배치잡 리팩토링: 8pt (미완료)
이 경우 완료된 포인트 = 5 + 8 + 13 = 26pt → 이 스프린트의 Velocity는 26입니다.
여러 스프린트를 보고 평균 내기
스프린트 1: 40pt 완료
스프린트 2: 50pt 완료
스프린트 3: 60pt 완료
평균 Velocity = (40 + 50 + 60) / 3 = 50pt → “우리 팀 평소 Capacity는 스프린트당 50pt 정도”라고 보는 기준이 됩니다.
일정 계획에 실제로 어떻게 쓰는지
백로그 합계를 보면, 어떤 릴리즈 목표까지 총 150pt worth의 스토리가 있음.
팀 평균 Velocity = 50pt/스프린트 → 최소 3 스프린트(=6주) 정도 필요하다고 rough하게 말할 수 있음.
PO/비즈니스와 일정 협의할 때 “6주 이내는 현실적으로 어렵다”는 근거가 됩니다.
3. “완료 포인트 합 / 스프린트 일수”는 언제 쓰는지
글에서처럼 “완료 포인트 합 / 스프린트 일수”로 보면 “하루 평균 처리량”도 계산됩니다.
예: 10일(2주) 스프린트에서 50pt 완료 → 하루 평균 5pt.
이게 유용한 케이스:
스프린트 길이가 자주 바뀌는 팀(1주 → 2주 → 3주 등)
공휴일, 대규모 휴가 등으로 특정 스프린트는 실제 근무일이 적을 때, “근무일당 처리량”을 비교하고 싶을 때.
4. 어디서, 어떻게 Velocity를 보는지 (툴 기준)
일반적으로는 Jira 같은 이슈 트래킹 툴에서 자동으로 보거나, Harness 같은 엔지니어링 인사이트 툴에서 메트릭으로 봅니다.
Jira 기준 예시
각 스프린트에 스토리 포인트 필드를 사용하고, 스프린트를 종료하면 “완료 이슈의 포인트 합”이 그 스프린트의 Velocity가 됩니다.
Jira의 “Velocity Chart”에서 최근 N개 스프린트의 Velocity 막대를 한 번에 볼 수 있고, 팀 평균도 시각적으로 확인 가능합니다.
Harness 기준 (이 글에서 언급)
Sprint Metrics Trend Report에서 Commit Done Points(완료 포인트 합), 스프린트 길이 등을 함께 보여줘서, Velocity를 시간 흐름에 따라 트렌드로 볼 수 있습니다.
같은 리포트에서 Creep Points(중간에 늘어난 스코프)까지 같이 보면서 “Velocity가 떨어진 이유가 mid-sprint scope 증가 때문인지”를 해석할 수 있습니다.
실무적으로는 “Jira Velocity Chart + 3~6개 스프린트 평균값”을 팀의 기본 플래닝 기준으로 쓰고, Harness 같은 도구로는 추세 변화(갑자기 떨어지거나 튀는 구간)를 모니터링하는 식으로 병행하면 됩니다.
Last updated