[Agile, 스토리포인트] 일정을 추정하는 것이란 얼마나 어려운 일인가.

이 짤 하나가 내가 글을 쓰게 된 모든 이유를 설명해준다.

들어가며

이 글은 애자일 방법론을 팀에 도입했으나 생각대로 되지 않은, 저의 이야기를 담은 일종의 회고록이자 스토리 포인트(story point)에 대한 개념을 정리한 글입니다. 저처럼 스토리 포인트를 제대로 알지 못하고 쓰고 계셨던 분들에게 도움이 될 것이라 생각합니다. 간결한 문장을 위해 평어체로 진행하겠습니다.

 

팀이 겪은 문제

부끄럽지만 프로젝트를 진행한지 6주 째, 지금껏 한 번도 제대로 스프린트의 태스크를 전부 끝내본 적이 없다. 처음에는 욕심을 많이 냈던 것 같다. "이 정도는 할 수 있을거야" 라는 마음으로 제대로 된 팀의 velocity(팀의 생산성, 추후 설명 예정) 측정도 하지 않은채로 개개인의 일감을 관리했다. 하지만 이렇게 6주가 진행되자 문제가 보이기 시작했다. 뭔가 일은 하는 것 같기는 한데, 전체적인 프로젝트의 진도는 나가지 않고, 심지어는 아에 일감을 끝내지 못할거라 생각하고 애초에 포기해버리는? 현상이 나타났다. 회사에 다닐 때, 그룹장님이 항상 하셨던 말씀이 있다. "스토리포인트는 시간에 비례하는 것이 아니라 복잡도에 비례하는 것이다" 하지만 그 땐 사실 그 의미를 정확히 몰랐다. 스토리포인트를 나의 생산성이라 생각했고, 많이 쳐낼 수록 좋은 것이라 생각했기 때문이다. 그래서 조금 간단한 일도 스토리 포인트 올려치기를 했었다...ㅎ 참 부끄러운 일이지만, 내가 했던 행동을 스토리포인트를 도입하는데에 가장 경계해야하는 점이라고 많은 글에서 설명한 것을 보면 빠지기 쉬운 함정이었던 것 같다.

 

그 때 내가 그렇게 행동했던 이유와 지금 내 팀이 비슷한 오류에 빠져있는 이유는 무엇일까?

바로 스토리 포인트에 [1] 상대성이 아닌 절대성을 적용했기 때문이고, [2] 1포인트에 대한 합의가 없었기 때문이다. 전 회사에서도, 지금 내 팀에서도 스토리 포인트를 할당하는데에 있어서 비교군이 없었다.

 

이는 큰 오류를 낳을 수 있는데, 절대적으로 스토리 포인트를 할당한다는 것은 어떤 것일지 예를 들어 설명해보자.

KBS에서 여의도역까지는 얼마나 걸릴까?

A: 10분정도 걸리는 것 같아요. (KBS 정문에서 가장 가까운 지하철 출구까지 걸어서 도착하는 시간이 그정도이기 때문에)
B: 5분 걸려요. (따릉이를 이용하는 사람이기 때문에)
C: 음... 안가봐서 모르겠지만, 지도를 보면 15분정도 걸릴 것 같은데요? (지도에 나오는 예상 소요시간에 여유 시간을 덧붙이기에)

이처럼 사람마다 사용하는 수단과 방법, 생각이 다르기 때문에 절대적인 수치로 평가를 하자면 다양한 대답이 나올 수 있다. 즉, 숙련된 개발자에게는 1시간 걸리는 일이, 신입 개발자는 2-3시간이 걸릴 수 있는 일이다. 이렇게 같은 일에 대한 다양한 스토리 포인트가 나오도록 할당하게 되면 제대로 된 팀의 생산성을 측정할 수 없게 된다.

 

그렇다면 절대적이아닌 상대적 방법으로 스토리 포인트를 할당하는 것은 무엇일까?

KBS에서 국회의사당역까지가 스토리포인트 1이라고 할 때, KBS에서 여의도역에 가는 것은 스토리포인트 몇 일까?

A: 2입니다.
B: 2-3 정도 되는 것 같아요.
C: 2보단 확실히 더 큰 것같은데, 3은 아닌 것 같아요.

