벨로시티

"이거 언제 끝나요?" 라는 질문에 개발팀이 감으로 답하던 시절이 있었습니다. 누군가는 최악을 가정해 두 달을 부르고, 누군가는 잘 풀릴 때를 생각해 2주를 불렀습니다. 같은 일을 두고 답이 네 배씩 차이 났으니 듣는 쪽은 어느 쪽도 믿지 않았습니다.

그래서 일정 회의는 늘 같은 모양으로 흘러갔습니다. 영업이 "다음 달까지 됩니까" 하고 물으면 개발팀이 "해 보긴 하겠는데요" 하고 답하고, 한 달 뒤에 안 되어 있으면 서로를 탓했습니다. 근거가 없으니 약속도 없었고, 약속이 없으니 신뢰도 쌓이지 않았습니다.

벨로시티는 이 질문에 근거를 붙이려고 만든 숫자입니다. 접근 방식을 뒤집은 게 핵심입니다. 앞으로 얼마나 할 수 있을지를 예측하는 대신, 지난 몇 주기에 실제로 얼마나 했는지를 재서 그 값을 그대로 다음 계획에 씁니다. 사람의 자신감이나 압박감이 아니라 기록이 답하게 만든 겁니다.

한 스프린트가 끝날 때 완료된 작업의 스토리 포인트를 전부 더하고, 그 합을 최근 3~5개 스프린트에 걸쳐 평균 냅니다.

스토리 포인트는 작업 하나의 크기를 나타내는 숫자입니다. 시간이 아니라 크기라는 점이 중요합니다. 팀이 "로그인 화면 만들기를 3이라고 하자" 고 기준을 하나 정해 두고, 다른 작업을 그것과 견줘 1·2·3·5·8 같은 값을 매깁니다. 시간으로 매기지 않는 이유는 같은 일도 사람마다 걸리는 시간이 달라서 합산이 의미를 잃기 때문입니다.

계산은 세 단계입니다.

1. 이번 스프린트에서 완료된 작업만 골라냅니다. 진행 중인 작업은 아무리 많이 해 뒀어도 이 단계에서 빠집니다.
2. 그 작업들의 포인트를 더합니다. 예를 들어 5·3·3·2·1 짜리 다섯 건을 끝냈으면 이번 스프린트는 14 입니다.
3. 최근 3~5개 스프린트의 합을 평균 냅니다. 14·16·12 였다면 벨로시티는 14 입니다.

여기서 걸리는 건 언제나 1번, "완료" 의 기준입니다. 완료 정의를 충족한 작업만 셉니다. 완료 정의는 팀이 미리 합의해 둔 체크리스트로, 보통 코드 리뷰를 통과하고 테스트가 돌고 운영 환경에 올라간 상태까지를 말합니다.

개발은 다 됐는데 검수가 남은 작업은 0점으로 처리하고 다음 스프린트로 넘깁니다. 8짜리 작업을 90퍼센트 했다고 7점을 주고 싶어지지만, 그렇게 부분 점수를 주기 시작하면 매 스프린트 숫자가 실제보다 높게 잡히고 그 부푼 숫자로 세운 다음 계획이 다시 밀립니다. 넘어간 작업은 다음 스프린트에서 완료될 때 8점을 온전히 받습니다.

절대값에는 의미가 없습니다. 스토리 포인트는 팀이 자기들끼리 정한 상대 단위라서, 어떤 팀의 40과 다른 팀의 40은 같은 양이 아닙니다. A 팀이 로그인 화면을 3으로 잡고 B 팀이 같은 화면을 8로 잡았다면 B 팀 숫자가 항상 두 배 넘게 나옵니다. 그렇다고 B 팀이 두 배 일하는 건 아닙니다. 벨로시티로는 팀을 줄 세우지 못합니다.

좋은 벨로시티는 높은 값이 아니라 흔들리지 않는 값입니다. 최근 세 스프린트가 32·30·34 처럼 붙어 있으면 다음 스프린트에 32 정도를 담는 계획이 서지만, 12·40·25 처럼 흩어져 있으면 평균 26 이라는 값이 아무것도 보장하지 않습니다. 체중을 잴 때 중요한 게 눈금의 크기가 아니라 같은 조건에서 같은 값이 나오는 것과 같습니다.

편차가 큰 데는 대개 원인이 있습니다. 스프린트마다 인원이 바뀌었거나, 작업 쪼개는 크기가 들쭉날쭉하거나, 완료 정의를 느슨하게 적용한 주기가 섞여 있는 경우입니다. 숫자를 손보기 전에 이쪽을 먼저 봅니다.

그래서 새로 꾸린 팀은 벨로시티를 바로 쓸 수 없습니다. 3~5개 스프린트를 돌려 편차가 작아진 뒤부터 계획의 근거로 씁니다. 팀 구성이 바뀌거나 포인트 기준을 다시 잡으면 그동안의 평균은 버리고 처음부터 다시 쌓습니다.

"지난 세 스프린트 벨로시티가 32인데 이번엔 40을 담았어요. 무리 아닐까요?"

이번 계획이 팀의 실적보다 25퍼센트 많으니 무엇을 빼자는 제안입니다.

"벨로시티로 팀끼리 비교하지 마세요. 포인트 기준이 서로 달라요."

숫자를 평가에 쓰려는 움직임을 막는 말입니다.

"아직 벨로시티가 안 잡혀서 이번 분기 일정은 범위로 드릴게요."

스프린트를 돈 횟수가 적어 평균이 믿을 만하지 않다는 뜻입니다.

페이지덱의 스프린트 플래닝 자리에서 지현이 자주 꺼내는 숫자입니다. 개발팀이 이번 주기에 담을 항목을 고르면 지현이 합계를 불러 주고, 최근 평균보다 눈에 띄게 많으면 무엇을 뺄지 그 자리에서 정합니다. 반대로 합계가 평균보다 한참 적으면 왜 그런지를 묻습니다. 누가 휴가를 가거나 다른 팀 지원이 잡혀 있으면 그건 정상이고, 이유가 없으면 담을 것을 더 고릅니다.

숫자가 결정을 대신하지는 않습니다. 대화를 여는 역할만 합니다. 지현이 "32였는데 40이네요" 라고 말한 뒤에 무엇을 뺄지는 항목을 아는 개발팀이 정합니다.

벨로시티를 생산성 점수로 읽는 경우가 가장 많습니다. 숫자가 높을수록 일을 많이 한 것처럼 보이니 자연스러운 오해입니다. 하지만 이 값은 팀이 스스로 매긴 포인트의 합이라서 기준을 조금만 후하게 잡아도 올라갑니다. 평가에 쓰기 시작하면 팀은 같은 일에 더 높은 포인트를 매기는 쪽으로 움직이고, 반년 뒤에는 숫자만 30에서 45로 오른 채 실제로 나가는 결과물은 그대로인 상태가 됩니다.

목표로 삼을 숫자로 읽는 것도 같은 문제입니다. "이번 분기에 벨로시티를 20퍼센트 올리자" 는 문장은 체중계 눈금을 올리자는 말과 같습니다. 재는 도구를 목표로 바꾸면 그 도구는 재는 기능을 잃습니다. 목표를 받은 팀은 대개 같은 일을 더 잘게 쪼개고 항목마다 포인트를 조금씩 높게 매기는 쪽으로 움직입니다. 그러면 다음 분기 계획은 40을 기준으로 세워지는데 실제로 나가는 결과물은 32이던 시절과 다르지 않습니다. 올려야 할 것은 벨로시티가 아니라 실제로 나가는 가치이고, 그게 올랐는지는 다른 지표로 확인합니다.