스프린트 계획 회의: 스프린트 기간 내내 무사히 진행될 수 있는 회의 진행 방법

일기 예측이 정확히 오후 3시에 비가 올 것이라고 단언하지 않고, 비 올 확률이 70%라고 말하는 데에는 이유가 있습니다. 일기 예측은 이용 가능한 정보를 활용하고, 불확실성을 고려하며, 새로운 데이터가 들어오면 이를 반영해 업데이트합니다. 예측을 확실한 보장으로 오해하지 않는 한, 이를 바탕으로 오후 일정을 계획할 수 있습니다.

스프린트 계획 회의도 비슷한 원리로 진행됩니다. 스크럼 팀은 제품 백로그, 가용 용량에 대한 추정치, 그리고 달성하고자 하는 목표를 가지고 있습니다. 하지만 일부 작업의 세부 사항은 스프린트가 진행되면서야 비로소 명확해집니다. 매 시간을 미리 계획해 두면 이러한 새로운 발견을 수용할 여지가 거의 없어지는 반면, 공유된 방향성 없이 시작하면 무엇에 주의를 기울여야 할지 결정하기가 더 어려워집니다.

이 과정의 목적은 가치 있는 결과물에 대해 합의하고, 이를 달성하기 위해 팀이 완료할 수 있는 작업량을 예측하는 것입니다. 이를 바탕으로 팀은 스프린트 목표를 놓치지 않으면서도 새로운 정보를 얻음에 따라 플랜을 유연하게 조정할 수 있습니다.

이 가이드에서는 백로그 준비, 시간별 아젠다, 실용적인 용량 산정 방법, 그리고 스프린트 진행 중 플랜을 조정하는 방법을 보여주는 실제 예시를 다룹니다.

스프린트 계획 회의란 무엇인가요?

스프린트 계획 회의는 각 스프린트 시작 시점에 열리는 스크럼 이벤트로, 팀이 달성하고자 하는 목표와 업무 수행 방식을 합의하기 위해 진행됩니다. 이 회의에는 제품 소유자, 스크럼 마스터, 개발자를 포함한 전체 스크럼 팀이 한자리에 모입니다. 보안 엔지니어나 고객 대응 담당자 등 다른 전문가들도 팀이 정보에 기반한 결정을 내리는 데 도움이 될 경우 회의에 참여할 수 있습니다.

스크럼 가이드에 따르면, 모든 계획 세션에서는 세 가지 결과물을 도출해야 합니다. 바로 업무의 가치를 설명하는 스프린트 목표, 해당 목표를 지원하는 제품 백로그 항목 선택, 그리고 이를 전달하기 위한 초기 계획입니다. 이 세 가지가 합쳐져 스프린트 백로그를 구성하며, 개발자들은 스프린트가 진행됨에 따라 이를 지속적으로 업데이트합니다.

스크럼 가이드(Scrum Guide)는 1개월 스프린트의 최대 시간을 8시간으로 정하고 있으며, 스프린트 기간이 짧을수록 소요 시간도 일반적으로 줄어듭니다. 백로그가 잘 정리되어 있다면, 아래의 아젠다대로 진행해도 2시간이면 충분합니다.

이 용어 중 익숙하지 않은 것이 있다면, 저희 용어집에서 애자일(Agile)과 스크럼(Scrum)의 기본 개념을 확인해 보세요.

스프린트 플랜 회의가 답하는 세 가지 질문

모든 스프린트 계획 세션은 다음 세 가지 질문을 중심으로 진행됩니다:

스크럼 가이드 ( Scrum Guide )는 전달하고자 하는 가치를 시작으로, 이러한 질문들을 중심으로 기획 과정을 구성합니다. 모든 구성원이 이를 명확히 이해하면, 어떤 백로그 항목에 주의를 기울여야 할지, 그리고 팀이 합리적으로 감당할 수 있는 작업량이 얼마인지 결정하기가 더 쉬워집니다.

스프린트가 중요한 이유

스프린트 목표는 팀이 향해 나아가야 할 방향을 제시하고, 이해관계자들이 무엇을 기대해야 하는지 이해하는 데 도움을 줍니다. 계획 세션이 끝나기 전에 스크럼 팀과 이 목표에 대해 합의하십시오.

