제품 백로그 작성 및 관리
작성: Mitch Lacey. 소유: Mitch Lacey & Associates, Inc(Agile 및 스크럼 도입과 개선 전문 컨설팅 업체)
2012년 1월
이 문서에서 Mitch Lacey는 제품 백로그의 중요성 및 우수한 백로그를 결정하는 요인에 대해 설명하고 백로그 만들기 및 유지 관리의 몇 가지 모범 사례를 제시합니다.
적용 대상
Application Lifecycle Management, TFS(Team Foundation Server)
이 문서의 내용
소개
제품 백로그
사용자 스토리
예측
우선 순위 지정
끊임없이 변화하는 제품 백로그
- 정리
제품 백로그는 프로젝트를 완료하는 데 필요한 모든 기능과 특징이 우선 순위가 지정된 상태로 포함된 목록입니다. TFS에서 작업 항목을 사용하여 제품 백로그를 관리합니다. 팀 프로젝트를 만드는 데 사용되는 프로세스 템플릿에 따라 선택하는 작업 항목 형식이 달라집니다. 프로세스 템플릿 및 지원되는 작업 항목 형식에 대한 자세한 내용은 팀 프로젝트 아티팩트 작업, 프로세스 템플릿 선택을 참조하세요.
Agile 팀이 제 역할을 수행하는 데 핵심적인 요소가 되는 우수한 제품 백로그의 특성은 다음과 같습니다.
팀이 가장 중요한 기능을 먼저 빌드하도록 우선 순위가 지정되어 있습니다.
우선 순위는 제품 소유자에게 명확한 정보를 제공하기 위해 팀에서 예측하는 것으로서, "이 스토리가 언제 완료되는가?" 등의 질문에 제품 소유자가 답을 알 수 있도록 합니다.
프로젝트를 완료하는 데 필요한 모든 작업을 포함합니다.
프로젝트의 현실을 반영하도록 끊임없이 변화하며 지속적으로 변경되고 개선되는 실무 문서입니다.
우수한 제품 백로그가 있다고 해서 우수한 소프트웨어를 장담할 수 있는 것은 아닙니다. 그러나 적절한 제품 백로그가 없으면 고객이나 관련자의 요구 사항을 충족하지 못하는 불완전한 소프트웨어가 생성되는 경우가 많습니다.
제품 백로그는 끊임없이 관리해야 합니다. 단순한 기술을 통해 시간이 많이 걸리고 부담이 되는 프로세스를 팀 멤버, 고객 및 관련자가 효율적으로 참여할 수 있는 반복적인 대화형 프로세스로 바꿀 수 있습니다. 따라서 제품 백로그를 작성하고 우선 순위를 지정하며 유지 관리하는 데 사용할 수 있는 신뢰할 만한 기술을 습득하는 것이 중요합니다.
제품 백로그
제품 백로그는 프로젝트를 완료하는 데 필요한 모든 기능이 포함된 마스터 목록으로, 우선 순위가 지정되어 있으며 끊임없이 변화합니다. 제품 백로그에는 대개 요구 사항 사용자 스토리(예: 요구 사항), 버그, 리서치 작업(스파이크) 및 엔지니어링 개선 사항이 포함됩니다. 스토리 점수로 통칭되는 추상적인 단위를 사용하여 이러한 항목을 예측합니다.
제품 백로그는 프로젝트에 필요한 모든 작업을 포함하며 시간이 지남에 따라 개선됩니다. 그러므로 제품의 새로운 기능뿐 아니라 버그 수정과 리서치 등 팀이 시간을 들여 수행해야 하는 모든 작업이 포함됩니다. 이처럼 팀이 수행해야 하는 모든 작업을 포함하는 제품 백로그는 프로젝트를 시작하는 출발점이 됩니다. 제품 백로그에 모든 작업이 포함되어 있으면 제품 소유자, 팀 및 관리 부서가 남아 있는 작업을 보다 명확하게 파악할 수 있으므로 이후 단계에서 예기치 못한 사태가 발생할 가능성이 줄어듭니다.
어떤 프로젝트든지 간에 처음부터 깔끔하고 명확하게 정의된 제품 백로그 항목 목록을 갖춰 바로 예측하고 우선 순위를 지정할 수 있는 경우는 많지 않습니다. 대부분의 경우 스토리 노트 카드 더미와 1~2개의 기능 명세만으로 시작하는 경우가 많습니다. 제품 소유자는 팀이 백로그 예측을 시작할 수 있도록 이렇게 정리가 안 되어 있는 정보를 적절하게 정리해야 합니다.
사용자 스토리
첫 단계에서는 모든 아이디어와 노트를 사용자 스토리로 변환합니다. 사용자 스토리는 구현 세부 정보(요구 사항을 충족하는 소프트웨어를 만드는 방법)를 제시하지는 않지만 최종 사용자가 원하는 기능(소프트웨어를 통해 수행할 수 있는 작업)을 제시할 수 있습니다. 각 사용자 스토리의 제목은 "<사용자>로서 나는 <기능>이 <이유>하기 위해 필요합니다."와 같은 형식을 따라야 합니다.
.png "스토리 카드 예제")
제품 백로그 자체와 마찬가지로 각 사용자 스토리도 시간이 지나면서 개선됩니다. 프로젝트 진행 과정에서 팀은 이러한 스토리 예측/우선 순위 지정, 스토리에 세부 정보 추가, 스토리를 더 작은 스토리로 분할/스토리 삭제 등을 수행합니다. 스프린트로 옮겨진 스토리는 구현되어 고객에게 제공됩니다.
사용자 스토리에 대한 자세한 내용은 백로그 만들기 및 PowerPoint를 사용하여 사용자 아이디어 스토리보딩을 참조하세요.
모든 아이디어와 노트를 사용자 스토리로 변환한 후에는 예측과 우선 순위 지정을 수행합니다.
예측
예측은 단어의 정의 그대로 정확하지 않습니다. 그러나 시간을 들여 전체 팀이 참여해서 연습한다면 시간이 갈수록 비교적 정확한 예측을 훨씬 효율적으로 작성할 수 있게 될 것입니다. 첫 단계에서는 제품 백로그 항목에 대한 예측 정보를 제공할 팀을 구성합니다. 팀은 각 스토리를 예측할 때 스토리 점수라는 추상적인 측정 단위를 사용하여 예상 상대 크기를 제시합니다.
예측이 꼭 필요한 이유는 다음의 두 가지입니다.
"언제 완료되는가?"라는 질문에 대답하는 데 도움이 됩니다.
제품 소유자가 각 항목의 우선 순위를 결정하는 데 도움이 됩니다.
제품 소유자와 팀은 예측을 통해 특정 스토리의 비용을 파악할 수 있으며, 이를 토대로 제품 소유자가 스토리의 상대적인 우선 순위를 지정할 수 있습니다. 팀의 예측 값이 클수록 시간과 자원 측면에서 해당 스토리를 구현하는 비용이 더 많이 들게 됩니다. 그러므로 제품 소유자의 희망 목록에서 우선 순위가 높은 항목의 비용이 만만치 않은 경우 우선 순위가 낮아질 수도 있습니다.
팀은 Planning Poker, The Big Wall 또는 기타 기술을 사용하여 스토리 점수 측면에서 작업을 예측할 수 있습니다. 예측 기술에 대한 자세한 내용과 스토리 점수에 대한 간략한 설명은 예측 및 백로그 정리 및 예상을 참조하세요.
팀에서 모든 스토리를 예측하고 나면 우선 순위를 지정합니다.
우선 순위 지정
모든 제품 백로그는 비즈니스 가치와 위험을 고려하여 우선 순위를 지정합니다. 제품 소유자는 백로그의 각 항목을 서로 비교하여 상대적 우선 순위를 결정합니다. 이를 위해 제품 소유자는 각 항목의 크기, 비즈니스에 대한 가치 및 그와 관련된 위험을 고려합니다. 그러고 나면 항목의 우선 순위를 내림차순으로 정렬합니다. 우선 순위가 높은 항목이 제품 백로그 위쪽에 표시되고 우선 순위가 낮은 항목이 아래쪽에 표시됩니다. 팀은 가장 중요한 항목을 먼저 완료할 수 있도록 우선 순위가 가장 높은 항목 중에서 다음 예정 스프린트에 착수할 작업을 선택합니다.
백로그의 항목은 크기가 서로 다를 수 있습니다. 스프린트 한 번으로 완료할 수 있는 항목도 있지만 크기가 매우 커서 팀이 관련 작업 또는 구현에 걸리는 기간을 확신할 수 없는 항목도 있습니다. 하지만 괜찮습니다. 항목이 백로그 위쪽으로 이동하면 팀이 예정된 스프린트에서 수행할 작업을 누구나 쉽게 파악할 수 있도록 항목을 보다 집중적으로 처리할 수 있는 더 작은 크기로 만듭니다.
예측과 마찬가지로 초기 제품 백로그의 우선 순위를 지정하는 작업은 까다로울 수 있습니다. 최종 제품, 위험 및 비용을 고려하면서 관련자의 상충되는 수요 간 균형을 효율적으로 유지할 수 있을까요? 다행히도 혁신 게임, 상대적 가중치 등의 다양한 기술이 있기 때문에 이러한 작업을 보다 쉽게 수행할 수 있습니다. 자세한 내용 및 기타 기술을 확인하려면 우선 순위 지정 및 백로그 정리 및 예상을 참조하세요.
어떤 우선 순위 지정 기술을 선택하든 간에 작업 순서는 팀이 비즈니스, 관련자 및 고객에게 가장 많은 가치를 제공하는 기능을 빌드하도록 지정해야 합니다. 작업 우선 순위를 지정하지 않으면 자원 및 일정 변경 시 우선 순위가 높지 않고 낮은 사용자 스토리나 불완전한 사용자 스토리를 제공하게 될 위험이 높아집니다.
백로그 항목의 특성에 대한 자세한 내용은 백로그 만들기 및 포트폴리오 백로그 작업을 참조하세요.
끊임없이 변화하는 제품 백로그
지금까지는 제품 백로그를 새로 만들어 예측과 우선 순위를 지정하는 과정에 대해 중점적으로 설명했습니다. 요구 사항 문서와 달리 제품 백로그는 프로젝트 시작 시 작성해서 그냥 보관해두는 것이 아니라 실제 프로젝트 현황에 따라 지속적으로 확장/축소되면서 개선되는 것입니다. 더 이상 관련성이 없어 제거해야 하는 제품 백로그 항목도 생기고, 더 작은 스토리로 분할해야 하는 항목도 수면 위로 떠오를 수 있습니다. 추가 요구 사항이 확인되면 새 사용자 스토리가 추가되고 예측 및 우선 순위 지정 과정이 진행됩니다.
팀과 관련자가 제품 백로그를 만들고 관리하지만 제품 백로그에 대한 최종 책임은 제품 소유자에게 있습니다. 제품 소유자는 고객과 팀이 모두 프로젝트 릴리스를 위한 작업 계획을 명확하게 파악할 수 있도록 백로그가 최신 상태로 정리되어 있으며 우선 순위가 지정되어 있는지 확인해야 합니다. 프로젝트가 한창 진행 중이더라도 제품 소유자는 제품 백로그를 적절한 상태로 유지하기 위해 여러 작업을 수행해야 합니다.
새 스토리 추가 및 우선 순위 지정
새 스토리를 예측하고 이제 더 잘 이해할 수 있게 된 예전 스토리 데이터도 다시 예측하도록 팀에 요청
팀과 함께 예정된 사용자 스토리를 검토하여 필요에 따라 항목 분할
고객 및 관련자와의 회의를 통한 요구 사항 검토 및 추가
누구나 언제든지 제품 백로그에 항목을 추가할 수는 있지만 제품 소유자만이 항목 우선 순위를 지정할 수 있습니다. 또한 스토리에 우선 순위를 할당할 수 있는 것도 제품 소유자뿐입니다. 팀의 다른 모든 멤버와 관련자는 스토리를 추가할 때 사용 중인 전자 도구에서 해당 정보를 입력하라는 메시지가 표시되더라도 우선 순위를 비워 두어야 합니다.
스토리가 추가되면 제품 소유자는 해당 스토리에 대한 이해도를 바탕으로 우선 순위 예비 평가를 수행합니다. 그런 다음 작성자와 함께 스토리에 대해 논의하여 팀의 질문에 대답할 수 있도록 스토리를 철저하게 파악합니다. 각 스프린트 중 미리 정해진 시간에 제품 소유자는 팀과 회의를 진행하여 새 스토리에 대해 논의하고 공동으로 예측을 진행합니다. 그럼으로써 백로그의 다른 스토리에 비해 새 스토리의 우선 순위를 상대적으로 정확하게 지정할 수 있습니다. 이 프로세스를 백로그 정리라고 합니다.
정리
앞에서도 언급했듯이 제품 백로그 정리는 정기적으로 수행해야 합니다.
스크럼에서 팀은 각 스프린트의 시간 중 5~15%를 정리 작업에 할애해야 합니다. 팀은 예정된 작업과 변경되는 사항을 파악하여 우선 순위가 높아지는 큰 스토리를 분할하고, 작성된 스토리에 대한 예측을 진행하고, 예정된 스토리에 대해 몇 가지 새 디자인 및 계획을 수행해야 합니다. 이를 위해 제품 소유자와 팀은 각 스프린트 계획 회의에서 해당 스프린트 중 백로그를 함께 정리할 일정 시간을 확보해 두어야 합니다. 스프린트 계획에 대한 자세한 내용은 스프린트 계획 및 스프린트 작업을 참조하세요.
개인적으로는 2주 길이 스프린트의 경우 두 번째 주에 이 회의를 진행합니다. 이 경우 제품 소유자가 고객 및 관련자와 의미 있는 대화를 나누고 업무 변경 사항을 파악하며 사용자 스토리 및 새로 추가되거나 우선 순위가 높아진 스토리를 확인할 수 있는 충분한 시간이 주어집니다. 뿐만 아니라 스프린트 중의 이 시기에 다음 스프린트 예측을 시작하고, 회의를 진행할 시기를 결정할 수 있습니다. 스프린트 중 정리 작업을 완료할 수 있는 시간을 충분히 확보하는 것이 중요합니다.
일반적인 정리 회의에서는 제품 소유자가 새로운 기능, 변경된 기능 및 이후 몇 개의 스프린트에 대한 계획을 제시합니다. 이 회의 때 팀은 새 스토리를 예측하고 빨리 완료해야 하는 스토리를 분할하며 시스템의 현재 아키텍처를 검토하고 예정된 기능을 계획 또는 설계합니다. 이 프로세스에서는 흔히 스토리 예측 정보가 변경되며 큰 스토리를 더 작은 스토리로 분할하는 과정에서 새 스토리가 생성될 수 있습니다.
이 프로세스는 간단해 보이지만 다소 까다로울 수 있습니다. 전반적인 과정을 원활하게 진행하려면 제품 소유자는 질문에 대답할 수 있도록 준비를 해야 합니다. 제품 소유자가 다음 스프린트에서 스토리를 완료하도록 계획했는데 팀이 적절한 예측 데이터를 제공하는 데 필요한 정보를 명확히 제공하지 못한다면 문제가 발생할 수 있습니다. 스프린트 계획 회의에서 이러한 상황이 발생하면 스크럼 마스터는 제품 소유자에게 고객 및 관련자로부터 팀에 전달해야 하는 정보가 무엇인지 조언을 해주어야 합니다.
각 정리 회의가 끝나면 제품 소유자는 누구나 새로운 기능, 예정된 기능 및 업데이트된 릴리스 계획을 확인할 수 있도록 관련자와 고객에게 변경 내용을 게시해야 합니다.
우수한 제품 백로그가 있으면 고객 및 관련자와의 대화에서 파악되고 사용자 스토리에서 정의된 가장 중요한 기능을 포함하는 소프트웨어를 빌드할 수 있습니다. 우수한 제품 백로그를 만들고 유지 관리하려면 모든 스프린트에서 정기적으로 관련자/고객 그룹 및 팀과 활발한 교류 관계를 유지해야 합니다.
우수한 백로그를 작성한다고 해서 반드시 효율적인 시스템을 빌드할 수 있는 것은 아닙니다. 하지만 우수한 백로그가 없으면 거의 대부분 고객이 요청한 기능을 수행하지 못하는 시스템을 빌드하게 됩니다. 다시 말해서 백로그를 최신 상태로 유지하지 않은 프로젝트는 거의 다 실패한다고 보면 됩니다.
제품 소유자는 중대한 역할이며, 백로그를 책임지고 관리하는 것은 제품 소유자의 몫입니다. 제품 백로그를 적절한 상태로 유지하면 고객에게 큰 도움을 줄 수 있습니다.
참고 항목
개념
Visual Studio ALM 및 TFS로 작업 추적