개요 - 제품 백로그가 무엇인가?

제품 백로그는 원하는 제품 기능에 대한 우선 순위 목록이다. 이는 무엇을 어떤 순서로 개발하느냐에 초점을 두고 있다. 제품 백로그는 가시성이 높은 산출물이며, 프로젝트에 참가하는 누구나 접근할 수 있다.

제품 백로그 항목

제품 백로그는 백로그 항목으로 구성된다. 대부분의 제품 백로그 항목은 제품 기능이다. 이는 사용자나 고객에게 실질적인 가치가 있는 기능 항목을 뜻한다. 제품 백로그는 종종 사용자 스토리로 작성된다.

제품 백로그 항목으로는 아래와 같은 것들이 있을 수 있다. (Page. 115 예시)

• 완전히 새로운 제품 기능
• 현존하는 제품 기능의 변화
• 수리가 필요한 결함
• 기술적인 개선
• 지식 습득을 위한 작업
• 기타 제품 책임자가 가치 있다고 여기는 것

좋은 제품 백로그의 특징

로만 피슬러와 마이크 콘은 DEEP 라는 줄임말로 좋은 제품 백로그의 몇 가지 중요한 특징들을 요약했다.

• Detailed appropriately: 적절한 세부사항
• Emergent: 발생적
• Estimated: 추정
• Prioritized: 우선 순위화

Detailed appropriately: 적절한 세부사항

위의 이미지처럼 모든 제품 백로그 항목이 같은 시점에 같은 수준의 세부 사항을 가지고 있지는 않다.

• 곧 작업하기로 계획하고 있는 제품 백로그 항목
  • => 백로그 위쪽에 있고 가까운 시기의 스프린트에서 작업할 수 있도록 크기가 작고 상당히 자세함
• 당분간 작업하지 않을 제품 백로그 항목
  • => 백로그 바닥 쪽에 있고 크기가 더 크며 덜 자세함(애자일 자체가 요구사항은 자주 변경될 수 밖에 없다는 것을 인정하므로 괜히 미리 세부적으로 나누면 추후 변경이 있을때 손실만 더 크다)

Emergent: 발생적

개발되거나 유지되고 있는 제품이 있는 이상 제품 백로그는 절대 완성되거나 동결되지 않는다.

대신에 이는 경제적으로 가치 있는 정보가 계속해서 흘러 들어옴에 따라 끊임없이 갱신된다.

• 고객의 니즈에 맞춰 생각을 바꾸는 것으로 인해
• 경쟁사의 예측 불가능한 행동으로 인해
• 예상치 못한 기술 문제로 인해

따라서 제품 백로그의 구조는 시간이 지남에 따라 계속해서 새롭게 만들어진다. 새로운 항목들이 더해지거나 기존의 항목들이 다듬어지면서 균형과 우선순위를 맞추어간다.

Estimated: 추정

제품 백로그 항목마다 그 항목을 개발하는데 들어간다고 추정되는 노력의 크기가 있다. 이 추정치는 제품 백로그 항목의 우선순위를 정하는데 고려되는 요소 중 하나이다.

Prioritized: 우선 순위화

백로그에 있는 모든 항목들이 우선 순위화 되진 않는다. 다가올 몇 개의 스프린트에서 작업할 높은 항목들의 우선순위를 정하는 것은 유용하다. 필요한 수준 이상으로 자세하게 우선순위를 정하는 것은 시간 낭비일 가능성이 크다.

그루밍

좋은 DEEP 제품 백로그를 얻기 위해 제품 백로그를 관리, 조직, 운영해야 한다.

그루밍이란?

그루밍은 아래와 같은 세 가지 주요 행동을 가리킨다.

• 제품 백로그 항목을 새로 만들거나 정제하기(세분화)
• 제품 백로그 항목 추정하기
• 제품 백로그 항목 우선순위 정하기

그루밍은 누가 하는가?

제품 백로그 그루밍은 제품 책임자가 주재하고 내부 및 외부 이해관계자, 스크럼 마스터, 개발 팀의 중요한 참여자들이 함께하는 지속적인 공동의 노력이다. (개발팀은 단순하게 개발만 하는게 아니다!)

하지만 최종적으로 그루밍에서 결정하는 사람은 제품 책임자 단 한명이다. 좋은 제품 책임자는 협력적인 그루밍이 모든 참여자 간에 중요한 대화를 조성하고 다양한 그룹에 소속된 개인들의 집단 지성과 관점을 통해 다른 방식으로는 놓칠 수 있는 중요한 정보를 밝혀낸다는 것을 이해한다. 또한 다양한 팀 멤버들을 그루밍에 포함시켜 모두가 더 명백하고 공통된 이해를 가지게 하여 잘못된 소통과 일을 전달하는데 걸리는 시간 낭비를 줄인다.