“34 스토리 포인트를 완료한다”와 같은 업무량 목표보다는 “체험판 사용자가 팀원을 초대할 수 있다”와 같이 사람들이 인식할 수 있는 결과를 기술하십시오. 예상치 못한 문제가 발생할 경우, 이 목표는 팀이 의도한 결과를 유지하면서 어떤 작업을 조정할지 결정하는 데 도움이 됩니다.

팀이 이번 스프린트 동안 완료할 수 있는 작업

목표에 합의했다면, 이제 팀이 현실적으로 무엇을 전달할 수 있는지 파악할 차례입니다.

개발자들은 사용 가능한 용량, 과거 실적, 그리고 ‘완료 기준(Definition of Done)’을 고려하면서 제품 소유자(Product Owner)와 논의하여 백로그 항목을 선택합니다. 또한 이때는 팀이 스프린트 작업에 할애할 수 있는 시간에 영향을 미칠 수 있는 기존 약속 사항을 검토하기에 적절한 시기이기도 합니다.

많은 팀이 스토리 포인트를 사용하여 백로그 항목의 상대적인 노력도와 복잡성을 비교합니다. 피보나치 척도는 특히 필요한 노력도가 불분명한 경우, 이러한 논의를 체계적으로 진행하는 데 도움이 될 수 있습니다.

팀이 일을 수행하는 방법

백로그 항목이 선택되면, 개발자들은 이를 ‘완료 기준(Definition of Done)’을 충족하는 완성된 제품 증분으로 전환할 방법을 모색합니다. 스크럼 가이드(Scrum Guide)는 대규모 항목을 하루 이내로 완료할 수 있는 크기의 작은 작업 단위로 분할할 것을 권장합니다.

그렇다고 해서 스프린트의 매 시간을 일일이 플랜으로 작성해야 한다는 뜻은 아닙니다. 초반 며칠은 더 상세한 플랜이 필요할 수 있지만, 후반부의 작업은 새로운 세부 사항이 드러남에 따라 유연하게 조정할 수 있도록 남겨두면 됩니다. 초기 추정치를 확고한 약속으로 간주하면, 도중에 범위가 변경되더라도 팀이 원래 수치를 달성해야 한다는 압박을 받을 수 있습니다.

Scrum.org의 CEO인 데이브 웨스트( Dave West)는 다음과 같이 설명합니다:

마감일을 지키기 위해 사용되는 예측은, 수치를 맞추기 위해 추정치에 여유를 두거나, 위험을 숨기거나, ‘완료됨’의 기준을 은밀히 재정의하는 등 신뢰를 훼손하는 행동을 오히려 조장합니다.

스프린트 플랜과 백로그 정제(Backlog Refinement)의 차이점은 무엇인가요?

백로그 정제 과정을 통해 팀은 다음 스프린트에 포함될 작업을 결정하기 전에 향후 수행할 일에 대해 더 명확하게 이해할 수 있습니다. 스프린트 계획 회의는 이러한 준비 과정을 바탕으로 목표를 합의하고, 백로그 항목을 선택하며, 초기 전달 플랜을 수립합니다.

이 두 활동은 스크럼 내에서 서로 다른 목적을 수행합니다:

팀이 스프린트 계획 수립 시 명확한 선택을 할 수 있도록, 향후 처리할 백로그 항목 중 충분한 수를 미리 구체화해 두십시오. 준비가 얼마나 필요한지는 우선순위가 얼마나 빨리 바뀌는지와 남아 있는 불확실성의 정도에 따라 달라집니다. 백로그 순위가 낮은 항목들은 선택 시점이 가까워질 때까지 세부 사항을 덜 구체화해 두어도 됩니다.

스프린트 계획 회의를 준비하는 방법

회의 며칠 전, 백로그의 모양이 제대로 되어 있는지, 그리고 모든 참가자가 의사결정에 필요한 정보를 갖추고 있는지 확인하세요. 그렇게 하면, 모든 요구 사항을 처음부터 다시 해결해야 하는 번거로움 없이, 무엇을 전달할지, 그리고 어떻게 접근할지에 대해 논의하는 데 시간을 할애할 수 있습니다.

다음 스프린트를 시작하기 전에 확인해 볼 체크리스트는 다음과 같습니다:

스프린트 회고와 계획 세션을 연달아 잡는 경우, 두 회의 모두에서 충분한 토론 시간을 확보하십시오. 회고에서 도출된 결과는 다음 스프린트 플랜에 반영되어야 하므로, 어느 회의도 서두르는 느낌이 들지 않도록 주의하십시오.

스프린트 계획 아젠다: 2주 스프린트를 위한 시간별 예시

2주 스프린트의 경우, 특히 백로그가 이미 정제된 상태라면 2시간짜리 계획 세션으로 시작하세요. 일에 복잡한 의존성이 있거나 논의가 필요한 결정 사항이 여러 개 있는 경우에는 추가 시간을 확보해 두세요.

이 샘플 아젠다를 팀의 필요에 맞게 조정하여 사용할 수 있습니다.

회의를 마무리하기 전에 Fist of Five와 같은 간단한 확신도 확인 방법을 활용할 수 있습니다. 이 방법에서는 모든 참가자가 플랜에 대한 확신도를 0개에서 5개의 손가락으로 평가합니다. 누군가 낮은 점수를 준다면, 우려의 원인이 무엇인지 물어보세요. 이를 통해 해결되지 않은 의존성, 지나치게 야심 찬 예측, 또는 더 많은 논의가 필요한 요구 사항이 드러날 수 있습니다.

목적은 플랜을 조정할 시간이 아직 남아 있을 때 우려 사항을 파악하는 것입니다.

6단계로 진행하는 스프린트 계획 수립 방법

백로그를 준비하고 참석자를 확정했다면, 계획 세션을 시작하세요. 이 세션의 목표는 팀이 우선순위와 가용 용량을 바탕으로, 자신 있게 수행할 수 있다고 확신하는 플랜을 수립할 수 있도록 돕는 것입니다.

1단계: 이전 작업을 검토하고 스프린트 목표에 합의하기

먼저 완료된 작업, 아직 완료되지 않은 작업, 그리고 회고에서 도출된 조치 사항 중 다음 스프린트에 반영해야 할 사항이 있는지 간략히 살펴보는 것으로 시작하세요. 스프린트 리뷰 전체를 다시 검토하기보다는, 팀의 우선순위나 접근 방식을 바꿀 수 있는 사항에 집중하세요.

그런 다음, 제품 소유자가 제안된 스프린트 목표를 소개하고, 이것이 더 광범위한 제품 목표를 어떻게 지원하는지 설명하게 하세요. 개발자들이 그 범위에 대해 질문하고, 의존성을 제기하며, 조정안을 제안할 수 있는 여지를 마련해 주세요.

예를 들어, 목표가 고객이 영업 팀에 문의하지 않고도 결제 절차를 완료할 수 있도록 하는 것이라면, 성공적인 결제 절차가 어떤 모습인지 합의해야 합니다. 여기에는 결제 확인과 오류 처리가 포함됩니까? 첫 번째 릴리스에서 자동 영수증 발송 기능이 필수적입니까?

이러한 논의를 통해 팀이 달성할 수 있는 결과를 명확히 정의할 수 있습니다. 백로그 항목을 선택하는 과정에서 표현은 변경될 수 있지만, 계획이 끝나기 전에는 모든 구성원이 최종 목표에 대해 합의해야 합니다.

2단계: 팀의 가용 용량 계산하기

작업 항목을 선택하기 전에, 개발자들이 스프린트에 현실적으로 얼마나 많은 시간을 할애할 수 있는지 먼저 파악하십시오.

먼저 근무 일수와 각 구성원의 예상 가용 시간을 파악하세요. 그런 다음 예정된 휴가, 스크럼 이벤트, 지원 업무, 그리고 기타 알려진 약속을 고려하세요. 개발자가 주중 절반을 운영 문제 해결에 할애한다면, 해당 시간은 이미 할당된 것이므로 계획된 스프린트 작업에 사용할 수 없습니다.

간단한 계산식은 다음과 같습니다: 가용 용량 = 총 근무 시간 − 이미 커밋된 업무

예를 들어, 2주 동안 80시간의 근무 시간을 가진 개발자의 경우, 8시간의 휴가, 10시간의 회의, 12시간의 지원 업무가 있을 수 있습니다. 따라서 추가적인 불확실성을 고려하기 전까지 50시간이 남게 됩니다.

