스토리포인트의 대안

 

스크럼은 애자일의 가치를 실현시키기 위한 프레임워크입니다. 이 때, 작업자들이 수행해야 하는 티켓의 규모 또는 복잡도를 나타내기 위해 '스토리포인트'라는 개념을 사용하게 되는데요. 오늘은 이 스토리포인트의 개념에 대해서 짚어보고, 이 개념이 실무에서 쓰기에 부적절한 이유를 물리량의 관점에서 설명드린 뒤, 스토리포인트의 대안을 제시해보려고 합니다.

 

스토리포인트와 추정

스토리 포인트는 제품 백로그 항목 또는 기타 작업을 완전히 구현하는 데 필요한 전반적인 노력의 추정치를 표현하기 위한 측정 단위입니다. 팀은 작업 복잡성, 작업량, 위험 또는 불확실성과 관련하여 스토리 포인트를 할당합니다.

https://www.atlassian.com/ko/agile/project-management/estimation

 

아틀라시안의 포스팅에서 스토리포인트를 '전반적인 노력의 추정치'로서 정의합니다. 이 스토리포인트는 '플래닝포커'라는 행위를 통해서 측정됩니다. (플래닝포커를 진행하는 방식에 대해서는 이 글에서는 자세히 설명하지 않습니다.) 이렇게 측정된 스토리포인트가 갖게 되는 의미는 다음과 같습니다.

경험주의

먼저, 팀이 결성된 초기에는 스토리포인트가 제대로 측정되지 않을 수 있습니다. 스크럼 가이드에서는 '경험주의'를 강조하는데, 스크럼이란 어떤 정해진 프레임워크라기보다는, 팀에 의해 개선될 수 있고, 커스텀하게 운영되어야 한다는 것입니다. 마찬가지로, 플래닝포커를 거듭할수록 구성원 간에 서로를 더 이해하게 되고, 프로덕트를 이해하게 되면서 합이 맞아지게 된다는 기대를 그 근거로 하고 있습니다.

더 나은 스토리포인트 추정이 되어가는 과정

특정 작업의 스토리포인트가 할당이 되고, 그 스토리포인트가 적절했는지에 대해서 회고에서 이야기합니다. 어떤 이유로 스토리포인트가 더 높았어야 했는지, 또는 더 낮았어야 했는지를 서로 평가하고 피드백합니다. 이러한 행위는 추후 플래닝포커에 근거가 되어 더 나은 스토리포인트를 '추정'할 수 있도록 도움을 줄 수 있어야 합니다.

거대한 스토리포인트

스토리포인트가 크게 잡혔다는 것은, 그 작업이 더 세분화되어야 한다는 의미이기도 합니다. 따라서, 플래닝포커 중에 스토리포인트가 높게 책정된 작업이 있다면, 그 작업을 세분화하여 작업을 구체화합니다. 곧, 스토리포인트가 크다는 것은 해당 작업의 정의가 모호하다는 것을 의미하기도 합니다. 

벨로시티

이렇게 측정된 스토리포인트는 팀의 벨로시티(velocity)를 측정하는 데 사용되게 됩니다. 팀이 지난 3개의 스프린트동안 처리한 스토리포인트가 각각, 26sp, 21sp, 32sp 였다면 지난 3개의 스프린트동안 처리한 스토리포인트의 평균은 약 26.3 이므로, 다음 스프린트에서 이 팀이 해결하길 기대하는 스토리포인트는 26.3 입니다. 즉, 하나의 스프린트 동안 팀이 처리할 수 있는 스토리포인트의 기댓값이 '벨로시티'입니다. (단위: story points/sprint)

벨로시티로 프로젝트 완료 시기 추정

