스토리 포인트: 일정을 맞히는 건 상대 크기가 아니다

디자이너: “이거 3점이면 며칠 걸려요?”

개발자: “그건 저도 몰라요.”

디자이너: “그럼 3점이 뭔데요?”

스프린트 계획 회의에서 여러 번 본 장면을 하나로 합쳐 내가 지어낸 대화다. 이상한 쪽은 개발자가 아니다. 3점은 크기를 재서 붙인 숫자인데, 무엇을 얼마나 쟀느냐고 되물으면 답이 안 나온다. 크기를 재는 단위치고는 이상하다.

사람이 왜 자기 일정을 낙관하는지는 계획 오류에서 다뤘다. 그 글은 낙관하는 이유를 봤고, 이 글은 재는 단위를 시간에서 점수로 바꾸면 무엇이 달라지는지를 본다.

한 가지 더 있다. 스크럼 안내서에는 스토리 포인트라는 말이 한 번도 안 나온다. 매주 회의에서 쓰는 숫자인데, 그 회의의 규칙을 적어 둔 문서에는 이름조차 없다.

팀이 점수로 일정을 맞히는 것은 크기를 상대로 재서가 아니라, 남은 점수를 지난 스프린트에 끝낸 점수로 나눠서다. 시간이 어쩌다 점수가 됐는지, 눈금에 왜 4가 없는지, 점수로 바꿔도 하나짜리 추정은 왜 안 맞는지 보고 나면, 답을 내는 것이 어느 계산인지가 남는다.

스토리 포인트는 방해받지 않았을 때의 시간을 줄여 부른 말이다

Ron Jeffries는 3점짜리 스토리가 아흐레쯤 걸리는 일이었다고 적는다. 스토리는 화면 하나 만들기나 로그인 고치기처럼 스프린트에 담는 일 한 건이고, 이 글에서는 일감이라고 적는다. 점수는 시간을 버리려고 만든 단위가 아니라, 방해받지 않았을 때의 시간을 짧게 부르다 이름만 남은 단위다.

그가 적은 순서는 이렇다. Jeffries가 있던 XP라는 개발 방식에서 일감은 처음에 시간으로 쟀다. 걸릴 시간을 그대로 적었다는 뜻이다. 곧 방해받지 않았을 때의 시간으로 옮겨 갔다. 개발자 둘이 그 일감 하나만 같이 붙들고 아무도 안 건드리면 얼마나 걸리겠느냐를 적었다. 그 말을 줄여 부른 이름이 점이다. 3점이라고 하면 아흐레쯤이었다.

그 시간을 실제 날짜로 바꾸려면 대체로 3을 곱했다. XP는 이 3을 부하율이라고 불렀다. 하루치 일을 하는 데 사흘이 걸린다는 뜻인데, 이해관계자가 그 말을 못 알아들었다. 그래서 팀은 이름을 점으로 바꿨다.

같은 글에서 그는 자기가 이 단위를 만들었다면 지금은 미안하다고도 적었다. 지금까지 옮긴 유래는 실험이 아니라 회고이고, 자기가 기억하는 대로 적었다고 그가 밝혀 뒀다.

유래가 그렇다고 지금 쓰는 정의까지 시간인 것은 아니다. Mike Cohn은 점수가 백로그 항목 하나를 끝까지 구현하려면 드는 노력을 다 합친 값이라고 적는다. 백로그 항목은 앞에서 말한 일감을 Cohn이 부르는 이름이고, 거기에는 일의 양과 복잡도, 위험과 불확실성이 한 값으로 들어간다. 그리고 그는 숫자 자체가 아니라 비율이 중요하다고 힘주어 적는다. 2점짜리는 1점짜리의 두 배이고, 그 둘이 각각 몇 시간인지는 이 정의 안에 없다.

디자이너 일로 옮겨 보면 감이 온다. 화면 하나를 새로 그리는 일과, 이미 있는 화면 다섯 개가 같은 규칙을 따르게 정리하는 일을 나란히 놓아 보자. 어느 쪽이 몇 배쯤 큰 일인지는 대충 답할 수 있다. 정리하는 쪽이 서너 배쯤 되겠다는 말은 나온다. 그런데 각각 몇 시간이냐고 물으면 둘 다 답이 안 나온다.

디자이너에게 제일 낯선 대목은 양도 복잡도도 아니고 위험이다. 한 번도 안 써 본 지도 API를 붙이는 일감이면 그릴 화면은 하나인데 될지 안 될지를 아무도 모른다. 이런 일에 점수를 높게 매겨야 위험이 크기에 들어간다.