이 수치를 팀의 과거 성과와 비교해 보세요. 벨로시티는 팀이 이전 스프린트에서 완료한 작업량을 나타내는 반면, 용량은 이번 스프린트에 할당된 가용 시간을 반영합니다.

3단계: 이전 스프린트에서 완료되지 않은 일을 재평가하세요

미완료 백로그 항목은 새로운 스프린트에 추가하기 전에 다시 한 번 검토할 필요가 있습니다. 2주 전에는 중요했던 항목이라도 우선순위가 바뀌었을 수 있으며, 팀이 남은 작업량에 영향을 미치는 새로운 정보를 얻었을 수도 있습니다.

제품 소유자와 함께 각 항목을 검토하고 다음 사항을 고려하십시오:

스프린트에 계속 포함되어야 하는 작업의 경우, 남은 노력량을 바탕으로 해당 작업에 필요한 용량을 판단하십시오. 절반 정도 완료된 항목은 원래 예상했던 것보다 노력량이 적을 수 있지만, ‘완료 기준(Definition of Done)’을 충족할 때까지는 여전히 미완료로 간주됩니다.

4단계: 목표를 지원하는 백로그 항목 선택

개발자들은 자신의 용량과 미완료 일을 파악한 상태에서, 완료할 수 있다고 판단되는 제품 백로그 항목을 선택할 수 있습니다.

스프린트 목표를 직접적으로 지원하는 항목부터 시작하세요. 해당 항목의 수락 기준, 기술적 의존성, 그리고 전달에 영향을 미칠 수 있는 불확실성 요소에 대해 논의하세요. 항목이 너무 크거나 불명확한 경우, 스프린트 기간 내에 가치를 제공할 수 있도록 더 작은 단위로 분할하는 것을 고려하세요.

유지보수나 기타 제품 관련 우선순위를 처리할 여유가 있을 수도 있지만, 해당 일을 수행할 경우 주요 목표 달성에 차질이 생길 수 있는지 확인하십시오.

얼마나 많은 용량을 확보해야 할까요?

예기치 못한 지원 업무를 정기적으로 처리하는 팀의 경우, 가용 용량의 80%만 계획하는 것이 합리적인 출발점이 될 수 있지만, 스크럼은 고정된 비율을 규정하지는 않습니다.

팀에서 잦은 업무 방해를 경험한 적이 있다면, 조정된 작업 용량의 10~20%를 예비 용량으로 확보한 뒤, 이 수치를 이전 스프린트에서 실제로 필요했던 양과 비교해 볼 수 있습니다. 업무가 안정적이고 방해 요소가 적은 팀은 더 적은 양으로도 충분할 수 있습니다. 반면, 빈번한 인시던트가 발생하는 운영 중인 서비스를 지원하는 팀은 더 많은 양이 필요할 수 있습니다.

동일한 업무 약속을 두 번 계산하지 않도록 주의하십시오. 2단계에서 예정된 지원 시간이 이미 차감되었다면, 추가 버퍼는 알려진 업무량 이상의 불확실성을 감당할 수 있도록 설정해야 합니다. 산출된 용량을 달성해야 할 목표가 아닌, 논의의 지침으로 활용하십시오.

5단계: 일을 세분화하고 의존성을 확인하세요

백로그 항목을 선택한 후, 개발자들은 이를 어떻게 전달할지 구체적인 방안을 마련할 수 있습니다. 여기에는 대규모 항목을 개발, 테스트, 통합, 검토 작업으로 세분화하는 과정이 포함될 수 있습니다.

업무의 순서를 면밀히 살펴보세요. 결제 인터페이스가 결제 제공자와의 의존성에 의존하는 경우, 팀은 해당 의존성이 언제 준비되어야 하는지 파악해야 합니다. 다른 팀이 보안 변경 사항을 승인해야 한다면, 그 결정이 어떻게, 언제 이루어질지 명확히 해야 합니다.

당면한 작업은 더 상세하게 플랜을 작성하고, 이후의 작업은 추후 논의를 위해 열어두세요. 스크럼 가이드에서는 선택한 항목을 일반적으로 하루 이내의 크기로 더 작은 작업 항목으로 분해할 것을 권장하지만, 작업을 어떻게 구성하고 배포할지는 개발자가 결정합니다.

