스프린트 계획 회의는 얼마나 오래 지속됩니까?

경험상 스프린트 계획 회의 (Scrum)는 얼마나 오래 지속됩니까? 8 시간? 아니면 더 짧아야하고 (간결) 스프린트의 일부로 추가 토론을 계획해야합니까? 스프린트는 10 일입니다.

스크럼 가이드 에 따르면 :

스프린트 계획 회의는 1 개월 스프린트에 대해 8 시간으로 시간 상자가 표시됩니다. 짧은 스프린트의 경우 이벤트가 비례 적으로 짧아집니다. 예를 들어, 2 주 스프린트에는 4 시간의 스프린트 계획 회의가 있습니다.

그것은 일반적으로 저에게 효과적입니다.

그것이 더 이상 지속될 필요가없는 한. 다른 것은 민첩하지 않습니다.

2-3 명의 개발자로 구성된 팀이 있고 일주일 동안의 스프린트를 수행하는 경우 한 시간 이상이 반 생산적 일 수 있습니다.

하루 종일보고있는 15 명과 2 주 스프린트로 구성된 팀이 있다면 그다지 자세한 내용은 충분하지 않습니다.

대부분의 경우 올바른 경험이 필요하며, 소급 적용되는 것이기 때문에 팀은 너무 길거나 짧은 것을 결정합니다.

책이 완벽하다고 생각하거나 책의 내용을 고수하는 것에 대해 걱정하지 마십시오.

SCRUM은 코드를 반복적으로 구체화하는 것만 큼 반복적으로 프로세스를 구체화하는 것입니다.

프로세스를 중심으로 비즈니스를 형성하지 마십시오. 프로세스는 비즈니스를 지원합니다. 자체 프로세스를 수행하는 순간 프로세스에서 도끼를 가져옵니다. 이를 위해 "올바른"방법은 없습니다. 회의는 당신이 무언가를 달성하는 동안에 만 가야합니다. 작동하는 한 30 분 또는 4 시간이 걸리면 함께 진행하십시오. 일부 서적 / 블로그 / 코치가 알려주는 내용을 무시하고 자신에게 맞는 것을하십시오.

팀이 스프린트에서 합리적으로 달성 할 수 있다고 생각할만큼 충분히 선택하십시오. 그러나 당신은 (이전) 스프린트 동안 백 로그를 다듬는 시간을 보내야합니다 : 스토리를 추정하고 다듬는 것.

스크럼 입문서 ( PDF )에서 :

제품 백 로그 개선

스크럼에서 덜 알려졌지만 중요한 지침 중 하나는 팀이 각 백 프린트의 5-10 %를 제품 백 로그를 정제 (또는 정리)하기 위해 헌신해야한다는 것입니다. 여기에는 세부적인 요구 사항 분석, 큰 품목을 더 작은 품목으로 분할, 새로운 품목의 추정 및 기존 품목의 재 추정이 포함됩니다. 스크럼은이 작업을 수행하는 방법에 대해서는 침묵하지만, 자주 사용되는 기술은 스프린트가 끝날 무렵에 초점을 맞춘 워크샵이므로 팀과 제품 소유자는 중단없이이 작업에 전념 할 수 있습니다. 2 주 스프린트의 경우, 지속 시간의 5 %는 각 스프린트에 반나절의 제품 백 로그 개선 워크숍이 있음을 의미합니다. 이 구체화 활동은 현재 스프린트를 위해 선택된 아이템을위한 것이 아닙니다. 그것은 미래의 아이템을위한 것이며, 다음 1 ~ 2 개의 스프린트에서 가장 가능성이 높습니다. 이 연습을 통해 Sprint Planning은 제품 소유자와 스크럼 팀이 명확하고 잘 분석되고 신중하게 추정 된 항목 세트로 계획을 시작하기 때문에 비교적 단순 해집니다. 이 개선 작업장이 수행되지 않거나 제대로 수행되지 않았다는 표시는 스프린트 계획에 중대한 질문, 발견 또는 혼란이 수반되고 불완전하다고 느끼는 것입니다. 계획 작업은 종종 스프린트 자체로 넘겨 지는데, 이는 일반적으로 바람직하지 않습니다.

이렇게하면 계획을 세우는 동안 계획에 집중할 수 있으며 하루 종일 걸리지 않으며 팀은 초점을 잃고 지루해지기 시작합니다.

스크럼에서 2 주 스프린트로 작업 할 때 스프린트 계획은 4 시간 단위로 시간 상자로 만들어져 반나절 이벤트가됩니다. 시간의 비교적 많은 양에 대한 이유 중 하나는 개발 팀이 있다는 것입니다 있어야 자신있게 모든 항목들이 세부 사항을 알 필요가 의미 전달 될 수 스프린트 백 로그에 들어갔습니다 동의 할 수. 스프린트 계획의 일환으로 팀이 일정 기간 동안 회의 공간에서 이탈하여 항목을 추가로 조사하고 스프린트 백 로그에 들어갈 준비가되었는지 확인하는 것은 드문 일이 아닙니다. 스프린트 계획을 회의가 아니라 이벤트로 생각하면 도움이됩니다.