이렇게 상대적인 비교군이 있을 때, 거리가 2-3배라는 것을 모두 인식할 수 있고 모두의 답변은 비슷하게 수렴할 수 있게 된다. 그리고 이런 답변이 나왔을 때, 해당 스토리 포인트는 3이 되는데 이는 구성원들의 토론과 합의가 필요하다. 가장 낮은 포인트 1의 기준이 될 개발 공정을 함께 정하고, 그 위의 중간 단위의 공정, 3, 또한 합의로 결정하여 이를 기준으로 모든 일감들의 스토리 포인트를 평가할 수 있게 된다.

 

제대로 된 스토리 포인트를 도입했을 때, 얻을 수 있는 이점은 무엇일까?

팀의 생산성을 쉽게 파악할 수 있다는 것이다. 개발은 다른 팀의 협업하는 사람들과 이해관계자들에게 숫자로 이해시켜야할 계획이 있어야한다. 한 스프린트 당, 팀이 소화해낼 수 있는 스토리포인트가 얼마인지 알 수 있다면 향후 일정파악에 큰 도움이 되기에 쉽게 계획할 수 있다. 즉, 협업 및 프로젝트 개발 산정 시간에 도움이 되기에 스토리포인트를 도입하게 된다. 또한, 스토리 포인트는 시간과 사람이라는 요소가 배제되어있다. 이렇게 외부 환경에 덜 의존하도록 디자인되어 있기에, 더욱 팀의 일정 추정에 용이하다.

 

다만, 여기서 명심해야할 부분이 있는데, 스토리 포인트는 팀의 생산성을 측정하기 위한 도구이지, 절대 개인의 생산성을 측정, 비교하는 도구가 아니라는 것이다. 역시 이 팀의 생산성은 팀들 간의 생산성을 비교하는 용도 또한 절대 아니며 그렇게 쓰여서는 안된다. 그렇게되면 나와 같은 문제를 겪게 된다.

 

우리 팀이 스토리 포인트를 도입한 방식

[피보나치 수열]

스토리포인트는 다양한 방법이 있지만 보통은 피보나치 수열을 이용하여 사용하게 된다. 피보나치를 사용하는 이유는 수가 보여주는 복잡성 때문이다. 0, 1, 2, 3, 5, 8 ... 이와 같은 숫자를 보면 하나씩 늘어날 수록 수가 기하급수적으로 증가하게 된다. 이는 일의 복잡성을 보여주는 것과 상당히 유사하다. 로그아웃을 스토리 포인트 1로 잡았을 때, 결제 시스템을 개발하는 것은 13 쯤 된다고 치면, 13이라는 숫자는 그 안에 있을 예측하기 어려운 변수들을 나타내준다. 그래서 피보나치 수열을 사용한다.

 

우리팀은 이 수열의 범위를 0-13 으로 잡았다. 13이라는 높은 수는 해결해나가면서 작은 수로 분해해주어야한다. 예를 들어, 위의 결제 시스템의 13을 3개로 나누어, "5는 상품을 결제한다. 5는 구입한 상품의 정보를 내정보에서 볼 수 있다. 5는 관리자페이지에서도 구입한 상품을 볼 수 있다." 와 같이 나눌 수 있다. 물론, 이렇게 되면 13에서 15로 숫자가 커지게 되겠지만 복잡성은 줄어들게 된다.

[벨로시티, Velocity]

그리고 우리는 이제 제대로 된 스토리 포인트를 할당했기에 팀의 벨로시티(Velocity)를 측정해야한다. 벨로시티란 팀이 스프린트 당 얼마만큼의 스토리 포인트를 획득할 수 있는지를 나타내는 지표이자, 팀의 생산성이다. 팀의 생산성을 알아야 매 스프린트의 일정을 추정할 수 있기 때문이다. 벨로시티는 3주간의 스프린트 스토리포인트의 평균값으로 나타낼 수 있다.

 

