스프린트 계획 회의는 재미 없을뿐만 아니라 끔찍합니다.

회의는 지루하고 지루하며 영원합니다 (하루이지만 훨씬 더 긴 느낌).
개발자들은 이에 대해 불평하고 다가오는 계획을 두려워합니다.

우리의 일상은 매우 표준 적이며 (우선 순위에 의해 스프린트 백 로그에 삽입 된 사용자 스토리 >> 스토리는 태스크로 분류됩니다 >> 태스크는 시간 단위로 >> 반복됩니다) 우리가 뭘 잘못하고 있는지 파악할 수 없습니다.

회의를 더 즐겁게하려면 어떻게해야합니까?

...

자세한 정보 요청에 대한 자세한 내용 :

스프린트 시작 전에 백 로그 항목이 삽입되고 우선 순위가 지정되지 않는 이유는 무엇입니까?

사용자 스토리는 우선 순위가 높습니다. 우리는 그것들을 과제로 나눌 때까지 얼마나 걸릴지 모른다! 여기에있는 (우수한) 답변에서 우리는 작업을 전혀 예측하지 말고 사용자 이야기 만 추측해야한다는 것을 알았습니다. 이야기가 아닌 과제를 추정하는 이유는 우리가 이야기 견적을 잘못 받았기 때문입니다. 그러나 그것은 전혀 다른 질문의 주제라고 생각합니다.

개발자가 왜 불평하고 있습니까?

1. 회의는 길다.

2. 회의는 단조롭습니다. 스토리 이후, 태스크 후 태스크, 소요 시간 및 예상 시간을 평가하기 위해 고군분투 (예, 고군분투)합니다.

3. 작업을 예측하면 사용자 스토리 예측이 무의미 해 보입니다.

4. 회의 시간이 길어질수록 회의실의 집중력이 떨어집니다. 집중력이 낮은 동료 일수록 회의 시간이 오래 걸립니다. 재귀 적 증오 나선이 ​​발생합니다. 우리는 사람들의 집중을 유지하기 위해 회의를 이틀로 나누는 것을 고려했지만 개발자들은 그 소식을 듣지 못했습니다. 계획의 하루는 충분하지 않습니다. 이제 우리는 두 개가 있을까요?!

우리의 문제의 일부는 (보다 정확한 추정을 얻기 위해) 매우 작은 세부 사항으로 이동한다는 것입니다. 그러나 우리가 대략 추정 할 때, 우리는 한계를 벗어납니다!

질문을 요약하면 다음과 같습니다.

• 우리가 뭘 잘못하고 있니?

• 회의를 더 즐겁게하기 위해 어떤 추가 방법이 있습니까?

추정을 더 쉽게

스프린트 계획을 세분화하십시오.

당신이 할 필요가 개별 작업을 추정하기 위해? 스프린트 계획은 두 가지 방법으로 수행했습니다.

1. 스토리는 스토리 포인트로 추정 된 다음 작업은 몇 시간으로 추정됩니다.
2. 스토리는 스토리 포인트로 추정되며 작업은 추정치없이 그에 해당합니다.

둘 중 두 번째 옵션을 선호합니다. 작업을 예측하지 않으면 개발자가 변경에 대처할 수있는 자유가 더 커집니다. 작업이 더 이상 의미가없는 경우 (작업이 적용되지 않거나 이전 스프린트에서 이미 수행 된 것을 몇 번이나 알게 되었음) 단순히 페널티없이 버리거나 현재 작업을 다음과 같이 변경해야 할 수도 있습니다. 새로운 것, 아마도 그것을 깨뜨릴 수 있습니다. 작업의 합계가 스토리 포인트를 나타내야하며 그 반대도 마찬가지이므로 둘 다 추정하면 실제로 중복됩니다. 개별 작업에 얼마나 많은 시간이 걸리는지 아는 것 외에는 실제로 어떤 가치가 있습니까? 실제로 차이를 만들기에 충분히 다양한 작업 크기를 발견 한 경우 해당 작업을 더 작고 더 균일 한 덩어리로 나누는 것이 좋습니다.

