#26. 'Backlog' 관리의 5가지 팁
팀은 Backlog 관리가 잘 되고 있나요?
Table of contents >
01. '질문'으로 시작되어야 합니다.
02. 'Backlog' 관리'의 5가지 팁
시작하며.
백로그의 우선순위 선정을 도와주는 여러 도구들이 있습니다. Kano model, RICE, MoSCoW, Value vs Effort 등 우선순위 지정 기술은 이론적으로 복잡하지 않으나 실제로 대부분의 제품 관리자들은 우선순위 지정 및 관리에 어려움을 말합니다. 백로그 관리의 첫 번째 원칙은 팀이 가장 중요한 것에 집중하는데 도움이 되는 행동으로 시작되어야 한다는 것입니다. 이는 다르게 말하면 가장 중요한 것에 대해 각기 다른 입장을 가지고 있기에 그 조정자의 역할이 어려워질 수 있다는 사실을 말해 줍니다. 그래서 오늘의 글은 백로그 관리의 도구적 측면의 글이 아닌, 어떻게 백로그 관리를 바라보고 운용할 수 있을지 기술적 측면에 대한 이야기를 해보겠습니다. 도구는 도구일 뿐, 도구를 어떻게 다루느냐가 가장 중요한 법이니까요.
01. '질문'으로 시작되어야 합니다.
핵심 질문 세 가지가 필요합니다.
스스로에게 묻고, 팀에게 묻고, 수백 개의 백로그 앞에 서서 질문에 대한 답을 요구해야 합니다.
첫째. 우리가 해결하려는 문제는 무엇인가. (왜 우리는 이 일을 하는가)
둘째. 우리는 누구를 위해 이 문제를 해결하려 하는가.(누구에게 어떤 접근이 필요한가)
셋째. 우리가 원하고 바라는 결과는 무엇인가. (성공의 기준은 무엇인가)
백로그를 단순하게 해야 할 일을 쌓아두는 곳으로 여기게 된다면, 팀은 잘못된 결과를 만들어 낼 가능성이 높아집니다. 백로그의 첫 시작은 질문으로 시작하며, 팀의 답이 필요합니다. 팀의 동의를 얻고 정기적으로 검토하며, 팀과 함께 보폭을 맞출 수 있도록 동기화가 되어야 합니다. 주기적으로 검토되고 동기화되어야 하는 이유는 우리가 싸워야 할 시장과 기술과 경쟁 환경은 고정된 타깃이 아니라, 엄청나게 빠른 속도로 변주되는 불확실한 영역이기 때문입니다. Vuca World!
02. 'Backlog' 관리'의 5가지 팁
이론적으로 백로그 - 스프린트 관계는 단순합니다.
하지만 현실은 이론만큼 단순하지 않습니다.
실제로는 복잡한 요인들이 존재합니다. 소규모 팀에서는 2주 동안의 스프린트로 원하고 필요한 모든 작업을 수행하기 버거우며, 2주마다 모든 작업 목록에 대해 세부적인 비용 효과 분석을 수행하는 것은 불가능에 가깝습니다. 처리하는 양에 비해 쌓이는 속도가 압도적으로 높을 수밖에 없습니다.
모든 백로그의 스토리가 처리될 수 없는 상황에서 백로그를 관리하고 운영하는 방식에 대한 몇 가지 요령들이 필요합니다. 백로그 관리에 있어 5가지 요령들에 대한 생각을 전달드립니다.
1️⃣ 공허한 약속 금지 & 무분별하게 던지기 금지.
팀이 작업을 진행하는 백로그 보드에는 미팅 때 나오는 모든 아이디어가 포함되면 안 됩니다. 모든 고객의 요청을 추가해서도 곤란합니다. "백로그에 추가하겠습니다"라고 말하는 순간 당신의 신뢰 자본에 악영향을 끼치는 공허한 약속으로 귀결될 가능성이 높습니다. 백로그에는 단기적으로 해결할 수 있는 확신이 높은 항목들이 포함되어야만 하며, 단기 실행의 스토리들과 전략 아이템, 아이디어 & 피드백들을 백로그에서 별도 보드로 분리시켜야 합니다. (백로그 인입 시점부터 분리수거가 되어야 합니다)
2️⃣ 축소 유지 - 백로그의 규모
많은 제품팀에서 백로그를 마치 무한대로 크나 큰 창고 혹은 쓰레기통으로 간주하는 경향이 있습니다. 일단 이슈와 피드백을 던지고 나면, 마치 심리적인 안전감을 확보되는 듯한 느낌을 받게 될지도 모릅니다. 하지만 너무 많은 항목의 백로그들은 관리 및 우선순위 지정이 시간이 지날수록 더욱 어려워지며, 중복된 스토리들이 양산되게 되며, 많은 양의 스토리를 한눈에 파악하기 어려워집니다. 팀은 점점 백로그로부터 멀어집니다. (큰 일입니다. 팀이 백로그로부터 멀어지면 안 됩니다!) 시간이 지날수록 더욱 많은 양이 쌓이며 처리 불가능한 영역으로 방치될 가능성이 높습니다. 정기적으로 백로그를 정리하고 팀의 관심을 끌지 못한 오래된 항목들을 삭제해야 합니다. (정말로 중요한 내용들은 부활해서 돌아옵니다.) 또한 백로그 보드에서 QA이슈와 고객 피드백의 내용들은 별도의 보드로 분리시키길 권장드립니다. 백로그의 규모를 어떻게 단기 목표에 부합될 수 있도록 축소 유지할 수 있을지 제품 관리자가 고민해야 합니다.
3️⃣ 팀 동기화 - 백로그 보드의 주요 흐름
팀이 개선 미팅 및 스프린트 계획 세션에서 백로 그의 주요 요구 사항들에 대해 처음 알게 되는 것은 좋은 신호가 아닙니다. 이는 팀이 제품에 투자해야 할 시간을 온전히 쓰고 있지 못하거나, 반복되는 작업들로 인해 놓치는 부분들이 생길 것이라는 징후입니다. 단기적인 목표와 계획들이 명확해야 하며, 팀은 백로그 보드의 주요 흐름들에 대해 파악하고 그에 발맞춰 움직여 줄 수 있어야 합니다.
4️⃣ 사전 필터링 - 부실한 내용의 백로그 아이템
개별 스토리들은 하나의 요구사항들로 완결성을 지니고 있어야 합니다. 기능 도입에 따른 사이드 이펙트가 설명되어야 하며, 발생 가능한 시나리오의 이슈들에 대한 대응책들은 팀과 사전에 논의가 진행되어야 합니다. 세부 요건과 내용이 없거나 맥락을 알 수 없는 부실한 상태의 백로그들이 개발팀으로 바로 넘어가게 될 경우, 각종 부작용들이 나타날 수밖에 없습니다. 팀은 신뢰관계로 묶여 있으며 프로세스상에서 신뢰를 떨어트리는 요인들은 제품 관리자가 사전에 차단 또는 점검하거나, 매 스프린트 회고 때마다 개선되어야 합니다. 제목만 존재하는 백로그들은 그 자체만으로 팀에 도움이 되지 못합니다.
5️⃣ 매직 백로그의 정의 - 순서 변경이 가능한, 난입이 가능한. 목록의 최상단에 올라가는.
스프린트 계획 세션 때, 갑자기 마법과 같이 최상단에 등장하는 스토리들은 팀에 당혹감을 안겨줄 수 있습니다. 계획과 우선순위는 늘 변경될 가능성이 존재하지만, 왜 어떻게 무엇으로 인해 이런 변경이 되는지에 대하여 같은 방향의 사고를 할 수 있어야 합니다. 팀의 응집력은 무엇을 향해 나아가고 있는지 비전을 같이 바라보는 것부터 시작합니다. 각기 다른 인식과 사고를 같은 방향을 향해 볼 수 있는 여건을 마련해야 하며, 계획과 우선순위 변동에 따른 내용들은 사전에 팀 내에서 충분히 논의될 수 있는 여건과 환경이 마련되어야 합니다.
- 우선순위 선정에 따른 원칙이 합의되지 못한 제품팀의 경우, 몇 가지 우선순위 선정에 대한 도구들을 활용해보시길 권장드립니다. ex) Kano model, RICE, MoSCoW, Value vs Effort, etc.
마치며.
백로그 관리는 팀의 역학관계에 따라 굉장한 스트레스로 다가올 수 있습니다. 전 세계의 제품 관리자는 동일하게 백로그의 우선순위 결정에 큰 부담을 안고 있습니다. (한국만 그렇지는 않다는 것이 위안이 될까요.) 갈등 상황에 놓여 있거나 팀의 이해관계 중심에서 제품 관리자의 역할은 때때로 충돌 상황의 중심에서 극도의 스트레스로 다가올 수 있습니다. (전 직군 중에 제품 관리자의 업무 만족도가 가장 낮다는 통계 결과 ㅜㅜ the state of Product Leadership 2020 )
선택과 집중이 필요합니다. 넓혀져 있는 전선을 짧게 단축시켜줘야 합니다. 백로그의 규모를 축소하고, 단기 목표에 부합하도록 팀과 동기화하세요. 현시대의 제품팀은 작은 전투의 승리가 차곡차곡 누적되어야 합니다. 조직 내의 제품 관리자가 신뢰자본을 쌓는 첫 발걸음은 백로그 관리부터 시작됩니다.