플랜에 필수적인 테스트 및 통합 작업을 포함한 ‘완료 기준(Definition of Done)’이 반영되었는지 확인하십시오. 의존성 문제로 인해 전달이 지연될 가능성이 있다면, 플랜을 확정하기 전에 선택한 항목을 재검토하거나 전달 방식을 조정하십시오.

6단계: 스프린트 백로그 확정 및 공유

스프린트 목표, 선정된 제품 백로그 항목, 초기 전달 플랜을 팀이 접근하고 업데이트할 수 있는 곳에 기록해 두세요. 이 모든 내용을 종합하면 팀이 달성하고자 하는 목표와 다음에 집중해야 할 작업이 명확해집니다.

회의를 마치기 전에 목표에 대한 합의가 이루어졌는지 확인하고, 모든 구성원이 예측과 관련하여 남아 있는 우려 사항을 제기할 기회를 제공하십시오. 중요한 의존성이나 용량 문제가 해결되지 않은 경우, 팀이 작업을 시작하기 전에 무엇을 변경해야 하는지 논의하십시오.

스프린트 기간 동안 진행되는 데일리 스크럼은 개발자들에게 목표 달성 진행 상황을 점검하고 스프린트 백로그를 조정할 기회를 제공합니다. 번다운(burndown) 또는 번업(burnup) 차트는 진행 상황의 변화를 보여주는 데 도움이 되며, 그 기반이 되는 작업들은 세부 정보를 제공합니다. 새로운 정보로 인해 선택한 범위에 영향을 미칠 경우, 개발자들은 스프린트 목표를 위태롭게 하지 않으면서 제품 소유자와 조정 방안을 논의할 수 있습니다.

스프린트 계획 수립 예시: 개발자 6명으로 구성된 팀

이러한 결정들이 실제로 어떻게 적용되는지 살펴보겠습니다.

B2B 청구 관련 제품을 위해 2주 스프린트를 계획하고 있다고 가정해 보세요. 팀에는 개발자 6명이 있으며, 제안된 스프린트 목표는 “신규 고객이 영업 팀에 문의하지 않고도 결제 시 카드 결제를 할 수 있다.”입니다.

백로그 항목을 선택하기 전에 팀이 사용할 수 있는 시간이 얼마나 되는지 파악해야 합니다. 이 예시에서는 계획된 스크럼 이벤트와 기타 업무를 차감하기 전, 각 개발자가 하루에 프로젝트 업무에 집중할 수 있는 잠재적 시간이 6시간이라고 가정합니다.

다음은 10일 근무일 동안의 용량 계산 방식입니다:

예시를 위해 20%의 여유 시간을 확보한 후, 이제 계획된 작업을 수행할 수 있는 시간은 216시간이 되었습니다. 실제로는 이전 스프린트에서 계획에 없던 일로 인해 일이 얼마나 방해받았는지를 바탕으로 여유 시간을 결정하게 됩니다.

스프린트 목표를 지원하는 일을 선택하세요

작업 용량이 확정되면, 개발자들은 제품 소유자와 함께 체크아웃과 관련된 백로그 항목을 검토합니다.

다음은 초기 작업 단위 노력 추정치를 바탕으로 한 선택입니다:

이러한 추정치를 바탕으로 계획된 작업 허용 범위 내에 6시간이 남으며, 예상치 못한 작업을 대비한 54시간의 여유 시간도 확보됩니다. 또한 팀은 제품 백로그에 보고 대시보드 개선 항목을 포함시켰습니다. 이 작업은 가치가 있지만, 체크아웃 목표 달성에 직접적으로 기여하지는 않습니다. 따라서 제품 소유자와 개발자들은 이를 향후 스프린트로 미루기로 합의했습니다.

상황이 변하면 플랜을 조정하세요

6일째, 결제 제공자가 API 변경 사항을 도입하여 통합 기능의 일부가 작동하지 않게 됩니다. 개발자들은 원인을 조사하고 필요한 추가 일량을 산정합니다.

원래의 작업 순서를 그대로 따르기보다는, 제품 소유자와 그 영향에 대해 논의합니다. 수정 작업이 남은 처리 용량 내에 들어맞는다면, 이를 우선순위로 두고 선택적인 영수증 디자인이나 다른 우선순위가 낮은 작업을 미룰 수 있습니다. 결제 확인 및 기타 필수 작업은 여전히 ‘완료 기준(Definition of Done)’을 충족해야 합니다.