점수는 처음부터 시간과 다른 무엇을 재려고 만든 단위가 아니었다. 시간을 재던 자리에 남은 이름이고, XP 팀도 그 이름을 날짜로 바꾸려면 3을 곱해야 했다.

Cohn은 3과 4가 갈리지 않는다고 보고 4가 없는 점수 눈금을 골랐다

1킬로그램과 2킬로그램은 손에 들어 보면 구별이 되는데, 20킬로그램과 21킬로그램은 안 된다. 늘어난 양은 둘 다 1킬로그램으로 같은데 한쪽만 구별된다. 1에서 2로 갈 때는 100%가 늘고 20에서 21로 갈 때는 5%밖에 안 늘기 때문이다. 사람은 두 자극의 차이를 절대값이 아니라 비율로 가른다. 이것을 베버 법칙이라고 부르고, Mike Cohn은 이 법칙을 근거로 눈금을 1, 2, 3, 5, 8로 띄엄띄엄 뒀다. 사람이 가려낼 수 있는 간격만 남기고 나머지 눈금은 지웠다.

이 눈금은 2 다음부터 각 수가 앞 수보다 약 60%씩 크다. 3에서 5로, 5에서 8로 갈 때가 그렇다. 3과 4는 33% 차이라 그 간격에 한참 못 미친다. 3인지 4인지를 놓고 회의에서 다투려면 사람이 그 차이를 실제로 가려낸다고 봐야 한다. Cohn은 그렇게 보지 않아서 눈금에서 4를 뺐다.

8 다음도 같은 비율로 늘리면 13, 21, 34가 된다. 그런데 Cohn이 실제로 쓰는 수열은 1, 2, 3, 5, 8, 13, 20, 40, 100이다.

21을 20으로 바꾼 이유는 21과 34 중 21에만 걸린다. 21이라고 적으면 댈 수 없는 정밀도를 주장하는 셈이 됐고, 이해관계자가 20이나 25로 반올림하지 않고 21이라고 부른 데 감탄하더라고 그가 적었다. 그다음의 40과 100은 다르다. 앞 수보다 100%와 150% 큰 값이라 더 벌렸다.

Cohn 자신은 어느 눈금이 나은지를 못 정했다고 적는다. 1, 2, 4, 8, 16, 32로 배수를 쓰는 팀도 똑같이 잘했고, 어느 쪽이 낫다는 뚜렷한 증거를 그는 못 찾았다. 2007년에 카드를 찍으면서 인쇄비를 줄이려고 둘 중 하나를 골라야 했고, 그때 살짝 더 마음이 갔던 쪽으로 정했다. 이 수열이 퍼진 이유는 해마다 수천 벌씩 찍힌 카드다.

점수를 매길 때 각자 숫자 카드를 골라 내는 플래닝 포커, 그것을 제안한 글에 James Grenning이 붙여 놓은 카드 뭉치에도 4가 없다. 값은 1, 2, 3, 5, 7, 10과 무한대다. 그는 4나 6이나 8이나 9를 꼭 내고 싶으면 카드 두 장을 같이 내라며, 그렇게 더한 정밀도는 별 도움이 안 될 것 같다고 적었다.

디자이너에게는 익숙한 결정이다. 여백 토큰을 4, 8, 16, 32로 두는 것과 같다. 5와 6을 따로 두면 화면마다 둘 중 무엇을 쓸지 고르는 데 시간이 들고, 정작 다 그려 놓고 보면 5와 6은 눈으로 구별이 안 된다. 고를 수 있는 값을 줄이면 고르기가 빨라진다.

눈금을 이렇게 두면 고르기는 쉬워진다. 그런데 고르기 쉬운 것과 맞는 것은 다른 얘기다.

단위를 점수로 바꿔도 사람은 일감 하나에 걸릴 시간을 못 맞힌다

오픈소스 프로젝트 32개를 뒤진 연구에서, 사람이 매긴 점수와 걸린 시간이 뚜렷하게 같이 움직인 프로젝트는 열에 하나가 안 됐다. 둘의 상관을, 그러니까 점수가 큰 일감이 실제로도 오래 걸리는 정도를 재봤더니 강한 곳이 7%였고 나머지는 중간이 58%, 낮음이 35%였다.

