[Essential Scrum] '프로덕트 백로그'(Product Backlog)란?

[Essential Scrum] '프로덕트 백로그'(Product Backlog)란?

PBI에 대해 공부하면서 본 essential scrum의 site내용을 번역한 자료입니다.

 

PRODUCT BACKLOG OVERVIEW

Product Backlog는 제품에서 요구되는 functionality(기능)의 우선 순위 목록이다. Product Backlog는 무엇을 만들지와 어떤 순서로 만들지에 대한 집중적이고 shared understanding(공유된 이해)를 제공해 준다.

PBI(Product Backlog Items)

Product Backlog는 PBI(Product Backlog Item)들로 구성되어 있다. 대부분의 PBI들은 사용자나 고객에게 실질적인 가치(tangible value)를 제공할 feature들이나 기능들의 item들이다. 이것들은 종종 User story(또는 use case or free form text)처럼 쓰여진다. 다른 PBI들에는 수정이 필요한 defect이나 기술 개선 사항들, 지식 습득 작업(knowledge-acquisition work), 그 밖에 PO(Product Owner)가 중요하다고 생각하는 기타 모든 작업이 포함된다.

 

GOOD PRODUCT BACKLOG CHARACTERISTICS

좋은 Product Backlog는 DEEP이라는 특성을 가진다. 여기서 DEEP이란 적절히 상세하고(Detailed appropriately), 신생의(Emergent), 잘 계산된(Estimated), 우선 순위가 매겨진(Prioritized)을 의미한다. 

Detailed Appropriately

PBI들의 세부 사항 수준은 다를 것이다. 빨리 작업해야 하는 것들, 곧 마무리 해야 하는 것들은 좀 더 자세할 것이다. 우리가 당분간 작업하지 않을 것들은 좀 덜 자세할 것이다. 우리는 backlog item들의 우선 순위가 높아질 수록 더 세부 사항을 충분히 시간에 맞게 추가하기를 원한다.

Emergent

Product backlog는 살아 있는 문서다. product가 계속 개발중이고 유지 보수 될 대 지속적으로 변경된다. 팀과 PO가 product와 marketplace에 대해 더 잘 알게 되면, 그들은 새로운 item들을 추가하고 어떤 것은 버리고, 변경할 수도 있다. 이러한 emergent nature(창발적 본성)은 예상할 수 있을 뿐만 아니라 정상적이고 기능적인 product backlog의 특징이다. (The emergent nature of the product backlog is not only expected but is a sign of a healthy and functioning product backlog.)

 

'창발적' 이란? 남이 하지 아니하거나 모르는 것을 처음으로 또는 새롭게 밝혀내거나 이루어 내는 것.

Estimated

적절한 시점에 각 Product Backlog는 해당 item을 개발하는 데 필요한 effort에 대응되는 크기의 견적이 있어야 한다. Product owner는 이 추정치를 이용하여 PBI들의 우선 순위를 결정한다. 이상적으로는 product backlog의 top에 있는 대부분의 item들이 단일 sprint동안 작업할 수 있을 만큼 충분히 작은 sprint 크기여야 한다. 우선 순위가 높고 큰 item들은 sprint-ready로 선언되기 전에 더 작은 단위의 stoty들로 구분되어야 한다.

 

Prioritized

Product backlog는 PBI들의 우선순위 리스트여야 하지만, 모든 PBI가 우선순위를 가질 필요는 없다. 나는 PBI들 release worth에 따라 우선 순위가 매겨지는 것을 추천한다. 그 이상의 우선 순위를 정하는 것은 처음 release가 되고 난 후에 너무 많은 것이 변경 될 수 있기 때문에 노력의 낭비가 될 것이다. 대신 새로운 item들이 등장할 때 "someday"나 "future release"와 같이 나중에 사용될 수 있도록 저장하는 것을 추천한다.

 

GROOMING

DEEP 특성을 가진 product backlog를 만들기 위해 우리는 product backlog를 groom하는 시간을 가져야 한다. Grooming은 3가지 원칙을 가진다. creating and refining PBIs, estimating PBIs, and prioritizing PBIs. 이러한 활동들은 Product development effort의 전체 시기에 걸쳐 진행된다.

 

