Story Points의 문제점: 엔지니어링 팀을 위한 더 나은 대안들

Story points는 애자일 개발에서 작업을 추정하는 사실상의 표준이 되었어요. 어떤 엔지니어링 팀의 기획 회의에 들어가 보면, 작업이 3인지 5인지, 또는 그 "간단한" 기능이 왜 8이 되었는지에 대한 토론을 듣게 될 거예요.

하지만 여기 불편한 진실이 있어요: story points는 종종 해결하는 것보다 더 많은 문제를 만들어요. 팀들이 추정으로 고생하는 것을 수년간 지켜본 후, 엔지니어링 팀이 실제로 가치를 전달하는 데 도움이 되는 더 나은 대안들을 탐색할 때가 되었어요.

Story Points가 부족한 이유

정밀성의 착각

Story points는 시간 기반 약속의 압박 없이 상대적 추정을 약속해요. 이론적으로 5포인트 스토리는 2포인트 스토리보다 대략 2.5배 더 오래 걸려야 해요. 실제로는 이 관계가 거의 성립하지 않아요.

이 시나리오를 생각해 보세요: 팀이 사용자 인증 기능을 5포인트로 추정했어요. 나중에 결제 통합을 5포인트로 추정해요. 이것들이 정말 복잡성에서 동등한가요? 인증은 간단한 CRUD 작업을 포함할 수 있지만, 결제 통합은 서드파티 API 통합, 보안 준수, 오류 처리가 필요해요.

게이밍과 Velocity 연극

Story points가 중요한 메트릭이 되면, 팀들은 불가피하게 시스템을 조작해요. 개발자들은 velocity를 더 좋게 보이게 하려고 추정을 부풀려요. 매니저들은 story points가 절대적이 아닌 상대적이라는 것을 이해하지 못한 채 팀들에게 velocity를 높이라고 압박해요.

이것은 "velocity 연극"을 만들어요 - 실제 생산성 인사이트를 가리면서 진행 측정의 착각을 만들어요. 이번 스프린트에 50포인트를 완료한 팀이 지난 스프린트의 40포인트보다 반드시 개선된 것은 아니에요; 단순히 추정을 재보정했을 수도 있어요.

Planning Poker 문제

Planning poker 세션은 매력적이지만, 종종 거짓 합의의 연습이 되어요. 가장 큰 목소리가 이기거나, 팀들이 복잡성을 진정으로 평가하기보다는 갈등을 피하기 위해 추정에 수렴해요.

더 나쁜 것은, 이런 세션들이 상당한 시간을 소모한다는 것이에요. 일반적인 기획 세션은 기능이 3포인트인지 5포인트인지 토론하는 데 30분을 보낼 수 있어요 - 실제 문제 해결이나 작업을 더 작고 관리 가능한 조각으로 나누는 데 사용될 수 있는 시간이에요.

Story Points에 대한 더 나은 대안들

1. 명확한 정의가 있는 티셔츠 사이징

숫자 story points 대신, 명시적이고 팀별 정의가 있는 티셔츠 사이즈(XS, S, M, L, XL)를 사용하세요:

• XS: 간단한 버그 수정이나 설정 변경 (< 1일)
• S: 명확한 요구사항이 있는 잘 이해된 기능 (1-2일)
• M: 약간의 연구나 조정이 필요한 기능 (3-5일)
• L: 여러 시스템에 걸친 복잡한 기능 (1-2주)
• XL: 더 작은 조각으로 나눠야 하는 에픽

이 접근법은 거짓 정밀성을 피하면서 상대적 사이징의 이점을 유지해요. 팀들은 XL 항목이 나눠져야 한다는 것을 자연스럽게 이해하여 "3스프린트가 걸리는 8포인트 스토리" 문제를 방지해요.

2. Cycle Time과 Lead Time 메트릭

추정된 복잡성보다는 실제 배송 시간 측정에 집중하세요:

이런 메트릭들은 추정의 주관성 없이 배송 프로세스에 대한 구체적인 데이터를 제공해요. 실제 병목 지점들을 강조해요: 느린 코드 리뷰, 긴 QA 사이클, 또는 배포 마찰.

3. 처리량 기반 계획

