# 스토리 포인트는 무의미 합니다, 큐를 측정하세요

> Clean Markdown view of GeekNews topic #15885. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15885](https://news.hada.io/topic?id=15885)
- GeekNews Markdown: [https://news.hada.io/topic/15885.md](https://news.hada.io/topic/15885.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-07-17T21:34:22+09:00
- Updated: 2024-07-17T21:34:22+09:00
- Original source: [brightball.com](https://www.brightball.com/articles/story-points-are-pointless-measure-queues)
- Points: 7
- Comments: 2

## Summary

Fractional의 CTO인 Barry Jones는 스토리 포인트는 신뢰할 수 없고 혼란을 야기하며, 정확한 추정을 위해서는 큐를 측정하는 것이 더 효과적이라고 주장합니다. 큐 측정은 단기 및 장기 추정 문제를 해결하고, 불확실성을 제거하며, 대규모 팀에게 더 가치 있는 연습을 제공합니다. 또한, 큐는 속도나 사이클 시간 관련 메트릭보다 20배 빠르게 문제를 예측하는 선행 지표를 제공하여 프로젝트 관리에 유리합니다.

## Topic Body

- 스토리 포인트는 완전히 신뢰할 수 없고 혼란을 야기하며, 끊임없이 관련자들에게 그 의미를 상기시켜야 함  
  - 낮은 포인트 값은 더 정확하지만 높은 포인트 값은 높은 변동성을 가정하며 범위를 나타내며, 정확하게 합산이 불가능함  
  - 스토리 포인트는 시간을 나타내지 않지만, 속도 메트릭과 결합될 때 사실상 시간을 의미하게 되어, 처음부터 숫자와 범위를 더하는 행위를 방해함  
- 소프트웨어 추정은 어렵고, 프로세스의 아웃풋은 인풋에 비해 일반적으로 유익하지 않음  
- 방해가 적은 소규모 팀은 정확하게 추정하는 것처럼 보이므로 대부분의 경우 하고 있는 일이 잘 되고 있다는 인상을 줌   
- Capacity가 완전히 활용되면, 모든 작업의 변동성이 급증하여 모든 견적과 타임라인에 급격한 영향을 미침  
- 측정된 큐는 단기 및 장기 추정 문제를 해결하고, 자연스럽게 범위 변경을 처리하며, 불확실성을 제거하면서 대규모 팀에게 훨씬 더 가치 있는 연습을 제공  
- 측정된 큐는 속도나 사이클 시간 관련 메트릭보다 20배 빠르게 문제를 예측하는 선행 지표를 제공함  
  
#### 스토리 포인트란 무엇인가?  
  
- [Atlassian](https://www.atlassian.com/agile/project-management/estimation)에 따르면, 스토리 포인트는 제품 백로그 항목 또는 다른 작업을 완전히 구현하는 데 필요한 전체 노력의 추정을 표현하는 단위임  
- 포인트는 복잡성, 작업량, 리스크 또는 불확실성, 작업의 양을 나타냄  
- 복잡성 측정은 상대적인 개념으로, 팀마다 같은 작업에 대해 다르게 평가할 수 있음  
- 포인트의 상대적 특성으로 인해 팀 간 비교는 의미가 없으며, 이는 관리 수준에서 자주 발생하는 문제임  
  
#### 내재된 변동성  
  
- 스토리 포인트는 피보나치 수열을 기반으로 하여 높은 값일수록 변동성을 더 크게 나타냄  
- 변동성이 큰 포인트 값들을 합하는 것은 의미가 없으며, 속도 메트릭에서 포인트를 합산하는 행위는 잘못된 것임  
- Goodhart의 법칙에 따르면, 측정이 목표가 되는 순간 그 측정은 좋은 측정이 될 수 없음  
  
#### 알려진 문제점  
  
- 스토리 포인트의 문제는 잘 알려져 있지만, 대체 추정 기술도 비슷한 문제를 겪기 때문에 여전히 사용되고 있음  
- 스토리 포인트의 창시자인 Ron Jeffries는 이를 부정하고, 오용에 대해 비판함  
- Scrum에서 "Commitment"를 "Forecast"로 변경했으나 여전히 잘못 사용되고 있음  
- 추정치보다 더 많은 일을 해내면 오히려 질타를 받는 역설적 상황이 발생함  
  
#### ROI로 우선순위 정하기  
  
- 비즈니스는 리소스(시간, 돈, 도구, 사람)를 최적화하기 위해 작업의 우선순위를 정함  
- 개발 추정은 투자 비용을 계산하는 데 필요하지만, 추정 자체가 어렵고 비용이 많이 듦  
- [Software Estimation: Demystifying the Black Art](https://amzn.to/3LmvBcn)은 추정의 어려움을 다루는 훌륭한 책임  
  
#### 프로세스의 출력  
  
- 스토리 포인트 추정 과정은 많은 시간을 투자하지만, 출력이 가치가 없음  
- 정기적인 그루밍 세션은 시간이 많이 걸리며, 팀 간 일관성 없이 다양하게 적용됨  
- 스토리 포인트 대신 유의미한 작업 목록을 작성하는 것이 더 가치가 있음  
  
#### 대안 제시  
  
- T-셔츠 사이즈로 추정하는 것이 더 나은 대안이 될 수 있지만, 이 또한 문제가 있음  
- 시간으로 추정하는 것도 유사한 문제가 있으며, 팀이 실제로 일하는 시간과 비즈니스 측에서 기대하는 시간이 다름  
- 작은 팀에서는 시간 추정이 잘 작동할 수 있지만, 팀이 커지면 추정의 정확도는 떨어짐  
- 도널드 라이너트슨의 "The Principles of Product Development Flow" 책에서 대안을 제시함  
  - 대기열(Queue) 관리에 초점을 맞추어 작업의 흐름을 최적화하는 것이 핵심  
  - 용량 계획을 세우고 변동성을 수용할 수 있는 버퍼 용량을 확보해야 함  
  
### 해결책  
- 팀이 함께 작업을 분석하여 작은 태스크 단위로 나누고 불확실성을 제거하는 것에서 시작  
- 태스크 목록은 대기열(Queue)이 되며, 총 태스크 수는 작업량(Job Size)을 나타냄  
- Story Point 대신 평균 Task 완료율(Average Task Rate)을 사용하여 추정  
- 평균 작업 속도를 기반으로 작업을 추적하고, 작업 완료율을 계산함  
- 새로운 정보나 피드백에 따라 태스크를 업데이트하면 자연스럽게 추정치가 조정됨  
- 개발자들이 추정에 대한 심리적 압박을 받지 않아도 됨  
  
### 대기열(Queue)은 선행 지표  
- 평균 태스크 완료율, Cycle Time, Velocity 등은 후행 지표인 반면, Queue는 선행 지표  
- Queue 크기가 증가하면 문제를 사전에 인지하고 대응할 수 있음  
  
### 요약  
- Story Point는 혼란을 야기하고 신뢰할 수 없으며 실패하도록 설계되어 있음  
- 대신 팀이 함께 문제를 이해하고, 불확실성을 제거하며, 태스크 단위로 나눠 Queue를 관리하는 데 시간을 투자하는 것이 의미 있고 가치 있는 일임  
  
### GN+의 의견  
- 기사에서 제시한 대기열 관리 방식은 애자일 개발에서 추정의 어려움을 극복할 수 있는 현실적인 대안으로 보임  
- 다만 태스크를 잘게 나누는 과정에서 개발자들의 수고로움이 있을 수 있고, 프로젝트 초기 단계에는 시간이 더 소요될 수 있음  
- 또한 태스크 분석 과정에서 개발자들의 적극적인 참여와 솔직한 의견 개진이 전제되어야 함  
- 한편으로는 개발 팀이 비즈니스 요구사항을 깊이 이해하고 함께 고민하는 긍정적 효과도 기대할 수 있음

## Comments



### Comment 27372

- Author: heal9179
- Created: 2024-07-19T02:15:56+09:00
- Points: 1

저게 칸반 방법론 아닌가요..?

### Comment 27337

- Author: neo
- Created: 2024-07-17T21:34:23+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40969693) 
- 개인적인 경험으로는 스토리 포인트의 숫자는 중요하지 않았지만, 팀이 작업의 복잡성을 평가하는 과정은 매우 유용했음
  - 스토리 포인트를 작업 시간 예측에 사용하는 것은 신뢰할 수 없는 지표였음
  - 팀과 도메인의 변화, 개발 외 작업의 가변성 등 여러 이유로 인해 스토리 포인트를 피하려고 함
  - 스토리 포인트를 사용하는 팀에서는 이를 작업 이해를 공유하는 도구로 사용했음

- Scrum 가이드에서 "Commitment"가 "Forecast"로 변경된 것은 2011년이 아님
  - 2010년과 2011년 가이드를 확인한 결과, "Commitment"라는 단어는 2011년 이전 버전에 없었음
  - "Forecast"는 2020년 가이드에서 "Estimate"를 대체했음

- 작업 패키지를 원자 단위로 분해하고 큐 길이를 측정하는 것은 다른 차원의 문제임
  - 작업 패키지를 팀과 함께 정제하면서 스토리 포인트를 사용할 수 있음
  - 모든 작업을 1 스토리 포인트로 분해하는 것은 비효율적이었음
  - 큐 길이와 가변성의 영향을 연결하는 것은 흥미로운 개념임

- 워터폴 방식과 시간 단위로 추정하는 것이 잘 작동하는 경우도 있음
  - 소규모 전문 서비스 팀에서 고객 요구사항을 문서화하고 팀과 논의한 후 시간 범위로 추정함
  - 고객이 승인하면 상세 설계, 개발, QA, 릴리스 과정을 거침
  - 20년 동안 프로세스가 변하지 않았고, 생산성이 높은 팀으로 평가받음

- 스토리 포인트는 시간 단위가 아닌 상대적 복잡성과 불확실성을 나타냄
  - 큰 숫자로 스토리를 측정할 수 있어야 함
  - 일부 팀에서는 7 이상의 포인트를 주지 않음
  - 다른 곳에서는 21, 30, 50 포인트를 주기도 했음

- 스토리 포인트는 대략적인 시간 단위였음
  - 스토리 포인트를 명확한 시간 단위로 맞추는 것은 오해의 소지가 있음
  - 개발자가 작업에 얼마나 시간을 쓸지 예측하는 것이 중요함
  - 큐 분석이 도움이 되려면 각 작업의 예상 시간을 알아야 함

- Scrum을 처음 사용할 때 Rally를 사용했음
  - 스토리 포인트, 예상 시간, 실제 시간을 모두 추적했음
  - Jira로 전환 후 시간 추적이 없어졌음
  - 예상 시간이 정확해지면서 팀의 작업 균형을 맞추기 쉬워졌음

- 스토리 포인트는 작업 복잡성을 논의할 때 유용하지만, 속도를 측정하는 데는 부적합했음
  - 새로운 엔지니어로서 많은 스토리 포인트를 처리했지만, 관리진이 이를 조정하려 했음
  - 복잡한 작업을 적절히 평가하기 어려웠음

- 소프트웨어 개발 프로젝트를 신뢰할 수 있게 추정하는 것은 어려움
  - 팀과 함께 작업을 작은 단위로 나누고 시간 범위를 추정하는 것이 중요함
  - 프로젝트가 진행됨에 따라 기능 목록과 새로운 추정 범위를 보고하는 것이 중요함

- 시간 단위로 추정하는 것이 더 나은 방법임
  - 스토리 포인트는 결국 시간 단위로 변환됨
  - Scrum의 복잡한 절차를 피하고 작업을 완료하는 것이 더 효율적임