수정 작업이 예상보다 규모가 크다면, 남은 작업 범위를 재평가하고 스프린트 목표가 여전히 달성 가능한지 여부를 재검토해야 합니다.

팀이 원래 예측했던 것보다 적은 수의 백로그 항목을 완료하고 끝날 수도 있습니다. 하지만 고객이 의도한 대로 결제를 완료할 수 있고, 일이 ‘완료 기준(Definition of Done)’을 충족한다면 스프린트 목표는 달성된 것입니다.

다른 팀을 위한 스프린트 목표 예시

스크럼 자체는 명확히 정의된 책임 범위와 이벤트를 가진 특정 프레임워크이지만, 소프트웨어 개발 이외의 일에도 동일한 계획 수립 방식을 적용할 수 있습니다.

예를 들어, 마케팅 팀은 “웨비나 랜딩 페이지를 공개하고 방문자가 별도의 도움 없이 등록할 수 있도록 한다”와 같은 목표를 설정할 수 있습니다. 운영 팀은 “다음 신입 사원 그룹의 모든 직원이 입사 첫날부터 필요한 장비와 시스템 접근 권한을 확보할 수 있도록 한다”를 목표로 삼을 수 있습니다.

두 목표 모두 스프린트 기간 동안 팀의 의사결정을 이끌어 줄 결과를 설명합니다. 백로그 항목과 전달 플랜은 달라질 수 있지만, 팀은 여전히 자신의 용량을 고려하고 성공적인 전달이 어떤 모습인지에 대해 합의해야 합니다.

스프린트 계획 수립 시 흔히 저지르는 실수와 해결 방법

팀이 스토리 포인트를 개인 성과 평가에 활용하거나, 불명확한 백로그 항목을 회의에 포함시키거나, 일을 지나치게 경직되게 배정하거나, 테스트 요구사항 및 외부 의존성을 간과할 경우 스프린트 계획 수립 과정에서 문제가 발생할 수 있습니다.

몇 가지 조정만으로도 이러한 문제가 전달에 영향을 미치기 전에 미리 파악할 수 있습니다.

여러 스프린트에 걸쳐 동일한 문제가 반복적으로 발생한다면, 이를 스프린트 회고 회의에 상정하고 다음 스프린트 동안 테스트해 볼 수 있는 개선 방안에 대해 합의하세요. 이 스프린트 회고 회의 템플릿을 활용하면 관찰 사항과 후속 조치를 체계적으로 기록할 수 있습니다.

스프린트가 끝날 때, 스프린트 검토 회의를 통해 이해관계자들과 함께 완료된 증분(increment)을 검토하고, 팀이 다음에 어떤 작업을 수행해야 할지 논의하십시오.

ClickUp에서 스프린트 계획 회의를 진행하는 방법

작업, 용량 추정치, 계획 결정 사항이 여러 도구에 흩어져 있으면 스프린트 계획 수립에 더 많은 노력이 필요합니다. ClickUp은 이러한 정보를 한곳에 모아 팀이 용량과 함께 일을 검토하고, 플랜이 변경될 때 계획 결정 사항을 재검토할 수 있도록 지원합니다.

ClickUp 애자일 스프린트 계획 템플릿으로 시작해 보세요. 이 템플릿의 백로그, 개발 상태, 리소스 보기를 통해 향후 일을 검토하고 계획 논의를 준비할 수 있습니다.

무료 템플릿 받기

다음은 주요 의사결정 과정을 진행하는 방법입니다:

다음 계획 세션 전에 Brain²에 “지난 스프린트 계획 세션에서 해결되지 않은 의존성은 무엇이었나요?”라고 물어보세요. Brain은 기록된 회의 노트에서 관련 맥락을 추출할 수 있습니다. 해당 세부 사항을 현재 작업과 대조하여 확인한 후, 다음 예측에 반영하세요.

ClickUp 요금제

스프린트가 시작되기 전에 어느 정도까지 플랜을 세워야 할까요?

스프린트 계획 세션이 끝나면 팀은 일을 시작할 수 있을 만큼 명확한 방향을 파악해야 합니다.