첫 시작은 어떻게 하는 것이 좋을까? 우리 팀은 나 빼고는 모두 직장을 다니고 있기에, 퇴근 후에 프로젝트에 전념할 수 있는 시간이 많지 않다. 많아봐야 3시간 정도? 되는 것 같다. 시간에 비례해서 스토리포인트를 할당하면 안되지만, 그래도 사이드 프로젝트이기에 절대적인 프로젝트 개발 시간의 고려는 필요한 것 같다. 그래서 로그아웃을 1 포인트로 설정하고, 일주일간 개인이 최대로 가능한 스토리 포인트를 3으로 잡았다. 이렇게 되면 총 개발자가 4인이 있기 때문에, 우리 개발 팀의 벨로시티는 12포인트가 된다.

 

이렇게 한 주를 진행한 뒤, 모든 태스크를 성공적으로 끝마쳤다면 개인 최대 가능 스토리 포인트를 5로 올린다. 그러면 벨로시티는 20포인트가 된다. 여기서 실패했다면? 개인 포인트를 4로 낮추고 또 스프린트를 진행한다. 이렇게 3주간 획득한 모든 포인트의 나누기 3을 하면 팀의 적당한 벨로시티를 알 수 있게 된다.

 

여기서 주의 사항

스토리포인트는 유저에게 실질적인 가치를 주는 것에만 부여를 해야한다. 이 점이 내가 스토리포인트에 대해 제대로 공부하기 전, 잘못한 점 중 또 한가지였다. 나는 아무래도 프로젝트 리더로 활동하고 있다보니 사업자 등록, 업체 컨택 등과 같은 필요한 행정 업무가 많았다. 이 때, 이에 대한 스토리 포인트를 할당했었는데, 사실 사업자 등록과 같은 것은 그 태스크에 대한 유저가 존재하지 않는다. 그러므로 스토리포인트는 0이 된다. 다만, 업체 컨택을 해서 그 업체의 API를 사용할 수 있도록 한다면? 그 API를 사용하는 서버팀이라는 유저가 존재한다. 그러므로 이는 포인트를 받을 수 있게 되는 것이다. 내가 하는 일의 제일 끝단의 사용자가 있는가?에 대해 생각하고 스토리 포인트를 할당하게 된다. 이렇게 스토리 포인트를 할당하다보면 정말 가치있는 일만 하고자 하기에 프로젝트의 진척에도 큰 도움이 된다!

 

그러면 리팩토링은 가점을 받을 수 있을까? 없다. 모든 제품에는 우리가 고려해야할 점이 있다. 항상 [1] 올바른 제품을 만든다(=제대로 작동하는 제품을 만든다)와 [2]제품을 올바르게 만든다(=기술 부채가 없는 높은 퀄리티의 코드로 만든다)이다. 모든 스토리 포인트에는 위의 [1], [2]가 포함되어 있다. [2]를 신경쓰지 않고, [1]만 충족시킨 다음에 나중에 리팩토링을 한다? 그러면 그 때의 스토리 포인트는 제대로 완성되지 않은 것이다. 그러므로 리팩토링의 스토리포인트는 0이 된다.

엇? 예전 개발자가 했던 레거시 코드를 고치는 신입 개발자는 스토리 포인트가 항상 0이 되는걸까요? 라고 궁금할 수 있다! 답만 말하면 그렇다. 그래서 스토리 포인트가 개인간의 성과를 비교하는 툴로 쓰이면 안된다고 했던 것이다. 팀 간의 비교툴로도 쓰일 수 없는게, 레거시를 개선하는 조직이라면 스토리 포인트가 낮을 수밖에 없기 때문이다. 

 

스토리 포인트는 팀의 일정을 빠르고 쉽게 추정할 수 있도록 하는 도구라는 것을 항상 명심하자!

 

 

참고 문헌:

https://www.atlassian.com/ko/agile/project-management/estimation - Jira를 만든 Attlasian의 스토리포인트란?

https://maily.so/eddy/posts/376a7408 - 세가지가 균형을 이룰 때 훌륭한 제품이 만들어집니다.

https://engineering.linecorp.com/ko/blog/user-story-point-in-line-pay-team - 라인페이 개발팀의 스토리포인트 이야기

https://engineer-mole.tistory.com/389- 일본 개발자의 스토리포인트 사용법, 번역서