이렇게하면 스프린트 계획에 소요되는 시간을 줄일 수 있습니다 . 스프린트 계획 중에는 스토리가 예상되며 스프린트를 시작하면 스토리를 구성하는 것으로 생각할 수있는 모든 작업을 내려 놓을 수 있습니다. 당신은 당신이 이야기 추정 건너 포인트가 분명히하면 알 수 작업으로 처리되어야 할 것이다, 당신은 이야기 정보에 저것을 추가하고 작업로를 넣을 수 있습니다.

이상적인 단위로 추정

스토리 포인트는 이상적인 근무 시간 또는 이상적인 근무일과 같은 이상적인 단위로 되어 있습니다 . 이것은 당신이 방해받지 않고 회의를하지 않고 모든 것이 계획대로 진행된 매일 완벽한 하루를 제공한다는 것을 의미합니다. 이제는 누구나 이것이 사실이 아니라는 것을 알고 있지만 통계에 대한 훌륭한 점은 통계가 필요하지 않다는 것입니다.

이것이 의미하는 바는 이상적인 날에 이들을 추정 한 후 스토리를 완성하는 데 평균 25 %의 시간이 걸린다는 것을 알고 있습니다. 4 일의 이상적인 근무일을 예상했지만 5 일이 걸렸다 고 가정 해 봅시다. 시간이 지남에 따라이를 추적하면 이상적인 날에서 실제 날로의 전환에 대한 대략적인 아이디어가 있습니다. 당신의 첫 번째 본능은 지나친 추정에 의해 이것을 보상하고 보상하는 것이며, 당신은 틀렸을 것입니다. 여기서 중요한 것은 일관성 을 유지하는 것 입니다. 그렇게하면 장기 평균이 동일하게 유지됩니다. 때때로, 그것은 아래에 있고 때로는 끝날 것입니다. 그러나 당신이 더 많이 추정할수록 더 나아질 것입니다. 여전히 당신이 발견하면 적절한 견적을 얻을 수 없습니다. 아마도 이야기를 제대로 평가하기에 대해 충분히 알지 못했을 수도 있습니다.

이야기에 대해 이야기

당신이 추정 할 때, 모든 사람은 처음부터 끝까지이 이야기가 완성되기 위해 무엇이 필요한지에 대해 대략적으로 생각해야합니다 . 모든 세부 사항을 알 필요는 없지만 자신이 이야기를 수행 할 수 있다고 생각할만큼 충분합니다. 그 정도의 확신이 없다면 추정하지 말아야 할 것입니다. "이 이야기가 우리가 대부분의 세부 사항을 알기에는 너무 큽니다"라고 말하면, 그 이야기가 너무 커서 세분화되어야 함을 나타냅니다. 적어도 내 경험상 이야기는 필요한 경우 한 사람이 혼자서 일하고 일주일 이내에 이룰 수있을 정도로 작습니다.

이것은 또한 편집에서 두 번째 점 해결하는 데 도움이 될 것입니다 너무 많은 추정 . 모든 단일 스토리에 대한 모든 단일 작업을 추정하는 대신 스토리 전체를 추정하기 만하면 많은 추정을 제거하는 데 도움이됩니다. 회의를 덜 단조롭게 만드는 것에 관해서는 포커 계획을 세우는 것이 좋습니다. 위에서 더 많은 정보를 볼 수 있습니다.

보다 매력적인 계획 수립

계획 포커를 사용하여 추정

예측을 더 재미있게 만드는 한 포커 계획 을 시도해 보셨습니까 ? 여러 팀에서 항상 모든 스프린트를 계획하는 방식이며 모든 사람이 적어도 뭔가를 선택해야하므로 모든 사람을 계속 참여시킬 수있는 좋은 방법입니다. 팀의 모든 사람이 3 명을 고를 때 누군가 20 명을 쓰러 뜨리고 스스로 설명해야 할 때, 또는 팀원 모두가 5 명을 쓰러 뜨 렸지만 관리자가 8 명을 쓰러 뜨릴 때 상당한 재미가 있습니다. 그가 당신에게 더 많은 시간을주고 싶어 할 때 보스!).

