제품 백로그

만들 것은 언제나 만들 시간보다 많았습니다. 문제는 그 많은 후보가 한곳에 모이지 않았다는 데 있었습니다. 영업이 들고 온 요청은 영업팀 시트에, 고객센터로 들어온 불만은 상담 도구에, 대표가 지나가며 말한 아이디어는 메신저 어딘가에, 개발자가 고치고 싶어 한 부분은 개발자 머릿속에 있었습니다. 목록이 넷이면 무엇을 먼저 할지 정하는 자리도 넷입니다.

그래서 순서는 대개 그 자리에서 가장 목소리가 큰 쪽으로 정해졌습니다. 회의에서 "이건 대표님이 말씀하신 건데요" 라는 한마디가 나오면 나머지 후보는 자연히 뒤로 밀렸습니다. 두 달 전에 세 고객이 같은 것을 요청했다는 사실은 그 자리에 기록이 없어서 아무도 꺼내지 못했습니다. 밀린 쪽은 왜 밀렸는지 설명을 듣지 못했고, 다음 달에 같은 요청을 다시 들고 왔습니다.

바쁘게 돌아가는데 밖에서 보기에는 아무것도 나가지 않는 상태도 흔했습니다. 일곱 개를 동시에 시작해 두고 어느 것도 끝내지 못한 상황입니다. 후보가 흩어져 있으면 지금 벌여 놓은 것이 몇 건인지조차 세기 어렵고, 세지 못하면 줄일 수도 없습니다.

제품 백로그는 흩어진 목록을 하나로 합치고 그 하나에 순서를 세우는 장치입니다. 합치는 것 자체가 절반입니다. 같은 자리에 놓이면 영업의 요청과 고객센터의 불만과 개발자가 고치고 싶어 한 부분이 같은 잣대로 비교되기 때문입니다. 순서를 매기면 나머지 절반이 채워집니다. 위에서부터 고른다는 규칙 하나로, 무엇을 안 하기로 했는지가 목록의 아래쪽에 남아 보이게 됩니다.

제품 백로그 아래 묶인 용어는 세 갈래로 나뉩니다. 후보를 어느 굵기로 적어 두는지(단위), 그 목록을 어떻게 관리하는지(활동), 그리고 기능이 아닌 항목을 어떻게 다루는지(유형)입니다.

단위는 한 줄이 얼마나 큰 일을 가리키는지를 가르는 갈래입니다. 셋이 층을 이룹니다.

1. 이니셔티브 — 에픽 여러 개를 묶는 가장 큰 덩어리입니다. "결제 경험을 처음부터 다시 만든다" 처럼 분기나 반기를 통째로 쓰는 크기라, 여기에는 만드는 방법이 아니라 이루려는 상태가 적힙니다.
2. 에픽 — 여러 조각으로 쪼개지는 큰 작업 덩어리입니다. 결제 이니셔티브 아래에 카드 등록, 환불 처리, 영수증 발송 같은 에픽이 놓입니다. 한 에픽은 대개 몇 주짜리라 한 주기 안에 끝나지 않습니다.
3. 태스크 — 실행할 수 있는 크기까지 내려온 항목입니다. 며칠 안에 한 사람이 끝낼 수 있고, 무엇을 어떻게 만드는지가 적힙니다.

에픽과 태스크 사이에는 유저 스토리가 놓입니다. 요구를 사용자 관점 한 문장으로 적은 단위인데, "카드를 등록한 사용자로서 다음 결제에서 카드 번호를 다시 입력하지 않고 싶다" 같은 모양입니다. 층을 나누는 이유는 순서를 정하는 시점과 만드는 시점이 다르기 때문입니다. 분기 계획은 이니셔티브 열 개를 놓고 이야기해야 한눈에 들어오고, 이번 주 개발은 태스크로 내려와 있어야 시작할 수 있습니다.

항목 하나에 적히는 칸도 대체로 정해져 있습니다. 다섯 가지가 기본입니다.

