스토리 포인트로 개인의 생산성을 측정할 수 있을까?
0. 들어가며
'에센셜 스크럼'이라는 책을 읽고, 스토리 포인트를 활용해서 개인의 생산성을 추정할 수 있을까? 하는 궁금증이 들어 작성한 글입니다.
1. 스토리 포인트란?
책에서는 스토리 포인트를 '상대적 크기', '제품 백로그 항목의 크기 혹은 규모를 측정하는 것', '복잡성과 물리적 크기를 모두 고려하는 방법'으로 소개하고 있습니다.
쉽게 말하자면 업무 덩어리마다 난이도 등에 따라 처리에 필요한 시간과 노력이 다르니 이를 고려해서 각 덩어리에 포인트를 매기는 것입니다.
이 때 스토리 포인트는 작업자와 별개로, 스토리 그 자체의 어려움을 나타내는 값입니다.
스토리 포인트는 개발팀 인원 전체(기획, 디자인 등 포함)가 합의 하에 산정하며, 상대적인 값이기 때문에 스프린트 진행에 따라 달라질 수 있습니다. 또한 스토리 포인트는 정밀한 것이 아니라, 추정 수단일 뿐입니다.
2. 궁금증
위에서도 언급했듯 스토리 포인트는 작업자를 기준으로 하는 것이 아니라 팀을 위한 것이지만, 팀별 생산성을 비교하기 위한 지표는 아닙니다. 해당 팀의 상황과 업무 가능 정도를 알려주는 지표에 더 가깝습니다.
여기서 궁금한 부분이 생겼습니다. 스토리 포인트로 해당 스프린트에서 팀원의 생산성도 추정할 수 있을까요?
3. 테스트
그래서 데이터를 기반으로 시뮬레이션을 진행해봤습니다.
가설
스프린트 기간 동안 처리한 스토리 포인트가 많을수록, 그 사람의 생산성은 스토리 포인트가 낮은 사람보다 높다.
필요 데이터
각 팀원이 스프린트별로 완료한 스토리 포인트 값
핫픽스, QA, 협업 부서 이슈 등 돌발 상황 처리 시 스토리 포인트화 (소요한 시간이나 일 수 등을 고려하여 계산)
연휴나 휴가 일정
추가 고려점
다만 위의 단순한 데이터로 처리할 수 없는 정성적인 요소들이 있었습니다.
개인 숙련도가 높은 업무 배정 여부 또는 숙련도 예측값의 정확도
각 일감별 스토리 포인트 산정에 팀원 전체의 동의 및 관여 여부
각 팀원이 일별로 소요한 시간이 동일한지 여부
각 팀원의 평균 업무 처리 속도 예측 정확도 (본인이 산정한 스토리 포인트대로 업무를 진행하였는지)
그 외
...
위의 정성적인 요소를 해결하지 못하면 결국 스토리 포인트는 열심히 예측해봐야 도루묵인 셈입니다.
어떻게 하면 이런 부분을 해결할 수 있을까요?
회고 시 실제 사용한 스토리 포인트를 작성하면 비교가 가능할까요?
스프린트 계획 미팅에서 예측한 스토리 포인트와 스프린트 리뷰에 스토리 포인트를 매겨 대푯값을 비교하면 그 간극이 줄어들지 않을까요?
4. 모든 룰에는 이유가 있다.
아쉽게도 우리 조직 데이터를 대상으로 가설 검증 후 내린 결론은, 스토리 포인트로 개인의 구체적인 공수를 측정하기는 어렵고, 사용해서도 안 된다는 것입니다. 그 이유는 아래와 같습니다.
1. 대푯값의 한계
우선, 대푯값은 충분한 대표성을 띠지 못했습니다. 데이터가 충분히 많고, 이것이 정규 분포를 따르는 수준이거나 검증 가능한 수준이었다면 믿을 수 있겠지만 우리 조직은 이에 해당하지 않았기에 개발자별 개별 데이터 작성이 필요했습니다.
개발자 개개인의 데이터를 가지고 확인한 결과, 결국 해당 업무를 본인이 혼자 오롯이 소화하는 케이스가 거의 없었습니다. (협업이 훨씬 빠르고 효율적인 경우, 인사이트가 없어 시니어의 도움 / 요청을 받는 경우 등)
더불어, 해당 스프린트에 본업 + QA를 모두 수행하는 경우, QA는 스토리 포인트를 책정하지 않기 때문에 데이터로 수치화되지 않는다는 한계가 있었습니다.
2. 예측 불가한 이슈 반영 실패로 인한 특이값 발생
스프린트 도중 이슈는 어쩔 수 없이 발생하는데요. 유관 부서와의 협업 과정에서 담당자의 장기간 부재, 선 / 후행 작업을 진행해줄 동료의 휴가 등 다양한 이슈를 간단하게 처리할 수 없었습니다. 우리 스프린트는 3주 (Working day 기준 15일)인데, 이 중에 1 ~ 2일 자리를 비우는 것도 꽤나 큰 문제였습니다. 게다가 주로 의사 결정을 하는 팀원이 여행을 떠나는 등 휴가를 사용한 경우가 상대적으로 조금 잦았는데요. 이 경우 그 사람이 돌아올 때까지 기다려야 했기에 일부 팀원은 본인의 판단과 관계 없이, 해당 담당자의 복귀를 마냥 기다리기만 해야 하냐며 불만을 표하기도 했습니다.
물론 해당 팀원에게 너무 부담을 주는 것도 문제가 되지만
문제는 이러한 이슈를 '어떻게 스프린트 및 스토리 포인트에 녹일 것인가?' 인데요. 유사한 돌발 상황이 그 다음 스프린트에도 발생한다고 추정할 수 없고, 매 스프린트마다 해당 이슈 발생이 들쭉날쭉하니 데이터를 정규화하기가 어려웠습니다.
3. 스토리 포인트 인플레이션
내 업무량을 보여준다는 것이 일부 조직에서는 평가와 직결되기도 합니다. 저희는 해당 스토리 포인트를 평가에 사용하지는 않았지만 결국 '저 이만큼 일 했어요!'를 어필할 수 있는 방안이고, 업무를 조금이라도 덜 할 수 있다 보니 (abusing) 공수를 부풀려 계상하는 경우가 있었습니다.
그 외에 '우선 스펙 처리만 하자!'에 초점을 맞추어, 완성도가 크게 떨어지고 결국 새로 만들거나 QA에 시간을 많이 소요해야 하는 경우도 있었습니다. 여러모로 부작용이 발생한 것이죠.
5. 마무리하며
위와 같이 개인에 초점을 맞추면 오히려 생각해야 할 것이 늘어나고, 그만큼 통제해야 할 것도 늘어나는 것 같습니다. 저희는 아래 방식으로 보완 해보았습니다.
- 계획 및 회고 단계
스프린트 계획 미팅에서 Spec 단위 일감을 정하고, 그 일감에 대한 스토리 포인트를 산정합니다. 가급적 Spec에 포함할 세부 내용은 구체화하되, 가능한 범위로 나누어 A Spec - 1차는 Sprint 1에, A spec - 2차는 Sprint 2에 진행하는 방식으로 쪼개어 진행했습니다.
-> 이 데이터를 활용해 조직의 Velocity를 산정하였고, 다음 스프린트에서 어느 정도의 업무를 완료할 수 있는지를 추정할 수 있었습니다.
-번다운 / 번업 차트
SP를 잘 소진하고 있는지 파악하기 위해 중간에 번다운 / 번업 차트를 활용하는 조직이 많을 텐데요. 저희 팀도 이를 활용해보려 했습니다. 그런데 저희의 번다운 차트는 Task 단위나 더 큰 단위의 일감이 '완료'될 때 8 -> 0 처럼 급격하게 떨어지기 때문에, 스토리 포인트가 추세선 형태가 아니라 계단식으로 떨어진다는 문제가 있었습니다. 일차적인 해결 방안은 당연히 일감을 쪼개어 실제 일일 진척도를 파악하는 것이지만, 자잘한 일감 관리 작업이 늘어나기 때문에 섣불리 도입하자고 제안하기가 어려운 상황이었습니다. 게다가 일감 구조 상 일감을 쪼개면 하위 일감이 많이 생성되고, 이것이 일을 위한 일이 되는 것은 아닌지 우려되기도 했습니다.
그러나 결국 개인이 조금 더 부지런히 움직이지 않으면 팀의 성과 평가는 요원한 일이다 보니, 관련하여 일감 등록 규약을 정하고 이를 우리 팀에 맞추어 수정 및 개선하는 방향으로 진행하려는 시도까지는 진행했습니다.
-> 실컷 번다운 / 번업 차트를 만들었지만, 이것이 next step으로 이어지지는 않았기에 데이터를 쌓기만 하고 끝났습니다........ 너무 아쉽지만 저희에게는 와닿는 수치는 아니고, 전반적으로 필요성을 이슈업하는 사람도 없었기에 흐지부지된 것 같습니다.
느끼셨겠지만 스토리 포인트 책정 시 조직의 규모나 팀원의 적극성, 참여도도 영향을 주기 마련인데요. 다른 조직은 어떻게 진행했는지 궁금합니다. 혹시나 비슷한 고민을 하신 분이 있다면 후기, 결과 등을 알려주시면 감사하겠습니다. :)
P.S. 꽤 오래 전에 작성하고는 최근에야 꺼낸 글이라, 읽으면서 어색한 감이 있더라도 양해 부탁 드립니다.
