백로그를 비우는 가장 빠른 방법

백로그가 쌓이는 방식

백로그는 대부분 비슷한 방식으로 쌓인다. 미팅에서 나온 아이디어, 사용자 피드백에서 나온 개선 요청, 코드를 보다가 “나중에 해야지” 하고 적어둔 항목들. 추가하는 속도가 처리하는 속도보다 빠르면 쌓인다.

처음에 우리 팀 백로그는 70개가 넘었다. 스프린트마다 몇 개씩 처리하면 언젠가는 줄 거라고 생각했다. 그런데 줄지 않았다. 처리하면 비슷한 속도로 새 항목이 들어왔다.

전략 전환: 처리 대신 검토

어느 시점에 접근 방식을 바꿨다. 백로그를 처리하는 게 아니라 검토하는 시간을 먼저 가졌다. 한 번의 세션에서 전체 항목을 빠르게 훑으면서 질문 하나만 했다. “이게 지금도 중요한가?”

결과는 예상보다 극적이었다. 70개 중 40개 가까이 “지금은 아니다” 판정을 받았다. 몇 달 전에는 중요했지만 상황이 바뀐 항목, 다른 방식으로 이미 해결된 항목, 처음부터 불분명했던 항목들이 섞여 있었다.

버리는 기준

아무렇게나 버리면 나중에 “그거 없앴어?” 소리를 듣는다. 우리가 쓰는 기준은 두 가지다.

첫째, 마지막으로 이 항목을 떠올린 게 언제인가. 2주 이상 아무도 언급하지 않은 항목은 강등 대상이다. 삭제가 아니라 별도 아카이브로 이동한다.

둘째, 이 항목이 없어졌을 때 누가 불편함을 느끼는가. 답이 불분명하면 우선순위가 낮다. 실제 사용자가 기다리는 항목인지, 팀원이 만들고 싶은 항목인지를 구분한다.

추가 제한

더 중요한 변화는 백로그 총 항목 수에 상한을 둔 것이다. 우리는 30개로 정했다. 새 항목을 추가하려면 기존 항목을 하나 버리거나 합쳐야 한다. 규칙이 생기니 추가할 때 더 신중해졌다. 미팅에서 아이디어가 나왔을 때 “이게 30개 안에 들어갈 만큼 중요한가”를 바로 논의하게 됐다.

이 방식이 완벽하지는 않다. 중요한 항목이 상한에 밀려 버려지는 일도 있었다. 그럴 때는 아카이브에서 꺼내오면 된다. 아카이브에서 꺼내는 일이 잦은 항목은 처음부터 상한 안에 있어야 했다는 신호다.

— by mings