---

Scrum Product Backlog란 무엇일까요? 놀라실 수도 있습니다!

Product Backlog(Scrum Backlog) 또는 Scrum Product Backlog는 Scrum 제품의 알려진 모든 요구사항을 관리하는 중심 요소입니다.

제품을 개선하고 목표를 달성하는 데 필요한, 점차 드러나며 순서가 정해진 작업으로 구성됩니다. 요구사항에는 기능 및 비기능 요구사항, 사용자 경험과 사용자 인터페이스 설계 관련 기능이 포함됩니다.

Product Backlog에는 기능 요청과 상위 수준의 사용자 스토리가 담깁니다. 테스트 및 개발 환경 구축 같은 선행 또는 보완 프로젝트 요구사항도 포함할 수 있습니다. 또한 알려진 버그 해결, 기술 부채 감소, 특정 소프트웨어 기능 개선에 필요한 사용자 스토리도 Product Backlog에 들어갑니다.

각 제품에는 그 제품을 만드는 모든 Scrum Team이 공유하는 하나의 Product Backlog가 있습니다. Scrum Product Owner는 Product Backlog의 작성, 유지, 세부 조정을 책임집니다. Product Backlog는 이러한 요구사항을 어떻게 개발하고 제공할지 답하지 않으며 답해서도 안 됩니다.

그것은 Scrum Team의 임무입니다. Scrum Team은 요구사항을 처리하는 데 필요한 작업을 결정하여 Sprint Backlog에 기록합니다. Product Backlog 항목이 Sprint Backlog의 내용을 이끌지만 두 Backlog는 물리적으로 별개의 개체라는 점에 유의하세요.

다음의 소유자는 Scrum 제품 백로그 Scrum Product Owner입니다. Scrum Master, Scrum Team, 다른 이해관계자는 제품 성공을 위한 더 폭넓은 사용자 스토리 목록을 만들도록 기여합니다.

Scrum Product Backlog를 사용한다고 해서 Scrum Team이 작업 관리를 위한 다른 산출물을 만들고 사용할 수 없는 것은 아닙니다. 추가 산출물에는 사용자 역할 요약, 작업 흐름 설명, 사용자 인터페이스 지침, 스토리보드, 사용자 인터페이스 프로토타입 등이 있습니다. 다만 이들은 Scrum Product Backlog를 대체하지 않고 내용을 보완하고 구체화한다는 점에 유의하세요.

Product Backlog는 살아 있는 문서입니다. 소프트웨어가 점진적으로 개선되듯 Product Backlog도 시간이 지나면서 성장합니다. Scrum 프레임워크는 별도의 변화 관리 프로세스 자체를 요구하지 않습니다. Scrum Product Owner는 제품에 대한 최선의 초기 이해를 바탕으로 Product Backlog의 첫 버전을 만듭니다.

Scrum Product Owner는 Sprint마다 제품이 드러나는 과정을 면밀히 관찰하고 고객 요구사항에 대한 지식이 늘어남에 따라 Product Backlog에서 요구사항을 추가하고 삭제하며 세부 조정합니다.

Scrum Product Owner는 Product Backlog 요구사항의 우선순위를 정합니다. Product Backlog 요소의 우선순위가 높을수록 더 상세해야 합니다. 그래야 Scrum Team이 높은 우선순위의 요구사항을 쉽게 이해하고 구현에 필요한 작업을 만들 수 있습니다.

또한 개발자들은 필요에 따라 Product Backlog 항목의 크기를 산정합니다. 스토리 포인트는 선택적인 기법 중 하나입니다. 우선순위가 높은 사용자 스토리의 추정치를 다듬고 개선하여 Sprint Planning 회의를 준비해야 합니다.

각 Scrum Product Backlog에는 단순한 할 일 목록과 구별되는 속성이 있습니다.

• Scrum Product Backlog의 사용자 스토리는 언제나 고객, 사업 소유자, 최종 사용자에게 사업적 또는 기술적 가치를 더합니다.
• 모든 사용자 스토리는 우선순위를 정하고 가장 높은 순서부터 낮은 순서까지 배열합니다.
• 사용자 스토리에 담긴 상세 수준은 Scrum Product Backlog 안의 위치에 따라 달라집니다.
• 필요에 따라 적절한 기법으로 사용자 스토리의 크기를 산정합니다.
• Scrum Product Backlog는 살아 있는 문서입니다.
• Product Backlog는 제품 작업을 설명하며 개발자의 구체적인 실행 계획은 Sprint Backlog에 속합니다.

사용자 스토리는 고객, 사업, 시스템에 가치를 더합니다

Scrum Product Backlog의 각 사용자 스토리는 고객 가치를 제공해야 합니다. 고객 가치가 없는 사용자 스토리는 순수한 자원 낭비이므로 제거해야 합니다. Scrum Product Backlog에는 다음 사용자 스토리가 포함될 수 있습니다.

• 기능 및 비기능 요구사항의 명세,
• 소프트웨어 제품 출시에 필요한 작업의 상위 수준 분할 요약,
• 비운영 개발 및 시연 환경 구축,
• 결함 수정.

Scrum Product Backlog 예시

일부 작업은 소프트웨어 시스템 기능과 사업 고객에게 직접 가치를 더하지 않을 수 있습니다. 그럼에도 장기적으로 품질을 높이고 기술 부채를 줄이며 제품의 유지보수성을 높여 가치를 더해야 합니다.