이를 위해서는 인덱스 카드 뒷면에있는 계획 포커 카드 나 얼굴 카드에 값이 첨부 된 일반 카드를 사용하면됩니다. 아무것도 환상적이지 않으며 모든 사람이 집중할 수 있습니다. 포커 계획을 포함하여 하루 종일 모든 작업을 수행하면 생산성이 저하됩니다. 많은 카드 세트에는 커피 카드가 제공됩니다. 누군가 타 버린 느낌이들 경우, 팀원들에게 재충전 할 시간을주고 모두가 신선 할 때 재충전하십시오!

실제 카드의 대안으로 전자 카드를 볼 수도 있습니다 . 여기에서 얻을 수있는 실질적인 이점은 결과를 자동으로 추적하고, 사용자 스토리를 추정하고, 모든 사람이 한 번에 자신의 카드를 보여서 "불륜"을 피할 수있게하는 것입니다 (한 사람이 자신의 카드를 볼 수 있기 때문에 다른 사람의 영향을받는 것으로 추정). 분명히 이것은 모든 사람이 컴퓨터를 가지고 있어야하고 당면한 과제에 집중할 수있는 능력이 필요하므로 자신의 재량에 따라 사용해야합니다.

1. 스프린트 시작 전에 백 로그 항목이 삽입되고 우선 순위가 지정되지 않는 이유는 무엇입니까? 개발자 시간을 낭비하는 것은 재미 있지 않습니다. 며칠 전에 팀 리더가 제품 소유자 및 프로젝트 관리자와 함께 작업하여 우선 순위를 정하도록하십시오. 이것은 각 스프린트 팀의 구성원을 계획하는데도 사용됩니다.

2. 일을 업무로 나누는 데 하루가 걸리는 이유는 무엇입니까? 합리적인 규모의 팀 (2-4 명의 개발자, 개발자 당 .5-1.5 QA 인원, 1-2 기타)이있는 경우이 스프린트에 2-4 명의 사용자 스토리가 있어야합니다. 제품 소유자가 요구 사항을 명확하게 한 다음 30 분 정도 소요 한 다음 30 분 정도 소요하면 ~ 8 시간 작업으로 분류됩니다. 회의 중에는 작업을 입력하지 마십시오. 제정신이 많은 사람들이 업무를 이해하고 책임이있는 사람과 시간이 얼마나 걸리는지 팀으로 동의하십시오. "테스트에 소요되는 시간"은 스프린트 내에 편안하게 맞습니다.

3. 일을 업무로 나누는 것이 아니라면 다른 일을하고 있습니까? 물론, 회고는 30-60 분이 걸릴 수 있지만 팀이 그루브에 들어가면 짧아집니다.

요약하자면 사람들의 시간을 낭비하지 않으면 회의가 약간 줄어들 것입니다. 그 외에도 팀의 재미와 동요는 회의에서 해결할 수있는 것이 아닙니다. 함께 점심을 먹으며 농담을하며 사람들을 섞어 더 나은 성격을 맞추고 콧수염을 키우는 경쟁을 벌입니다.

계획은 팀이 많은 유연성을 갖는 스크럼의 한 영역입니다. 당신의 팀에 맞는 것을 칠 때까지 스프린트마다 새로운 것을 시도하십시오.

내가 개인적으로 시도했거나 다른 팀으로부터 들었던 몇 가지 성공적인 아이디어 :

