개발 공수 통계·예정 작업 비교 계산기 사용 안내
계산 과정
기본 입력값으로 계산하면 평균은(는) 15 시간입니다. 항목별 내역은 위 표에서 확인할 수 있습니다.
결과가 실제와 달라지는 경우
- 로그인 화면 8시간과 결제 서버 80시간처럼 범위·위험이 다른 일을 한 목록에 넣으면 평균 24시간이 어느 작업도 대표하지 못합니다. 기능 유형, 담당 스택, 완료조건이 유사한 표본만 묶어야 합니다.
- 소요시간에 대기시간을 포함한 티켓과 순수 작업시간만 기록한 티켓이 섞이면 중앙값과 표준편차가 프로세스 차이를 반영합니다. 코드리뷰·QA·배포 대기를 포함할지 팀이 먼저 정의하세요.
- 8개 과거 사례의 평균은 다음 작업을 확정하는 약속이 아닙니다. 외부 API 불확실성, 데이터 마이그레이션, 보안 검토처럼 이번에만 있는 위험은 목록에 나타나지 않으므로 별도 작업으로 쪼개거나 버퍼를 명시해야 합니다.
- 여러 개발자가 동시에 16시간 일한 것을 경과시간 8시간으로 적으면 사람시간과 캘린더시간이 섞입니다. 공수는 인원×투입시간, 일정은 의존관계가 반영된 경과시간으로 분리해 관리하세요.
- 작은 실패 작업이나 취소 티켓을 데이터에서 빼면 성공한 사례만 남는 생존편향이 생깁니다. 재작업 6시간이 실제 투입됐다면 최초 예상에 없었더라도 실제 공수에는 포함해야 합니다.
알아두면 좋은 기준
- 기본 8개 사례 10·14·18·12·16·22·13·15시간의 평균은 15시간이고 중앙값은 14.5시간입니다. 22시간 같은 큰 사례가 있어 평균이 중앙값보다 약간 높습니다.
- 전체 과거 작업을 모집단으로 단정하지 않고 앞으로 할 유사 업무의 일부 표본으로 취급해 분산을 n−1로 나눕니다. 값이 1개뿐이면 표본 표준편차를 계산할 수 없으므로 최소 2개가 필요합니다.
- 예정 공수 20시간은 기본 표본 8개 중 7개보다 큽니다. 도구의 백분위는 같은 값의 공동순위를 엄밀히 처리하는 일정 확률이 아니라 과거 관측치보다 큰지 비교한 위치 정보입니다.
- 1사분위와 3사분위 사이에는 과거 사례의 가운데 50%가 놓입니다. 이번 예상이 그 밖에 있다면 무조건 틀렸다는 뜻이 아니라 범위 확대나 위험 요인이 과거와 다른지 설명할 신호로 쓰세요.
자주 묻는 질문
스토리 포인트를 시간 대신 넣어도 되나요?
같은 팀과 같은 척도의 포인트만 넣으면 분포 분석은 가능합니다. 다만 결과 단위 표시는 시간으로 나오므로 숫자 해석을 시간으로 하지 말아야 하며, 팀 간 포인트를 합쳐 생산성을 비교하는 용도로는 부적절합니다.
평균 15시간이면 이번 계획도 15시간으로 잡아야 하나요?
유사성이 높고 새 위험이 없다면 출발점이 될 수 있지만 마감 확률을 보장하지 않습니다. 중앙값 14.5시간, 3사분위와 가장 느린 22시간을 보고 납기 위험을 어느 수준까지 감수할지 결정하세요.
예정 공수의 상위 퍼센트는 어떻게 읽나요?
20시간보다 작은 과거 값이 7개라면 과거 사례의 87.5%보다 큰 예상입니다. 숫자가 클수록 성과가 좋다는 평가가 아니라, 이번 계획이 과거보다 긴 쪽에 있다는 뜻입니다.