스토리 포인트는 시간이 아니다

스토리 포인트는 시간이 아니다

스토리 포인트는 시간이 아니다

스프린트 계획 회의였다. 백로그 항목 하나를 놓고 팀이 20분쯤 떠들었다. 이건 지난번 검색 필터보다는 크고 결제 화면보다는 작다, 그럼 3이다. 여기까지는 좋았다. 그런데 바로 다음에 나온 질문 하나가 그 20분을 통째로 지웠다.

PM: “3포인트면 며칠이죠?”

개발자: “음, 이틀이나 사흘쯤이요.”

PM: “그럼 이틀로 잡을게요.”

세 마디 사이에서 무슨 일이 벌어졌냐면, 팀이 20분 동안 만든 추정이 버려졌다. 3포인트는 이틀이라는 뜻이 아니었다. 이틀일 수도 있고 나흘일 수도 있고, 붙어봐야 아는 게 남아 있다는 뜻이었다. 그 폭이 날아가고 이틀이라는 숫자 하나만 캘린더에 박혔다.

나는 같은 장면을 여러 팀에서 봤다. 그리고 매번 같은 결론에 도달했다. 스토리 포인트는 시간을 줄여 부르는 말이 아니다. 시간으로 바꾸는 순간 포인트는 원래 담으려던 걸 흘려버린다.

포인트가 담으려던 것

포인트 하나에는 세 가지가 섞여 있다. 일의 크기, 일의 복잡도, 그리고 아직 모르는 정도.

이사를 예로 들어보자. 짐을 옮기는 데 몇 시간 걸리냐고 물으면 아무도 못 맞힌다. 엘리베이터가 있는지, 주차가 되는지, 사다리차를 불러야 하는지에 따라 두 배씩 벌어지니까. 그런데 질문을 바꿔서 원룸 이사와 세 식구 아파트 이사 중 어느 쪽이 더 큰 일이냐고 물으면 누구나 답한다. 절대 시간은 흔들려도 둘 사이의 크기 차이는 잘 안 흔들린다. 포인트는 팀에게 두 번째 질문만 시키는 장치다.

플래닝 포커도 상대 크기라는 전제 위에 서 있다. 2002년에 James Grenning이 오래된 델파이식 집단 추정법을 다듬어 이름을 붙였고, 2005년 Mike Cohn의 책으로 퍼졌다. 카드 눈금이 1, 2, 3, 5, 8, 13처럼 뒤로 갈수록 성기게 벌어지는 것도 같은 생각에서 나왔다. 큰 일일수록 정밀하게 못 맞히니, 눈금 자체를 성기게 만들어 정밀한 척을 못 하게 막아둔 것이다.

눈금이 성긴 건 결함이 아니라 설계다. 13과 14를 구분할 수 없어야, 3포인트는 12시간이라고 우기는 일이 안 생긴다.

스크럼 가이드에는 스토리 포인트라는 말이 나오지 않는다. 2020년판은 추정이라는 단어를 걷어내고 항목의 크기를 정한다는 표현을 쓰며, 어떤 추정 기법도 지정하지 않는다. 포인트는 규칙이 아니라 팀이 고른 도구 중 하나다.

환산표가 생기면

1포인트는 4시간이라는 환산표가 생기는 순간 세 가지가 연달아 일어난다.

첫째, 모르는 부분이 지워진다. 3포인트가 12시간이 되면 그 안에 있던 불확실성은 표 어디에도 안 남는다. 12시간은 폭이 없는 숫자다.

둘째, 추정이 약속으로 바뀐다. 폭이 없는 숫자는 일정표에 그대로 옮겨 적힌다. 그리고 못 지키면 누군가는 왜 늦었는지 설명해야 한다. 추정은 앞으로 어떨 것 같다는 예측인데, 약속은 지켜야 하는 것이다. 둘은 완전히 다른 물건인데 환산표가 하나를 다른 하나로 바꿔버린다.

셋째, 팀이 방어를 시작한다. 지난번에 3이라고 했다가 주말을 반납한 사람은 다음부터 5를 부른다. 나쁜 마음이 아니라 합리적인 반응이다. 문제는 방어가 몇 스프린트만 반복되면 포인트가 부풀고, 부푼 포인트로 계산한 벨로시티는 올라가고, 위에서는 팀이 빨라졌다고 읽는다는 것이다. 실제로 나가는 결과물은 그대로인데.