• 팀 전체없이 사용자 스토리를 만들고 우선 순위를 정하십시오. 제품 소유자 및 / 또는 스크럼 마스터는 많은 바쁜 작업을 처리하고 팀이 조정하도록 할 수 있습니다.
• 하나의 스프린트보다 백 로그를 상당히 길게 만드십시오. 이를 구축하는 데 시간이 다소 걸릴 수 있지만 백 로그가 오래 걸리면 계획 조정 회의가 약간 조정되거나 최근의 비즈니스 개발 문제를 해결하는 것으로 축소됩니다.
• 스프린트 계획과는 별도의 견적 회의를 갖습니다. 사람들이 회의가 너무 길다고 생각하면 회의를 나누지 않을 이유가 없습니다.
• 구체적으로 계획은 의제에 속합니다. 한두 명의 팀원이 돌아 오기를 기다리는 데 종종 시간을 낭비하는 경우에 유용합니다.
• 회의 중간에 휴식을 취하고 모든 사람에게 하나 또는 두 개의 사용자 스토리를 작성하도록 할당 한 다음 다시 만나 합의를보고하십시오.
• 계획 회의가 수행 방법 이 아니라해야 할 일 에 관한 것인지 확인하십시오 . 엔지니어들은 후자에 매우 쉽게 빠진다. 필요한 경우 방법을 논의 할 별도의 설계 회의를 설정하십시오.
• 스토리를 조사와 구현으로 분리하십시오. 팀 구성원이 작업 할 대상에 대해 너무 적게 알고 회의 중이를 파악하려고 할 때 계획 회의는 종종 너무 오래 걸립니다.
  예를 들어 팀이 경험하지 않은 API와 통합해야한다고 가정 해보십시오. 계획 회의에서 자신이 모르는 것에 대한 견적과 작업을 만들려고 시도하는 대신 API를 배우고 간단한 "hello world"앱을 작성하여 팀에 가르치는 조사 스토리를 만듭니다. 그런 다음 실제 작업을 계획 할 수 있습니다.
• 특정 문제를 회의 중에 추적하십시오. "계획은 지루합니다."뿐만 아니라 "우리는 불명확 한 요구 사항에 대해 많은 시간을 소비하며 아무도 정답을 알지 못하는 것 같습니다." 그런 다음 회고에서 특정 문제를 논의하고 특정 솔루션에 대한 브레인 스토밍하십시오. 조각이 쉽게 풀릴 때까지 문제를 해결하십시오.

스프린트 계획과 회고를 동시에 진행하며 거의 90 분 안에 완료되지만 더 빠른 팀 중 하나입니다. 우리는 4-6 시간이 걸리는 5 회 스프린트마다 회사 전체의 장기 계획을 수행합니다. 물론 모든 팀은 다르지만 하루 종일 모든 스프린트를 보내고 있다면 개선의 여지가 많이 있습니다.

계획 세션이 너무 깁니다!

내 경험에 따르면, 스프린트 계획 회의는 계획된 주당 2 시간을 초과하지 않아야하지만 (예 : 2 주 스프린트는 최대 1/2 일이 소요됨) 성공한 회의는 그보다 짧아야합니다 (반의 절반).

특별한 경우 : 왜 작업을 추정합니까? 계획하는 동안 스토리 만 추정해야합니다. 작업은 나중에 특정 작업 소유자 가 추정 할 수 있습니다 .

나를 위해 일한 방법 :

• PO의 스프린트에 대한 빠른 소개
• 스프린트 용량 추정
• 스프린트를 커버하기에 충분한 추정치가 될 때까지 스토리가 소진되고 포커 (스토리 당 5/10 분에 타임 박스)가 계획됩니다
• 팀의 공식 약속 / 예보

그런 다음, 책상에서 직무 / 작업 / 작업 추정을 병행 / 쌍 / 자기 조직합니다.

이전의 직업에서, 각 스프린트의 첫날 (우리는이를 반복이라고 함)을 다음과 같이 취했습니다.

