개발에서 스토리 포인트 — 개념, 평가 척도 및 적용

스토리 포인트란?

스토리 포인트는 스크럼 및 기타 애자일 방법론에서 사용되는 작업 복잡성의 지표입니다. 팀은 각 작업을 시간이 아닌 상대적 단위로 평가합니다: “이 작업은 기준보다 두 배 복잡합니다.” 이 접근 방식은 개발자 간의 속도 차이를 평준화하고 복잡성에 초점을 맞춥니다.

용어의 기원

스토리 포인트의 개념은 2000년대 초반 스크럼의 대중화와 함께 등장했습니다. 이 방법을 처음으로 설명한 사람 중 하나는 익스트림 프로그래밍(XP)의 일부인 Ron Jeffries였습니다. 아이디어는 항상 부정확한 “인-시간” 추정에서 팀이 집합적으로 결정하는 상대적 복잡성으로 이동하는 것이었습니다. 오늘날 스토리 포인트는 애자일 팀의 업계 표준입니다.

스토리 포인트에서 고려되는 요소

스토리 포인트로 추정할 때 팀은 세 가지 요소를 고려합니다: 작업량(코드, 화면, 로직의 양), 복잡성(기술적 과제, 새로운 기술), 불확실성(불명확한 요구사항, 위험). 1 스토리 포인트는 “위험이 없는 간단한 작업”을 의미할 수 있고, 8은 “불확실성이 높은 복잡한 작업”을 의미할 수 있습니다.

스토리 포인트 척도: 선택 방법

스토리 포인트 척도의 선택은 추정 정확도와 계획 편의성에 영향을 미칩니다. 가장 인기 있는 척도는 피보나치 수열이지만 대안도 있습니다.

왜 피보나치인가? 척도의 심리학

피보나치 수열은 우연히 선택되지 않았습니다. 1과 2의 차이는 미미하지만(50%), 13과 21의 차이는 상당합니다(62%). 이는 현실을 반영합니다: 작은 작업은 더 정확하게 추정되고, 큰 작업은 더 큰 분산으로 추정됩니다. 작업이 21 스토리 포인트로 추정될 때 팀은 이해합니다: “얼마나 걸릴지 모르지만 확실히 13보다는 많습니다.” 피보나치 척도는 거짓 정밀도를 방지합니다.

기준 작업 — 척도의 기초

척도가 작동하려면 팀이 기준에 합의합니다: “작업 X는 1 스토리 포인트입니다.” 일반적으로 간단하고 잘 알려진 작업이 기준으로 선택됩니다: “화면에 텍스트 필드 추가” 또는 “오타 버그 수정.” 다른 모든 작업은 기준에 상대적으로 추정됩니다. 기준 없이는 스토리 포인트가 의미를 잃습니다 — 각자가 단위를 다르게 이해합니다.

팀 벨로시티 및 예측

벨로시티는 팀이 스프린트당 완료하는 스토리 포인트의 평균 수입니다. 이는 프로젝트 일정 예측을 위한 핵심 지표입니다.

벨로시티 계산 방법

벨로시티는 완료된 작업을 기준으로 계산됩니다: 팀이 완료한 모든 작업(완료 정의 충족)의 스토리 포인트가 합산됩니다. 미완료 작업은 계산되지 않습니다. 정확성을 위해 최근 3~5개 스프린트의 평균을 사용합니다. 예를 들어 팀이 지난 4개 스프린트에서 20, 22, 18, 24 스토리 포인트를 완료했다면 벨로시티 = 21스‌포입니다.

벨로시티를 통한 예측

벨로시티와 스토리 포인트로 된 백로그 총량을 알면 릴리스까지 필요한 스프린트 수를 예측할 수 있습니다. 예를 들어 백로그에 210 스토리 포인트가 있고 벨로시티가 21이면 10개의 스프린트가 필요합니다. 이는 작업이 진행됨에 따라 정제되는 대략적인 예측입니다. 중요: 벨로시티는 평균이며 약속이 아닙니다. 평균이 아닌 하한(18스‌포)을 기준으로 계획하세요.

벨로시티를 높이는 방법

