스토리 포인트, 별도 추정해도 되나요?
스토리 포인트 별도 추정 리얼 후기
0. 들어가며
지난 글에 이어, 이번에는 별도 추정 케이스에 대해 이야기해보겠습니다.
여기서 말하는 별도 추정이란, 기획/개발/디자인별 스토리를 나누고, 그 스토리 단위로 스토리 포인트를 추정하는 것을 의미합니다.
1. 현황
지난 번에도 이야기했듯, 개발 중인 툴은 다른 곳과 마찬가지로 기획자, 개발자, 디자이너가 협업합니다. 협업 방식으로는 '듀얼 트랙 스크럼'을 채택하고 있습니다.
개발자와 디자이너가 기획 초기 단계부터 참여하여 공유된 이해를 형성하고, 효율적인 프로세스를 거쳐 기능을 개발하는 프로세스입니다.
듀얼 트랙 스크럼, 이런 느낌입니다.Design Track과 Develop Track이 나뉘어 있습니다.
스토리도 아래처럼 분리했습니다.
유저 스토리 1 : '공간 관리 기능 기획'
유저 스토리 2 : '공간 관리 기능 디자인'
유저 스토리 3 : '공간 관리 기능 개발'
여기서 드는 의문에 대해 이야기해봅니다.
"사용자 스토리를 기획/개발/디자인으로 분리하는 프로세스, 미니 워터폴이나 진배없잖아요? 스토리 포인트 추정이 의미가 있나요?"
2. 듀얼 트랙 스크럼과 업무별 스토리 추정
아시다시피,
스토리 = 일의 덩어리, 기획 + 개발 + 디자인 (+QA 외 개발 관련 업무)입니다.
그런데 이 전제는 저희가 듀얼 트랙 스크럼을 진행하면서 두 방면에서 충돌하게 되는데요.
첫 번째로 듀얼 트랙 스크럼에서는 기획과 디자인, 개발이 독립적으로 업무를 진행하기 때문에 하나의 기능 단위인 스토리와 충돌합니다.
두 번째는 듀얼 트랙 스크럼 방법론 자체가 UX에 대한 고민이 수반하면서 파생한 방법론이기 때문에, 스토리 진행 중 기획/디자인, 기획/개발 등 서로 인터럽션이 너무 자주 발생한다는 것입니다. 비정기적인 인터럽션에 대한 스토리 포인트 추정은 당연히 어렵고요.
소수 인원이 여러 개의 기능을 효율적으로, 빠르게 개발하기 위한 방법을 찾다 보니 듀얼 트랙 스크럼이 적합하다는 결론은 내렸으나...
스토리 포인트는 어떻게 추정하면 좋을지 고민하다가 결국 가장 단순한 것이 가장 정확할 것이란 생각을 하게 됩니다. 그래서 기획/디자인/개발 스토리를 분리하고 각 스토리에 대한 스토리 포인트를 산정했습니다.
결론부터 말하면, 의외로(?) 효과적이었습니다.
스토리를 분리하니 각 담당자는 기간 내 어느 정도 범위의 업무를 수행할 것인지 더 구체적으로 그릴 수 있게 되었습니다. 스토리에 대한 설명을 구체적으로 할 수 있게 되자 스토리 포인트 추정 정확도가 높아졌습니다. 특정 분야에 일이 몰리는 상황도 줄었습니다.
팀의 벨로시티는 비슷한 선에서 유지되었는데, 정확도는 높아지고 헤매는 상황이 줄어드니 결과물 측면에서 완성도가 조금 더 높아졌습니다.
듀얼 트랙 스크럼을 진행하더라도, 어렵게 생각할 필요 없이 각 스토리별 스토리 포인트를 추정하는 것이 외려 더 정확하다는 결론을 내렸습니다.
4. 마무리
저희는 여러 방법을 시도하다 보니 위 방법으로 정착했지만, 이것이 반드시 정답이라 말하기는 어렵습니다. 지금까지 진행했던 스토리 포인트 산정과 다른 측면이 분명 존재하니까요. 어쩌면 최적의 방안을 아직 찾지 못한 걸지도 모릅니다.
다만 저희와 비슷한 고민을 갖고 있다면, 저희는 어떤 방법으로 문제를 해결했는지 공유한 것에 가까우니 참고하는 수준에서 봐주셨으면 합니다.
추후 더 나은 방안을 찾으면 공유하겠습니다. :)
5. 참고
https://brunch.co.kr/@640b9d9bfc7a480/10
