Agile 프로젝트 퀵가이드(4) : Starting편 -제품백로그 도출
Updated:
제품 백로그(Product Backlog)란?
제품 백로그는 출시하려는 제품에 필요하다고 알려진 모든 요구사항에 대한 우선 순위화된 목록입니다. 제품 책임자와 스크럼 팀이 이해할 수 있는 수준의 개요와 설명을 포함하며, 무엇을 개발할지 어떤 순서로 개발하느냐에 초점을 맞춘 공통의 이해를 나타냅니다. 제품 백로그는 스크럼 프레임워크의 중심에 있는 가시적인 산출물이며, S/W개발의 최종 제품 산출물은 이 백로그를 근거로 실제 세계에 구현된 기능이 되는 것입니다.
그러면 제품 백로그는 언제, 어떻게 도출할까요?
제품 백로그 도출
스크럼 프로세스에 의하면 제품 백로그는 가장 먼저 준비되어야 하는 산출물입니다. SI 프로젝트의 경우, 착수 단계에서 프로젝트 요구사항을 수집하여 목록으로 만들는데 이를 제품 백로그로 볼 수 있습니다. 착수 단계에서의 제품 백로그는 간단한 개요 수준으로 작성이 되므로, 보다 상세한 내용은 스프린트를 통해 구체화되어야 합니다.
각 스프린트 진입시 제품 백로그 목록으로부터 항목을 선정하고, 스프린트 수행동안 해당 백로그를 보다 구체적으로 상세화하하여 기능에 반영하여야 합니다. 이 과정에서 시장의 요구, 고객가치에 따라 우선순위가 조정되거나 항목이 추가, 삭제될 수 있습니다다. (단, 이러한 백로그의 조정은 제품 책임자에게 권한이 있음)
- 제품 백로그와 요구사항
- SI 프로젝트에서는 요구사항 목록이라고 볼 수 있다.
- 프로젝트 착수 전에 요구사항의 범위가 정의되어 있습니다고 하더라도, Boundary의 개념이거나 또는 상위 수준의 요구사항인 경우가 있으므로, 개발 범위가 명확하지 않은 경우 제품 백로그 목록을 도출해 봄으로써 개발 범위를 구체화하는 효과가 있다.
- 즉, 제품 백로그 목록은 처음부터 완전한 것이 아니며 프로젝트의 전 LifeCycle에 걸쳐 상세화되어 가는 것이므로, 시작 단계에서 세부 요구사항 확정을 위해 지나친 노력을 쏟을 필요가 없다.
자, 이제 제품 백로그는 작성해봅시다. 다음과 같이 간단하게 목록 형태로 작성을 해도 되고 JIRA를 사용하여 일감으로 등록을 하게 되면 효율적으로 백로그를 관리할 수 있습니다.
(예시1) 엑셀에서 백로그 작성
(예시2) JIRA에서 백로그 작성
제품 백로그와 사용자 스토리(User Story)
제품 백로그는 스크럼 가이드북에서 정의한 요구사항을 담은 산출물이라면, “사용자 스토리”는 제품 백로그를 표현하기 위한 다양한 기법 중 하나로 볼 수 있습니다.
제품 백로그의 내용을 상세화하기 위한 템플릿으로 기존의 요구사항 명세서나, 유즈케이스 등을 활용할 수도 있습니다. 스크럼 프로젝트의 경우 보통 사용자 스토리 방식을 선호하는데, 형식화된 문서 산출물을 지양하고 이해당사자간 이해와 공유를 빠르게 하기 위한 스크럼의 취지에 부합합니다.
단, 사용자 스토리는 사용자가 사용하는 기능 위주로 표현이 되므로, DB성능, 편리한 UI 등과 같은 비기능적 요구사항은 사용자 스토리 외의 다른 방식으로 백로그에 수집이 되어야 합니다. JIRA와 같은 도구를 이용하면 일감 등록시 “Story”와 “Task” 유형을 제공하므로 제품 백로그를 통한 요구사항 관리가 편하게 됩니다.
프로젝트 초반 사용자 스토리 W/S을 개최합니다면 보다 빠르게 전반적인 사용자 스토리를 도출하고, 업무의 전체 맥락과 기능을 공유하고 이해하는데 도움이 될 수 있습니다.
【 사용자 스토리 작성 방법 】
론 제프리스는 사용자 스토리를 간단하고 효과적으로 작성할 수 있는 다음과 같이 방법을 제안하였습니다.
시작 시점에서 위와 같이 단순하게 작성된 사용자 스토리는 점차적으로 구체화되어야 합니다. 사용자 스토리가 구체화되면서 해당 내용은 사용자 스토리의 목표 기능을 테스트하거나 해당 기능이 완료되었음을 알 수 있는 알 수 있는 조건-인수조건 또는 DoD(Definition Of Done)라 함-이 포함되어야 합니다.
사용자 스토리가 하나의 스프린트 내에 완료할 수 없을 만큼 크다면, 좀 더 작은 크기로 여러 개의 사용자 스토리로 분할하는 것이 좋습니다.
- 제품 백로그는 언제 구체화하나 ?
- 보통 일정이 정해진 SI 프로젝트에서는 제품 백로그 목록 수준으로 준비 단계에서 도출하고, 상세한 작성은 스프린트 내에서 구체화시킨다.
- 단, 스프린트 내에서 구체화되면서 프로젝트의 예산이나 일정을 초과되는 일이 발생할 수도 있다. 이 경우 스프린트 주기 내에 달성 가능한지 여부를 검토하고, 제품 책임자와 우선순위에 대해 조정해야 한다.
- 제품 백로그를 어떻게 관리할지는 아래 제품 백로그 관리 부분을 참고한다.
제품 백로그의 활용(in 스프린트)
제품 백로그는 릴리즈 계획 및 각 스프린트 수행을 위한 Input으로 사용됩니다.
스프린트 수행시 선택된 제품 백로그에 대해 상세화하게 되는데, 이를 스크럼 Framework에서는 “스프린트 백로그”라고 합니다.
제품 백로그에서 선택된 사용자 스토리를 구현하기 위한 구체적인 화면 스케치, 전제사항 및 실무자가 진행해야 할 Activity 등이 담깁니다. 스프린트 백로그는 스프린트 수행 단계에서 작성되므로, 여기에서는 이 정도로만 활용 범위를 소개합니다.
제품 백로그에 대해 보다 정확한 이해를 위해서는 “스크럼 가이드북”을 참고하십시오.
제품 백로그의 관리
제품 백로그의 우선순위 및 변경에 대해서는 원칙적으로 제품 책임자가 관리의 책임과 소유권을 가집니다. 제품에 대해 다양한 이해관계자가 있는 경우 제품 책임자가 이를 조정하며, 대표적인 결정 권한을 가져야 합니다. 또한 개발 팀이 제품 백로그를 잘 이해하고 개발할 수 있도록 협력해야 합니다.
제품 백로그의 권한이 제품 책임자에게 있습니다고 해서 개발팀이 무조건 따라야 하는 것은 아닙니다. 스프린트 목표에 부합하며 기술적으로 구현 가능한지, 기간 내에 달성 가능한지 등에 대해 개발팀의 의견을 반영해야 합니다.
즉, 애자일 프로젝트라고 해서 고객의 요구사항을 전부 반영해야 하는 것은 아니며, 애자일을 떠나서 요구사항 관리는 프로젝트 관리의 중대한 임무이자 모두가 갖는 책임입니다. 다만, 애자일을 도입할 경우 고객 가치에 기반하여 우선순위를 조정하여 가치 우선한 제품을 되도록 이른 시기에 릴리즈함으로써 불필요한 rework과 무의미한 결과물을 피하고자 빠른 피드백을 받는 것에 목적이 있는 것이지, 변경요청이 무한 반복된다거나 일정과 가용 리소스를 넘어서는 요구사항의 수용으로 오해해서는 안됩니다. 요구사항 주어진 요구사항이 금번 스프린트 내에 달성 불가능하다면 백로그 목록에 추가하여 다음 스프린트에서 검토되도록 해야 합니다.
- 제품 백로그는 언제 변경할 수 있는가 ?
- 제품 백로그의 변경은 주로 스프린트 리뷰 및 스프린트 계획 미팅에서 논의하도록 한다.
- 스프린트 도중에 변경이 되어야 합니다면 스프린트 계획 미팅시 이에 대해 충분히 검토되지 않았음을 의미한다. 보다 상세한 내용은 스프린트 계획 편을 참고하시라.
< EOF >