Product Backlog는 살아 있는 문서입니다

Scrum Product Backlog는 살아 있는 문서입니다. 프로젝트 전체에 걸쳐 변화하고 발전합니다. 필요하면 새 사용자 스토리를 추가하고 기존 스토리를 바꾸거나 더 자세히 정의하거나 삭제할 수 있습니다. Scrum 프로젝트의 요구사항은 폭포수 방법론 때처럼 초기에 고정하지 않습니다.

대신 Scrum Product Backlog의 최종 요구사항 집합은 새롭게 나타나는 소프트웨어 Increment와 함께 반복적으로 발전합니다.

이는 전통적인 요구공학과 다릅니다. 그러나 이 새로운 고객 요구사항 처리 방식은 Scrum Team이 고객 가치를 극대화하고 자원 낭비를 최소화하도록 합니다.

서로 다른 상세 수준

Scrum Product Backlog의 요구사항은 세분화 정도에 따라 깊이가 다를 수 있습니다. 다음 몇 번의 Sprint에서 구현할 요구사항만 더 자세히 정의해야 합니다. 다른 모든 사용자 스토리는 대략적인 수준으로 유지하고 Scrum Team이 더 알아야 하는 시점 직전에 “적시에” 처리해야 합니다.

구현이 필요해질 때까지 일부 요구사항이 바뀌거나 사라질 수 있으므로 그 명세에 시간과 자원을 투자하는 것은 합리적이지 않습니다. 요구사항의 “적시” 처리는 프로젝트에서 “모르는지도 모르는 것”에 대응하도록 Scrum 프레임워크가 제공하는 최고의 이점 중 하나입니다.

Product Backlog에는 하위 수준 작업을 넣지 않습니다

Product Backlog는 보통 제품 작업을 설명하며 이를 수행하는 상세 작업 분할은 담지 않습니다. Scrum Product Owner는 Backlog 정제나 Sprint Planning 회의에 가져오기 전에 사업 고객 및 이해관계자와 함께 요구사항을 정의합니다. 구체적인 작업 분할과 자기 업무의 조직화는 개발자들이 책임집니다.

Scrum Product Backlog는 우선순위에 따라 정렬됩니다

모든 사용자 스토리의 우선순위를 정하고 Scrum Product Backlog를 그 순서대로 높은 것부터 낮은 것까지 배열합니다. Scrum Product Owner는 Scrum Team의 지원을 받아 우선순위를 정합니다. 이때 팀이 가장 흔히 고려하는 요인은 고객 사업에 주는 부가가치, 비용, 위험, 의존성입니다. 이 우선순위를 통해 Scrum Product Owner는 Scrum Team이 다음에 무엇을 만들고 제공해야 할지 결정할 수 있습니다.

Product Backlog 항목 크기 산정

개발자들은 피보나치식 척도의 스토리 포인트나 S/M/L/XL/XXL 상대 크기 등 합의한 기법으로 Product Backlog 항목의 크기를 산정할 수 있습니다. Scrum은 하나의 척도나 먼 미래의 모든 항목에 대한 추정을 요구하지 않습니다. 자세한 내용은 이 자료의 뒷부분에서 다룹니다. 이러한 추정치는 Sprint 가용 역량 계획, Sprint Backlog 내용, 출시 계획에 영향을 줍니다.

Backlog 활용

Scrum Product Backlog에는 정기적인 관리와 관심이 필요합니다. 세심하게 관리해야 하는 이유는 소프트웨어 제품의 본질을 이해하는 기준 정보이기 때문입니다.

프로젝트 초기에는 성공에 매우 관련 있을 수도, 아닐 수도 있는 상위 수준의 스토리가 많이 담깁니다. 프로젝트가 Sprint마다 진행되면서 Scrum Product Owner와 팀은 프로젝트를 더 많이 배웁니다.

이후 Scrum Product Backlog의 내용은 점점 제품과 팀이 배운 것을 반영합니다.

이러한 초기 설정 뒤에는 Scrum Product Backlog를 계속 유지해야 합니다. 유지 작업은 다음을 뜻합니다.

• 새 요구사항을 발견하면 설명하고 추가합니다. 기존 요구사항은 적절히 바꾸거나 제거할 수 있습니다.
• Scrum Product Backlog를 정렬합니다(우선순위 설정). 가장 중요한, 우선순위가 가장 높은 사용자 스토리를 맨 위로 옮깁니다.
• 다음 Sprint Planning 회의를 위해 우선순위가 높은 사용자 스토리를 준비합니다(보통 Backlog 정제 회의 중).
• Scrum Product Backlog의 사용자 스토리를 추정하거나 다시 추정합니다(보통 Backlog 정제 회의 중).

Scrum Product Owner는 Scrum Product Backlog가 언제나 양호한 상태인지 확인할 책임이 있습니다. 다만 유지는 협력적인 과정입니다. 지속적인 Product Backlog 정제와 Scrum 이벤트에 필요한 시간을 위해 Scrum Team 구성원의 적절한 역량을 확보해 두어야 합니다.

또한 Scrum Product Backlog를 함께 관리하면 요구사항을 명확히 하고 새롭게 나타나는 소프트웨어 제품에 대한 Scrum Team 구성원의 공감과 동의를 얻을 수 있습니다.