연구가 훑은 것은 오픈소스 프로젝트 37개에서 뽑은 스토리 37,440개다. 그중 상관을 잰 프로젝트가 32개다.표본이 오픈소스 프로젝트라는 한정이 붙는다. 사내 팀이 매기는 점수도 같은지는 이 연구가 말하지 않는다. 상관은 Pearson, Kendall, Spearman 세 가지로 쟀고 강약은 그 셋의 평균으로 나눴다. 걸린 시간은 대개 지라 상태 변경 이력에서 뽑은 대리값이고, 실제 기록된 시간으로 다시 재도 결과가 비슷했다고 논문이 적는다. Vali Tawosi, Rebecca Moussa, Federica Sarro, On the Relationship Between Story Points and Development Effort in Agile Open-Source Software, ESEM 2022. 2026년 7월에 논문 PDF 전문을 열어 숫자를 확인했다.

프로젝트 32개 중 25개에서는 같은 점수를 받은 일감들이 실제로는 서로 다른 시간이 걸렸다. 열에 여덟꼴이다. 한 프로젝트 안에서도 점수가 같은 자로 안 매겨졌다는 뜻이다.

단위를 바꿔도 안 되는 까닭은 재는 쪽이 사람이라는 데 있다. Jorge Aranda는 23명에게 같은 자료 열세 쪽을 읽히고 개발 기간을 개월로 답하게 했다. 요구사항 열 쪽에 프로젝트 배경 세 쪽이 붙은 자료인데, 조건마다 딱 한 줄만 달랐다. 배경 문서에 인용된 고객 쪽 관리자의 발언이다. 아무 숫자도 없는 조건에서 답의 평균은 8.3개월이었고, 두 달쯤 걸리지 않겠느냐는 짐작을 읽은 조건은 6.8개월, 스무 달이라는 짐작을 읽은 조건은 17.4개월이었다.

높은 숫자를 먼저 읽은 사람들은 그 숫자 가까이에서 답을 골랐다. 이 현상을 앵커링(anchoring)이라고 부른다.낮은 숫자를 읽은 조건과 아무 숫자도 없는 조건 사이에서 같은 효과가 나는지는 자료가 모자라 판정하지 못했다고 논문이 적는다. 그러니 먼저 나온 숫자에 따라 답이 위아래 양쪽으로 달라진다고는 말할 수 없다. 조건마다 참가자가 6명에서 9명이라 표본도 작고, 참가자들은 자기 답에 책임을 지지 않는다는 것을 알고 있었다. Jorge Aranda, Anchoring and Adjustment in Software Estimation, University of Toronto 석사학위 논문, 2005. 참가자 수는 Experiment Execution 장, 조건 사이 비교는 Data Analysis and Interpretation of Results 장과 Discussion and Conclusions 장, 책임을 안 진다는 대목은 Experiment Plan and Design 장의 외적 타당도 섹션에서 확인했다. 답이 흩어진 폭은 스물다섯 달이다. 가장 짧게 답한 사람이 3개월, 가장 길게 답한 사람이 28개월이었다.

회의에서 오가는 판단도 같은 종류다. 누가 먼저 “이거 8 아니에요?” 하고 말한다. 그러면 나머지 사람들도 그 8을 이미 읽은 상태에서 자기 숫자를 고른다. 실험이 만든 자리와 조건이 같다. 점수를 매기는 일도 사람이 하는 판단이라, 단위를 시간에서 점수로 바꿔도 판단이 흔들리는 자리는 그대로 남는다.

그런데 팀들은 점수로 실제로 계획을 세우고 있고, 대체로 맞는다. 맞히는 것이 점수가 아니면 무엇인가.

팀은 남은 점수를 지난 스프린트에 끝낸 점수로 나눠 날짜를 얻는다

디자인 시스템을 정리하는 일감이 스무 개 쌓인 백로그 앞에서 언제 끝나느냐는 물음을 받았다고 하자. 남은 일감의 점수를 다 더해 120점이 나왔고 팀이 스프린트마다 40점을 끝내 왔다면, 120을 40으로 나눠 세 스프린트다. 2주짜리 스프린트면 여섯 주다. 3점이 며칠인지는 이 계산 어디에도 안 들어갔다. 점수가 몇 시간인지 아무도 몰라도 날짜가 나오는 까닭은, 남은 점수를 지난 스프린트에 실제로 끝낸 점수로 나누기 때문이다. 나눗셈의 위는 남은 점수이고 아래는 한 스프린트에 끝내는 점수다.