Grooming은 PO(의사 결정자)가 주도하고 ScrumMaster, 개발팀, 주요 내 외부 stakeholder의 상당한 참여를 포함하는 협업적인 노력이라 할 수 있다. Scrum에서 Grooming은 여러 차례 발생할 수 있지만, 대부분 release planning, sprint review후에 각 sprint의 정기적인 부분(PO와 팀에 적절하게 ad hoc(임시), 주간, 또는 1회로) 초기에 발생한다. 일반적으로 개발팀은 각 sprint당 최대 10%의 시간을 grooming 활동을 보조하는데 사용할 것으로 예상해야 한다.

Definition of Ready

Grooming의 최종 결과로 Backlog의 제일 위에 있는 item들이 sprint로 이동할 준비가 되어 있어야 한다. 일부 팀들은 PBI를 위한 'definition of ready' checklist를 사용하여 이 상태를 공식화 했다.

 

Example Definition of Ready

-Business Value가 명확하게 표현됨

-세부 사항이 충분히 이해가 가능함.

-종속성들이 식별 가능하고, 차단된 종속성들이 존재하지 않음.

-PBI와 관련하여 적절하게 인력이 배치됨.

-sprint중에 완료할 수 있을 정도로 충분히 작게 추정됨.

-Acceptance criteria가 명백하고 testable함.

-Performance criteria(성능 기준)을 정의하고 테스트할 수 있음

-Team이 완료된 PBI를 어떻게 demo해야 하는지를 이해함.

 

Flow Management

Scrum팀은 양질의 Product Backlog를 통해 불확실한 상황에서도 빠르고 유연한 흐름(fast, flexible, flow)을 제공할 수 있다.

 

Release Flow Management