• 회고전. 우리는 마지막 날 오후에 이것을 시작했지만 종종 스프린트에 대해 회고 한 다음 스프린트 작업의 마지막 느슨한 끝을 묶는 작업으로 돌아가는 것을 자주 발견했습니다. 그것을 회고하기 전에 모든 것이 우리 뒤에 있었다. 또한 스크럼 프로세스의 모든 회의 오버 헤드를 통합하여 다른 날을보다 이상적인 용어로 계획하고 사용할 수 있도록하는 것이 논리적으로 보였습니다. 일반적으로 2 시간이 걸렸습니다.
• 스프린트 계획. 백로 그는 마일스톤 계획 회의 (개발자와 PO 모두 하루 종일 가능) 중에 평가되었으며 각 스프린트가 시작되기 전에 PO에 의해 우선 순위가 결정되었습니다. 우리는 얼마나 많은 개발자의 날 (휴일, 휴가 등을 고려한)을 파악하고, 우리가 할 수있는 일을 파악하고, 사용자 요구 사항 (이전에 BA가 심사 한 것)을 신속하게 검토했습니다. MPM 동안의 간단한 개요로 얻은 것보다 작업에 수반되는 내용에 대해 더 완벽하게 이해할 수 있습니다. 일반적으로 2 시간이 더 걸렸습니다.
• 작업 계획. 이야기와 수용 기준을 알면서, 우리는 각 이야기를 이상적인 시간으로 추정되는 한입 크기의 과제로 나 bro습니다. 우리의 포인트 스케일이 교정되는 방식은 5가 개발자 스프린트 였으므로 1은 최대 개발자 2 일을 포함하여 무엇이든 될 수 있습니다. 이러한 이유로 팀원들이 스크럼 보드에 진행 상황을 표시 할 수 있도록 거의 모든 것이 분리되어야했습니다. 이것은 또 다른 2 시간의 블록이었고, 이것과 다음 항목 사이에 약간의 공짜가있었습니다.
• AAT 개요. 우리의 PO와 BA는 프로그래머가 아니었고 코딩도하지 않았습니다. PO는 계약서 뒤에 숨어서 요구 사항을 Word 템플릿 형식으로 제공하고 BA와 협력하여 해당 형식으로 세분화 할 것이라고 규정했습니다. BA는 코드를 이해했지만 시간은 순전히 분석 및 최종 테스트였습니다 (시스템이 있어야하므로 매크로를 셀레늄에 기록 할 수 있음). 따라서 코드가 승인 기준을 충족하는지 확인하려면 "용지"합격 테스트의 동작을 모델링하는 자체 AAT를 작성해야했습니다. 우리는 일반적으로 단위 및 통합 테스트에 사용한 것과 동일한 NUnit 프레임 워크에서이 작업을 수행했습니다 (FitNesse를 사용해 보았지만 충분히 빨리 포기할 수 없었습니다). 이것은 각 스프린트의 첫날의 나머지 날이었고 두 번째 날까지 계속되었습니다.

현재 직장에서 우리는 여전히 Scrum 프로세스를 채택하고 있으며 팀 전체의 마일스톤 계획이 없었으며 현재 진행중인 많은 작업에는 엄격한 승인 기준이 없습니다. 따라서 스프린트 계획은 각 스토리에 수반되는 내용과 우리가해야 할 일에 대한 설명입니다. 이는 최고의 X 이상 근무 시간을 최고 수준으로 끌어 올리 겠다는 약속입니다. 우리는 사내 팀이기 때문에 지금 당장 그것을 피해 갈 수 있습니다. 우리 각자는 소프트웨어의 최종 사용자와 개인적으로 협력하여 요구 사항과 디자인 솔루션을 수집합니다. 그럼에도 불구하고 스프린트 계획은 매주 월요일마다 아침마다 일어나며 오후에는 화요일에 본격적으로 개발을 시작할 수 있도록 개인적인 장애물을 없애는 데 소비됩니다.

오래 걸리지 않아야한다는 다른 의견 / 응답을 대조하기보다는 실제로 OP의 질문에 대답하기 위해, 사용하는 것보다 조금 더 흥미로운 애자일 추정, 스프린트 계획 및 회고에 접근하는 방법이 있습니다.

귀하의 우려를 구체적으로 해결하십시오.

