스프린트 계획
Mitch Lacey 작성.Agile 및 Scrum 채택과 개선을 전문으로 하는 컨설팅 기업인 Mitch Lacey & Associates, Inc가 소유자입니다.
2012년 1월
스프린트 계획은 해결할 필요가 없습니다."무엇을 위해 노력할까요?"라는 질문에 답변할 수 있도록 전체 스크럼 팀이 함께 작업하여 camaraderie를 빌드하는 것은 대개 보람 있는 일입니다. 이 문서에서 저자는 스프린트 계획을 초점을 맞추고 효과적으로 유지하는 데 필요한 예제, 전략 및 스프린트를 계획할 때 팀에 발생하는 공통적인 문제에 세부적인 잠재 솔루션을 제공합니다.
적용 대상
응용 프로그램 수명 주기 관리; Team Foundation Server
이 문서의 내용:
소개
예측 및 커밋의 비교
스프린트 계획이란 무엇입니까?
어떻게 수행할까요?
일반적인 문제
시나리오: 팀은 제품 소유자가 요청한 모든 스토리를 커밋할 수 없습니다.
시나리오: 제품 소유자가 준비되지 않았습니다.
시나리오: 파트 1이 시간 설정을 초과합니다.
시나리오: 파트 2가 시간 설정을 초과합니다.
시나리오: 제품 소유자를 사용할 수 없습니다.
시나리오: 팀에 필요로 하는 수락 기준이 없습니다.
시나리오: 제품 소유자가 완료의 의미를 알지 못합니다.
시나리오: ScrumMaster 또는 제품 소유자가 팀의 예측/작업을 예측하고 영향을 미치고 있습니다.
결론
우리는 계획하지 않습니다.스크럼을 사용하므로 실행하는 것과 마찬가지입니다.
난 항상 들어왔습니다.사람들은 스크럼과 Agile이 계획, 예측, 모임 등이 아니라고 생각합니다!이것은 진실에서 더 멀어질 수 없습니다.우리는 다양한 수준의 agile 프로젝트를 계획합니다. 즉, 일일 계획 또는 일일 스탠드업, 주간 계획(스프린트 또는 반복, 백로그), 릴리스 계획(제품 백로그) 등
스프린트 계획에 중점을 두겠습니다.
예측 및 커밋의 비교
2011년 여름 Ken Schwaber 및 Jeff Sutherland는 Scrum 가이드를 개정했습니다.여기에 팀이 만들어 제품 소유자 및 고객과 약정된 스크럼으로 알려진 길게 설정된 동작을 제거합니다.커밋은 예측으로 대체되었습니다.이들은 팀은 자신의 작업을 예측할 수 있지만 커밋하지는 못한다고 말합니다.
그들의 논리를 이해하고 있지만 다음과 같은 이유로 커밋을 선호합니다.
무엇인가를 커밋하면 팀은 예측 보다는 다른 마음가짐을 가지게 됩니다.팀은 팀원들이 할 수 있다고 말한 모든 것들이 충족되지 않을 수도 있음을 수용하는 것을 의미합니다.팀은 예측을 통해 더 적은 추정 가변성을 가질 수 있지만 커밋하는 팀과 비교해 예측하는 팀이 가변성을 줄이는 데 더 많은 시간을 소요한다는 점을 알게 되었습니다.
제품 백로그에 대해서는 예측 또는 예상이 적합합니다.그러나 제품 백로그 대신 스프린트 백로그를 사용하고 이를 세분화할 때, 팀은 다른 수준의 정교성을 얻을 수 있습니다. 즉, 그들 스스로 *이것을 커밋할 수 있는가?*를 물어 세부 정보들을 찾을 수 있습니다. "우리가 예측만 할 수 있다면, 약간의 내용을 놓쳐도 나중에 알 수 있어서 상관없어"라고 말하는 대신 예측은 팀을 게으른 상태로 만들 위험이 있습니다.
그리고 좀 더 가볍게 분위기를 바꿔서, 여러분이 아내, 남편, 배우자에게 "나는 우리가 10년 동안 함께 할 거라고 예측할 수 있어."라고 말하는 경우와 "나를 당신한테 맡길게." 라고 말하는 경우를 상상해 보십시오. 그렇습니다. 그러면 모든 일이 잘 될 것입니다.
결국 Scrum이 일반적이 될 것입니다.커밋 방식과 예측 방식을 모두 시도해 보는 것이 좋습니다.이는 사용하는 단어에 대한 것이 아니라 학습에 대한 것입니다. 따라서 현명하게 사용자, 팀 및 회사 모두에 최선의 것을 실험 및 사용해야 합니다.
스프린트 계획이란 무엇입니까?
우리는 다가오는 스프린트에서 어떤 팀을 빌드하고 어떻게 팀을 빌드할 것인가를 계획하는 스프린트 계획 회의를 개최했습니다.스프린트 계획 회의라고 부르기는 하지만 실제로는 매우 다른 두 부분으로 구성되었습니다.1부에서는 팀에게 빌드하도록 요청한 사항과 제품 소유자와 팀 참석에 초점을 맞춥니다.파트 2는 팀이 원하는 기능을 빌드하기 위해 계획하는 방법에 초점을 맞춥니다.전체 팀은 2부에 참석해야 하지만 제품 소유자의 참석 여부는 옵션입니다.어떤 이유로든 제품 소유자가 두 번째 파트에 참석하지 않았더라도 제품 소유자는 이에 대해 질문할 수 있어야 합니다.
스프린트 계획 회의의 첫 번째 파트에서 제품 소유자는 팀에게 원하는 스토리를 설명할 수 있습니다.이 세션은 스토리의 내용 부분을 집중적으로 다루는 세션입니다.제품 소유자는 스토리를 제공하고 상호 작용하는 방법을 보여주고 인터페이스를 수행합니다.또한 인프라 또는 아키텍처 항목을 검토할 수 있습니다.목표는 팀 구성원의 머리에 기능을 구축하는 방법을 파악할 수 있도록 충분한 정보를 채우는 것입니다.팀은 어떤 방식으로 모임을 수행해야 하는가에 대한 정보를 수집하기 위해 다음과 같은 다양한 질문을 던집니다.
“이러한 모든 사례의 수락 기준은 무엇입니까?”
“어떤 데이터 소스를 사용 중이라고 생각하십니까?”
“이 컴퓨터에서 인터페이스를 표시하는 방법은?”
스프린트 계획 회의의 2부 과정에서 팀은 스프린트 백로그-스프린트 과정 중 완료하는데 요구되는 스토리 및 작업의 목록-를 작성하는데 주의를 기울입니다.백로그를 작성하려면 팀은 제품 소유자가 요청한 각 스토리를 작업 수준으로 세분합니다. 각 작업에는 시간당 추정치가 제공됩니다.2부가 끝날 때 팀에서 스프린트 기간에 완료할 수 있는 스토리를 결정합니다.
더불어 스프린트 계획 회의의 2부는 2~8시간이 걸릴 수 있습니다.엄지 단추 I 사용의 일반 규칙에 따르면 각 부품은 스프린트 길이의 일주일 마다 한 시간이 소요되어야 합니다.즉 일주일 스프린트를 실행 중인 경우 회의는 총 2시간 소요됩니다(1부 한 시간과 2부 한 시간).반면에 4주 스프린트를 실행 중이라면 회의는 총 8시간(첫 번째 파트 4시간, 두 번째 파트 4시간)입니다.
어떻게 수행할까요?
팀이 스토리 목록을 완성하기 위한 스프린트 계획 회의를 떠나는 것이라면 스프린트 계획의 목적을 달성한 것입니다.모든 팀 구성원들이 약정 만들기에 거부감이 없을 때 목적을 달성할 수 있습니다. 그러나 약간의 사전 계획과 중재가 필요합니다.
스프린트 계획 동안 제품 소유자는 하나의 작업을 가지며 원하는 스토리의 집합을 설명할 수 있는 회의에 갑니다.팀의 목표는 제품 소유자의 관점에서 스토리를 이해하고 제품 소유자의 비전을 공유하는 것입니다.Scrum 마스터는 팀이 충분한 질문을 하고 승인 기준, 스케치 및 모든 가정을 포함하여 모든 결과 데이터를 캡처링하도록 해야 합니다.Scrum 마스터는 또한 제품 소유자가 팀이 질문을 작업으로 세분하기 시작한 후 추가 질문을 할 수 있는지 알 수 있도록 해야 합니다.대략 그 동안의 팀 속도에 해당하는 스토리를 제품 소유자가 제공하지만 주어진 스프린트에서 모든 스토리를 다룰 수 있는지 여부는 스프린트 계획 회의 1부와 2부를 거치며 획득한 내용을 토대로 팀이 최종적으로 결정합니다.
팀이 모든 정보를 제품 소유자로부터 얻은 후 스토리를 작업으로 세분화하고 모든 스토리, 메모, 승인 조건, 작업 및 특정한 스프린트에 대한 추정치를 캡처하는 스프린트 백로그를 생성해야 합니다.여러 가지 방법으로 이 작업을 수행하는 동안 모든 팀 구성원의 아이디어를 활용하고 모든 사람에게 작업 분해 시 역할을 제공하는 다음 메서드를 사용합니다.
스크럼 마스터 또는 회의 중재자가 스토리를 일고 "모두 이해하셨습니까?"라고 질문하고, 팀은 제품 소유자와 반드시 그것에 관해 논의할 시간을 가져야 합니다.팀의 누군가가 이해하지 못했다면 이야기를 다시 검토하고 제품 소유자에게 질문할 시간을 할애하십시오.
그런 다음 각 팀 멤버가 스티커 패드를 잡습니다.각 팀 멤버에게 스티커 메모에 작업을 하나씩 적도록 부탁하고 테이블 가운데에서 메모를 섞습니다.
- 각 스티키가 테이블 가운데로 던져지면 스로워가 작업을 발표합니다.따라서 "저장 프로시저 업데이트"를 작성하는 경우 크게 말합니다.이는 아이디어를 떠올리게 하고 다른 사람이 "예. 우리는 이 데이터 소스를 업데이트해야 합니다."라고 말하게 하므로 중요합니다. 이 지점에서 누군가는 스티커 "데이트 소스 업데이트"에 작성한 다음 중간에 throw합니다.이 브레인스토밍 활동은 정말 모든 관련 작업을 플러시합니다.이 번에는 중복에 대해 우려하지 마십시오.모든 작업 스티커 메모를 내다 버리는 데 일반적으로 스토리 당 5-10 분 정도 걸립니다.
스티커 메모가 테이블에 가득 차면 정렬할 시간입니다.모두 벽에 붙이고 한 걸음 물러서서 보십시오. 스티커가 얼마나 많습니까!중복을 식별하는 것으로 시작하고 중복되는 모든 스티커 메모를 겹칩니다.그런 다음 유사하거나 서로 의존적이라서 연관되어 보이는 작업을 찾습니다.예를 들어, 두 스티키스가 유사한 관계에 있다면, 다음 그림과 같이 그들을 같이 결합하되 오프셋을 줍니다.
.png "비슷한 스티커 - 오프셋")
두 작업이 거의 동일하게 밀접히 관련되어 있다면 경우 아래와 같이 두 작업을 오버랩할 수 있습니다:
.png "비슷한 스티커 - 겹침")
스티커 메모를 정렬함으로써 팀이 작업 목록을 추려내고 나머지 작업들 사이의 관계를 시각화할 수 있습니다.
작업이 정렬되면 예상할 시간입니다.저는 작업 예측에 있어서 계획 포커 기술을 사용합니다. 다만, 카드의 숫자가 점수 대신 시간을 나타낸다는 점만이 다릅니다.사람들은 시간에 비해 불필요한 세부 사항에 매달리는 경향이 있으므로, 특히 큰 작업을 수행하는 경우, 저는 이렇게 합니다.두려움을 느끼는 좋은 이유가 있습니다.흔히 회사는 팀을 이길 스틱으로 예측을 사용합니다.“8시간 걸릴 것이라고 말했지만 12시간이 걸렸습니다.무엇이 문제입니까?” 또는 “8시간이 걸려야 했는데 4시간 밖에 걸리지 않았다고 말했습니다.예상이 중복됩니다.”
카드를 사용하여 스토리 지점을 쉽게 추정할 수 있는 방식과 같은 방식으로 작업 추정에 카드를 사용하면 팀은 자유롭게 최종 선택을 하면서 고정된 숫자 집합을 선택할 수 있습니다.또한 작업을 6 시간 또는 6.5 시간 또는 7 시간에서 추정해야 할지 여부에 대해 열심히 토론할 필요가 없습니다.
최종 추정이 무엇이든지 추정은 팀에서 수행하고 팀의 자신감을 높이고 속도를 기반으로 제품 소유자가 요청한 작업을 달성할 수 있는지 여부를 결정하도록 도움을 제공하기 위해 팀에서 사용합니다.작업 예측은 메트릭이 아니며 이렇게 사용해서는 안 됩니다.절대로 예측을 팀에 대한 무기로 사용하지 않습니다.
작업이 추정되었으므로 팀은 더 많은 작업을 수행할 수 있는 능력이 있는지 확인해야 합니다.이를 위해 팀의 능력과 스프린트 동안 팀이 사용할 수 있는 총 시간을 알아야 합니다.용량을 결정하는 것은 완전히 전용화된 팀이 있는 경우엔 쉽지만 여러 프로젝트에 걸쳐 파트 타임으로 근무하는 사람들로 이루어진 팀의 경우에 더욱 어렵습니다.모든 사람이 프로젝트를 위해 작업할 수 있는 하루의(또는 스프린트 당 전체) 작업 시간을 적도록 부탁합니다.팀에 사용 가능한 총 시간 수를 가져오려면 모든 숫자를 더합니다.팀의 용량이 200시간이라고 합시다.한 스토리에 대한 작업의 합이 30시간을 소비할 것으로 예상되면 팀에게 "더 많은 작업을 선택할 수 있습니까?"라고 물어볼 것이고, 초기 단계에서 팀은 명백히 예라고 대답합니다.
더 많은 용량을 채울 수 있기 때문에 다음 스토리로 이동하여 1~5단계를 반복합니다.
(Team Foundation Server를 사용하여 이 작업을 수행하는 방법에 대한 자세한 내용은 Agile 계획 및 반복을 참조하십시오.)
어느 시점이 되면 "더 많은 작업을 담당할 수 있을까?"라는 질문에 대답하기가 어려워 질 것입니다. 팀의 한계에 가까워지고 있기 때문입니다.이 프로세스를 진행해 나가면서 스프린트를 용량까지 채우지 않는 것을 고려하십시오.물잔 끝까지 물로 채우는 경우 엎질러질 가능성이 매우 큽니다.이는 스프린트의 경우에도 마찬가지입니다.작업 예상 시간이 모든 사용 가능한 시간을 소비하고 새로운 작업이 스프린트에서 이후에 식별되면, 작업들은 과잉되게 됩니다.긴급 작업을 위한 공간이 있어야 합니다.
스프린트 커밋을 고려하면 과거 스프린트의 회고 데이터를 고려하면 도움이 됩니다.팀이 더 많은 작업을 일관성 있게 가져와야 합니까?팀은 스프린트를 계획하는 동안 추가로 커밋할 수 있습니다.팀이 스프린트에 대한 모든 작업을 일관성 있게 완료할 수 없습니까?팀은 불완전한 스프린트의 근본 원인을 해결할 때까지 해당 약정에 더 보수적이어야 합니다.
"얼마나 가득 유리를 채울 것인가"라는 질문에 번호를 매기는 한 가지 방법은 계획 크기 증가를 고려하는 것이다.계획 크기 증가는 실제 사용 시간을 초기 추정치와 비교하는 방법을 평가합니다.예를 들어, 우리 팀의 용량은 200시간 사용할 수 있다고 가정해 봅시다.팀은 예측을 기반으로 190시간이 되도록 커밋합니다.스프린트가 끝날 때 팀은 이러한 스토리에 240 시간의 실제 작업 시간이 포함됐으며 20%의 계획 크기 상승을 야기했다는 것을 측정합니다.
이 불일치를 찾는 팀은 이유를 조사하는 회고 기간 동안 시간을 어느 정도 소비해야 합니다.
계획하는 동안 식별되지 않은 너무 많은 작업이 실행하는 동안 식별되고 있습니까?
팀이 현재 기술 세트를 기반으로 작업을 과소 평가하고 있습니까?
팀이 역량을 과대 평가했습니까?
등
또한 팀은 스토리에 커밋할 수 있는지 결정할 때 다음 스프린트 계획 회의 동안 계획 크기 증가를 고려해야 합니다.예제로 돌아가서 팀이 여전히 200 시간 용량을 예측한다면 기록된 데이터를 기반으로 "예상된" 계획 크기 증가를 보완하기 위하여 상위 20%를 빼야 합니다.다시 말해, 적어도 이 스프린트에 대해서는, 팀이 160 시간을 얻었을 때 넘치는 것을 방지하기 위하여 팀 스스로 용량 선언을 하여야 합니다.
계획 크기 증가는 스프린트가 얼마나 커야 하는지 정량화하는 한 가지 방법입니다.그러나 목표가 용량과 정확하게 일치하지 않는다는 것을 인식하십시오.대신 적절 한 수(과중한 부담을 주지 않고 팀을 격력하는 수)의 스토리를 커밋할 때 팀이 자신감을 가질 수 있습니다.계획 크기 증가는 모든 다른 요소가 같을 경우 다음 스프린트를 얼마나 가득 채울 것인가를 대략적으로 결정하는 방법입니다.
모든 스토리가 추정되거나 스토리에서 모든 시간이 소비되면 제품 제품 소유자에 다시 돌아가 팀이 제공할 스프린트 백로그를 공유합니다.스프린트가 이제 시작됩니다. 일을 시작합시다!
일반적인 문제
스크럼을 채택할 수 있도록 팀과 오랜 기간동안 컨설팅해온 결과, 성공적인 스프린트 계획을 방해하는 동일한 문제들을 많이 보았습니다.스프린트 계획은 간단한 것 같지만 막 스크럼을 시작하는 팀은 힘들어하는 경향이 있습니다.이러한 문제 및 잠재적 해결책 대부분은 이 섹션에서 자세히 설명합니다.
.gif "Hh765982.collapse_all(ko-kr,VS.110).gif")
시나리오: 팀은 제품 소유자가 요청한 모든 스토리를 커밋할 수 없습니다.
종종 이런 일이 발생할 것을 예상해야 합니다.팀에서 이 항목 앞부분의 4단계와 5단계에서 가져온 데이터를 가지고 업무를 지원할 수 있다면 제품 소유자가 만족할 것입니다.이 커밋 실패가 초과 패딩 또는 대규모 작업의 결과가 되지 않도록 하려면 잘 지켜 보아야 합니다.스크럼 마스터는 정확성을 보장하기 위해 지나치게 보수적인 예측을 하는 경우 이의를 제기해야 합니다.제품 소유자는 2자리 예측을 갖는 작업을 문의해야 합니다.작업이 2일 이상 소요될 것으로 예상되는 모든 작업은 소규모의 작업으로 나눈 다음 다시 측정해야 합니다.이는 모든 프로젝트에 대해 참이지만 1주 또는 2주 스프린트를 실행하는 팀에서 특히 문제입니다.
시나리오: 제품 소유자가 준비되지 않았습니다.
한 스크럼 값은 존경입니다.준비하지 않은 채 회의에 참석하는 것은 무례한 행동입니다.따라서 팀이 필요로 하는 정보 없이 제품 소유자가 표시 되는 경우에 팀은 무엇을 해야 할까요?제품 소유자가 준비될 때까지 회의를 연기하는 것도 선택 사항이지만 이렇게 함으로써 그러한 행동을 격려할 뿐이므로 이를 피합니다.또 다른 옵션은 스프린트를 취소하는 것입니다.작동할 수 있지만 극단적입니다.
최상의 솔루션은 두 배가 됩니다.첫째, 제품 백로그는 우선 순위의 일부이어야만 합니다. 이는 만약 제품 소유자가 특정 스토리 집합을 가지고 있지 않다면, 팀과 제품 소유자가 그들의 능력 이상에 도달할 수 있을 때까지 우선 순위 내에서 스토리를 논의할 수 있도록 하기 위해서입니다.팀은 평상시처럼 회의의 파트 2 동안 정확한 커밋을 결정할 수 있습니다.
회의가 끝난 후 ScrumMaster는 제품 소유자가 준비하지 않은 이유를 이해하려고 노력해야 합니다.계약 사항 부족 문제에는 스크럼마스터가 이야기 세트를 준비하고 회의에 참여하는 중요성을 제품 소유자에게 교육시킬 수 있습니다.반면에, 아마도 정리하는 것에 실패했기 때문에 문제가 제품 소유자가 준비할 수 없었다는 것이라면, 스크럼 마스터는 이 문제를 해결하기 위하여 도와주어야 합니다.
시나리오: 파트 1이 시간 설정을 초과합니다.
다른 값은 포커스입니다.회의의 1부가 실행 중인 경우 초점 부족의 증상이 있습니다.때때로 제품 소유자는 준비와 우선 순위 부여 부족으로 집중할 수 없거나 너무 많은 스토리를 설명하려 합니다.또는 포커스 부족은 "어떻게"로 "무엇을" 대화를 이탈시키는 팀에서 기인합니다.
Scrum 마스터는 제품 소유자가 완전히 설명할 수 없는 모든 스토리를 표로 만들고 팀에게 1부에서 상세한 구현 토론 내용을 계속해서 제공할 것을 주장함으로써 일이 진행되는 데 도움을 주어야 합니다.집중되지 않은 토론을 위한 한 가지 간단한 해결 방법은 스톱워치 또는 타이머를 사용하는 것입니다.
시나리오: 파트 2가 시간 설정을 초과합니다.
다시 포커스입니다.만약 팀이 너무 말만 앞선다면 회의를 정리하기 위하여 토론을 제한하는 규칙이 때때로 필요합니다.에그 타이머를 사용하여 작업 예상 사이에 1~2분간 대화합니다.목표는 100% 정밀도가 아닌 정확도입니다.
또는 2부 중 포커스 부족은 스프린트 실행 동안 제품 백로그 정리 부족입니다.정리 시간은 팀이 이후 스토리를 확인하고 제품 소유자가 스토리를 추가하거나 설계 방향에 대한 정보를 구체화하거나 구조에 관한 질문을 명시화하는 시간입니다.정기적으로 제품 백로그 정리를 하지 않으면 스프린트 백로그 계획은 다루기 불편하고 고통스러워집니다.
시나리오: 제품 소유자를 사용할 수 없습니다.
제품 소유자가 어떤 이유에서든 회의 참석할 수 없고 대리인도 임명하지 않은 경우는 준비 없이 회의에 참석한 것과 같습니다.상위 항목을 통해 작업하고 가장 잘 할 수 있는 것으로 커밋합니다.제품 소유자의 일정을 수용하기 위해 모임 시간을 변경해야 할 수 있습니다.Don’t.모임 시간 이동은 다수를 희생하여 한 사람의 요구를 수용합니다.할 만한 가치가 없습니다.
시나리오: 팀에 필요로 하는 수락 기준이 없습니다.
저는 항상 팀원들에게 첫 번째 파트를 수행하는 동안 제품 소유자에게 "이 제품을 승인 조건이 무엇입니까?" 또는 "이 제품 승인을 위해서 무엇이 필요합니까?"의 질문을 하도록 조언합니다. 만약 두 번째 파트에서 이런 질문에 대한 답을 알지 못한다면, 저희팀이 작업을 결정할 때 작업을 완료하기 위한 방법을 얻을 수 없습니다.첫 번째 파트에서 들은 것을 바탕으로 팀이 추측하면 제품 소유자는 스토리가 완성되지 않은 스프린트의 끝에서 결정할 위험이 있습니다.각 스토리의 시작부터 수락 기준을 물어 보십시오.ScrumMasters—제품 소유자가 이 데이터를 제공하도록 지도합니다.
시나리오: 제품 소유자가 완료의 의미를 알지 못합니다.
팀이 승인 기준을 원하는 것과 마찬가지로 제품 소유자는 팀이 "스토리는 완료되었습니다"라는 의미에 대한 최신 설명을 들을 권한이 있습니다. 이러한 완료 목록은 먼저 게시 및 업데이트되어 제품 소유자가 항상 사용할 수 있어야 합니다.작업 완료 목록이 구식이면 수행이 완료되었을 때 어떤 모습일지에 대한 일반적인 이해가 부족하기 때문에 계획하기가 어렵습니다.완료 목록을 업데이트하는 것은 모든 스프린트 검토 또는 회고의 일부입니다.
시나리오: ScrumMaster 또는 제품 소유자가 팀의 예측/작업을 예측하고 영향을 미치고 있습니다.
제품 소유자는 모임 2부에 시작하지만 2부의에서 제품 소유자 역할은 요구 사항을 명확히 하고 특정 질문을 전달하는 것으로 제한되어야 합니다.제품 소유자는 스토리를 구현하는 방법에 대한 팀의 토론을 방해해서는 안되며 작업 예상에 대한 언급을 하지 않아야 합니다.제품 소유자는 작업을 수행하는 팀을 신뢰해야 합니다.
제품 소유자가 이러한 지침을 따르지 않으면 스크럼 마스터는 보다 적절한 역할을 하도록 코치할 수 있어야 합니다.제품 소유자가 수동적인 역할만을 수행한다면 스크럼 마스터는 제품 소유자에게 작업에서 빠질 것을 요구할 권한이 있습니다.
스프린트 계획은 해결할 필요가 없습니다."무엇을 위해 노력할까요?"라는 질문에 답변할 수 있도록 전체 스크럼 팀이 함께 작업하여 camaraderie를 빌드하는 것은 대개 보람 있는 일입니다. 회의가 길어지면 아마 이는 근본 원인 문제 의한 것일 수 있습니다.만약 당신이 스크럼 마스터라면, 제품 소유자와 팀이 제품 백로그를 함께 정리함으로써 회의의 목적을 유지합니다.회의 전에 스토리 수락 기준을 준비함으로써 제품 소유자가 준비하도록 도와줍니다.마지막으로 제품 소유자와 팀이 스프린트를 실행하기 위해 무엇을 결정해야 하는지, 직접 작업에 몰두할 수 있도록 계속 도와주십시오.