Grooming은 지속적인 release planning, release기간 내의 feature들의 흐름을 지원해 준다. 각각의 release들은 Product backlog를 통해 실행되는 두 개의 라인으로 시각화 될 수 있고 3가지 영역으로 구분할 수 있다. (must have, nice to have, and won't have.) 상위 라인에 있는 PBI들은 반드시 release에 포함되어야 한다. 상위 라인과 하위 라인에서 떨어져 있는 것들은 "nice to have"가 될 것이다. 하위 라인아래 있는 PBI들은 release에 포함되지 못할 것이다.

 

Sprint Flow Management

Product backlog grooming은 효과적인 sprint flow를 보장해야 한다. Product backlog를 Product feature들이 sprint로 흘러 가듯이 pipeline을 그려보라. 여기서 team은 design하고 built하고 test할 수 있다. 제안된 feature가 pipeline의 끝에 가까워 질 수록 점차적으로 작아지고 더 정교해 진다는 것을 알고 있어야 한다. feature가 producct backlog pipeline에서 나갈 때까지 준비되어야 한다. 팀이 이를 이해하고 sprint 동안 그것을 편안히 deliver할 수 있을 만큼 상세해야 한다. Product owner는 절대 pipeline을 마르게 해서는 안된다. 팀은 최적의 방식으로 sprint를 채울 수 있는 충분한 잠재적 아이템을 필요로 한다.

 

마찬가지로, product owner는 pipeline에 너무 많은 작은 items이 과도 하게 채워져 있으면 상황이 변할 경우 재작업하거나 폐기해야 할 세부 inverntory(requirements)가 쉽게 발생할 수 있기 때문에 너무 많은 item들을 과다하게 채우지 말아야 한다. 따라서 많은 구성원들이 항상 backlog에서 2-3 sprint가치의 sprint-ready features을 보유해야 한다.

 

WHICH AND HOW MANY PRODUCT BACKLOGS?

 

일반적으로 각 제품에는 제품 build에 필요한 작업을 설명하는 단일 backlog가 있어야 한다. 그러나 때때로 이 규칙이 깨질 수 있다. 그 방법과 이유를 이해하기 위해 먼저 Product라는 용어를 정의해 보겠다.

 

What Is a Product?

 

무엇이 Product을 구성하는지는 항상 명확하지 않다. Microsoft Excel이 Product입니까? 아니면 Microsoft Office라고 하는 더 큰 Product의 구성 요소입니까? 나는 고객이 무엇을 구매하고 당신이 팔 의향이 있느냐에 따라 다르다고 말한다. 다시 말해, Product은 고객이 기꺼이 지불할 가치가 있고 우리가 포장하여 판매할 가치가 있는 것이다. 이 정의는 12장에서 논의된 바와 같이 더욱 복잡해질 수 있지만, 이 초기 논의에는 충분하다.

Large Products-Hierarchical Backlogs

가능하면 Microsoft Office와 같은 대형 제품에서도 product backlog 를 하나 사용하는 것이 좋다. 하지만, 때때로 이것은 실용적이지 않다. 이 경우 일부 조직에서는 제품의 대규모 기능을 설명하고 우선 순위를 지정하는 1개의 backlog를 맨 위에 배치하는 hierarchal backlogs(계층적 백로그)를 사용한다. top-level backlog는 chief product owner가 관리한다. 그리고 가장 높은 단계의 backlog 아래에는 각각 특정 기능 영역을 설명하고 지정된 product owner가 관리하는 여러 영역 backlog가 있다.

Multiple Teams-One Product Backlog

One-product-one-backlog 규칙은 제품의 모든 팀이 product backlog를 공유할 수 있도록 설계되었다. 이렇게 하면 모든 기능이 다른 모든 기능과 우선 순위를 다투기 때문에 경제성이 최적화되므로 전체 제품 관점에서 가장 우선 순위가 높은 feature을 식별하고 우선 순위를 지정할 수 있다. 그런 다음, 모든 팀이 상호 교환이 가능한 경우(interchangeable), 어떤 팀도 단일 백로그에서 어떤 PBI라도 처리할 수 있으므로 항상 최우선 순위가 높은 항목을 먼저 개발할 수 있다.

 

하지만 때로는 우리 팀이 서로 교환이 안 되는 경우도 있다(not interchangeable). 그들은 더 전문적인 기술과 지식을 가지고 있다. 이러한 경우, 백로그에 대한 team-specific views가 필요하므로 팀은 자신의 skillsets와 관련된 features만 보고 선택할 수 있다. 이는 효과가 있지만, 일부 팀이 다른 팀보다 훨씬 낮은 우선 순위 기능에 대해 작업하게 되는 불행한 부작용이 있다. 이것이 조직이 높은 수준의 shared ownership(공유 소유권)과 상호 교환 가능한 팀(interchangeable teams)을 위해 노력해야 하는 한 가지 이유이다.

One Team-Multiple Products

회사가 여러 제품을 보유하고 있는 경우 여러 개의 제품 백로그가 발생한다. 여러 제품 백로그를 처리하는 가장 좋은 방법은 각각 제품 백로그를 독자적으로 작업할 수 있게 하나 이상의 팀을 할당하는 것이다. 조직 장애로 인해 이러한 문제가 발생할 경우, 한 팀이 여러 제품에 대해 동시에 작업해야 하는 경우, 영향을 받는 제품의 PBI를 하나의 product backlog로 병합하는 것이 좋다. 이를 위해서는 영향을 받는 각 백로그의 product owners가 함께 모여 앞으로 다가올 모든 items에 대해 단일 우선 순위(single prioritization)에 도달해야 한다.

 

CLOSING

 

product backlog는 불확실성 상황에서 빠르고 유연한 가치 제공 흐름을 달성하는 데 중요한 역할(crucial rule)을 한다. 다음 장에서는 제품 백로그 항목을 추정하는 방법과 이러한 추정을 velocity(속도) 측정에 사용하는 방법에 대해 설명한다.

 

Scrum의 성공을 위해서는 우수한 제품 백로그 관리가 필수적이다. 

 

원문 출처

innolution.com/essential-scrum/table-of-contents/chapter-6-product-backlog

Chapter 6 of "Essential Scrum": Product Backlog | Innolution