개별 항목을 추정하는 대신, 팀이 시간당 얼마나 많은 항목을 완료하는지 추적하세요. 이 접근법은 추정 정확성보다는 흐름에 집중해요.

예를 들어, 팀이 일반적으로 스프린트당 8-12개의 작은 항목이나 2-3개의 큰 항목을 완료한다면, 그에 따라 계획하세요. 이 방법은 추정이 본질적으로 불확실하다는 것을 인정하면서도 예측 가능한 계획을 가능하게 해요.

4. 몬테카를로 예측

확률적 예측을 만들기 위해 과거 데이터를 사용하세요. 팀이 지난 6개월 동안 유사한 기능들을 3-8일에 완료했다면, 신뢰 구간으로 예측할 수 있어요:

• 5일 내 완료 50% 확률
• 7일 내 완료 80% 확률
• 10일 내 완료 95% 확률

이 접근법은 거짓 정밀성 뒤에 숨기기보다는 불확실성을 받아들여요.

변화 구현하기: 실용적 접근법

작은 실험으로 시작하기

Story points를 하룻밤에 버리지 마세요. 대신 병렬 실험을 진행하세요:

1. 1-2주차: Story point 추정을 계속하되 실제 cycle time도 추적하기
2. 3-4주차: 배송 패턴을 모니터링하면서 새 작업에 티셔츠 사이징 시도하기
3. 5-6주차: 한 팀이나 프로젝트에서 처리량 기반 계획 실험하기

각 접근법의 정확성과 유용성을 특정 상황에서 비교해 보세요.

지속적 개선에 집중하기

추정 방법에 관계없이, 목표는 배송 능력의 지속적 개선이어야 해요. 정기 회고는 다음에 집중해야 해요:

• 이번 반복에서 우리를 느리게 한 것은 무엇인가?
• Cycle time을 어떻게 줄일 수 있을까?
• 더 일관되게 배송하는 데 무엇이 도움이 될까?

중요한 것을 측정하기

Velocity 대신, 비즈니스 가치와 직접 연관된 메트릭들을 추적하세요:

• 배포 빈도: 얼마나 자주 프로덕션에 배포하는가
• 변경사항 리드 타임: 커밋부터 프로덕션까지의 시간
• 평균 복구 시간: 문제를 얼마나 빨리 고치는가
• 변경 실패율: 문제를 일으키는 배포의 비율

이런 DORA 메트릭들은 story point 추정의 오버헤드 없이 엔지니어링 효과성에 대한 실행 가능한 인사이트를 제공해요.

Story Points가 여전히 의미 있을 수 있는 경우

Story points가 전적으로 나쁜 것은 아니에요. 다음의 경우에는 잘 작동할 수 있어요:

• 함께 작업을 나누는 법을 배우는 새로운 팀들
• 상대적 비교가 도움이 되는 매우 불확실한 도메인들
• 공통 추정 언어가 필요한 팀 간 조정
• 비즈니스 파트너들이 개념을 이해하는 이해관계자 커뮤니케이션

핵심은 정밀한 측정 시스템이 아닌 대화와 계획을 위한 도구로 사용하는 것이에요.

결론

Story points는 추정 문제를 해결하겠다고 약속했지만, 종종 새로운 문제들을 만들어요: 거짓 정밀성, 게이밍, 그리고 시간 소모적인 계획 의식들. 대안들 - 티셔츠 사이징, cycle time 메트릭, 처리량 계획, 확률적 예측 - 은 엔지니어링 작업을 계획하고 측정하는 더 실용적인 접근법들을 제공해요.

최고의 추정 시스템은 팀이 실제로 의사결정을 내리고 배송을 개선하는 데 유용하다고 생각하는 시스템이에요. 지속적 개선에 집중하고, 중요한 것을 측정하고, 목표가 완벽한 추정이 아니라 고객에게 효율적이고 예측 가능하게 가치를 전달하는 것임을 기억하세요.

작게 시작하고, 다양한 접근법으로 실험하고, 팀이 더 나은 소프트웨어를 더 빠르게 배송하는 데 도움이 되는 방법들을 선택하세요. 미래의 당신(과 팀)이 story point 함정을 넘어선 것에 감사할 거예요.