• 회의 시간 이 길다 . 회고, 스프린트 계획, 과제 분석 등 각 회의는 명확한 목적과 토론 주제를 가져야하며 가능한 한 정해진 시간으로 제한되어야합니다. 이러한 회의를 주제로 유지하고 시간 목표를 달성하기 위해 계속 진행하는 것이 Scrum Master의 임무입니다.

• 회의는 단조롭습니다 . 그 중 일부가있을 것입니다. 한 번에 한 입 크기의 덩어리로 작업하므로 동일한 작업을 반복해서 수행하게됩니다. 팀의 집중력을 유지하고 회의의 목적을 달성하기 위해 추진하는 것이 도움이 될 것입니다.

  내가들은 다른 것은 스프린트 계획 회의가 너무 많은 성과를 거두려고한다는 것입니다. 마지막 회사에서 스토리 평가는 "마일스톤 계획 회의"에서 이루어졌습니다.이 회의는 약 1/4 분기에 하루 종일 진행되었습니다. 이러한 회의에서 우리가 추정하지 않은 백 로그에 구축 된 모든 내용은 포인트 단위로 추정되었습니다. 포인트 단위로 스토리 추정을 수행 한 다음 시간 단위로 작업 추정을 수행하는 경우 동시에 같은 날짜에 수행하지 않을 수 있습니다.

• 포인트 단위로 스토리를 추정 한 다음 몇 시간 내에 작업을 수행하는 것은 불필요한 것처럼 보입니다 . 두 가지 목적이 있습니다. 스토리 추정의 목적은 과거의 속도와 예상 대역폭을 기반으로 스프린트 백 로그를 채우는 데 사용할 수있는 대략적인 복잡성을 추정하는 것입니다. 작업 추정의 목적은 이야기를 개발자의 하루 이하로 처리하는 것으로 분류하고 (따라서 한 번에 완료 할 것으로 예상되는 단일 사람에게 할당 할 수 있음) 스프린트에서 씹을 수있는 것보다 많은 이야기의 복잡성을 잘못 추정하거나 물린 것.

  스토리가 모두 하루 이하로 걸리면 중복되지만 모든 포인트 스케일이 동일하게 보정되는 것은 아닙니다. 마지막 직장에서 5는 개발자 주 2 회 (처음에는 많은 서사시가 있었기 때문에 추정치가 많았 기 때문에)는 선형 척도로 최대 2 일 개발자 포인트를 만들었습니다. 이런 종류의 규모가 주어지면 사실상 모든 것이 작업으로 분류되어야합니다. 나의 새로운 회사에서, 개발자의 하루 반이 가까워 지므로 1 또는 2는 확실히 자체 작업이며, 3-8은 팀이 작업으로 분할하도록 강요하는 것과 관련하여 성가시다.

• 사람들의 집중력을 떨어 뜨리는 데 시간 이 걸리는 악순환이 있습니다 . 코딩 할 때와 마찬가지로 휴식을 취하십시오. 30 분마다 5 분씩 다리를 늘리거나 재편성하십시오. 1 시간마다 10 분씩 만들 수는 있지만 회의 시간을 확실하게 초과하지 마십시오. 배가 고프거나 커피가 더 필요하거나 화장실이 필요합니다. 거부하지 마십시오. 당신이 그들을 빨리 게하면 당신은 그들의 마음이 방황을 찾을 수 있습니다. 그 외에도, 토론을 짧고, 달콤하고, 요점까지 유지하면 앞에서 언급 한 것처럼 도움이 될 것입니다.

스프린트 계획 회의는 두 부분으로 구성됩니다.

1. 팀이 무엇을 할 것인지 결정
2. 팀이 어떻게 할 것인지 결정하십시오.

첫 번째 부분은 팀이 취할 수있는 스토리 포인트 수, 우선 순위에 따라 많은 사용자 스토리를 완료하겠다는 결심에 따라 비교적 간단합니다. 끝난.

