IPM(반복 계획 회의)

샘플 안건 및 메시지

1. 회의를 위한 대화의 틀을 마련하는 것부터 시작합니다. 최근 승인된 스토리와 진행 중인 스토리나 검증 환경에서 최신 기능의 현재 상태를 간략하게 요약하여 필요에 따라 전반적인 프로젝트 컨텍스트를 설정하여 이 다음 반복을 시작할 때 모든 사람이 현재 상황을 파악하고 있도록 합니다. 제품에 추가할 사항을 요약하여 새로운 사용자 스토리를 검토합니다. 사용 가능한 경우 사용자 인터페이스 모형을 제시합니다.

2. 첫 번째 사용자 스토리를 꼼꼼히 읽고 비즈니스 가치, 사용자 가치, 검증 기준을 설명합니다. 참가자에게 질문하도록 허용하고 필요한 경우 명확하게 설명합니다.

   팁: 모든 팀원이 편안하게 평가할 수 있도록 필요한 설명을 얻을 수 있도록 하십시오. 대화를 이어나가는 개인의 성격 또는 전체 팀의 이해를 방해하는 방식에 주의하십시오.

3. 엔지니어가 사용자 스토리를 평가할 준비가 되면 알려주도록 하고, 준비가 되면 동시에 스토리 점수 평가에 투표하여 스토리의 상대적인 복잡도를 평가하도록 유도합니다.

   평가와 관련된 팁은 아래에 있는 간단한 평가 가이드를 참조하십시오.

4. 평가에 대한 의견이 일치하면 평가 결과를 사용하여 사용자 스토리에 레이블을 지정하고 백로그에 승격하여 팀에게 이 스토리의 우선순위를 보여 줍니다. 또는 의견이 일치하지 않는 경우, 팀이 만족하는 의견 일치가 나올 때까지 토론하고 필요한 경우 다시 평가하도록 엔지니어를 유도합니다.

   팁 1: 대화가 너무 길어지거나 해당 사용자 스토리의 범위에서 너무 벗어나지 않도록 하십시오. 명확하지 않은 부분이 많거나 해당 스토리의 범위에서 의견이 일치되지 않는 경우, 향후 IPM에서 합리적으로 평가할 수 있으려면 조사 또는 실험을 위해 제품 백로그에 작업을 추가해야 할 수도 있습니다.

   팁 2: 사용자 스토리는 구현에 구애받지 않아야 합니다. 상대적인 복잡성을 평가할 때 구현에 대한 논의가 당연히 발생하지만, 이러한 논의를 개괄적인 수준으로 유지하고 구현에 관한 자세한 논의는 보류하십시오.

5. 이 회의를 위해 준비된 나머지 사용자 스토리에 대해서 2~4단계를 반복합니다.

   팁: 가능한 시간을 활용하여 준비된 사용자 스토리를 최대한 많이 논의하고 평가하십시오. 필요한 경우 일부 사용자 스토리를 다음 반복 계획 회의로 연기할 수 있습니다. 계획한 것보다 많은 시간을 들여 팀의 소중한 에너지를 소모하지 마십시오.

6. 회의 마지막 10분 동안, 엔지니어링 작업을 포함하여 제품 백로그 항목의 상대적인 우선순위를 검토하고 논의합니다.

   팁: 엔지니어가 제품 백로그로 승격하려는 작업의 범위와 중요성에 관해 조언하도록 유도하십시오.

성공/예상되는 성과

첫 번째로, 팀은 논의된 제품 백로그 항목의 범위와 상대적인 복잡성에 대해 다 같이 이해해야 합니다. 두 번째로, 제품 백로그에 항목을 추가하여 현재 우선순위에 따라 정렬되어야 합니다. 팀은 다음 반복에서 나올 작업에 대해 일치되고 활기를 얻은 느낌으로 IPM을 마쳐야 합니다.

진행자 메모 및 팁

• IPM을 보다 효과적으로 진행하기 위해 회의에서 논의될 사용자 스토리가 사전에 적합하게 다듬어져 있는지 확인하십시오. 디자이너 및 엔지니어와 협업하여 스토리가 실행 가능하며 INVEST 기준을 충족하도록 만드십시오. 회의 중에 스토리를 급하게 작성하지 마십시오.
• 필요한 작업을 생성하도록 엔지니어를 격려하고, 필요한 경우 엔지니어와 협업하여 IPM 전에 해당 작업의 우선순위를 정하고 다듬으십시오.
• 평균 팀 속도에 따라, 논의 및 평가할 사용자 스토리를 이미 준비했으며 제품 백로그에 3회 이내의 반복 작업이 포함된 경우에만 IPM을 진행하십시오. 지나치게 평가하는 경우, 평가의 정확성이 떨어지고 팀이 해당 사용자 스토리에 대한 작업을 시작할 때까지 컨텍스트를 잊어버릴 수 있습니다.

간단한 평가 가이드

• 제품 백로그에 3회 이상의 반복에서 전에 평가된 사용자 스토리가 있는 경우, 팀이 도움이 될 것이라고 동의한다면 IPM에 대해 스케줄링된 시간을 활용해 다음 사용자 스토리를 검토하고 다시 평가하십시오.
• 복잡성은 제품 백로그의 다른 사용자 스토리와 비교해서 또는 기준 사용자 스토리와 비교해서 평가될 수 있습니다.
• 상대적인 복잡성은 작업 완료에 걸리는 시간에 비해 사용자 스토리의 크기를 평가하는 보다 쉽고 신뢰할 수 있는 방법입니다.
• 평가는 일반적으로 “스토리 점수”를 사용해 수량화되고, 팀은 프로젝트 전체에서 사용할 점수 척도를 미리 일치시켜야 합니다(예: 피보나치, 직선, 지수).
• 편견을 방지하기 위해 평가를 동시에 수행하는 것이 중요합니다. 동시에 수행하는 좋은 방법은 셋을 세면 참가자가 투표하도록 하는 것입니다.
• 큰 스토리 점수 평가는 분할된 스토리가 여전히 사용자에게 유용한 경우, 사용자 스토리 분할을 제안할 수 있습니다.
• 검증 시험/검증 이후 수행할 작업이 거의 없거나 없는 사용자 스토리의 경우 스토리 점수 0점으로 평가될 수 있습니다.
• 스토리 점수 평가가 정확하지 않아도 괜찮습니다. 같은 제품을 작업하는 같은 팀은 일반적으로 시간이 지남에 따라 더 정확하고 일관되게 평가합니다.
• 일반적으로 평가는 엔지니어 또는 작업을 제공할 사람만 수행해야 합니다. 테스터나 아키텍트 같은 기타 역할은 상대적인 복잡성을 충분히 이해하면 평가할 수 있습니다.

관련 사례

스프린트 계획 대 반복 계획

스크럼 “스프린트”와 “반복”은 모두 시간이 제한된 활동이지만 계획 수행 방식에 영향을 미치는 차이점이 있습니다.

이전 단계

반복 사전 계획(선택 사항)

권장 자료

Agile Estimating and Planning(저자: Mike Cohn)

Yesterday’s Weather

Planning Poker

Chapter 12 of Extreme Programming Explained의 12장(저자: Kent Beck, Cynthia Andres)

ExtremeProgramming.org