스토리 포인트는 팀이 특정 기능을 개발하는데 필요한 노력의 양을 추정하기 위한 편리하고 효율적인 측정 기술이다.

스토리 포인트는 추정치이다. 추정은 예측을 하는 것이고 실제 사실과는 다를 수 있다. 애자일 및 스토리 포인트의 제작자도 정기적인 스프린트 기대치를 충족시키지 못했다고 한다. 경영진은 숫자, 약속, 속도등을 원하기에 스토리 포인트를 이용해 그들을 즐겁게 한거라고 한다. 결국 스토리 포인트를 추가함으로써 경영진을 행복하게 만드는 방법을 찾은 것이다. (믿거나~ 말거나~)

일반적으로 사용자 스토리가 주어지면 스토리의 복잡성을 숫자로 추정한다. 1-5 혹은 1-10 범위로 제한되며 때로는 큰 추정치로 작성한다.

예전부터 스토리 포인트를 사용했었다. 스토리 포인트가 팀의 작업 능력을 식별하는 데 도움이 된다고 생각했다. 그러나 이번에 진행을 하면서 스토리 포인트와 퍼포먼스 측정을 내가 잘 사용하고 있는가에 대한 의문이 들었다.

몇 가지 가정을 해보자. 모든 개발자가 동등한 역량을 지니고 있고, 유사한 스킬을 가지고 있고, 전체 스프린트에 걸쳐 있고, 다른 스프린트에 속하지 않는다면, 예측 가능한 시간으로 작업할 수 있기에 추정치와 비슷하게 나올 것이다. 하지만 현실에서는 거의 불가능하다고 생각한다. 그 이유는 아래에 언급한 것들을 세세하게 고려하기가 어렵기 때문이다.

• Lamp-up 타임 (문제를 이해하고 그 문제를 해결하는 시간) - 사람마다 다르기에 이 부분이 고려되어 있지 않다.
• 방해 타임 (회의, 1:1 미팅, 비즈니스 우선 순위 변경, 개인 사유등)
• 숨겨진 작업

스토리 포인트는 무엇을 추정하는데 사용되는 것일까? 고정된 크기의 스프린트와 정확한 포인트 추정치가 존재한다면, 예측 가능한 번다운 비율이 있어야 한다. 이를 통해 고정된 시간 내에 수행될 작업을 매우 정확하게 예측할 수 있게된다. 그러나 현실에서는 정확한 포인트 추정을 할 수 없다. 그래서 번다운 비율을 예측하기가 어렵다. 그렇다고 해서 스토리 포인트가 가치가 없는 것은 아니다.

스토리 포인트의 역할은 복잡성을 측정하는 것이다.우리팀이 스프린트당 얼마나 많은 복잡성을 처리 할 수 있는지에 대한 추정해 볼 수 있는 것인데, 단순히 시간과 같은 것으로 생각했던 것 같다. 일반적으로 포인트1당 = 하루로 계산했던 것 같다. 물론 이렇게 계산하는게 내부적으로도 편하고 경영진과 의사소통하기에도 무난했지만, 이는 잘못된 방식인 것을 깨달았다. 스토리 포인트는 관리를 위한 것이라기보다는, 팀을 위한 것인데… 이 부분을 놓쳤던 것 같다.

우리 인간의 두뇌는 하루에도 많은 일을 처리하고 있다. 팀원들은 시간을 기능으로 바꾸는 기계가 아니다. 즉, “8시간이 하나의 기능을 의미한다면 16시간에는 2개의 기능을 의미한다.” 처럼 잘못된 것으로 인지 될 수 있다. 이것은 사실이 아니기 때문이다. 인간이 하루에 집중할 수 있는 시간은 생각보다 많지 않다고 생각한다. 스토리 포인트가 5점이라고 해서 1점보다 5배의 시간이 걸린다는 의미는 아니고 1점보다 5배 더 복잡하다는 의미로 생각해야했다. 일반적으로 5점짜리가 1점짜리보다 더 많은 시간이 걸릴 가능성이 매우 높기에 이를 시간으로 환산 하려 했던 점이 잘못되었던 것 같다.

이번에 Jira를 세팅하면서 제품 백로그를 추정하기 위해 스토리 포인트를 사용했다. 하지만 스프린트 백로그는 포인트 단위가 아닌 시간 단위로 추정하도록 했다. 즉, 스토리 포인트는 복잡도/장기적 관점에서 활용하고 스토리 포인트는 스프린트 시간으로 나누는 방식이다.

앞으로 스토리 포인트는 팀이 현재 스프린트의 복잡성 추정하는 용도로만 사용할 것이다.

References

• https://rigidity.medium.com/agile-waste-story-points-pt-1-a9df2572d0a3
• https://www.leadingagile.com/2018/12/the-problem-with-story-points/