백로그와 우선순위 선정
백로그나 우선순위 선정이 중요한가요?
제품을 만드는 모든 과정이 시간적이나 비용적으로 여유롭거나 충분한 인력이 있다면 좋겠지만 대부분의 경우에는 이러한 리소스가 부족하다. 그렇기 때문에 팀 내 떠오르는 모든 아이디어나 고객으로부터 나오는 모든 문제를 즉각적으로 해결하기는 어렵다.
리소스는 늘 부족하다. 그렇기 때문에 서비스 기획자나 PM/PO는 매번 어떤 새로운 기능을 추가할지 고민해야 한다. 이뿐만 아니라 어떤 문제를 해결하는 데 어떤 리소스를 얼마나 투입할지도 고민해야 한다. 한정된 리소스를 토대로 좋은 제품을 만들기 위해서는 백로그를 잘 관리하고, 우선순위를 잘 선정해야 한다.
이번 글은 제품 개발 과정에서 서비스 기획자나 PM/PO 직무가 겪게 될 우선순위를 선정하는 방법과 백로그에 대해서 소개한 글이다. 글의 순서는 아래와 같다.
1. 백로그란?
2. 우선순위 선정 방법 2가지
백로그(Backlog)
백로그(backlog)는 개발해야 할 기능 또는 제품에서 요구하는 기능과 우선순위를 말한다. 흔히 백로그를 할 일 목록이나 미처 처리하지 못한 것들을 모아두는 것이라고 생각하는 경우가 많은데, 엄밀히 말하자면 이러한 할 일 목록 리스트는 백로그라고 보기 어렵다.
백로그에는 ‘누가’, ‘어떤 문제’를 겪고 있는지, 그래서 우리가 ‘문제를’, ‘어떻게 해결’할 수 있을지, 그 문제를 해결함으로써 ‘얻게 되거나 기대하는 결과’는 무엇인지를 명시해야 한다. 이렇게 백로그를 정리해야 추후 팀에서 백로그를 선정할 때 우선순위를 선정하기가 쉽고, 함께 서비스를 만들 팀원을 설득하기가 쉽다. 그리고 이러한 백로그는 팀에서 주기적으로 논의하고 선정해서 관리할 수 있어야 한다.
우선순위 선정 방법 2가지
백로그를 작성했다면 이제 주기적으로 백로그의 우선순위를 판단해서 개발하는 과정을 거쳐야 한다. 우선순위를 정하는 방법은 여러 가지가 있다. 그중 반드시 하나만 선택해서 진행해야 하는 것은 아니다. 조직마다 적합한 우선순위 선정 방법이 다르고, 여러 방법을 섞어서 활용하기도 한다. 이 글에서는 자주 사용되는 두 가지 방법을 소개한다.
1. MoSCoW 방법
MoSCow 방법은 백로그를 크게 4가지로 구분해서 우선순위를 정리하는 방법을 말한다. 4가지는 각기 ‘Must have’, ‘Should have’, ‘Could have’, ‘Won't have’이며, 각 항목의 앞글자를 따서 MoSCow라고 불린다.
l Must have: 서비스 운영에서 이 기능을 빼고는 온전한 서비스라고 생각하기 어려운 기준을 말한다. 백로그 중에서 서비스 자체에 치명적인 영향을 끼치거나 시급성이 높아서 반드시 해결해야 할 기능을 말한다.
l Should have: 서비스를 운영하는 데 있어서 당장 적용하지 않아도 서비스에 영향이 없는 기능 중 우선순위가 높은 기준을 말한다. 해결할 필요성은 분명해서 중요한 기능이지만 Must have에 비해 시급성이 낮은 기능을 말한다.
l Could have: 서비스를 운영하는 데 있어서 전혀 영향이 없는 기능 중 우선순위가 낮은 기준을 말한다. 만약 팀에 가용 가능한 리소스가 존재해서 여유가 있을 때 시도해봄으로써 서비스를 더 좋게 만들 수 있는 기준을 말한다. 흔히 ‘있으면 좋고, 없어도 상관없는’ 기준으로 정리되곤 한다.
l Won't have: 서비스를 운영하는 데 있어서 전혀 영향이 없으며, 우선순위가 가장 낮은 기준을 말한다. 중요도도 떨어지고, 적용했을 때 효과도 아주 미미한 수준의 기능을 말한다.
2. RICE 방법
RICE 방법은 백로그에 RICE라는 4가지 항목을 적용해서 점수를 도출함으로써 우선순위를 정리하는 방법을 말한다. RICE의 4가지 항목은 각각 ‘Reach’, ‘Impact’, ‘Confidence’, ‘Effort’이며, 각 항목의 앞글자를 따서 RICE라고 불린다.
l Reach: 얼마나 많은 수의 사용자에게 도달하며, 그들에게 영향이 미치는지에 대한 기준을 말한다. 백로그를 통해 개발될 기능이 특정 기간 동안에 얼마나 많은 사용자가 사용할 수 있는지를 말한다. 서비스의 실질적인 지표인 일별 활성 사용자(DAU; Daily Active Users)나 월별 활성 사용자(MAU; Monthly Active Users) 같은 수치로 평가할 수 있다.
l Impact: 도달하게 될 사용자들이 해당 기능을 사용할 때 얼마나 큰 영향을 받게 되는지에 대한 기준을 말한다. Impact는 측정하기에 따라 매우 다르고, 명확한 기준을 수립할 수 없다. 다만 그 영향의 척도를 5단계 정도로 구분해서 상대적인 점수를 부여하는 것이 일반적이다. 예를 들어, ‘효과가 매우 큼’의 경우 3점, ‘효과가 큼’의 경우 2점, ‘효과가 중간’의 경우 1점, ‘효과가 낮음’의 경우 0.5점, ‘효과가 매우 낮음’의 경우 0.25점을 주는 식으로 평가할 수 있다.
l Confidence: 개발하게 될 기능이 성공할지에 대해 얼마나 확신을 가지는지에 대한 기준을 말한다. PM/PO 또는 서비스 기획자로서 만들게 될 기능이 사용자에게 얼마나 만족스러운 가치를 전달하는지에 대한 것이라고 보면 된다. 크게 3단계로 구분해서 점수를 적용한다. ‘높은 신뢰도’의 경우 100%, ‘중간 신뢰도’의 경우 80%, ‘낮은 신뢰도’의 경우 50%를 적용해서 평가할 수 있다.
l Effort: 백로그를 개발하는 과정에서 시간이나 인력이 얼마나 소요되는지에 대한 기준을 말한다. 시간이나 인력 소요를 토대로 평가할 수도 있으나 계산이 용이하도록 4단계 점수로 적용할 수도 있다. 4단계 점수로는 ‘매우 큰 수준의 노력’은 4점, ‘큰 수준의 노력’은 3점, ‘중간 수준의 노력’은 2점, ‘적은 수준의 노력’은 1점을 적용해 평가할 수 있다.
이렇게 각 항목에 대해 점수를 부여했다면 최종적으로 RICE 점수를 계산해서 백로그에 적용해야 한다. RICE 점수는 ‘R * I * C / E’의 공식으로 산출할 수 있다. 이렇게 계산한 RICE 점수가 클수록 우선순위가 높은 백로그라고 볼 수 있다.
결론
사실 앞에서 소개한 방법만으로 백로그를 평가하기보다는 조직마다 특이한 세부 조건을 추가해서 점수를 산출하는 것이 더 일반적이다. 앞에서 말한 우선순위 선정 방법은 정답이 아니다. 그래서 때로는 여러 개의 우선순위 선정 방법을 혼합해서 사용하기도 하고, 아예 회사나 조직에 맞춘 우선순위 선정방법을 개발해서 사용하기도 한다.
거듭 이야기하지만 백로그를 선정하거나 우선순위를 선정하는 방법에는 정답이 없다. 무엇보다 중요한 것은 ‘한정된 리소스’로 ‘최고의 결과’를 만들 수 있도록 우선순위를 선정하는 것이라고 볼 수 있다.