벨로시티는 명령으로 높일 수 없습니다 — 이는 프로세스 건강의 증상입니다. 지속 가능한 벨로시티 성장은 다음을 통해 달성됩니다: 기술 부채 감소, 코드 리뷰 프로세스 개선, 컨텍스트 스위칭 감소, 테스트 및 CI/CD 자동화. 중요: 다른 팀의 벨로시티는 비교할 수 없습니다 — 각 팀이 스토리 포인트를 자신의 방식으로 정의합니다.

스토리 포인트 vs 시간: 무엇을 언제 사용할까

스토리 포인트와 시간은 목적이 다르며, 둘 사이의 선택은 상황에 따라 달라집니다. 경험 많은 팀은 다양한 작업에 두 접근 방식을 모두 사용합니다.

스토리 포인트가 더 효과적인 경우

스토리 포인트는 스프린트 계획에 필수적입니다: 누가 작업을 수행할지에 의존하지 않습니다. 주니어는 하루에 2스‌포, 시니어는 4스‌포를 처리할 수 있지만 작업 추정치는 둘 다 2스‌포로 유지됩니다. 스토리 포인트는 개발자를 비교하지 않고 팀 생산성을 추적할 수 있게 합니다. 이는 정치적 압력을 줄이고 팀 분위기를 개선합니다.

시간이 필요한 경우

시간은 외부 약속(계약, 예산, 클라이언트 보고)에 필요합니다. 클라이언트는 “8 스토리 포인트”가 아니라 “3주”를 알고 싶어합니다. 스토리 포인트를 시간으로 변환하려면 과거 변환율을 사용하세요: 팀은 1스‌포가 약 4시간의 작업과 같다는 것을 알고 있습니다. 변환은 투명하고 데이터 기반이어야 하며 추측에 기반해서는 안 됩니다.

결합 접근법

많은 팀이 결합 접근법을 사용합니다: 스프린트 계획을 위해 작업을 스토리 포인트로 추정한 다음 관리자가 외부 보고를 위해 시간/일로 변환합니다. 하나의 프로세스에서 두 시스템을 혼합하지 않는 것이 중요합니다: 스토리 포인트로 추정하고 벨로시티에서 시간을 도출하거나, 직접 시간으로 추정해야 합니다.

스토리 포인트 작업 시 흔한 실수

스토리 포인트 도입은 종종 상대적 추정의 이점을 무효화하는 실수를 동반합니다. 가장 흔한 실수는 다음과 같습니다.

스토리 포인트를 시간에 연결

가장 흔한 실수 — 팀이 합의합니다: “1스‌포 = 4시간.” 이 경우 스토리 포인트는 의미를 잃고 다른 이름의 시간이 됩니다. 스토리 포인트는 상대적이어야 하며 시간에 얽매이지 않아야 합니다. 작업 A가 작업 B보다 두 배 복잡하면 시간이 얼마나 걸리든 2스‌포를 받습니다.

사후 추정

작업이 완료된 후 추정되는 경우 — 이는 추정이 아니라 기록입니다. 스토리 포인트는 작업 시작 전, 최대 불확실성의 시점에 할당되어야 합니다. 사후 추정은 벨로시티를 왜곡하고 계획에 이점을 제공하지 않습니다. 게다가 잘못된 정확성 감각을 만듭니다.

팀 간 벨로시티 비교

팀 A와 팀 B의 벨로시티 비교는 의미 없는 행위입니다. 각 팀은 기준과 척도를 다르게 정의합니다. 한 팀에게 1스‌포는 간단한 1시간 작업이지만, 다른 팀에게는 하루짜리 작업입니다. 비교할 수 있는 것은 시간에 따른 동일 팀의 벨로시티(증가 또는 감소 여부)뿐입니다.

일관되지 않은 척도

같은 복잡성의 다른 작업이 다른 스토리 포인트를 받고 더 복잡한 작업이 더 적은 포인트를 받으면 척도가 깨집니다. 팀은 정기적으로 척도를 보정해야 합니다: 3~6 스프린트마다 추정치가 실제 복잡성과 얼마나 일치했는지 회고적으로 검토합니다. 이는 추정의 일관성을 향상시킵니다.