일반적인 규칙은 개발 팀이 각 스프린트의 10% 정도의 시간을 제품 책임자를 도와 그루밍 활동을 하는데 할애해야 한다는 것이다. 이 시간을 새로 생긴 제품 백로그 항목을 제작하거나 검토하고, 또한 큰 항목을 작은 항목으로 점진적으로 정제하는데 사용한다. 또한 제품 백로그 항목의 크기를 추정하여 우선순위를 정리하는데 도움을 준다.

언제 그루밍이 일어나는가?

그루밍을 할 수 있는 여러 시기는 아래와 같다.

• 초기 그루밍은 출시 계획 활동의 일부로서 실행된다.
• 개발 팀과 일을 할 때 제품 책임자는 스프린트 시행 기간 동안 주간 혹은 매 스프린트마다 한 번씩 그루밍 워크숍 일정을 만들 수 있다.
  • 그럼으로써 일정에 주기적으로 그루밍을 넣고 팀이 스프린트 계획 시 이를 고려하게 할 수 있다.
  • 이는 또한 계획되지 않은 회의를 잡기 위해 노력하는데 들어가는 낭비를 줄인다.
• 때때로 팀이 미리 일정한 시간을 정해 두기보다는 그루밍을 스프린트 전반에 걸쳐 나눠하기를 선호하는 경우 일일 스크럼 다음에 약간의 시간을 잡아 점진적인 그루밍을 한다. 이때 모든 팀원들이 참여하지 않아도 된다.
• 대부분의 팀은 스프린트 리뷰의 일부로서 약간의 그루밍을 하는 것이 자연스럽다고 여긴다.
  • 참여하는 모두가 제품이 어느 위치에 와있고 또 어느 방향으로 가는지에 대해 더 나은 이해를 얻으면서 새로운 제품 백로그 항목이 만들어지거나 현존하는 제품 백로그 항목의 우선순위가 다시 정해지고, 혹은 더 이상 필요하지 않다면 삭제된다.

Note: 그루밍은 언제 언제 하느냐보다, 유연하고 빠른 비즈니스 가치 전달을 보장하도록 스크럼 개발 흐름과 잘 통합되게 하는 것이 더 중요하다.

준비의 정의

제품 백로그를 그루밍하는 것은 백로그 위쪽에 있는 항목을 스프린트로 이동할 준비를 하는 것이다.

일부 스크럼 팀은 준비의 정의(definition of ready)를 만들어 이를 형식화한다. 준비의 정의와 완료의 정의 를 스프린트 사이클 동안 스프린트 백로그 항목의 두 가지 상태로 생각할 수 있다.

준비의 정의와 완료의 정의 모두 제품 백로그 항목이 각각의 상태를 갖추었다고 생각되기 전에 해야 할 일의 체크리스트 이다.

Note: 확실한 준비의 정의는 스크럼 팀이 스프린트 목표를 성공적으로 이룰 확률을 상당히 증진시킬 것이다.

흐름 관리

제품 개발에서 불확실성을 제거할 순 없다. 경제적으로 중요한 정보의 흐름이 계속 들어올 것이고, 일을 계속해서 조직하고 관리해야 한다는 가정을 해야 한다. 그래야 좋은 흐름을 유지하면서 이정보를 빠르고 효율적으로 처리할 수 있다.

좋은 출시 흐름 과 스프린트 흐름 을 돕는 제품 백로그의 역할은 아래와 같다.

출시 흐름 관리

제품 백로그는 반드시 진행 중인 출시 계획을 돕는 방향으로 그루밍되어야 한다.아래 그림과 같이 제품 백로그를 각 출시 때마다 두 줄의 선을 이용해 나누는 것이 실제로 편리하다.

• 개발해야 할 것: 성공적인 출시를 위해 반드시 개발해야 하는 것들
• 개발하면 좋을 것: 다음 출시의 목표이며 포함시키면 좋은 것들(시간이나 자원이 부족하면 포기할 수 도 있음)
• 개발하지 않을 것: 현재 출시 시점에선 확실히 포함하지 않을 것들

이런 식으로 제품 백로그를 관리하는 것은 진행 중인 출시 계획을 더 잘 할 수 있게 도와준다.

스프린트 흐름 관리

좋은 스프린트 흐름을 위해 그루밍할 때, 제품 백로그를 요구사항의 파이프라인이라고 보는 것이 도움이 된다.

크기가 크고 덜 이해된 요구 사항들이 파이프라인으로 삽입된다. 정제되지 않은 요구 사항은 파이프라인을 통해 진행되고, 작업을 해야하는 시간에 가까워질수록 그루밍 활동으 통해 점진적으로 정제된다. 하나의 파이프라인을 따라 흘러나올 때면 반드시 준비가 되어 잇어야 한다.(오른쪽에 있는 팀이 이해할 수 있을만큼 자세하고, 하나의 스프린트 동안 편하게 전달할 수 있다는 것을 의미)

만일 유입과 유출 사이에 부조하나 차이가 생기면 문제가 발생한다. 그러기에 적당한 제품 백로그 ㅎ아목을 재고로 가지고 있어 일정한 흐름을 만들되 낭비되지는 않아야 한다.