회사에서 하나의 큰 프로젝트를 팀에 맡겼고, 이 프로젝트를 기능 단위로 구분해서 나눠보았더니 약 30개정도의 작업(티켓)으로 분리되어 명세할 수 있었다고 가정합시다. 30개의 작업 각각에 대해서 플래닝포커를 진행했고, 계산된 스토리포인트의 총 합은 80sp 가 되었습니다. 그렇다면, 이 팀이 이 프로젝트에 몰두하였을 때, 프로젝트 완성까지 기대되는 소요 스프린트는 80sp / 26.3sp/sprint 으로 계산하여 3.04sprint 가 나오게 됩니다. 약 3번의 스프린트를 거치면 해당 프로젝트가 완성될 수 있다고 기대할 수 있는 것입니다.

 

반응형

 

스토리포인트의 결함

물리량으로서의 스토리포인트

학창시절 수학이나 과학 시험을 볼 때, 가령 계산 결과로 '길이'를 써야 한다면, '27cm'와 같이 그 단위를 꼭 써주어야만 정답처리가 되고, '27'으로만 쓰면 오답처리가 되는 기억이 납니다. 스토리포인트는 '단위'를 정할 수 없기 때문에 추정으로서는 어색한 개념입니다.

 

위 아틀라시안 포스팅을 참고하더라도 스토리포인트를 구성하는 요소는 복잡성, 작업량, 위험 또는 불확실성 이 복합적으로 작용하여 결정됩니다. 여기에서 나열된 개념만 4가지인데, 이 4가지의 각각 정의되기도 힘들뿐더러, 정의된다고 하더라도 서로 단위가 다를 것이기에 이걸 합산하여 표현하기에는 무리가 있습니다. 이러한 개념을 팀 단위에서 '경험주의'라는 이름 아래, 플래닝포커를 통해 집단지성을 이용한 어떤 연결고리를 만들어내어 팀 내에서 통용되는 관습적 의미의 '스토리포인트'를 완성시킬 수는 있지만, 문제는 이 스토리포인트가 결국 '벨로시티'와 연결된다는 것입니다.

작업량 추정을 시간과 떼어내기

스토리포인트가 제안된 배경에는, 시간 기반의 추정이 작업자들을 시간에 쫓기게 만들거나, 압박감을 주어 프로덕트 개발에 방해가 된다는 가정이 담겨 있습니다. 그래서 스토리포인트는 숫자가 아닌 티셔츠 사이즈로 측정하기도 하고 피보나치 수열로 한정하기도 하는 것입니다. 어차피 틀릴 추정을 정확히 하려고 애쓰지 말자는 의도도 담겨 있습니다. 여기서 추구하려고 하는 본질이 무엇이었는지는 개인적으로도 굉장히 공감이 되는 부분입니다. 하지만 결국 이 스토리포인트들은 평균이 내어져 벨로시티의 재료가 됩니다.

 

고전적인 물리 개념인 '거리', '시간', '속도'의 개념을 보면, 거리라는 개념 자체는 시간과 관계 없는 개념이지만 '속도'를 정의하면서 연관되어지게 됩니다. 결국 '속도'를 정의하면서부터 '거리'와 '시간'의 개념의 관계가 형성됩니다. 이는 스토리포인트와 벨로시티의 관계에 대해서도 동일하게 적용된다고 볼 수 있습니다.

스토리포인트의 대안

론 제프리즈의 사과

론 제프리즈(Ron Jeffries)는 스토리포인트의 창시자라고 여겨지는 인물입니다. 2019년 5월에 글을 하나 올리게 되는데, '스토리포인트 발명에 대한 사과'라고 이름 붙일 수 있을 것입니다.

I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think.

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

 

 스토리포인트의 개념이 어떻게 업계에서 왜곡되어 사용되고 있는지, 그리고 현재 자신이 생각하는 스토리포인트의 대안에 대해 설명합니다. 이 글이 스토리포인트의 발명에 대한 사과처럼 보이지만, 실은 그렇다기보다, 제품 개발에 있어서의 본질이 무엇인지 다시금 생각해보게 해주는 글이라 꼭 따로 읽어보시기를 권해봅니다.

 

위 인용문의 본문의 내용을 정리하면 다음과 같습니다.