벨로시티가 성과 지표로 쓰이는 순간이 제일 위험하다. 굿하트의 법칙(Goodhart’s law)은 어떤 측정값이 목표가 되면 그 값은 더 이상 좋은 측정이 못 된다고 말한다. 포인트는 굿하트의 법칙에 유난히 약하다. 팀이 스스로 매기는 숫자라서, 올리고 싶으면 그냥 크게 부르면 되니까.

스토리 포인트를 만든 사람으로 자주 지목되는 Ron Jeffries도 비슷한 얘기를 했다.

I like to say that I may have invented story points, and if I did, I’m sorry now.

내가 포인트를 발명했다면 지금은 미안하다는 말이다. 다만 그가 문제 삼은 건 포인트 자체보다 쓰임이었다. 팀끼리 벨로시티를 비교하고, 추정이 얼마나 맞았는지로 사람을 평가하는 것. 포인트가 팀에 도움이 안 되면 그냥 쓰지 말라는 게 그의 조언이다.

오른쪽으로 긴 꼬리

한 가지 더. 추정을 시간으로 못 박으면 안 되는 이유가 사람 심리 말고 숫자 쪽에도 있다.

일이 실제로 얼마나 걸렸는지를 여러 번 기록해서 늘어놓으면, 좌우 대칭인 종 모양이 안 나온다. 이유는 단순하다. 왼쪽은 막혀 있고 오른쪽은 안 막혀 있어서다.

이틀 걸릴 일이 아무리 잘 풀려도 0시간이 되지는 않는다. 반나절쯤이 바닥이다. 그런데 안 풀리는 쪽은 바닥이 없다. 라이브러리 버전이 안 맞고, 남의 서버 응답이 문서와 다르고, 그걸 고치니 다른 화면이 깨진다. 이틀짜리가 2주가 되는 길은 활짝 열려 있는데 2시간이 되는 길은 막혀 있다. 그래서 분포는 오른쪽으로 긴 꼬리를 그린다.

설명용 예시 그림. 실제 팀 데이터가 아니라, 추정 대비 실제 소요 시간이 그리는 오른쪽으로 긴 꼬리 모양만 보여준다.

꼬리가 길면 평균과 중앙값이 벌어진다. Erik Bernhardsson이 추정과 실제 시간이 같이 남아 있는 데이터로 계산해 보니, 실제를 추정으로 나눈 배수의 중앙값은 1배인데 평균은 1.8배쯤이었다. 절반은 추정대로 끝나는데 몇 개가 크게 터지면서 평균을 끌어올린 것이다. 한 데이터셋에서 나온 값이라 우리 팀 숫자로 그대로 쓸 건 아니고, 오른쪽 꼬리라는 모양이 흔하다는 것만 가져가면 된다.

실무에서 중요한 건 합계의 성질이다. 항목 열 개를 각각 추정해서 더하면 그럭저럭 맞는 편이다. 크게 잡은 것과 작게 잡은 것이 서로 상쇄되니까. 그런데 꼬리에 있는 한 개가 터지면 상쇄가 무너진다. 스프린트가 깨지는 건 대개 열 개가 조금씩 늦어서가 아니라 한 개가 크게 늦어서다.

꼬리가 길다는 걸 알고 나면 회의실 대화가 달라진다.

PM: “이거 얼마나 걸려요?”

개발자: “보통 사흘이면 되는데, 인증 쪽이 물려 있어서 길어지면 2주까지 갈 수도 있어요.”

범위로 답하는 게 정직한 답이다. 그런데 우리는 대개 사흘로 줄여서 말한다. 범위로 답하면 우유부단해 보이니까. 포인트는 우유부단해 보일 압박을 우회하는 장치이기도 하다. 사흘도 2주도 말하지 않고, 이건 저것보다 크다는 정보만 남긴다.

그래서 내가 하는 것

정리하면 내가 팀에서 지키려고 하는 건 다섯 가지다.

환산표를 안 만든다. 포인트를 시간으로 바꾸는 공식이 문서에 한 줄이라도 적히면 그 뒤로는 아무도 포인트로 생각하지 않는다.

5보다 크면 쪼갠다. 큰 항목은 추정이 어려운 게 아니라 아직 이해를 못 한 상태다. 쪼개면 두 가지가 같이 좋아진다. 꼬리가 짧아지고, 진행 상황이 매일 눈에 보인다. 나는 추정을 정교하게 다듬는 것보다 쪼개는 게 예측에 훨씬 크게 기여한다고 본다.