Jeffries가 적은 점수의 쓸모도 하나뿐이다. 한 스프린트에 얼마를 담을지 정하는 데 썼고, 20점쯤이라고 하면 아무도 토를 안 달았다고 한다. 팀이 한 스프린트에 실제로 끝낸 점수의 합을 벨로시티(velocity)라고 부른다. 이 글에서는 지난 스프린트에 끝낸 양이라고 적는다.

스크럼 안내서에는 이름이 없는데 계산은 있다. 백로그 항목에 더하라고 안내서가 예로 든 것은 설명과 순서와 크기이고, 크기는 그 일을 할 개발자가 정한다. 스프린트에 얼마를 담을지를 두고 안내서는 지난 성과와 남은 여력과 완료 기준을 가리킨다. 완료 기준을 두는 팀은 무엇까지 해야 그 일이 끝났다고 칠지를 미리 정해 둔다. 점수를 어떻게 매기라는 말은 없고, 지난 성과를 보라는 말이 있다.

여기서부터는 내가 종이에 적어 본 산술이다. 실험도 아니고 남이 재 본 값도 아니다.

팀이 모든 일감을 실제 크기의 두 배로 매긴다고 하자. 지난 스프린트에 40점을 끝냈다면, 배율을 걷어낸 실제 크기로는 20을 끝낸 셈이다. 다음 스프린트에 40점을 담으면 담기는 실제 크기도 20이다. 같은 일을 세 배로 매기는 팀은 같은 스프린트에 60점을 끝낸 것이 되고 60점을 담는데, 담기는 실제 크기는 역시 20이다. 배율이 무엇이든 결과가 같다. 앞의 백로그도 마찬가지다. 세 배로 매기는 팀에게는 남은 점수가 180이고 한 스프린트에 끝내는 점수가 60이라, 180을 60으로 나눠도 세 스프린트다. 나눗셈은 위와 아래에 똑같이 들어 있는 배율을 이렇게 지운다.

이 나눗셈이 맞으려면 두 가지를 지켜야 한다. 첫째, 팀이 같은 크기에 매번 같은 점수를 매겨야 한다. 배율이 일감마다 흔들리면 위와 아래에 같은 수가 안 들어가서 지워질 배율이 없다. 앞에서 본 프로젝트 25개에서 이 첫째가 깨졌다.

첫째는 점수 합을 목표로 걸 때 제일 잘 깨진다. 점수를 많이 낸 팀이 일을 많이 한 팀으로 읽히면 같은 크기에 매기는 점수가 스프린트마다 커진다. 이 일이 왜 벌어지는지는 굿하트의 법칙에서 따로 다뤘다.

둘째, 팀이 한 스프린트에 해내는 양이 스프린트마다 크게 안 흔들려야 한다. 사람이 빠지거나 새로 들어오면 지난 스프린트에 끝낸 양을 보고 다음 스프린트를 셈할 수 없다. 이 나눗셈은 지난번과 이번이 같은 팀일 때만 맞는다.

계획 오류는 내 감이 아니라 비슷한 일을 먼저 해 본 남들의 기록을 보고 예측하라고 했다. 그 기록을 밖에서 빌려 오라는 말인데, 스프린트마다 점수를 적어 온 팀은 자기 기록을 이미 갖고 있다. 남의 프로젝트를 뒤질 필요 없이 지난 세 번의 숫자가 손에 있다.

그러니 팀이 이 계산으로 답을 낼 수 있는 단위는 일감 하나가 아니라 스프린트 하나다. 그런데 이 단위를 만들었을지도 모르는 사람은 그렇게 쓰지 말라고 적었다.

점수를 버려도 팀은 나눗셈을 하고, 시간으로 돌아가도 부하율을 쓴다

여기까지의 주장에 정면으로 반대하는 쪽이 있다. 그런데 그쪽이 내놓는 대안도 결국 지난 스프린트에 끝낸 양으로 나누거나, XP가 쓰던 곱셈을 도로 꺼내 든다.

가장 센 말을 한 사람이 Ron Jeffries 본인이다. 그는 점수로 언제 끝날지 예측하는 발상이 잘해야 약하다고 적었고, 추정을 실제와 견주는 일은 잘해야 낭비이며 팀을 추정이나 벨로시티로 견주는 일은 해롭다고 적었다. 그리고 점수든 시간이든 추정은 피하는 편이 낫다고 적었다. 앞에서 본, 자기가 이 단위를 만들었다면 지금은 미안하다는 문장도 같은 글에 있다. 그는 스토리를 하루 안에, 되도록 두어 시간 안에 끝날 크기로 잘라서 추정을 아예 안 하는 편을 권한다.

