스토리 포인트 산출하기
Story Point Estimation
미래란 앞으로 과거가 될 것을 선취하는 시간개념이다. 지금은 비록 갖고있지 않지만 앞으로는 많은 것을 소유하게 되리라는 사실을 시사한다.
에리히 프롬 <소유냐 존재냐>
처음 Jira에 프로젝트를 셋업하고 팀원들이 읽을 가이드를 작성할 때, 스토리 포인트에 대한 내용은 완전히 배제했다. 스토리 포인트를 모르지는 않았다. 그럼에도 과감하게 뺀 이유는 당시 팀이 특정 이벤트를 기준으로 정해진 일자에 맞추어 MVP를 출시하는 빠듯한 일정으로 달리고 있었기 때문이다.
또 하나의 이유는 이전에 스토리 포인트를 활용하면서 느낀 애매함이었다. 당시 매 스프린트마다 포인트를 관리하는 방식은 이러했다.
프로젝트 매니저와 프로덕트 매니저(나)가 배포 내용과 일정을 합의한다.
프로젝트 매니저는 스프린트 초반에 엔지니어들에게 작업 시간을 기준으로 스토리 포인트 부여를 요청한다. 스프린트 종료 직전에도 리마인드한다.
엔지니어는 각자에게 할당된 태스크의 예상 소요 시간, 또는 작업 후 걸린 시간을 되짚어 스토리 포인트를 부여한다.
이렇게 부여된 스토리 포인트는 사실 프로덕트 매니저에게는 큰 의미가 없었다. 잘 생각해 보면, 다른 사람들에게도 큰 의미가 없었을 것이다.
프로덕트 매니저현재 스프린트에서 할 작업과 일정은 이미 정해져있으므로, 각 태스크에 걸리는 시간은 중요한 정보가 아니다.엔지니어태스크 해결에 소요된 시간을 기록하는 용도로 한정된다.프로젝트 매니저개인의 업무 방식이나 속도, 포인트 부여의 충실성에 편차가 있으므로 리소스 관리 측면에서 신뢰할 만한 지표가 되기 어렵다.
이렇게 누구에게도 뚜렷한 도움이 되지 않는 수치를 관리하기 위해 할애하는 시간이 아까웠다. 긍정적이지만은 않았던 첫인상을 떨치고 스토리 포인트를 다시 도입하기로 한 이유는 이전 포스트에서 아래와 같이 정리했다.
뿐만 아니라, 해야 할 일을 '구현해야 할 기능'의 형태로 소통하는 것보다 '사용자에게 주는 가치'의 형태로 소통하는 관점의 전환이 필요했다. 학생에게 숙제를 주듯 태스크를 전달하는 건 양쪽 모두에게 시시한 방식이다. 사용자에 대해 치열한 고민은 프로덕트 매니저의 무거운 의무지만, 그 혼자서만 고민한다면 팀 전체의 역량에 큰 제한이 생긴다. 동기 부여에도 부정적 영향을 준다.
스토리 포인트 도입의 기대효과가 내 안에서 뚜렷해지기까지는 다음과 같은 과정이 있었다.
이전의 경험을 뒤로하고, 스토리 포인트에 대한 개념을 다시 정리했다. <Agile Estimating and Planning>이라는 책이 많은 도움이 되었다.
스토리 포인트 부여 기준과 진행 방식을 찾아보고 팀에 적합한 적용 방안을 검토했다.
사용자 스토리를 준비하는 형식과 Estimation 과정은 Tanzu Developer Center의 자료를 주로 참고했다. 예시를 시각적으로 확인할 수 있어 유용하다.
그 외 여러 레퍼런스를 종합해 스토리 포인트 산출의 방향성을 정리해 보았다.
중점: 사용자가 겪는 문제를 기반으로 해결책을 구체화한다.
활용 및 기대효과
포인트 부여의 대상(단위)가 되며, 사용자 중심 사고가 논의의 출발점이 되도록 한다.
스프린트 계획을 세우는 Building block으로 활용할 수 있다.
그리고 평소 활용하는 업무 툴을 이용해 스토리 포인트 산출 과정을 진행할 양식을 준비했다.
노션으로 만든 사용자 스토리 백로그 (링크)
사용자 스토리에 필요한 정보를 노션 DB로 만들었다.
상태 관리 기능을 이용해 칸반 보드 형태로 시각화했다.
많은 준비를 했음에도 첫 시도는 순탄치 않아 예상보다 많은 시간이 걸렸다. 과정과 결과 모두 만족스럽지 않았다.
첫 산출 회의의 레슨런
포인트를 부여할 정보가 충분하지 않았다.
설명, 인수 조건과 기타 고려사항을 상세하게 작성해야 한다. 목업 디자인 등 시각적 자료가 있다면 더 좋다.
스토리 해결을 위한 To-do를 먼저 정리하면 포인트 부여가 수월해진다.
To-do 리스트업을 할 수 없는 상태라면 포인트 부여를 보류한다.
스토리를 수정하거나 나눠야 하는 경우 바로 반영해야 한다.
포인트를 결정할 때 시간이라는 요소를 완전히 배제하기는 어렵다.
복잡도, 리스크를 우선적으로 고려하되 최종 합의를 하기 어려울 때 결정 기준으로 사용하도록 한다.
프론트와 백엔드 엔지니어로 구성되어 있어서 만장일치라는 기준이 현실적이지 않다.
프론트 엔지니어들이 합의한 포인트와 백엔드 엔지니어들이 합의한 포인트를 합산하기로 했다.
포인트 공개가 동시에 이루어지지 않아서 부담스럽다.
이 부분은 나(진행자)의 생각이 짧았던 부분. 잼보드에서 동시에 공개하도록 방법을 바꿨다.
구글 잼보드로 만든 플래닝 포커 보드 (링크)
엔지니어들이 링크에 접속해 각자의 노트에 포인트를 작성하고, 동시에 '저장' 버튼을 누르면 포인트가 공개된다.
포인트 스케일 참고차 이전에 포인트를 부여한 스토리를 남겨놓으면 유용하다.
새 시스템을 정착시키려면 시간이 꽤 걸리겠다는 생각이 들었다. 그래서 두 번째 회의 전에는 파악하기 쉬울 만한 작은 단위의 스토리를 많이 준비했다. 그리고 Jira의 모든 태스크에 포인트를 부여하려 하지 않았다. 팀원들이 스토리 포인트에 익숙해지는 것이 우선이었다.
포인트 부여의 주체는 엔지니어다. 기획이나 디자인 등 개발 외 업무에 대한 추정은 스토리 포인트에 포함되지 않는다. 그렇다고 해서 기획과 디자인이 100% 구체화되어야만 포인트 부여가 가능한 것은 아니다. 여러 번의 시행착오를 거치면포인트를 부여하기에 적절한 수준의 정보량을 파악할 수 있다. 다만 제품의 특성, 구성원의 성향, 팀의 상황 등 여러 요인에 따라 그 정도는 많이 다를 것이라 생각한다.
돌아보면, 도입 직후에는 스스로도 확신이 부족해서 혼란스러웠다. 그래도 새로운 방식을 제안한 책임이 나에게 있으니 잘 정착시켜야겠다는 의욕이 앞섰다. 아마 동료들은 내가 자꾸 길고 낯선 회의를 제안해서 괴롭지 않았을까 싶다.
그 이후
회의 과정이 수월해지고, 논의는 충실해지고, 일치에 도달하는 시간이 짧아지는 시점이 왔다. 스토리 포인트 도입의 또 다른 이유인 속도 파악을 위해 모든 태스크에 전면적으로 포인트를 부여하기로 했다. 새로운 성장과제도 눈에 보이기 시작했다.
첫째로, 스프린트 내에 처음 계획한 목표(합의하에 포인트가 부여된 사용자 스토리) 외의 태스크 비중이 높아 개선이 필요하다. 이 부분을 개선해야 스토리 포인트를 일정 계획에 더 유용하게 쓸 수 있을 것이다. 두 번째로, 여러 사람이 스토리를 작성하는 것이 이상적인 팀이라 생각한다. 이 목표는 길게 보고 한 발씩 나아가려 한다.
그 외에도 크고 작은 의문이 들 때마다 나 챗GPT가 추천하는 레퍼런스를 확인해 본다.
Last updated
Was this helpful?