1. 제목 — 목록에서 한 줄로 보이는 이름입니다. "결제 개선" 처럼 넓게 적으면 두 달 뒤에 그 줄이 무엇을 가리켰는지 아무도 기억하지 못합니다.
2. 배경 — 왜 필요한지를 적습니다. 요청한 사람과 그 요청이 나온 자리를 함께 남겨 두면 나중에 순서를 다시 볼 때 근거로 쓰입니다.
3. 완료 조건 — 무엇이 되면 끝인지를 적습니다. "카드를 등록한 사용자가 다음 결제에서 번호를 다시 입력하지 않는다" 처럼 됐는지 안 됐는지를 한 번에 판정할 수 있는 문장이어야 합니다.
4. 크기 — 얼마나 큰 일인지를 나타내는 값입니다. 며칠짜리인지 몇 주짜리인지가 잡혀야 이번 주기에 담을지 말지를 정할 수 있습니다.
5. 순서 — 목록에서 몇 번째에 놓이는지입니다. 앞의 넷이 항목 자체의 성질이라면 이것만 목록 전체와의 관계입니다.

이 가운데 자주 빠지는 것이 완료 조건입니다. 빠진 채로 개발에 들어가면 다 만든 뒤에 "이것도 되는 줄 알았는데요" 가 나오고, 그 대화가 한 주를 더 씁니다. 더 자세히 적어야 하는 항목은 PRD를 따로 붙이고 백로그 항목에는 그 문서로 가는 길만 남깁니다.

활동은 목록을 살아 있게 유지하는 일입니다. 백로그 정리가 여기 속합니다. 보통 한두 주에 한 번, 한 시간 안팎으로 모여 위쪽 항목의 설명을 보충하고 크기를 매기고 순서를 다시 봅니다. 여섯 달 전에 등록됐고 그동안 아무도 언급하지 않은 항목을 지우는 일도 여기서 합니다. 지우기를 아까워하면 목록이 300건으로 불어나고, 그쯤 되면 위에서부터 읽는 사람이 없어져 목록이 있으나 마나 해집니다. 정리가 손대는 범위는 위쪽 이삼십 건이면 충분합니다. 아래쪽은 순서가 바뀔 확률이 높아 지금 다듬어 봐야 다시 다듬게 됩니다.

유형은 기능이 아닌 항목을 목록에 어떻게 들여놓을지를 다룹니다. 기술 부채 티켓이 대표적입니다. 눈에 보이는 화면이 늘어나지 않지만 구조를 정리해 두는 일이라, 목록에 올려 두지 않으면 언제나 새 기능에 밀립니다. 그래서 다른 후보와 같은 목록에 같은 형식으로 올려 두고 순서 경쟁에 참여시킵니다. 한 주기 분량의 일정 비율을 미리 이쪽에 떼어 두는 팀도 많습니다. 한 주기에 담는 양이 30이면 그중 6 만큼을 구조 정리 쪽으로 고정해 비워 두는 식입니다. 비율을 정해 두지 않으면 급한 기능이 들어올 때마다 이 자리가 가장 먼저 사라지고, 그 상태가 반년쯤 이어지면 새 기능 하나를 붙이는 데 걸리는 시간이 눈에 띄게 늘어납니다.

세 갈래를 합쳐 놓아도 목록이 저절로 정렬되지는 않습니다. 무엇을 위에 둘지는 우선순위 결정이 맡습니다. 그리고 정렬된 목록의 위쪽에서 이번 주기에 할 만큼을 덜어 낸 것이 스프린트 백로그입니다. 제품 백로그는 계속 남아 있고 스프린트 백로그는 주기와 함께 생겼다 사라집니다.