회의에서 자주 듣는 다른 말도 있다. 점수는 시간을 감춘 시간이다. 다들 속으로 1점이 몇 시간인지 바꿔 보고 있고, 팀 사이 비교에도 쓰인다. 그럴 거면 처음부터 시간으로 적는 편이 정직하다.

인정하고 시작할 것이 세 가지다. 일감 하나의 시간을 못 맞힌다는 것은 이 글이 앞에서 이미 인정했다. 팀 사이 비교도 안 된다. 배율이 팀마다 다르고 나눗셈은 팀 안에서만 배율을 지우므로, 이 글이 편 계산도 팀 사이에는 안 맞는다. Jeffries도 같아 보이는 스토리에 한 팀이 2를, 다른 팀이 6을 매겨도 팀을 견주는 데는 쓸모가 없다고 적었다. 두 숫자는 애초에 같은 자로 잰 값이 아니다. 잘게 쪼개는 편이 낫다는 말도 맞다. 앞에서 근거로 쓴 그 논문이, 5점보다 큰 일감에서 일관성이 무너지기 시작하므로 그보다 큰 일감은 쪼개라고 스스로 권한다.

개수만 세는 방식은 점수를 버리는 것이 아니라 모든 일감을 1점으로 만들어 놓고 세는 것이다. 하루 안에 끝나는 크기로 자른 팀이 지난 스프린트에 여덟 개를 끝냈다면, 스물네 개가 남았을 때 세 스프린트다. 앞에서 한 120 나누기 40을 그대로 다시 하는 셈이다. 갈리는 것은 나눗셈을 하느냐가 아니라, 일감 크기를 고르게 만드는 데 품을 들이느냐 아니면 크기 차이를 숫자로 남기느냐다.

그럴 거면 시간으로 적자는 말은 XP가 이미 해 보고 그만둔 방법이다. 이해관계자가 그 곱셈을 못 알아들어서 이름을 점수로 바꿨다는 것을 앞에서 봤다. 시간으로 되돌리면 팀은 그 부하율을 다시 곱해야 한다. 그러니 시간으로 적어도 팀이 부르는 숫자와 달력 사이에는 수 하나가 그대로 낀다. 점수를 버려도 그 수는 안 없어지고, 곱하느냐 나누느냐만 달라진다.부하율과 벨로시티를 같은 환산으로 잇는 것은 내 판단이다. Jeffries는 부하율을 적었을 뿐, 그것을 벨로시티와 같다고 적지 않았다. 부하율이 어디서 나온 값인지도 그가 적지 않았다. 그리고 반박 두 개는 세기가 다르다. 앞은 내가 편 산술이고, 뒤는 회고 하나에 기댄다.

정리: 물어야 할 것은 3점이 며칠이냐가 아니다

팀이 점수로 날짜를 낼 수 있는 것은 일감끼리 크기를 견줘서가 아니다. 지난달의 자기 자신에게 견주기 때문이다.

점수는 방해받지 않았을 때의 시간을 줄여 부른 말이었고, 그때도 날짜로 바꾸려면 3을 곱해야 했다. 눈금을 띄엄띄엄 둔 것은 고르기를 쉽게 하려는 결정이었고, Cohn 자신이 배수 눈금과 견줘 어느 쪽이 낫다는 증거를 못 찾았다고 적었다. 오픈소스 프로젝트 32개에서 점수와 걸린 시간이 뚜렷하게 같이 움직인 곳은 7%였고, 스무 달을 먼저 읽은 사람들의 답은 두 달을 먼저 읽은 사람들보다 두 배 넘게 길었다. 그런데도 날짜가 나오는 까닭은 남은 점수를 지난 스프린트에 끝낸 점수로 나누기 때문이고, 그 나눗셈은 팀이 크기를 일정하게 매길 때만 배율을 지운다.

다음 회의에서 3점이 며칠이냐는 물음이 나오면 답하지 말고 두 가지를 되물어라. 지난 세 스프린트에 우리가 몇 점을 끝냈나. 그리고 반년 전에 3점이라고 부른 일과 지금 3점이라고 부르는 일이 같은 크기인가.