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

• 스토리 포인트는 완전히 신뢰할 수 없고 혼란을 야기하며, 끊임없이 관련자들에게 그 의미를 상기시켜야 함
  • 낮은 포인트 값은 더 정확하지만 높은 포인트 값은 높은 변동성을 가정하며 범위를 나타내며, 정확하게 합산이 불가능함
  • 스토리 포인트는 시간을 나타내지 않지만, 속도 메트릭과 결합될 때 사실상 시간을 의미하게 되어, 처음부터 숫자와 범위를 더하는 행위를 방해함
• 소프트웨어 추정은 어렵고, 프로세스의 아웃풋은 인풋에 비해 일반적으로 유익하지 않음
• 방해가 적은 소규모 팀은 정확하게 추정하는 것처럼 보이므로 대부분의 경우 하고 있는 일이 잘 되고 있다는 인상을 줌
• Capacity가 완전히 활용되면, 모든 작업의 변동성이 급증하여 모든 견적과 타임라인에 급격한 영향을 미침
• 측정된 큐는 단기 및 장기 추정 문제를 해결하고, 자연스럽게 범위 변경을 처리하며, 불확실성을 제거하면서 대규모 팀에게 훨씬 더 가치 있는 연습을 제공
• 측정된 큐는 속도나 사이클 시간 관련 메트릭보다 20배 빠르게 문제를 예측하는 선행 지표를 제공함

스토리 포인트란 무엇인가?

• Atlassian에 따르면, 스토리 포인트는 제품 백로그 항목 또는 다른 작업을 완전히 구현하는 데 필요한 전체 노력의 추정을 표현하는 단위임
• 포인트는 복잡성, 작업량, 리스크 또는 불확실성, 작업의 양을 나타냄
• 복잡성 측정은 상대적인 개념으로, 팀마다 같은 작업에 대해 다르게 평가할 수 있음
• 포인트의 상대적 특성으로 인해 팀 간 비교는 의미가 없으며, 이는 관리 수준에서 자주 발생하는 문제임

내재된 변동성

• 스토리 포인트는 피보나치 수열을 기반으로 하여 높은 값일수록 변동성을 더 크게 나타냄
• 변동성이 큰 포인트 값들을 합하는 것은 의미가 없으며, 속도 메트릭에서 포인트를 합산하는 행위는 잘못된 것임
• Goodhart의 법칙에 따르면, 측정이 목표가 되는 순간 그 측정은 좋은 측정이 될 수 없음

알려진 문제점

• 스토리 포인트의 문제는 잘 알려져 있지만, 대체 추정 기술도 비슷한 문제를 겪기 때문에 여전히 사용되고 있음
• 스토리 포인트의 창시자인 Ron Jeffries는 이를 부정하고, 오용에 대해 비판함
• Scrum에서 "Commitment"를 "Forecast"로 변경했으나 여전히 잘못 사용되고 있음
• 추정치보다 더 많은 일을 해내면 오히려 질타를 받는 역설적 상황이 발생함

ROI로 우선순위 정하기

• 비즈니스는 리소스(시간, 돈, 도구, 사람)를 최적화하기 위해 작업의 우선순위를 정함
• 개발 추정은 투자 비용을 계산하는 데 필요하지만, 추정 자체가 어렵고 비용이 많이 듦
• Software Estimation: Demystifying the Black Art은 추정의 어려움을 다루는 훌륭한 책임

프로세스의 출력

• 스토리 포인트 추정 과정은 많은 시간을 투자하지만, 출력이 가치가 없음
• 정기적인 그루밍 세션은 시간이 많이 걸리며, 팀 간 일관성 없이 다양하게 적용됨
• 스토리 포인트 대신 유의미한 작업 목록을 작성하는 것이 더 가치가 있음

대안 제시

• 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+의 의견

• 기사에서 제시한 대기열 관리 방식은 애자일 개발에서 추정의 어려움을 극복할 수 있는 현실적인 대안으로 보임
• 다만 태스크를 잘게 나누는 과정에서 개발자들의 수고로움이 있을 수 있고, 프로젝트 초기 단계에는 시간이 더 소요될 수 있음
• 또한 태스크 분석 과정에서 개발자들의 적극적인 참여와 솔직한 의견 개진이 전제되어야 함
• 한편으로는 개발 팀이 비즈니스 요구사항을 깊이 이해하고 함께 고민하는 긍정적 효과도 기대할 수 있음

[heal9179]

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

[neo]

Hacker News 의견

• 개인적인 경험으로는 스토리 포인트의 숫자는 중요하지 않았지만, 팀이 작업의 복잡성을 평가하는 과정은 매우 유용했음

  • 스토리 포인트를 작업 시간 예측에 사용하는 것은 신뢰할 수 없는 지표였음
  • 팀과 도메인의 변화, 개발 외 작업의 가변성 등 여러 이유로 인해 스토리 포인트를 피하려고 함
  • 스토리 포인트를 사용하는 팀에서는 이를 작업 이해를 공유하는 도구로 사용했음

• Scrum 가이드에서 "Commitment"가 "Forecast"로 변경된 것은 2011년이 아님

  • 2010년과 2011년 가이드를 확인한 결과, "Commitment"라는 단어는 2011년 이전 버전에 없었음
  • "Forecast"는 2020년 가이드에서 "Estimate"를 대체했음

• 작업 패키지를 원자 단위로 분해하고 큐 길이를 측정하는 것은 다른 차원의 문제임

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

• 워터폴 방식과 시간 단위로 추정하는 것이 잘 작동하는 경우도 있음

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

• 스토리 포인트는 시간 단위가 아닌 상대적 복잡성과 불확실성을 나타냄

  • 큰 숫자로 스토리를 측정할 수 있어야 함
  • 일부 팀에서는 7 이상의 포인트를 주지 않음
  • 다른 곳에서는 21, 30, 50 포인트를 주기도 했음

• 스토리 포인트는 대략적인 시간 단위였음

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

• Scrum을 처음 사용할 때 Rally를 사용했음

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

• 스토리 포인트는 작업 복잡성을 논의할 때 유용하지만, 속도를 측정하는 데는 부적합했음

  • 새로운 엔지니어로서 많은 스토리 포인트를 처리했지만, 관리진이 이를 조정하려 했음
  • 복잡한 작업을 적절히 평가하기 어려웠음

• 소프트웨어 개발 프로젝트를 신뢰할 수 있게 추정하는 것은 어려움

  • 팀과 함께 작업을 작은 단위로 나누고 시간 범위를 추정하는 것이 중요함
  • 프로젝트가 진행됨에 따라 기능 목록과 새로운 추정 범위를 보고하는 것이 중요함

• 시간 단위로 추정하는 것이 더 나은 방법임

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