7장 — 백로그가 아니라 베팅 (Bets, Not Backlogs)
원문: Bets, Not Backlogs — Shape Up
한 줄 요약
섹션 제목: “한 줄 요약”작성된 피치(pitch)는 백로그(backlog)로 들어가지 않는다. 6주마다 열리는 베팅 테이블(betting table)에서 소수의 잠재적 베팅(potential bets)만 검토하고, 선택되지 않은 것은 붙잡지 않고 흘려보낸다.
핵심 내용
섹션 제목: “핵심 내용”백로그를 두지 않는다 (No backlogs)
섹션 제목: “백로그를 두지 않는다 (No backlogs)”백로그는 지고 다닐 필요 없는 무거운 짐이다. 결코 손대지 못할 작업이 수십, 수백 개 쌓이면서 실제로는 뒤처지지 않았는데도 늘 뒤처진 듯한 기분을 만든다. 오래된 아이디어를 반복해서 검토하고 정리(grooming)하는 데 쓰는 시간은, 지금 정말 중요한 시의성 있는 프로젝트를 진전시키는 것을 방해한다.
소수의 잠재적 베팅만 (A few potential bets)
섹션 제목: “소수의 잠재적 베팅만 (A few potential bets)”대신 각 6주 사이클 전에 베팅 테이블을 열어, 지난 6주 동안 셰이핑된 피치와 누군가 의도적으로 되살려 다시 밀고 있는 피치만 본다. 거대한 아이디어 목록도, 백로그 정리 시간도 없다. 리스크가 줄어든 잘 셰이핑된 옵션 몇 개만 놓고 결정하므로 회의는 드물고 짧고 대단히 생산적이다. 베팅하면 다음 사이클에 들어가고, 베팅하지 않으면 그냥 놓아준다 — 추적하거나 보관할 것이 없다. 시기가 안 맞았을 뿐 좋은 피치라면, 원하는 사람이 각자의 방식으로 기억해 두었다가 6주 뒤 다시 로비하면 된다.
분산된 리스트 (Decentralized lists)
섹션 제목: “분산된 리스트 (Decentralized lists)”중앙 백로그가 없다고 과거를 전부 잊는 것은 아니다. 서포트는 자주 올라오는 요청 목록을, 프로덕트는 미래 사이클에 셰이핑하고 싶은 아이디어를, 프로그래머는 고치고 싶은 버그 목록을 각자 관리한다. 이 리스트들은 베팅 프로세스의 직접 입력이 아니다. 부서 간의 정기적이지만 드문 일대일 대화가 아이디어를 교차 수분시킨다. 우선순위와 추적의 책임이 분산되어 관리 가능해지고, 다시 꺼내지는 안건은 항상 맥락과 사람과 목적을 갖고 돌아오므로 대화가 늘 신선하다.
중요한 아이디어는 다시 돌아온다 (Important ideas come back)
섹션 제목: “중요한 아이디어는 다시 돌아온다 (Important ideas come back)”아이디어는 과대평가되기 쉽지만 사실 값싸다. 정말 중요한 아이디어는 잊으려 해도 다시 떠오른다. 고객이 다시 겪는 버그는 다시 들려온다. 한 번 듣고 끝이라면 애초에 문제가 아니었을 수 있고, 계속 들려온다면 해법을 셰이핑해서 다음 사이클에 베팅을 제안할 동기가 저절로 생긴다.
실무 포인트
섹션 제목: “실무 포인트”- 중앙 백로그와 정기 grooming 회의를 없애고, 베팅 테이블에는 잘 셰이핑된 피치 몇 개만 올린다
- 베팅되지 않은 피치는 추적 시스템에 넣지 말고 놓아준다 — 부활은 옹호자가 6주 뒤 직접 로비
- 부서별(서포트·프로덕트·개발) 분산 리스트는 허용하되, 베팅의 직접 입력으로 쓰지 않는다
- 부서 간 일대일을 드물게라도 정기화해 상위 이슈가 자연스럽게 전달되게 한다
- 반복해서 다시 들려오는 문제만 셰이핑 후보로 승격한다