Note: 스크럼팀이 사용하는 한 가지 접근법으로는 백로그에 적절한 양의 그루밍과 구현 준비를 마친 항목 재고를 두는 것이다. 경험적으론 두 개에서 세 개의 스프린트 분량의 스토리를 준비하는 것이 적절하다.

어떤 그리고 얼마나 많은 제품 백로그가 있어야 하는가?

한 제품에는 하나의 백로그만 가져간다.

하지만 이와 같은 기준을 적용할땐 여러 가지 문제가 있을 수 있다.

• 제품을 구성하는 것이 무엇인지 명확하지 않는 경우나 제품이 너무 큰 경우
• 상호 교체될 수 없는 여러 개의 팀이 있거나 한 팀이 여러 개의 제품을 만드는 경우

제품이란 무엇인가?

무엇을 제품으로 볼 건지에 대한 이슈가 있다.

마이크로스프트 워드는 제품이가 혹은 마이크로소프트 오피스라 불리는 더 큰 제품의 일부인가? 만일 우리가 하나의 제품 세트만 판매한다면 세트를 위해 제품 백로그를 만들어야 하는가 아니면 세트 안에 있는 각각의 제품에 대해 제품 백로그를 만들어야 하는가?

제품은 무언가 가치가 있는 것으로, 고객이 비용을 지불할 의사가 있으면 우리가 포장하고 판매할 의사가 있는 것이다. 휴대용 GPS와 경로 알고리즘의 예시를 통해 어느 것을 제품으로 볼 것인가의 관점으로 접근하자하면 블랙홀로 깊이 빠져들 수 있다.

포장, 전달, 그리고 최종 사용자의 가치가 더해진 제작물을 기준으로 제품 백로그를 맞추자.

큰 제품 -계층적인 백로그

핸드폰처럼 큰 제품 개발 과정에는 하나의 시장성 있는 기기를 만들기 위해 할께 일하는 수십 내지 수백 개의 팀이 존재한다. 이 모든 팀에서 오는 제품 백로그 항목들을 하나의 관리 가능한 제품 백로그로 만드는 것은 실용적이지 않다.

우선 이 모든 팀들은 연관된 영역에서 일하고 있는 것이 아니다. 예를 들어, 핸드폰의 시각 음향 플레이어를 만드는 7개 팀이 있고, 핸드폰의 웹 브라우저 작업을 하는 8개 팀이 있다고 해보자. 각 영역은 고객에게 인식 가능한 가치를 전달하고,다른 영역과 어느 정돈 무고나하게 세부 수준에서 정렬되고 우선순위화 될 수 있다.</b>

위의 이미지의 맨 왼쪽 처럼 계층 구조 맨 위에는 여전히 큰 규모의 제품 기능(에픽)을 기술하고 우선순위를 매긴 하나의 제품 백로그가 있다. 그 다음에 각 연관된 제품 기능 영역에 각각의 제품 백로그가 있다. 따라서 시각 음향 플레이어 영역의 7개 팀이 작업하는 제품 백로그가 있다. 이 제품 기능 영역 수준의 제품 백로그 항목은 해당 제품 백로그에 있는 항목보다 규모가 더 작을 가능성이 크다.

여러 팀 - 한 제품 백로그

상호 교환적이지 않은 팀의 경우엔 각 팀이 제품 백로그 항목 중에 어떤 항목을 작업할 수 있는지 반드시 알아야 한다. 대신에 공용 백로그의 팀별 시각을 갖는다. 팀이 자신의 기술과 연관된 제품 기능들만 보고 선택할 수 있는 구조를 가지도록 한다.

한 팀 - 여러 제품

여러 개의 제품 백로그를 다루는 가장 좋은 방법은 한 개 혹은 더 많은 팀이 각 제품 백로그를 담당하게 하는 것이다. (아래 이미지의 왼쪽처럼) 하지만 아래 이미지의 오른쪽처럼 한 팀이 여러 개의 제품 백로그 작업을 하게 될 수 도 있다. 이럴때 대부분의 최고의 해결법은 팀이 한 번에 한 제품만 작업하도록 하는 것이다.

하지만 만약 조직적 장애물이 한 팀이 여러 제품을 동시에 작업할 수 밖에 없도록 한다면, 세 개 제품 백로그 항목을 모두 합쳐 하나의 제품 백로그로 만드는 것을 고려할 수 있다. 이때에는 세 가지 제품 책임자들이 모여서 모든 제품들에 걸친 하나의 우선순위를 만드는 것이 필요하다.

마무리

지금까지 불확실성이 있는 가운데 빠르고 유연한 가치 전달 흐름을 이루는데 중요한 제품 백로그의 역할을 설명했다.

제품 백로그 안에 있는 항목의 종류와 몇가지 원하는 제품 백로그 특징을 얻기 위해 그루밍하는 방법 등 제품 백로그를 둘러싼 몇 가지 구조 및 과정에 관련된 쟁점을 강조했다. 그리고 어떤 제품 백로그가 얼마나 많이 있어야 하는지 이야기하면서 결론을 내렸다.