스프린트 계획
작성: Mitch Lacey. 소유: Mitch Lacey & Associates, Inc(Agile 및 스크럼 도입과 개선 전문 컨설팅 업체)
2012년 1월
스프린트 계획은 그리 어려운 문제가 아닙니다. 실제로 전체 스크럼 팀은 "무엇을 약속할 수 있는가?"를 파악하기 위해 서로 도와줌으로써 즐겁게 계획을 세울 기회가 됩니다. 이 문서에서 작성자는 스프린트 계획에 계속 초점을 맞추고 그 효율성을 유지하기 위한 예와 전략을 제시하고 팀이 스프린트를 계획할 때 자주 발생하는 문제에 대한 잠재적 해결 방법을 자세히 설명합니다.
적용 대상
Application Lifecycle Management, Team Foundation Server
이 문서의 내용
소개
예측과 약속 비교
스프린트 계획이란
계획을 세우는 방법
일반적인 문제
시나리오: 제품 소유자가 요청한 일부 스토리를 팀이 약속할 수 없음
시나리오: 제품 소유자가 준비가 되지 않은 상태임
시나리오: 1부가 기한을 초과함
시나리오: 2부가 기한을 초과함
시나리오: 제품 소유자가 참석하지 않음
시나리오: 팀에 필요한 수용 기준이 없음
시나리오: 제품 소유자가 완료된 작업의 의미를 모름
시나리오: 스크럼 마스터 또는 제품 소유자가 팀의 예측/작업을 미리 예상하려 하거나 영향을 줌
우리는 계획을 세우는 대신 스크럼을 작성하여 실행합니다.
요즘 이와 같은 문구를 자주 확인할 수 있는데요. 스크럼과 Agile을 사용하는 경우 계획, 예측, 회의 등을 전혀 진행하지 않아도 된다고 생각하는 경우가 많습니다. 그러나 실제로는 전혀 그렇지 않습니다. Agile 프로젝트에서도 다양한 수준에서 계획을 세웁니다. 일별 계획(작업), 주별 계획(스프린트, 반복, 백로그), 릴리스 계획(제품 백로그) 등 여러 가지 계획이 있습니다.
여기서는 스프린트 계획에 대해 중점적으로 설명하겠습니다.
예측과 약속 비교
2011년 여름에 Ken Schwaber와 Jeff Sutherland는 스크럼 가이드를 수정하면서 '스크럼'에 오랫동안 알려지고 확립되어 왔던 행동 한 가지를 제거했습니다. 그것은 바로 제품 소유자와 고객에 대해 팀이 갖던 '약속'입니다. 이들은 약속을 빼는 대신 예측을 추가했습니다. 이제는 팀이 작업을 예측할 수는 있지만 약속하지는 않는다는 내용을 적용한 거죠.
이처럼 바뀐 논리를 이해는 하지만 개인적으로는 다음과 같은 이유로 약속을 선호하는 편입니다.
무엇인가를 약속하는 과정에서 팀은 단순한 예측과는 다른 태도를 나타냅니다. 팀이 예측을 하는 경우 달성할 수 있다고 본 목표를 모두 충족하지 못해도 괜찮다는 의미가 내포됩니다. 팀이 예측을 통해서도 좋은 정보를 얻어 결과적으로는 예측의 편차를 줄일 수는 있지만 예측만 하는 팀은 약속하는 팀에 비해 그러한 편차를 줄이는 시간이 더 오래 걸리는 것을 발견했습니다.
예측 또는 예상은 제품 백로그에 적절합니다. 그러나 팀이 스토리를 제품 백로그에서 스프린트 백로그로 진행하여 각각을 자세히 구분하면 팀이 이를 한층 더욱 세분화하여 "이거 약속할 수 있을까?"라고 자문하게 만드는 세부 정보까지 파악하게 됩니다. 반면 예측 시에는 팀이 놓친 부분이 있더라도 나중에 확인하면 된다는 식의 다소 안일한 상태가 될 위험이 있습니다.
실생활의 예를 들어 보자면 부부나 연인 사이에 "우리 사이는 10년 동안 갈 거라고 예측해"라고 말하는 것과 "당신에게 헌신할 것을 약속할게"라고 말하는 것 중에서 어느 쪽이 좋을지는 명확하겠죠.
결국 스크럼은 상식을 발휘하는 것입니다. 약속 방식과 예측 방식을 둘 다 사용해 보시기 바랍니다. 이건 모두 배우는 과정이기 때문에 어떤 단어를 사용하든 필요한 정보만 파악할 수 있으면 됩니다. 그러므로 상황을 잘 판단해서 두 방식을 적절히 실험해 보고 자신과 팀, 회사에 가장 적합한 방식을 선택하면 됩니다.
스프린트 계획이란
우리는 팀이 예정된 스프린트에서 빌드할 내용과 해당 방법을 계획하는 스프린트 계획 회의를 진행합니다. 여기서 스프린트 계획 회의는 실제로 두 가지의 아주 다른 부분으로 구성됩니다. 1부에서는 팀이 빌드 요청을 받은 대상에 대해 집중적으로 논의합니다. 이 과정에는 제품 소유자와 팀이 모두 참석합니다. 2부에서는 팀이 원하는 기능을 빌드할 방법을 중점적으로 논의합니다. 2부의 경우 팀 전체가 참석해야 하지만 제품 소유자는 원하는 경우 참석해도 됩니다. 제품 소유자는 2부에 참석은 하지 않더라도 질문에 대한 답변은 할 수 있는 상태여야 합니다.
스프린트 계획 회의 1부에서 제품 소유자는 팀에 원하는 스토리 세트를 설명할 수 있습니다. 이 과정에서 스토리의 내용 부분을 상세하게 논의합니다. 제품 소유자가 스토리를 제시하고 각 요소 간의 상호 작용 방식을 보여주며 인터페이스를 단계별로 진행합니다. 인프라 또는 아키텍처 항목을 검토할 수도 있습니다. 이를 통해 팀 멤버들이 해당 기능을 빌드하는 방법을 파악하는 데 충분한 정보를 제공합니다. 그러면 팀은 빌드 방법 회의를 위한 정보를 수집하기 위해 다음과 같은 다양한 질문을 하게 됩니다.
"이러한 모든 스토리의 수용 기준은 무엇입니까?"
"저희가 어떤 데이터 소스를 사용하고 있다고 생각하십니까?"
"이 구성 요소에서 인터페이스는 어떻게 보이면 되죠?"
스프린트 계획 회의의 2부에서 팀은 스프린트 백로그 작성 관련 사항, 즉 스토리 및 스프린트 중에 해당 스토리를 완료하는 데 필요한 작업 목록을 작성하는 데 주력합니다. 백로그를 작성하기 위해 팀은 제품 소유자가 요청한 각 스토리를 작업 수준으로 분할하고 각 작업에 예측 시간을 지정합니다. 2부를 완료할 때 팀은 스프린트 중에 완료를 약속할 수 있는 스토리를 결정합니다.
스프린트 계획 회의의 1부와 2부에는 총 2~8시간이 소요될 수 있습니다. 개인적으로 경험에 따라 사용하는 일반적인 규칙은 스프린트 기간 1주마다 회의의 각 부분에 1시간씩을 지정하는 것입니다. 따라서 1주 길이 스프린트를 실행하는 경우 회의는 총 2시간(1부와 2부에 각 1시간씩)이 소요됩니다. 반면 4주 길이 스프린트를 실행하는 경우 회의는 총 8시간(1부와 2부에 각 4시간씩)이 소요됩니다.
계획을 세우는 방법
여러 스토리가 포함된 목록을 완료하기로 약속하며 스프린트 계획 회의를 마친 팀은 스프린트 계획의 목적을 달성한 것입니다. 그러나 각 팀 멤버가 무리없이 약속할 수 있는 지점까지 도달하려면 사전 계획과 간소화를 위한 작업이 다소 필요합니다.
제품 소유자는 스프린트 계획 중에 회의에 참석하여 원하는 일련의 스토리를 설명해야 합니다. 팀의 목표는 제품 소유자 관점에서 스토리를 이해하여 제품 소유자의 비전을 공유하는 것입니다. 스크럼 마스터는 팀이 충분한 질문을 하여 대답을 통해 도출되는 수용 기준, 스케치, 가정 사항 등의 모든 데이터를 캡처하는지를 확인해야 합니다. 또한 스크럼 마스터는 팀이 질문을 관련 작업으로 구분하는 단계가 시작된 후에 추가적인 질문을 할 수도 있음을 제품 소유자에게 알려야 합니다. 제품 소유자가 전체적으로 볼 때 팀의 기존 작업 속도와 대략적으로 일치하는 스토리를 제시하더라도 팀은 스프린트 계획 회의 1부와 2부에서 파악한 내용에 따라 지정된 스프린트에서 모든 스토리를 실제로 진행할 수 있는지를 최종적으로 결정해야 합니다.
팀은 제품 소유자로부터 모든 정보를 확보한 후 스토리를 작업으로 구분하고 스프린트 백로그를 만들어 각 스토리에 대한 모든 스토리, 참고 사항, 수용 기준 및 예측 데이터를 캡처해야 합니다. 이 작업은 다양한 방식으로 수행할 수 있지만 개인적으로는 모든 팀 멤버의 아이디어를 활용하며 모두가 작업 분석 시 의견을 제시할 수 있는 다음 방법을 사용해 볼 수 있습니다.
스크럼 마스터나 회의 진행자가 스토리를 낭독한 다음 모든 참석자가 스토리를 파악했는지 질문합니다. 팀은 방금 제품 소유자와 함께 스토리에 대해 논의했으므로 해당 스토리를 파악하고 있어야 합니다. 팀에 스토리를 파악하지 못한 멤버가 있으면 시간을 할애해 스토리를 다시 파악하여 필요한 경우 제품 소유자에게 질문을 합니다.
다음으로 각 팀 멤버가 메모지에 각 팀 멤버에게 작업을 하나씩 적고 발표한 다음 메모지를 탁자 한가운데에 놓도록 합니다.
- 각 팀 멤버는 메모지를 탁자 가운데에 던지면서 자신이 적은 작업을 말합니다. 예를 들어 "저장 프로시저 업데이트"를 메모지에 적었다면 "저장 프로시저 업데이트"라고 크게 말합니다. 이 과정을 통해 다른 팀 멤버들이 "그러면 데이터 소스도 업데이트해야 되겠구나"라고 생각하는 등 여러 아이디어를 얻을 수 있으므로 이 과정은 중요합니다. 여기서 메모지에 "데이터 소스 업데이트" 작업을 적은 사람이 있으면 "데이터 소스 업데이트"라고 말하고 메모지를 탁자 가운데에 놓습니다. 이 브레인스토밍 활동을 통해 모든 관련 작업을 파악할 수 있습니다. 이때 중복된 작업이 나와도 관계없습니다. 이 단계를 완료하는 데는 스토리당 대개 5~10분 정도 소요됩니다.
탁자 가운데에 메모지가 모두 모이면 메모지를 정렬합니다. 벽에 메모지를 모두 붙이고 전체적으로 살펴봅니다. 먼저 중복되는 항목을 확인해 겹쳐서 붙입니다. 그런 다음 비슷하거나 종속 관계가 있는 등 서로 관련된 작업을 찾습니다. 예를 들어 비슷한 관계의 작업이 적힌 메모지는 다음 그림과 같이 일부분만 겹치도록 붙입니다.
.png "비슷한 스티커 - 오프셋")
두 작업이 매우 밀접하게 관련되어 거의 동일한 경우에는 아래 그림과 같이 거의 겹치게 붙입니다.
.png "비슷한 스티커 - 겹침")
이렇게 메모리를 분류하면 팀이 작업 목록을 추려내 남은 작업 간의 관계를 파악할 수 있습니다.
작업을 정렬한 후에는 예측을 진행합니다. 개인적으로는 작업 예측 시 카드 게임 방식을 사용합니다. 단, 카드의 숫자가 점수가 아닌 시간을 나타낸다는 점이 다릅니다. 이러한 방식을 사용하는 이유는 큰 작업의 경우 시간과 관련해 불필요한 세부 정보에 집착하는 경향이 많기 때문입니다. 이를 두려워하는 이유는 물론 있습니다. 대부분의 회사에서는 예측 결과를 토대로 팀에게 책임을 묻는 경우가 많기 때문입니다. "8시간이라고 하더니 실제로는 12시간이 걸렸네요. 뭐가 문제죠?" 또는 "8시간이라고 했는데 실제로는 4시간밖에 걸리지 않았군요. 예측을 부풀렸군요"하는 식입니다.
이러한 카드 게임 방식을 사용하는 경우 스토리 요소 예측을 간략하게 유지할 수 있습니다. 즉, 작업 예측에 카드를 사용하면 팀이 일정 수의 작업 중에서 자유롭게 선택을 하되 최종적으로는 적절한 작업을 선택할 수 있게 됩니다. 또한 작업 시간을 6시간으로 예측할지 6.5시간 또는 7시간으로 예측할지에 대해 격한 논쟁을 벌이지 않아도 됩니다.
최종 예측 결과와는 관계없이 예측은 팀이 수행하는 것입니다. 신뢰감을 높이고 제품 소유자가 팀의 작업 속도를 기준으로 요청한 작업을 팀이 완수할 수 있을지를 결정하기 위해 팀만이 사용할 수 있음을 기억해야 합니다. 작업 예측은 특정 기준이 아니며 기준으로 사용해서도 안 됩니다. 또한 예측 결과를 놓고 팀을 비난해서도 안 됩니다.
작업을 예측한 후 팀은 추가 작업을 수행할 수 있는지를 결정해야 합니다. 이렇게 하려면 팀의 수용작업량, 즉 팀이 스프린트 중에 작업할 수 있는 총 시간을 파악해야 합니다. 전담 팀이 있으면 수용작업량을 결정하기가 쉽지만 각기 여러 프로젝트에 배정된 비상근 직원으로 구성된 팀의 경우에는 이 결정이 어려워집니다. 모든 팀 멤버에게 매일 프로젝트 작업을 수행할 수 있는 시간 또는 스프린트당 총 시간을 작성해 제출하도록 한 다음 시간을 모두 더하여 팀이 사용할 수 있는 총 시간을 계산합니다. 팀의 수용작업량이 200시간으로 확인되었다고 가정해 보겠습니다. 예측 결과 스토리의 작업을 수행하는 데 30시간이 걸리는 경우 팀에게 작업을 추가로 맡을 수 있는지 문의합니다. 물론 이 초기 단계에서는 팀이 맡을 수 있다고 대답할 것입니다.
수용작업량을 토대로 작업을 더 추가할 수 있으므로 다음 스토리로 이동해 1~5단계를 반복합니다.
Team Foundation Server를 사용하여 이 작업을 수행하는 방법에 대한 자세한 내용은 공동 작업[리디렉션]을 참조하세요.
어느 시점부터는 작업을 더 맡을 수 있는지에 대한 질문에 대답하기가 어려워집니다. 팀의 수용작업량에 거의 도달했기 때문입니다. 이 과정을 진행할 때는 스프린트의 수용작업량을 가득 채우지 않는 것으로 가정하세요. 컵에 물을 가득 채우면 쏟아지는 것처럼 스프린트의 경우도 마찬가지입니다. 사용 가능한 모든 시간이 예측한 작업 시간에 사용되었는데 스프린트의 이후 단계에서 새 작업이 확인되면 새 작업을 수행할 수가 없게 됩니다. 그러므로 새로 발생하는 작업에 대처할 수 있는 여유 시간을 두어야 합니다.
스프린트 약속을 고려할 때는 이전 스프린트의 데이터를 회고하면 도움이 됩니다. 팀이 지속적으로 작업을 추가로 수행해야 한다면? 스프린트 계획 시 팀이 더 많은 작업을 맡기로 약속할 수도 있습니다. 팀이 스프린트의 모든 작업을 일관되게 완료할 수 없는 경우라면? 완료되지 않은 스프린트의 근본 원인을 해결할 때까지 함부로 약속하지 말아야 할 수도 있습니다.
수용작업량을 얼마나 채울 지 결정할 때는 계획 크기의 증가를 고려하는 방법이 있습니다. 계획 크기의 증가는 초기 예측과 비교하여 실제로 소요된 시간을 측정합니다. 예를 들어 팀의 수용작업량이 사용 가능한 시간 200시간이라고 가정해 보겠습니다. 이 팀은 예측 결과에 따라 190시간으로 확인된 작업을 약속합니다. 그런데 스프린트를 완료한 후에 해당 스토리에는 실제로 240시간에 해당하는 작업이 포함되어 있음이 확인되어 계획 크기가 20%나 증가했습니다.
이처럼 시간의 불일치가 확인되면 팀은 일정 시간을 할애하여 다음과 같은 원인을 조사해야 합니다.
실행 단계에서 계획 중에 확인되지 않은 작업이 너무 많이 발견되었는가?
팀이 현재 기술을 토대로 작업을 과소 평가하고 있는가?
팀이 수용작업량을 과대 평가했는가?
기타 등등
또한 팀은 다음 스프린트 계획 회의 중에 특정 스토리를 약속할 수 있을지 결정할 때도 계획 크기의 증가를 고려해야 합니다. 위의 예제를 다시 살펴보자면, 팀에서 수용작업량을 계속 200시간으로 예측하는 경우 이전 데이터를 기준으로 한 "예상" 계획 크기 증가를 고려하여 작업을 20% 줄여야 합니다. 다시 말해서 최소한 이 스프린트에 대해 작업 초과를 방지하려면 팀은 작업 시간이 160시간에 도달한 시점에서 수용작업량이 모두 사용되었음을 선언해야 합니다.
계획 크기 증가를 고려함으로써 스프린트를 어느 수준까지 채워야 하는지를 수량화할 수 있습니다. 그러나 궁극적인 목표는 정확히 일치하는 수용작업량을 계산하는 것이 아닙니다. 팀이 과도한 부담을 느끼지 않는 적절한 수의 스토리를 안정적으로 약속할 수 있도록 하는 것이 목표입니다. 계획 크기 증가는 기타 모든 요소가 동일하게 유지되는 경우 다음 스프린트를 어느 수준까지 채울지를 대략적으로 결정하는 한 가지 방법일 뿐입니다.
모든 스토리 또는 스토리에 소요되는 총 시간을 예측한 후에는 팀에서 제공할 수 있도록 약속한 스프린트 백로그를 제품 소유자와 공유합니다. 그런 후에 스프린트를 시작할 수 있습니다.
일반적인 문제
스크럼을 도입하는 많은 팀들을 대상으로 한 다년간의 컨설팅 경험에서, 스프린트를 적절하게 계획하기 어렵도록 만드는 여러 가지 동일 문제를 확인한 바 있습니다. 스프린트 계획은 단순한 것 같지만 스크럼을 처음 시작하는 팀은 혼란스러워하는 경우가 많습니다. 이 섹션에서는 이러한 대부분의 문제와 가능한 해결 방법에 대해 자세히 설명합니다.
시나리오: 제품 소유자가 요청한 일부 스토리를 팀이 약속할 수 없음
자주 발생하는 문제 중 하나입니다. 팀이 이 항목 윗부분 4~5단계의 데이터를 약속을 뒷받침하는 데 활용할 수만 있다면 제품 소유자도 만족해할 것입니다. 여기서 약속 실패가 과도한 중복 작업 또는 대규모 작업으로 인한 것이 아닌지를 면밀히 파악해야 합니다. 스크럼 마스터는 너무 낮다고 생각되는 예측 결과를 파악해 수치가 정확한지를 확인해야 합니다. 제품 소유자는 예측 결과 값이 두 자릿수인 작업에 대해 의문을 제기해야 합니다. 작업일 기준으로 3일 이상이 걸리는 것으로 예측된 작업은 더 작은 작업으로 구분한 다음 다시 예측해야 합니다. 모든 프로젝트가 마찬가지이지만 특히 1~2주 길이의 스프린트를 실행하는 팀의 경우에는 이 과정이 까다로울 수 있습니다.
시나리오: 제품 소유자가 준비가 되지 않은 상태임
스크럼에서 중요한 가치 중 하나는 존중입니다. 예를 들어 준비되지 않은 상태로 회의에 참석하는 것은 존중받을 수 없는 행동입니다. 제품 소유자가 팀에 필요한 정보 없이 회의에 참석하는 경우 등을 예로 들 수 있습니다. 이러한 경우 제품 소유자가 준비될 때까지 회의를 연기할 수도 있지만 이 경우 같은 행동을 반복하게 만들 수 있으므로 이 옵션은 피하는 것이 좋습니다. 다른 옵션은 스프린트를 취소하는 것입니다. 이 옵션도 사용 가능하기는 하지만 극단적인 경우입니다.
개인적으로 생각하는 최적의 솔루션은 두 단계로 구성됩니다. 먼저 제품 백로그를 일종의 우선 순위대로 놓아 두어야 합니다. 그래서 제품 소유자가 특정 스토리 세트를 준비하지 않은 경우 수용작업량이 가득 차거나 초과하는 지점에 도달할 때까지 팀과 제품 소유자가 함께 우선 순위에 맞게 스토리를 논의할 수 있습니다. 그런 다음 팀은 회의의 2부에서 일반적인 방식대로 정확한 약속을 결정할 수 있습니다.
회의 후에 스크럼 마스터는 제품 소유자가 정보를 준비하지 않은 이유를 파악해야 합니다. 제품 소유자가 단순히 약속을 지키지 않은 경우 스크럼 마스터는 회의 참석 시 스토리 집합을 준비하는 작업의 중요성에 대해 제품 소유자에게 교육을 할 수 있습니다. 반면 팀이 정리를 도와 주지 않은 등 제품 소유자가 준비를 할 수 없었던 경우에도 스크럼 마스터는 해당 문제 해결을 지원해야 합니다.
시나리오: 1부가 기한을 초과함
스크럼의 또 다른 가치는 집중입니다. 회의의 1부 시간이 길어지는 것은 집중도가 낮기 때문일 수 있습니다. 제품 소유자가 준비 부족, 우선 순위 또는 과다한 스토리 설명 등으로 인해 집중하지 못하는 경우도 있고, 팀이 "무엇"이 아닌 세부적인 "방법론"에 치중하여 집중도가 떨어지는 경우도 있습니다.
스크럼 마스터는 제품 소유자가 완전히 설명할 수 없는 스토리는 제외하도록 하고 팀이 상세 구현 관련 논의는 1부에서 언급하지 않도록 하여 해당 과정을 신속하게 진행해야 합니다. 토론 집중도 저하 현상을 해결하는 방법 중 하나는 초시계나 타이머를 사용하는 것입니다.
시나리오: 2부가 기한을 초과함
여기서도 1부와 마찬가지로 집중도가 중요합니다. 특정 팀이 발언을 너무 많이 하는 경우 토론 내용을 제한하는 원칙을 정하는 것만으로도 원활하게 회의를 진행할 수 있는 경우가 많습니다. 모래시계를 놓고 각 작업 예측에 할당된 대화를 1~2분으로 제한합니다. 이 단계의 목표는 정확성입니다. 100% 완벽한 정밀성이 아닙니다.
2부에서 집중도가 떨어지는 또 다른 이유는 스프린트 실행 중의 제품 백로그 정리 부족입니다. 정리 시에는 팀이 이후 스토리를 파악하고 제품 소유자와 협력하여 스토리나 스파이크를 추가해 설계 방향을 정하거나 아키텍처 관련 의문 사항을 처리합니다. 제품 백로그를 정기적으로 정리하지 않으면 스프린트 백로그 계획이 번거롭고 까다로워집니다.
시나리오: 제품 소유자가 참석하지 않음
제품 소유자가 회의에 참석할 수 없는데 대리자를 지정하지 않은 경우 제품 소유자가 준비되지 않은 상태로 회의에 참석한 경우로 가정하고 행동합니다. 최상위 항목부터 차례대로 파악한 다음 최선을 다해 각 작업을 약속합니다. 제품 소유자의 일정에 맞게 회의 시간을 변경하면 된다고 생각할 수도 있겠지만, 그러면 안 됩니다. 회의 시간을 옮기면 제품 소유자는 참석할 수 있겠지만 여러 가지 사항을 변경해야 하므로 도움이 되지 않습니다.
시나리오: 팀에 필요한 수용 기준이 없음
개인적으로는 항상 팀이 회의의 1부에서 제품 소유자에게 스토리의 수용 기준이나 작업이 수용되려면 충족되어야 하는 사항에 대해 질문하도록 충고합니다. 2부에서 해당 정보가 없으면 팀이 작업을 결정할 때 스토리 마감 방법을 파악할 수 없게 됩니다. 팀이 1부에서 확인된 사항을 토대로 추측을 해야 하는 경우 스프린트 완료 시 스토리가 완료되지 않았다고 제품 소유자가 판단할 수 있는 위험이 있습니다. 따라서 각 스토리를 시작할 때 수용 기준을 반드시 문의해야 합니다. 스크럼 마스터는 제품 소유자가 이 데이터를 제공하도록 합니다.
시나리오: 제품 소유자가 완료된 작업의 의미를 모름
팀에 수용 기준이 필요한 것처럼 제품 소유자도 팀이 "스토리를 완료"했다는 것이 무엇을 의미하는지에 대한 최신 설명을 지속적으로 들어서 알아야 합니다. 이 완료 목록은 최신 상태로 명확하게 게시해야 하며 제품 소유자가 항상 확인할 수 있어야 합니다. 완료 목록이 오래되어 버리면 완료 상태가 무엇인지에 대한 공통 정보가 없으므로 계획하기가 어려워집니다. 그러므로 모든 스프린트 검토 또는 회고의 일환으로 완료 목록을 업데이트해야 합니다.
시나리오: 스크럼 마스터 또는 제품 소유자가 팀의 예측/작업을 미리 예상하려 하거나 영향을 줌
제품 소유자가 회의의 2부에 참석하는 것은 자유이지만 회의 2에서의 제품 소유자 역할은 요구 사항 확인이나 특정 질문에 대한 대답 정도로 제한해야 합니다. 제품 소유자는 팀의 스토리 구현 방식 관련 논의를 방해해서는 안 되며 작업 예측에 대한 의견을 언급해서도 안 됩니다. 즉, 팀이 작업을 완료할 것임을 신뢰해야 합니다.
제품 소유자가 이러한 지침을 벗어난 행위를 하는 경우 스크럼 마스터는 제품 소유자에게 보다 적절한 역할을 안내해야 합니다. 제품 소유자가 보다 소극적인 역할 수락을 거부하는 경우 스크럼 마스터는 제품 소유자의 퇴장을 명할 수 있습니다.
스프린트 계획은 그리 어려운 문제가 아닙니다. 실제로 전체 스크럼 팀은 "무엇을 약속할 수 있는가?"를 파악하기 위해 서로 도와줌으로써 즐겁게 계획을 세울 기회가 됩니다. 회의가 길어지는 경우에는 근본 원인으로 인한 문제 때문일 가능성이 높습니다. 스크럼 마스터는 제품 소유자와 팀이 제품 백로그를 정리하는지를 확인하여 회의 집중도를 유지해야 합니다. 제품 소유자가 회의 전에 스토리 수용 기준을 준비하여 회의에 참석하도록 합니다. 끝으로 제품 소유자와 팀이 당면 작업에 주력하여 스프린트에 대해 약속할 수 있는 작업을 결정하도록 합니다.