두 번째 부분은 개발자가 실제로 즐기는 것, 스토리의 정교화 및 솔루션 설계입니다. 그 작업은 그로부터 벗어납니다. 따라서 제품 소유자 나 그가 제공 한 SME가 선택한 이야기를 설명하도록하십시오. 그런 다음 개발자가 맡고 싶은 디자인 토론을 진행하십시오. 화이트 보드를 사용하십시오. 아이디어를 바운스하십시오. 즐기세요

그게 다야. 디자인 회의가 재미 있지 않다면 문제가있을뿐입니다.

그러나 나는 이것이 오래된 질문이라는 것을 알고 있지만 새로운 대답이 있습니다. :피

회의를 나눕니다.

스프린트 계획 회의를 3 개의 개별 미니 회의로 나누었습니다.

• 백 로그 그루밍
• 이야기 선택
• 작업 분석

우리는 매일 스크럼 바로 다음에 각각 다른 날에 일을합니다. 매일 작업이 완료 되 자마자 계획 활동에 참여한 다음 하루의 나머지 시간에 (정기 계획된) 회의에서 벗어날 수 있습니다.

그렇습니다, 우리는 우리의 계획을 넘어 섰습니다.

잠시 후 각 세션과 관련된 내용에 대해 자세히 설명하겠습니다. 그러나이 과정에 어떻게 도달했는지 설명하겠습니다.

우리는 당신과 마찬가지로 정말 스프린트 계획 회의에 문제가있었습니다. 우리는 모든 올바른 요소를 가지고 있었지만 모든 것이 영원히 지속되었으며 정신적으로나 감정적으로 빠져 나갔습니다.

그런 다음 매일 5 분 동안 Pivotal의 Business Insider 기사를 읽고 회의를 더 짧은 세션으로 나누고 매일 시작하는 것에 대해이 아이디어를 얻었 습니다.

나는 회고에서 팀과 함께 그것을했다. 일부 팀원들은 바로 그것을 좋아했고 다른 팀원들은 조금 불안해했습니다. 그러나 우리 인턴 은 포모 도로 기술 에 대해 읽고 연구를 시작했으며 아이디어가 견인력을 얻는 데 실제로 도움이되었다는 연구를 언급 했습니다.

그래서 우리는 그것을 시도하기로 결정했습니다.
우리는 2 시간 회의를 3 개의 25 분 세션으로 나누었습니다. (그렇습니다. 퍼지 수학이지만 모든 사람들은 회의 시간이 너무 길어서 시간을 절약해야 할 뿐이라고 생각했습니다).

그리고 효과가있었습니다! 우리는 지금 두 개의 개별 프로젝트 (총 6 주 2 회 스프린트)에서 약 6 주 동안이 일을 해 왔으며, 세계는 차이가났습니다.
우리는 더 생산적입니다. 우리는 많은 시간을 절약합니다.
더 나은 결과물을 얻습니다. 그리고 더 이상 계획 회의를 두려워하지 않습니다.

솔직히 말해서, 25 분짜리 시간 상자는 꽤 느슨합니다. 일부 세션은 5-10 분의 일부 손질 세션에서 실제로 빠르게 진행되고 일부는 우리가 새로운 이야기를 식별하거나 이야기를 나누는 것처럼 길어집니다. 협상 중에 재 추정합니다. 전반적으로, 그것은 일반적으로 전체 세방에 대해 평균 1.5 시간을 넘지 않기 때문에 그것이 잘 작동하는 이유라고 생각합니다.

세부 사항에 .....

백 로그 그루밍

매우 간단합니다. 우선 순위가 가장 높은 이야기를 검토하고 그 내용에 대해 이야기하며 추정치가 올바른지 확인합니다.

우리는 필요한 경우 이야기를 다시 추정 할 것입니다. 몇 달 전에 무언가를 추정하고 비슷한 이야기가 실제로 무엇을했는지 깨달은 후에 다시 추정하는 데 동의 할 수 있습니다. (우리는 단위가없는 이야기 포인트 를 사용하며 작업을 추정하지 않습니다 ).

