백로그 정리

제품 백로그는 앞으로 만들 후보를 순서대로 모아 둔 목록인데, 저절로 읽을 만한 상태로 남아 있지는 않습니다. 항목은 회의 도중에, 고객 응대 중에, 버그 제보를 받다가 한 줄씩 쌓입니다. 적는 순간에는 다들 맥락을 알고 있으니 제목만 적고 넘어갑니다. 두 달 뒤에 그 줄을 여는 사람은 그 맥락을 모릅니다.

밀린 것은 스프린트 플래닝에서 한꺼번에 터집니다. 이번 주기에 무엇을 할지 정하는 한 시간짜리 회의에서 "결제 개선" 이라고만 적힌 줄을 열고 "이거 누가 요청한 거죠" 부터 묻게 됩니다. 요청한 사람을 찾고, 무엇이 되면 끝인지 합의하고, 얼마나 큰 일인지 가늠하는 작업을 그 자리에서 다 하려니 회의가 두 시간을 넘기고, 대개는 "다음에 다시 보죠" 로 미뤄집니다.

미뤄지는 동안 목록은 계속 길어집니다. 반년이면 300건이 되고 그중 절반은 이미 다른 방식으로 해결됐거나 제품 방향이 바뀌어 더는 할 일이 아닌 것들입니다. 그쯤 되면 위에서부터 읽는 사람이 없어지고, 다들 자기 기억에 남은 항목만 들고 회의에 들어옵니다.

백로그 정리는 이 두 가지를 계획 회의 밖으로 빼낸 장치입니다. 목록을 다듬는 자리를 며칠 앞서 따로 돌리면, 계획 회의는 이미 읽을 수 있게 된 항목 중에서 고르기만 하면 됩니다.

한 시간을 여섯 단계로 나눠 씁니다. 뒤 단계가 앞 단계의 결과를 그대로 쓰기 때문에 순서를 지킵니다. 크기를 매기려면 완료 조건이 있어야 하고, 순서를 정하려면 크기가 있어야 합니다.

1. 범위를 자릅니다. 목록 위에서부터 이삼십 건만 봅니다. 아래쪽은 한 달이면 순서가 바뀌어 지금 다듬어 봐야 다시 다듬게 됩니다.
2. 항목을 읽고 배경을 채웁니다. "고객사 세 곳이 지난달 갱신 면담에서 같은 말을 했다" 처럼 누가 왜 요청했는지가 담긴 한 줄이면 충분합니다.
3. 완료 조건을 붙입니다. 인수 조건이라고 부르는 칸으로, "카드를 등록한 사용자가 다음 결제에서 번호를 다시 입력하지 않는다" 처럼 됐는지 안 됐는지가 한 번에 갈리는 문장이어야 합니다. 이 칸이 비면 뒤의 두 단계가 통째로 흔들립니다.
4. 큰 항목을 쪼갭니다. 에픽처럼 몇 주짜리 덩어리는 한 주기 안에 끝나지 않으니 유저 스토리 단위로 나눕니다. 유저 스토리는 요구를 사용자 관점 한 문장으로 적은 단위입니다. 설명이 길어지는 항목은 PRD를 따로 붙이고 목록에는 그 문서로 가는 길만 남깁니다.
5. 크기를 매깁니다. 시간이 아니라 스토리 포인트라는 상대 단위를 씁니다. 기준이 되는 작업 하나를 3 으로 정해 두고 나머지를 그것과 견줘 1·2·3·5·8 을 붙입니다. 8 을 넘는 값이 나오면 4번으로 돌아가 더 쪼갭니다.
6. 순서를 다시 보고 지울 것을 지웁니다. 등록된 지 여섯 달이 지났고 그동안 아무도 언급하지 않은 항목이 대상입니다. 아까워서 남기면 목록 아래에 쌓이기만 합니다.

한 시간에 다 못 밟으면 위에서부터 끊고 나머지는 다음 회차로 넘깁니다.