위의 시간별 아젠다와 처리 용량 예시는 출발점이 됩니다. 이를 팀의 업무량에 맞게 조정한 다음, 예측된 내용과 완료된 업무 및 방해 요인을 비교하여 다음 회의를 개선하세요.

ClickUp에서는 계획 노트를 스프린트 작업에 연결하고, 업무가 변경될 때마다 스프린트 백로그를 업데이트할 수 있습니다. 팀은 무엇을 조정할지 결정할 때 합의된 플랜을 다시 참고할 수 있습니다.

스프린트 계획에 관한 자주 묻는 질문

스프린트 계획과 릴리스 계획의 차이점은 무엇인가요?

스프린트 계획 회의는 팀이 한 스프린트 동안 달성하고자 하는 목표와 그 작업을 어떻게 전달할지에 초점을 맞춥니다. 릴리스 계획은 더 긴 기간을 고려하며, 예를 들어 어떤 기능이 여러 스프린트에 걸쳐 제공될 수 있는지, 사용자가 언제 해당 기능을 이용할 수 있을지 등을 검토합니다. 릴리스 예측은 팀이 자세히 알아봄에 따라 변경될 수 있는 반면, 각 스프린트 목표는 해당 스프린트 내의 작업을 안내하는 역할을 합니다.

스프린트 계획 수립을 위해 ‘준비 기준(Definition of Ready)’이 필요하신가요?

아닙니다. 스크럼에서는 공식적인 ‘준비 완료 기준(Definition of Ready)’을 반드시 요구하지 않습니다. 일부 팀은 백로그 항목을 선택하기 전에 명확한 요구사항, 관리 가능한 범위, 알려진 의존성 등 공통된 기대치를 설정하기 위해 이를 활용하기도 합니다. 이러한 기준은 팀이 필요할 때 항목을 구체화하는 데 방해가 되지 않으면서도 토론을 뒷받침할 수 있을 정도로 가볍게 유지해야 합니다.

스프린트 플랜 수립 후 스프린트를 취소할 수 있나요?

네. 제품 소유자만이 스프린트를 취소할 수 있으며, 비즈니스 우선순위나 시장 조건이 크게 변해 스프린트 목표가 더 이상 유효하지 않게 된 경우 취소가 가능합니다. 어려운 작업이나 부정확한 추정치만으로는 반드시 취소를 정당화할 수 있는 것은 아닙니다.

스프린트와 애자일의 차이점은 무엇인가요?

애자일은 ‘애자일 선언문’의 가치와 원칙에 기반한, 업무 관리를 위한 포괄적인 접근 방식입니다. 스프린트는 스크럼 프레임워크 내에서 1개월 이하의 고정된 기간을 의미하며, 이 기간 동안 팀은 스프린트 목표를 달성하고 사용 가능한 증분(increment)을 생성합니다. 스프린트를 사용하지 않고도 애자일 원칙을 따를 수 있습니다. 예를 들어, 칸반(Kanban)은 고정된 기간의 반복 주기를 요구하지 않으면서도 업무의 지속적인 흐름을 지원합니다.

하나의 스프린트에 여러 개의 스프린트 목표가 있을 수 있나요?

스크럼에서는 하나의 스프린트 목표를 스프린트의 유일한 목표로 정의합니다. 해당 목표를 위태롭게 하지 않는 한, 다른 우선순위를 지원하는 백로그 항목을 선택할 수 있습니다. 팀에서 정기적으로 서로 관련 없는 여러 목표가 필요한 경우, 해당 작업이 더 광범위한 공동의 결과를 지원하는지, 아니면 계획 수립 전에 상충되는 우선순위를 해결해야 하는지 논의하십시오.

스프린트 계획 회의에서 버그를 스토리 포인트로 추정해야 할까요?

스크럼에서는 스토리 포인트가 선택 사항이며, 버그의 경우도 마찬가지입니다. 버그에 대한 추정치를 산출하는 팀은 언제, 왜 그렇게 할지에 대해 합의해야 합니다. 알려진 결함은 계획 단계에서 평가할 수 있지만, 개발 과정에서 발견된 버그는 ‘완료 기준(Definition of Done)’을 충족하기 위해 이미 필요한 작업 범위에 포함될 수 있습니다. 동일한 노력을 두 번 계산하는 일은 피하십시오.