Brain💡 핵심 인사이트
스토리 포인트는 애자일 팀이 특정 기능(유저 스토리)을 개발하는 데 필요한 노력과 복잡도를 "며칠, 몇 시간 걸린다(절대 시간)"로 계산하지 않고, "A 기능보다 B 기능이 2배 정도 어렵네(상대적 점수)"로 매기는 독특한 추정 방식입니다.
시간의 함정에 빠지는 것을 막고 팀 전체의 평균 속도(Velocity)를 파악하는 핵심 도구입니다.
Ⅰ. 기존 '시간(Hours)' 기반 산정의 치명적 결함
PO가 "로그인 화면 만드는 데 며칠 걸려요?"라고 물었을 때, 전통적 방식에서는 "음.. 제가 하면 3일(24시간) 걸립니다"라고 대답했습니다.
- 개인차의 발생: 10년 차 시니어에게는 3일 걸릴 일이, 신입사원에게는 10일이 걸립니다. "로그인 = 3일짜리 일"이라고 박아두면 누가 그 일을 맡느냐에 따라 일정이 완전히 박살 납니다.
- 낙관적 편향: 인간은 본능적으로 방해 요소(회의, 서버 장애)를 빼고 순수 코딩 시간만 예측하여, 일정을 항상 부족하게 잡습니다.
Ⅱ. 스토리 포인트의 원리: 상대적 추정
애자일은 시간을 버리고 추상적인 **'점수(Point)'**를 도입했습니다.
- 기준점(Reference) 잡기: 팀원들이 모두 동의하는 가장 쉽고 뻔한 작업(예: 단순 텍스트 변경)을 골라 **"이걸 1포인트라고 치자!"**라고 기준을 잡습니다.
- 상대적 크기 비교: 이제 새로운 '로그인 모듈 연동' 작업을 봅니다. "이건 아까 그 텍스트 수정(1점)보다 로직이 한 5배쯤 복잡하고, 보안 위험도도 높네. 그럼 이건 5포인트!"라고 점수를 매깁니다.
- 효과: 신입이든 시니어든 "로그인 기능이 텍스트 수정보다 5배 무겁다"는 상대적 덩치에는 모두가 이견 없이 동의할 수 있습니다. 개인의 코딩 속도와 무관하게 일의 '객관적 사이즈'가 도출됩니다.
피보나치 수열의 사용 (1, 2, 3, 5, 8, 13...)
스토리 포인트를 매길 때 1, 2, 3, 4처럼 선형으로 매기지 않고 피보나치 수열을 씁니다.
- 왜냐하면 1점짜리 일과 2점짜리 일은 크기가 체감되지만, 숫자가 커져서 20점짜리 거대하고 불확실한 일감과 21점짜리 일감을 사람의 뇌로 구분하는 것은 불가능하기 때문입니다.
- 큰 작업일수록 불확실성이 크다는 것을 인정하여 간격을 팍팍 넓혀버립니다 (8, 13, 20, 40). 만약 어떤 작업이 13점을 넘어간다면 "이건 너무 거대해서 한 스프린트 안에 못 해. 백로그를 더 잘게 쪼개와!"라는 신호가 됩니다.
Ⅲ. 벨로시티 (Velocity, 팀의 개발 속도)
포인트를 쓰면 우리 팀의 진짜 실력이 숫자로 증명됩니다.
- 스프린트 1에서 팀이 완료한 스토리 포인트를 다 더했더니 30점이었습니다.
- 스프린트 2에서도 다 더해보니 32점이 나왔습니다.
- 아하! 우리 팀의 벨로시티(평균 속도)는 2주당 약 30점이구나!
이제 PO가 백로그에 300점 치 일감을 쌓아놓으면, "아, 우리 팀 속도가 30점이니까 저걸 다 만들려면 대략 10번의 스프린트(20주)가 걸리겠구나"라고 매우 정확하고 수학적인 프로젝트 완료 일정(릴리즈 계획)을 역산할 수 있게 됩니다.
📢 섹션 요약 비유: 스토리 포인트는 건물을 지을 때 **'바위의 크기와 무게'**를 재는 것입니다. 바위가 100kg(스토리 포인트)이라는 상대적 사실은 변하지 않습니다. 힘센 어른(시니어)이 들면 1시간 만에 옮기고, 꼬마(신입)가 들면 5시간이 걸리겠지만, **이 돌이 10kg짜리 벽돌보다 10배 무겁다는 본질(크기)**을 파악하는 것이 프로젝트 일정 계획의 핵심입니다.