RICE 스코어링: 공식, 계산 예시, 흔한 실수

RICE 스코어링은 도달 범위 곱하기 영향 곱하기 확신을 노력으로 나눈 숫자 하나로 제품 아이디어의 순위를 매긴다. 점수가 높을수록 작업 단위당 기대 가치가 크다. 이 방법은 인터콤의 제품팀에서 나왔고, 감으로는 가를 수 없는 기능 요청을 비교하는 기본 수단이 되었다. 진지한 후보 몇 개를 추린 목록에서 가장 잘 통하며, 입력하는 추정치만큼만 믿을 수 있다.

RICE 스코어링 공식은 무엇인가

점수는 도달 범위 × 영향 × 확신 ÷ 노력이다. 도달 범위, 영향, 확신은 각각 성과의 크기를 키우므로 곱하고, 같은 성과라도 일이 많이 들수록 비용이 크므로 노력으로 나눈다. 도달 범위에는 분기처럼 하나의 기간을 정해 모든 항목에 똑같이 쓴다. 그러지 않으면 점수끼리 비교할 수 없다.

인터콤의 원문 글이 위 표의 척도를 정의하며, 대부분의 팀은 사람 사이에 점수를 비교할 수 있도록 이를 그대로 쓴다.

RICE의 각 요소는 어떻게 점수를 매기는가

도달 범위는 이미 갖고 있는 데이터에서 나온다. 기능 요청이라면 요청한 고유 계정 수에서 시작해, 요청하지 않아도 쓸 것으로 보이는 계정 수의 추정치를 더한다. 영향은 가장 부정확한 요소이므로 다섯 값의 척도를 쓰고 소수점을 지어내지 않는다. 확신은 추측에 대한 할인이다. 사용 데이터나 검증된 프로토타입이 있을 때만 100%, 강한 신호가 있으면 80%, 대부분 짐작이면 50%를 쓴다. 노력은 디자인과 테스트를 포함해 관련된 모든 사람의 시간을 인월로 센다.

두 사람이 같은 항목에 점수를 매기면 모든 요소에서 한 단계 안쪽으로 모여야 한다. 그렇지 않다면 그 항목은 순위를 매길 만큼 이해되지 않은 것이고, 의견 차이가 곧 발견이다.

RICE 스코어링 예시는 어떤 모습인가

추적 중인 백로그의 요청 네 개를 한 분기 기준으로 점수 매긴다.

첫 줄을 계산하면 400 × 1 × 0.8 ÷ 1 = 320이다. 다크 모드는 세 배 많은 사람에게 닿지만 한 사람이 얻는 것이 작아서 내보내기 바로 아래에 놓인다. Slack 연동은 영향 점수가 좋은데 확신이 그것을 반으로 깎으며, 이는 다음 단계가 개발이 아니라 조사라는 뜻이다.

싱글 사인온은 꼴찌인데, 한 번 더 들여다볼 만하다. 60개 계정은 작은 도달 범위지만, 그 계정이 더 큰 계정이고 갱신 여러 건이 이 기능에 달려 있다면 점수에는 이 방법이 볼 수 없는 무언가가 빠져 있다.

RICE의 흔한 실수는 무엇인가

첫째는 거짓 정밀도다. 도달 범위 1,247과 영향 1.3은 엄밀해 보이지만 1,200과 1보다 더 많은 정보를 담지 않는다. 과감하게 반올림한다.

둘째는 이미 만들기로 정한 항목에 점수를 매기는 것이다. 그러면 마음에 드는 항목이 이길 때까지 점수를 조금씩 고치게 되고, 그 작업은 명분만 만든다.

셋째는 누가 요청했는지를 무시하는 것이다. RICE는 사람 수를 세므로 작은 계정 열 곳의 요청이 열 곳을 합친 것보다 가치가 큰 계정 한 곳의 요청을 앞선다. 매출이 중요하다면 매출 열을 추가하고 점수 옆에 두고 읽는다. 계정별 가중치는 기능 요청 우선순위를 정하는 방법에서 다룬다.

넷째는 서로 다른 기간이나 다른 팀의 척도로 나온 점수를 비교하는 것이다. 시트 하나, 기간 하나, 정의 하나를 유지한다.

RICE 대신 다른 방법을 써야 하는 때는 언제인가

도달 범위 데이터가 없다면 도달 범위를 빼고 노력을 쉬움 평점으로 바꾼 ICE(영향, 확신, 쉬움)를 쓰되, 더 거칠다는 점을 받아들인다. 질문이 얼마나 큰가가 아니라 기능이 어떤 종류의 가치를 지니는가라면, 카노 모델이 요청을 당연, 성능, 감동 요소 기능으로 분류하며 둘은 함께 쓰기 좋다. 결정이 순위가 아니라 순서와 시점에 관한 것이라면 로드맵 형식이 더 맞고, 제품 로드맵 만드는 법이 이를 다룬다.

RICE 점수를 시간이 지나도 정직하게 유지하려면

결과만이 아니라 입력값도 점수 옆에 저장해서, 어떤 가정이 순위를 좌우했는지 누구나 볼 수 있게 한다. 새 요청이 쌓여 도달 범위가 올라가거나 엔지니어가 노력이 두 배라는 것을 발견하는 것처럼 사실이 바뀌면 항목을 다시 살펴본다. 출시한 뒤에는 예측한 도달 범위와 영향을 실제 결과와 비교해, 다음에 팀이 추정하는 방식을 조정한다. 도달 범위의 원재료는 기능 요청 추적에서 설명한 묶고 라벨을 붙인 요청 목록이며, 결과는 요청한 사람들에게 보내는 답장에 담겨야 한다.

FAQ

좋은 RICE 점수란 얼마인가? 숫자는 도달 범위 기간과 노력 단위에 따라 달라지므로 보편적인 기준은 없다. 점수는 시트 하나 안에서만 비교하고, 결과물은 절대값이 아니라 순위로 다룬다.

RICE와 ICE 스코어링은 무엇이 다른가? ICE는 영향, 확신, 쉬움을 곱하고 도달 범위를 뺀다. 채우기는 빠르지만 기능마다 영향받는 사용자 수가 크게 다를 때는 덜 정확한데, 바로 RICE가 설계된 경우다.

기능 요청의 도달 범위는 어떻게 추정하는가? 요청한 계정 수에서 시작해, 요청 없이도 쓸 것으로 보이는 활성 계정의 비율을 더하고 분기당 합계로 표현한다. 추정이 거칠다면 정밀도를 지어내지 말고 확신 요소를 낮춘다.

모든 기능 요청에 RICE를 적용해야 하는가? 아니다. 점수 매기기는 동점을 가려야 할 만큼 가까운 소수의 항목에만 수고를 들일 가치가 있다. 뻔한 승리와 뻔한 거절은 점수 없이 결정할 수 있다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 도구 비교