"준비의 정의"와 스프린트 계획 이벤트가 스프린트에 들어가는 모든 백 로그 항목이 모두 가능 하고 준비되어 있는지 확인하는 시간을 사용하십시오 . 즉, 스프린트 내에서 (완료된 "정의"에 따라) 수행 할 수 있으며, 팀이 지금 할 수있는 충분한 정보가 있습니다.
물론 시간이 많이 걸리는 스프린트 계획 중에 모든 항목에 대해이 작업을 수행하고 싶지는 않을 것입니다. 백 로그 항목을 분류하고 계획 포커를 사용하여 아직 예측되지 않은 항목을 추정 할 수있는 정기적 인 백 로그 정리 (스프린트 계획 제외)를 시도하십시오. (저희는 저녁 시간에 팀의 가용성이 고급 스러우면 개발 팀과 함께 저녁 식사를하는 동안 효과적인 활동이 될 수 있음을 발견했습니다!)

스프린트 계획 직전에 제품 소유자가 우선 순위가 높은 항목을 제품 백 로그에 추가 할 수 있으며, 스프린트 계획 이벤트 전에 일상적인 백 로그 그루밍을 수행 할 수 있으며, 일반적으로 스프린트 계획 이벤트 전에 수행해야하는 경우 항상 다음과 같은 새 항목이 있습니다. 팀은 스프린트 계획 이벤트 동안 세부 사항을 해결하고 복잡성을 추정하는 데 시간을 소비해야하므로 10 일 / 2 주 스프린트 동안 4 시간으로 확장 될 수 있습니다.

이 이벤트에서 더 긴 토론을해야하는 경우, 스프린트 백 로그에 "x를 설정하기 위해 그러한 토론을하도록"백 로그 항목이있을 수 있지만 스프린트 항목을 포함하여 진행중인 작업을 수행하지 않아야합니다. 스프린트에 들어가기 위해 "준비된"백 로그 아이템이 아니기 때문에 해당 토론 중에 수행 할 요구를 결정합니다.

사람들이 말했듯이, 프로세스가 효과적으로 작동하지 않으면 Scrum 실행 방식을 변경해야 할 이유가 있습니다. 그러나 스크럼은 매우 잘 고 안되고 테스트 된 프레임 워크이므로 프로세스를 변경하기 전에 추론을 정당화 할 수 있습니다.

스프린트 계획 회의에서 팀은 두 가지 사항을 결정해야합니다.

A)이 스프린트 동안 팀이 개발할 내용

B) 어떻게 개발 될 것인가

이 회의는 스프린트의 각 주마다 최대 2 시간의 타임 박스로 이루어져야하며 회의의 각 부분 (파트 A 및 파트 B)에 대해 균등하게 분할됩니다.

따라서 4 주 스프린트의 경우,이 미팅은 8 시간을 초과하지 않아야합니다 (파트 A의 경우 최대 4 시간, 파트 B의 경우 최대 4 시간).

파트 A 동안, 개발 팀은이 스프린트 동안 가질 것으로 예상되는 팀 속도를 추정해야합니다. 또한 최우선 사용자 스토리를 추정하고 자신의 예상 팀 속도에 따라 완료 할 수 있도록 이러한 (이미 추정 된) 사용자 스토리를 충분히 선택해야합니다.

파트 B에서 개발자 팀은 이미 개발하기로 선택한 더 도전적인 사용자 스토리를 개발하는 방법에 대해 논의합니다. 대부분의 경우 개발자 팀은 선택한 모든 사용자 스토리를 개발하는 방법에 대해 논의 할 시간이 충분하지 않으므로 가장 까다로운 사용자 스토리를 선택해야합니다.

스프린트 동안 개발자 팀은이 토론을 완료 할 시간이 충분합니다.

스크럼 가이드 에 따르면 :

스크럼 이벤트

규정 된 이벤트는 스크럼에서 규칙 성을 작성하고 스크럼에 정의되지 않은 미팅의 필요성을 최소화하기 위해 사용됩니다. 모든 이벤트는 타임 박스 이벤트이므로 모든 이벤트는 최대 기간을 갖습니다. 스프린트가 시작되면 지속 시간이 고정되며 단축하거나 연장 할 수 없습니다. 나머지 이벤트는 이벤트의 목적이 달성 될 때마다 종료되어 프로세스에 낭비를 허용하지 않고 적절한 시간을 소비 할 수 있습니다.