순서를 최종적으로 정하는 한 사람과 실제로 만드는 쪽 두셋이 모입니다. 다섯 명을 넘기지 않습니다.

1. 순서를 정하는 사람. 스크럼을 쓰는 팀이면 프로덕트 오너, 그렇지 않은 팀이면 프로덕트 매니저가 맡습니다. 이 자리가 비면 그날의 결론이 남지 않습니다.
2. 개발자 한두 명. 크기를 매길 근거를 아는 쪽이라 5번 단계가 이들에게 달려 있습니다.
3. 디자이너 한 명. 화면이 걸린 항목이 있는 회차에만 들어옵니다.

팀 전원을 부르지 않는 이유는 비용이 곱해지기 때문입니다. 열 명이 한 시간을 앉아 있으면 열 시간을 쓴 것이고, 그중 여덟 명은 자기 항목이 나올 때까지 듣기만 합니다. 대신 그날의 결정은 목록에 바로 반영하고 팀 채널에 알립니다.

시점은 한두 주에 한 번, 한 시간 안팎이고 주기 중반에 둡니다. 계획 회의 전날에 붙이면 정리와 계획이 한 덩어리가 되어 두 시간짜리 회의 하나로 돌아갑니다. 중반에 두면 "이 항목은 법무 확인이 필요하다" 같은 질문이 나와도 답을 받아 올 며칠이 남습니다. 2주 주기라면 두 번째 주 화요일쯤입니다.

"이번 정리는 위쪽 열다섯 건만 보죠. 아래는 어차피 다음 달에 순서 바뀝니다."

한 시간 안에 끝내려고 범위를 먼저 자르자는 제안입니다.

"이 항목은 완료 조건이 없어서 크기를 못 매기겠어요. 다음 정리까지 채워 올게요."

지금 추정해 봐야 아무 숫자나 나오니 한 회차 미루자는 뜻입니다.

"여섯 달째 아무도 안 찾는 항목인데 지울까요?"

목록 길이를 줄여 위에서부터 읽히는 상태로 되돌리자는 제안입니다.

페이지덱에서는 지현이 격주 수요일 오후 4시에 한 시간을 잡아 둡니다. 태오와 민서가 들어오고 지현이 목록 위에서부터 한 건씩 엽니다. 배경이 비어 있으면 그 자리에서 채우고, 태오가 "이건 데이터 옮기는 작업이 붙어 있어서 한 주기에 안 끝납니다" 라고 하면 둘로 쪼갭니다. 화면이 필요한 항목은 민서가 표시해 둡니다.

마지막 10분은 지우는 시간입니다. 지현이 여섯 달 넘게 잠긴 항목을 불러 주고 아무도 붙잡지 않으면 지웁니다. 지난 회차에는 열두 건이 빠졌습니다. 회의가 끝나면 위쪽 스무 건은 다음 계획 회의에서 설명 없이 바로 고를 수 있는 상태가 됩니다.

순서를 정하는 사람이 혼자 미리 해 두면 되는 일이라고 여기는 경우가 가장 많습니다. 항목을 쓰고 순서를 정하는 게 그 사람의 일이니 여럿이 한 시간씩 모이는 게 낭비로 보입니다. 그런데 크기를 매길 근거는 만드는 쪽에 있습니다. 화면 한 장을 더 그리는 일인지 데이터 구조를 바꿔야 하는 일인지는 코드를 아는 사람만 압니다. 혼자 매긴 숫자는 추측이고, 그 추측으로 세운 계획은 "이건 그 크기가 아닌데요" 한마디에 무너집니다. 결국 계획 회의 안에서 정리를 다시 하게 됩니다.

목록 전체를 훑어야 제대로 한 것이라는 오해도 자주 봅니다. 정리라는 말이 목록 전체를 가리키는 것처럼 들려서 생깁니다. 300건을 한 시간에 보면 한 건에 12초가 돌아가 제목만 읽고 넘어갑니다. 손댈 곳은 다음 한두 주기에 실제로 시작될 위쪽 구간뿐입니다.