쓰는 사람과 읽는 사람도 정해져 있습니다. 순서를 최종적으로 정하는 사람은 한 명입니다. 스크럼을 쓰는 팀에서는 프로덕트 오너, 그렇지 않은 팀에서는 프로덕트 매니저가 그 자리를 맡습니다. 항목을 등록하는 것은 누구나 할 수 있고 오히려 여러 곳에서 들어오는 편이 낫습니다. 다만 순서를 정하는 손이 둘이면 목록이 두 개인 것과 같아집니다. 읽는 쪽은 더 넓습니다. 개발과 디자인은 다음에 무엇이 오는지 보려고, 세일즈와 고객 성공은 고객에게 답할 말을 찾으려고, 경영진은 이번 분기에 무엇을 안 하기로 했는지 확인하려고 봅니다. 목적이 다르니 보는 위치도 다릅니다. 개발과 디자인은 위쪽 열 건 남짓을 읽고, 세일즈는 자기가 등록한 항목이 몇 번째에 있는지를 찾아보고, 경영진은 아래로 밀린 구간을 훑습니다. 그래서 목록은 위에서부터 읽는 사람과 특정 항목 하나를 찾아오는 사람 양쪽이 같이 쓸 수 있는 모양이어야 합니다.

"그 요청은 백로그에 넣어 뒀는데 지금 열여덟 번째예요. 이번 분기에는 못 갑니다."

거절이 아니라 순서를 알려 주는 말이고, 올리고 싶으면 무엇을 내릴지 함께 가져오라는 뜻이 붙어 있습니다.

"이 에픽은 아직 안 쪼개져 있어서 이번 주기에는 못 담아요. 정리 때 태스크로 내립시다."

크기가 주기보다 큰 항목은 계획에 넣을 수 없으니 먼저 나누자는 제안입니다.

"완료 조건이 비어 있는데 이대로 시작하면 다 만들고 나서 다시 이야기하게 됩니다."

항목의 필수 칸이 빠졌다는 지적이고, 지금 10분을 쓰면 나중에 며칠을 아낀다는 뜻입니다.

페이지덱에서는 격주 수요일 오후에 지현이 목록을 열고 위에서부터 훑습니다. 태오가 크기를 매기다가 "이건 알림까지 건드려야 해서 생각보다 큽니다" 라고 하면 그 자리에서 항목이 둘로 갈라지고, 갈라진 조각이 각각 순서를 다시 받습니다. 민서는 화면이 필요한 항목에 표시를 남겨 디자인이 먼저 붙어야 하는 순서를 맞춥니다.

수아가 고객 요청을 들고 오는 것도 같은 자리입니다. 말로 전하면 그날의 대화로 끝나지만 항목으로 등록하면 순서 경쟁에 들어갑니다. 같은 요청이 세 고객에게서 반복되면 그 기록이 항목에 쌓이고, 다음 정리에서 위로 올라갈 근거가 됩니다. 규원이 분기 계획을 물을 때 지현이 보여 주는 것도 이 목록입니다. 무엇을 하기로 했는지보다 스물몇 건을 왜 아래에 두었는지가 대화의 대부분을 차지합니다.

가장 흔한 오해는 백로그를 다 만들어야 할 약속 목록으로 읽는 것입니다. 목록에 올라와 있으니 언젠가는 하겠다는 뜻으로 보이고, 등록한 사람도 그렇게 기대합니다. 실제로는 아래쪽 항목 대부분이 끝내 만들어지지 않습니다. 후보를 모아 비교하려고 만든 목록이지 대기표를 나눠 준 것이 아니기 때문입니다. 약속으로 읽으면 두 가지가 무너집니다. 등록한 사람은 반년이 지나도 소식이 없는 것을 보고 신뢰를 거두고, 관리하는 사람은 지우기가 부담스러워져 죽은 항목을 계속 안고 갑니다. 정리 시간에 "이건 안 하기로 합니다" 라고 말하고 닫는 편이 서로에게 낫습니다.

두 번째는 목록이 길수록 잘 관리되고 있다고 믿는 것입니다. 아이디어가 빠짐없이 기록됐다는 뜻으로 보이니 그럴듯합니다. 하지만 목록의 값어치는 담긴 개수가 아니라 위에서부터 읽었을 때 다음에 할 일이 바로 나오는지에 달려 있습니다. 400건짜리 목록에서 위쪽 열 건을 찾으려면 그때마다 다시 훑어야 하고, 그 수고 때문에 사람들은 목록 대신 기억에 의존하게 됩니다. 그러면 흩어진 목록으로 돌아간 것과 다르지 않습니다. 오래된 항목을 지워도 잃는 것은 거의 없습니다. 정말 필요한 요청은 반드시 다시 들어옵니다.