• 비교: 불행하게도 추정치로 팀을 비교하는 잘못은 흔하게 일어남 (본능임)
• 추적: 추정을 정확하게 하기보다 가치를 빠르게 전달하는 것이 중요
• 압박: 많이 하는 것보다 가치 있는 일을 하는 것이 중요
• 예측완료: 마감일을 정해 한꺼번에 작업을 전달하기보다, 가까운 날짜를 정해 가장 좋아보이는 기능을 제공하는 것이 중요
• 분할: 스토리포인트 추정의 대안 - 하루보다 적게 걸리는 작업으로 분할하기
• 미래예측: 그럼에도 추정이 필요하지 않아요? 라는 질문에 대한 가이드(는 위 인용문 링크 참조)

스토리를 작게 나누기

위 론 제프리즈의 글에서는 스토리를 나누라고 제안합니다. 가능하면 작은 노력을 들이면서도 높은 가치를 전달할 수 있는 작업으로요. 작업 시간도 제안합니다. 하루보다 적게 걸리거나 수시간동안 작업할 수 있는 분량으로요. 

 

작업이 실제로 얼마나 걸릴지 정확히 그 누구도 알 수 없습니다.

“when will all this be done?” The answer is that no one knows.

 

3개월이 걸릴 것 같은 작업에 대한 추정이 3일이 걸릴 것 같은 추정보다 오차가 더 크게 날 것입니다. 따라서, 작업이 세분화 될수록, 오히려 추정하기 쉬워집니다.

 

추정은 본래 미래 예측의 속성을 갖기에 정밀하기 어려운 행위이지만, 작게 만들 수록 그 오차를 줄일 수 있습니다. 즉, 스토리를 작게 만들수록 프로젝트(또는 릴리즈)의 예측가능성을 높일 수 있습니다.

Productivity VS Activity

스토리포인트라는 주제 자체가 어떻게 하면 '추정을 제대로 해볼 수 있을까'라는 질문에서 찾게 된 개념이라면, 그 질문의 방향을 바꿔야 함을 론 제프리즈는 이야기합니다. 추정보다 중요한 것은 가치의 전달이라고요. one thing 의 저자는 한 인터뷰에서 생산성(Productivity)과 Activity(활동)을 구분지어 이야기합니다. 진정한 생산성은 정해진 시간에 정해진 일을 최대한 많이 해내는 것이 아니라, 가치 있는 일을 해내는 것이 생산성이라고 언급합니다.

 

정리

스토리포인트의 개념과 활용되는 방식에 대해 알아보는 것을 시작으로 스토리포인트의 결함이 무엇인지 물리량의 예를 근거로 설명해보았습니다. 이어서 스토리포인트의 창시자가 스토리포인트의 대안으로 제시하는 여러 개념들을 살펴보았습니다. 중요한 것은 '정확한 추정'보다 '가치를 더하는 것'임을 알 수 있었는데요. 그렇더라도, 추정을 해야 한다면 스토리를 더 잘게 쪼개 하루보다 적은 수시간 단위의 일로 나누는 것이 타당하다는 제안 또한 알아보았습니다. 개인적으로도 내가 해야겠다라고 생각한 모든 일들을 해내기 위해 어떻게 하면 생산성을 높일 수 있을까? 를 고민해왔었는데요. 점점 모든 일을 다 해낼 수는 없음을 깨달아가는 요즘입니다. 어떻게 하면 더 가치 있는 일을 할 수 있을까? 그렇다면 내가 집중하지 않아야 되는 일은 무엇인가, 버려야 하는 열망은 무엇인가에 대해서도 질문해보게 되는 순간이었습니다. 이 글이 여러분들께서 더 가치 있는 일에 집중하게 되는 계기가 되길 바라면서 이만 글을 마칩니다.

 

To me, the important thing in Real Agile is to pick the next few things to do, and do them promptly. The key question is to find the most valuable things to do, and to do them quickly. - Ron Jeffries