또한 PO가 우선 순위가 높다고 생각하는 새로운 스토리를 추가 한 경우에는이를 평가할 때입니다.

다음 날까지 스토리 선택을 수행하지 않기 때문에이 프로세스는 PO가 다음 반복에서 수행해야 할 가장 중요한 사항에 대한 최종 판단을 내릴 시간을 조금 더줍니다. 이는 매우 도움이되었습니다.

이 회의는 일부 PO는 부족하고 다른 PO는 오래 걸리는 경향이 있습니다. (개인적으로는 PO가 수행하는 방식에 대한 훌륭한 냄새 표시기라고 생각합니다)

이야기 선택

Chris Voss를 켜 십시오 . 협상 할 차례입니다.

이 회의에서 우리는 최우선 과제를 다루고 각각에 대한 DoD 를 정의합니다 . 우리는 모두 스프린트 목표에 동의 할 수있을 때까지 필요에 따라 스토리를 나누고 결합하여 각각 무엇이 수반 할 것인지 협상합니다.

우리는이 회의를 위해 신선한 마음과 좋은 아침 에너지를 통해 많은 혜택을 얻습니다. 그리고 우리가 다른 날에 할 일을 알면 우리는 실제로 잘 협상하고 약속을 이해하는 데 필요한 시간을 보낼 수 있습니다.

작업

좋아, 내가 말을 가장 먼저 받아 볼 수 있습니다, 작업 내이었다 LEAST 계획의 좋아하는 부분은 우리의 오래된 일일 회의에서.

우리는 이것으로 우리의 걸음을 결코 치지 않았습니다. 우리는 회의가 끝날 때까지 작업을 저장하려고 시도했지만 그 당시에는 모두 지쳐 버렸고 실제로 비생산적이었습니다. 협상 중에 DoD와 동시에 작업을 정의하려고 시도했지만 너무 산만하고 번거로 웠습니다. 모든 이야기를 선택하기 전에 불타 버릴 것입니다. 또한 견적, 협상, 스토리 선택 및 작업 생성간에 초점 / 사고를 계속 전환하는 것이 매우 어려웠습니다. 우리는 어려움을 겪고 빨려 들어 갔으며 회의가 두려웠습니다.

그러나 이제는 하루에 DoD를 정의하고 다음 날까지 작업을 수행하지 않아도 화상을 입지 않고 항상 올바른 사고 상태에 있으며, 하루 종일 이야기를 끝내고 실제로 시작하기 전에 모든 작업을 생각하고 이해하십시오.

IMHO는 이것만으로도 완벽한 게임 체인저입니다.

함께 모아서.

스프린트 행사 일정은 다음과 같습니다.

• 월요일-일일 스크럼-> 스프린트 검토
• 화요일-일일 스크럼-> 백 로그 정리
• 수요일-일일 스크럼-> 스토리 선택
• 목요일-일일 스크럼-> 작업
• 금요일-일일 스크럼-> 회고

그것은 우리를 위해 정말 잘 작동했습니다. 당신이 그것을 주사하면 당신의 생각을 듣고 싶습니다.

우리는 1 시간 회의로 매주 스프린트를하게되는데, 여기서는 이전 스프린트에 대해 논의하고 남은 일을 다음 주 계획으로 진행합니다. 한 시간 안에 모두.

물론 스크럼을 따르는 것이 너무 많은 시간을 낭비한다는 것을 알았 기 때문에 이것은 물론입니다. 이는 요청자가 사용자 스토리를 만들 때 대부분의 스토리가 이미 팀 구성원과 논의 되었기 때문입니다.

팀이 계획 회의를 두려워하는 경우 스크럼의 "규칙"중 일부를 놓아야 할 것입니다.

이 질문은 포괄적으로 답변되었지만 작동하고 재미있게하려면 한 가지만 있으면됩니다.

팀에 힘을주십시오. 즉, 그들이 가장 중요하다고 생각 하는 일을 하게 한다.