13이 나오면 추정이 아니라 신호로 읽는다. 13은 크다는 뜻이 아니라 모른다는 뜻이다. 그러면 바로 만들지 않고 하루 이틀짜리 조사를 먼저 잡는다.

벨로시티는 팀 안에서만 쓴다. 다음 스프린트에 몇 개나 넣을 수 있을지 가늠하는 용도지, 팀끼리 비교하거나 사람을 평가하는 숫자가 아니다. 다른 팀의 5와 우리 팀의 5는 애초에 같은 단위가 아니다.

밖으로 나갈 땐 범위로 말한다. 이번 스프린트에 들어갈 것 같다, 아마 두 스프린트는 걸린다, 이 정도로. 하나의 날짜를 요구받으면 날짜와 함께 무엇이 틀어지면 밀리는지를 같이 적는다.

내가 걸리는 부분

여기까지 쓰고 내 주장을 다시 읽어보면 구멍이 몇 개 보인다.

먼저 날짜 문제. 시간으로 환산하지 말라는 말은 날짜를 말하지 말라는 말로 읽히기 쉬운데, 날짜를 안 주는 건 답이 아니다. 밖에 약속된 일정이 있는 조직에서는 누군가 날짜를 말해야 한다. 내가 안 주면 상대가 자기 편한 날짜를 정한다. 그러니 내 규칙은 시간으로 말하지 말자가 아니라, 시간으로 말할 때 폭을 버리지 말자로 고쳐야 정확하다. 포인트는 팀 안에서 폭을 유지하는 장치이고, 밖으로 나갈 땐 어차피 날짜로 번역된다. 번역을 금지할 게 아니라 번역하면서 폭을 안 잃는 게 핵심이다.

더 아픈 지점은 따로 있다. 앞에서 내가 효과가 크다고 꼽은 건 대부분 쪼개기였다. 그럼 포인트는 정말 필요한가. 항목을 비슷한 크기로 쪼개 놓으면 개수만 세도 예측이 된다. 실제로 포인트를 접고 흐름 지표로 옮겨간 팀들이 있고, 스크럼 가이드도 추정이라는 말을 걷어냈다. 내가 아직 포인트를 쓰는 이유는 예측이 정확해져서가 아니다. 숫자를 맞춰보는 과정에서 서로 다르게 이해하고 있던 게 드러나기 때문이다. 같은 항목에 5와 1이 동시에 나오면 그 자리에서 대화가 터진다. 나한테는 대화가 목적이고 숫자는 부산물이다. 여기까지 인정하고 나면 포인트는 추정 도구라기보다 대화를 유발하는 장치에 가깝다. 그리고 대화를 유발하는 게 목적이라면, 그 목적에 안 쓰이는 팀에서는 포인트를 접는 게 맞다.

마지막으로 나도 예외가 아니다. 위에서 방어적으로 포인트를 부풀리는 팀 얘기를 남 얘기처럼 썼는데, 내가 낸 추정도 대체로 낙관적이었고 몇 번 데인 뒤에는 나도 숫자를 올려 불렀다. 그래서 나는 추정을 더 정직하게 하자는 식의 결론은 안 믿는다. 사람의 의지로 고쳐지는 문제가 아니라 구조의 문제다. 폭을 지울 수 없게 만들어두는 쪽이 훨씬 오래 간다.

정리

포인트는 시간을 줄여 부르는 말이 아니라, 아직 모르는 게 남아 있다는 사실을 숫자에 실어 나르는 방법이다. 환산표를 만드는 순간 모른다는 사실이 지워지고, 남는 건 시간을 이상한 이름으로 부르는 습관뿐이다.

3포인트면 며칠이냐는 질문을 다음에 받으면 나는 이렇게 답할 생각이다. 보통 이틀에서 사흘인데, 인증이 물려서 늘어나면 2주까지도 간다고. 숫자 하나보다 답이 길지만, 지울 게 없다는 점에서 훨씬 쓸모 있다.

이 글, 어떠셨어요?

이 글에 오류가 있나요?

사실이 틀렸거나 오탈자, 깨진 링크를 발견하셨다면 알려주세요. 확인하고 고치겠습니다.