스크럼 가이드의 목적

• 스크럼 가이드는 스크럼의 정의를 담고 있습니다. 스크럼 프레임워크의 각 요소는 스크럼으로 실현하려는 전체적인 가치와 결과에 필수적인 특정한 목적을 이루기 위해 설계된 것입니다. 스크럼의 핵심 설계나 아이디어를 변경하거나, 요소를 누락하거나, 스크럼 규칙을 따르지 않으면 문제점을 파악할 수 없고 스크럼의 이점이 제한되며, 심지어 스크럼이 무용지물이 될 수도 있습니다.
• 스크럼을 사용하다 보면 스크럼에 부합하는 패턴, 프로세스, 인사이트를 발견하고 적용하고 고안할 수 있습니다. 그런 부분은 스크럼 가이드를 벗어나므로 대해서는 이 가이드에서 다루지 않습니다.

스크럼 정의

• 스크럼이란 어려운 문제를 적응형 해결책을 통해 가치를 만드는 사람, 팀, 조직을 돕는 경량 프레임워크입니다.

• 간단히 말해, 스크럼은 스크럼 마스터가 다음과 같은 환경을 조성하도록 합니다.

  1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 작업들을 우선순위에 따라 프로덕트 백로그에 정렬합니다.
  2. 스크럼 팀은 스프린트 동안 백로그에서 선별된 작업들을 가치의 증가로 만들어 냅니다.
  3. 스크럼 팀과 이해관계자들은 결과를 점검하고 다음 스프린트를 위해 조정합니다.
  4. 위 과정을 반복합니다.

• 스크럼은 단순합니다. 제시한대로 사용해보고 목표 달성과 가치 창출에 도움이 되는지 판단하시기 바랍니다. 스크럼 프레임워크는 의도적으로 불완전하게 설계되었으며, 스크럼 이론을 구현하는데 필요한 부분만 정의하고 있습니다. 스크럼은 스크럼을 사용하는 사람들의 집단지성을 기반으로 만들어졌습니다. 스크럼 규칙은 상세한 지침을 제공하기보단, 사람들의 관계와 상호작용을 가이드합니다.

스크럼 이론

• 스크럼은 경험주의와 린 사고에 기반을 두고 있습니다. 경험주의는 지식이 경험에서 비롯되며 관찰을 바탕으로 의사결정을 내린다고 가정합니다. 린 사고는 낭비를 줄이고 핵심에 집중합니다.
• 스크럼은 반복적이고 점진적인 접근 방식을 통해 예측 가능성을 최적화하고 위험을 관리합니다. 스크럼은 작업을 하기 위한 모든 기술과 전문성을 가진 (혹은 필요할 경우 기술을 공유하거나 새로 습득하는) 사람들이 어우러지게 합니다.
• 스크럼은 3가지 핵심 원칙이 있습니다.
  • 투명성
    • 새롭게 형성되는 프로세스와 작업은 작업을 수행하는 사람과 결과물을 받는 사람 모두에게 투명하게 공개되어야 합니다. 스크럼에서 중요한 결정들은 세 가지 공식적인 아티팩트의 이해한 상태를 기반으로 합니다. 투명성이 낮은 아티팩트는 가치를 떨어뜨리고 리스크를 높이는 결정을 하게 만들 수 있습니다.
    • 투명성은 점검을 가능하게 합니다. 투명성 없이 진행하는 점검은 오해를 낳을 것이고 시간낭비일 것입니다.
  • 점검
    • 스크럼 아티팩트와 합의된 목표 달성을 위한 진행 상황은 잠재적인 편차나 문제점을 발견하기 위해 빈번하고 꼼꼼하게 점검해야 합니다.
    • 점검은 적응을 가능하게 합니다. 적응이 없는 점검은 무의미합니다. 스크럼 이벤트들은 (점검을 통한) 변화를 일으키도록 설계되었습니다.
  • 적응
    • 만약 프로세스의 어떤 부분이라도 허용 범위를 벗어나거나 결과물이 만족스럽지 못한 경우, 적용되는 프로세스나 생산되는 것들을 조정해야 합니다. 추가적으로 더 생길 편차를 최소화하기 위해 가능한 한 빨리 조정해야 합니다.
    • 관계자들이 권한이 없거나 자율적으로 관리하지 못하는 경우 적응은 더욱 어려워집니다. 스크럼 팀은 점검을 통해 새로운 사실을 알게 되는 즉시 적응해야 합니다.

스크럼 가치

• 스크럼을 성공적으로 활용하려면 구성원들이 다음 다섯 가지 가치를 더욱 능숙하게 실천해야 합니다.
  • 약속
    • 스크럼 팀은 목표 달성과 서로를 지원하는 것을 약속해야 합니다.
  • 집중
    • 팀의 최우선 목표는 스프린트 작업에 집중하여 목표 달성을 위해 최선을 다하는 것입니다.
  • 개방
    • 스크럼 팀과 이해관계자들은 작업 내용과 어려움에 대해 개방적이어야 합니다.
  • 존중
    • 스크럼 팀 구성원들은 서로를 유능하고 독립적인 사람으로 존중하며, 함께 일하는 사람들로부터도 존중받습니다.
  • 용기
    • 스크럼 팀 구성원들은 올바른 일을 하고 어려운 문제를 해결할 용기를 가지고 있습니다.
• 이러한 가치들은 스크럼 팀의 작업, 행동, 태도에 대한 방향을 제시합니다.
• 스크럼 팀 구성원들은 스크럼 이벤트와 스크럼 아티팩트를 활용하면서 이러한 가치들을 배우고 탐구합니다.
• 스크럼 팀과 그들이 함께 일하는 사람들이 이러한 가치들을 구체화할 때, 투명성, 점검, 적응이라는 스크럼의 경험적 핵심 원칙들이 현실로 구현되어 신뢰를 구축하게 됩니다.

스크럼 팀

• 스크럼 조직의 기본이 되는 단위인 스크럼 팀은 적은 수의 인원으로 구성됩니다. 스크럼 팀은 스크럼 마스터 1명, 프로덕트 오너 1명, 그리고 개발자들로 구성됩니다. 스크럼 팀 내에는 하위 팀이나 위계질서가 없습니다.
• 스크럼 팀은 다양한 기능을 갖춘 팀으로, 구성원들은 매 스프린트마다 가치를 창출하는 데 필요한 모든 기술을 보유하고 있다는 의미입니다. 또한, 팀 내부적으로 누가 무엇을, 언제, 어떻게 할지 결정하는 자율 관리 시스템을 갖추고 있습니다.
• 스크럼 팀은 민첩성을 유지하면서도 스프린트 내에 의미 있는 작업을 완료할 수 있을 만큼 충분히 큰 규모(일반적으로 10명 이하)로 구성됩니다. 만약 스크럼 팀이 너무 커지면, 같은 프로덕트에 집중하는 여러 개의 작은 팀으로 나누는 것을 고려해볼 수 있습니다. (만약 팀을 나누더라도) 각 팀은 같은 프로덕트 목표, 프로덕트 백로그, 그리고 프로덕트 오너를 공유해야 합니다.
• 스크럼 팀 전체는 매 스프린트마다 가치 있고 유용한 증가를 만들어낼 책임이 있습니다.
• 스크럼은 아래 세 가지 구체적인 역할을 정의합니다.

개발자들 (Developers)

• 개발자는 매 스프린트마다 사용 가능한 증가의 측면을 만들기 위해 전념하는 사람들입니다.
• 개발자에게 필요한 구체적인 기술은 광범위하며 업무 영역에 따라 달라집니다. 그러나 개발자는 항상 다음과 같은 책임을 져야 합니다.
  • 스프린트 계획 및 스프린트 백로그 작성
  • 완료 기준 준수를 통한 퀄리티 관리
  • 스프린트 목표 달성을 위한 일일 계획 조정
  • 전문가로서 서로가 서로의 책임을 다 하도록 하는 것

프로덕트 오너 (Product Owner)

• 프로덕트 오너는 스크럼 팀의 작업 결과물인 프로덕트의 가치를 극대화할 책임이 있습니다. 이를 달성하는 방법은 조직, 스크럼 팀, 그리고 개인에 따라 매우 다양할 수 있습니다.
• 프로덕트 오너는 또한 효과적인 프로덕트 백로그 관리에 대한 책임이 있으며, 여기에는 다음이 포함됩니다.
  • 프로덕트 목표 디벨롭 및 명확한 전달
  • 프로덕트 백로그 항목 생성 및 명확한 전달
  • 프로덕트 백로그 항목 우선순위 지정
  • 프로덕트 백로그가 투명하고 가시적이고 이해되도록 보장하는 것
• 프로덕트 오너는 위 업무를 직접 수행하거나 다른 사람에게 책임을 위임할 수 있습니다. 하지만 어떤 경우든 프로덕트 오너에게 최종 책임은 남아있습니다.
• 프로덕트 오너가 성공하려면 전체 조직이 반드시 프로덕트 오너의 결정들을 존중해야 합니다. 이러한 결정은 프로덕트 백로그의 내용과 순서, 그리고 스프린트 리뷰에서 점검 가능한 증가를 통해 나타납니다.
• 프로덕트 오너는 단체가 아닌 한 사람입니다. 프로덕트 오너는 프로덕트 백로그에서 여러 이해관계자의 요구사항을 대변할 수 있습니다. 프로덕트 백로그를 변경하고자 하는 사람은 프로덕트 오너를 설득해 변경할 수 있습니다.

스크럼 마스터 (Scrum Master)

• 스크럼 마스터는 스크럼 가이드에 정의된 대로 스크럼을 정착시킬 책임이 있습니다. 스크럼 팀과 조직 전체가 스크럼 이론과 실무를 이해하도록 도와줌으로써 이를 수행합니다.
• 스크럼 마스터는 스크럼 팀의 효과를 책임집니다. 스크럼 프레임워크 내에서 스크럼 팀이 실무를 개선할 수 있도록 지원함으로써 이를 수행합니다.
• 스크럼 마스터는 다음과 같은 다양한 방식으로 스크럼 팀을 지원합니다.
  • 팀원들의 자기 관리 및 협업 능력 향상을 위한 코칭
  • 스크럼 팀이 완료 기준을 충족하는 고가치 증가들을 만드는 것에 집중하도록 돕기
  • 스크럼 팀의 진행을 방해하는 방해들을 제거
  • 모든 스크럼 이벤트가 제자리에, 긍정적이고, 생산적이고, 시간을 지키도록 보장
• 스크럼 마스터는 다음과 같은 다양한 방식으로 프로덕트 오너를 지원합니다.
  • 효과적인 프로덕트 목표 정의와 프로덕트 백로그 관리를 위한 테크닉을 찾는 것을 돕기
  • 스크럼 팀이 명확하고 간결한 프로덕트 백로그 항목의 필요성을 이해하도록 돕기
  • 복잡한 환경에서 경험 기반의 프로덕트 계획을 수립하도록 돕기
  • 요청이나 필요에 따라 이해관계자들의 협업을 촉진
• 스크럼 마스터는 다음과 같은 여러 방식으로 조직에 기여합니다.
  • 조직에 스크럼 적용을 주도하고, 훈련시키고, 코치합니다.
  • 조직에 스크럼 이행을 계획하고 가이드합니다.
  • 조직원들과 이해관계자들이 복잡한 업무에 대한 경험 기반의 접근 방식을 이해하고 실행하도록 돕습니다.
  • 이해관계자와 스크럼 팀 간의 방해물들을 제거합니다.

스크럼 이벤트

• 스프린트는 다른 모든 이벤트를 담는 컨테이너입니다. 스크럼의 각 이벤트는 스크럼 아티팩트를 점검하고 수정할 수 있는 공식적인 기회입니다. 스크럼에서 이벤트는 규칙성을 확보하고 스크럼에서 정의되지 않은 회의의 필요성을 최소화하는 데 사용됩니다.

스프린트

• 스프린트는 아이디어가 가치로 전환되는 스크럼의 핵심입니다.
• 스프린트는 일관성을 유지하기 위해 한 달 혹은 그보다 적은 정해진 기간으로 진행됩니다. 새로운 스프린트는 이전 스프린트가 종료된 직후에 시작됩니다.
• 스프린트 계획 회의, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하는 데 필요한 모든 작업은 스프린트 기간 동안 이루어집니다.
• 스프린트 동안
  • 스프린트 목표를 위태롭게 할 수 있는 변경은 하지 않습니다.
  • 퀄리티를 저하시키지 않습니다.
  • 프로덕트 백로그는 필요에 따라 정제될 수 있습니다.
  • 스프린트 범위는 새로운 것을 더 배우면서 프로덕트 오너와 협의하여 명확히 하거나 재협상할 수 있습니다.
• 스프린트는 적어도 매달 프로덕트 목표 달성 진행 상황을 조정함으로써 예측 가능성을 높여줍니다. 스프린트 기간이 너무 길면 스프린트 목표가 무효화되거나, 복잡성이 증가하거나, 위험이 커질 수 있습니다. 더 짧은 스프린트를 활용하면 학습 주기를 늘리고 비용과 노력에 대한 위험을 더 짧은 기간으로 제한할 수 있습니다. 각 스프린트는 짧은 프로젝트로 여겨질 수 있습니다.
• 스프린트 목표가 더 이상 유효하지 않게 되면 스프린트를 취소할 수 있습니다. 스프린트 취소 권한은 프로덕트 오너에게만 있습니다.

스프린트 계획

• 스프린트 계획은 스프린트 기간 동안 수행할 작업을 명확히 정의하는 것으로 스프린트를 시작합니다. 이 계획은 전체 스크럼 팀이 참여하여 만들어집니다.
• 프로덕트 오너는 참여자들이 프로덕트 백로그의 가장 중요한 항목과 프로덕트 목표를 어떻게 연관시킬지 논의하도록 준비시킵니다. 스크럼 팀은 조언을 받기 위해 다른 사람들을 스프린트 계획에 초대할 수도 있습니다.
• 스프린트 계획에서는 다음 주제들을 다룹니다.
  1. Why - 왜 이번 스프린트가 가치있는가?
     • 프로덕트 오너는 이번 스프린트에서 프로덕트의 가치와 효용을 어떻게 높일 수 있을지 제안합니다. 그러면 전체 스크럼 팀은 스프린트 목표를 정의하기 위해 협력합니다. 스프린트 목표는 스프린트 계획이 끝나기 전에 확정되어야 합니다.
  2. What - 이번 스프린트에서 무엇이 완료되어야 하는가?
     • 프로덕트 오너와 논의를 통해 개발자들은 프로덕트 백로그에서 이번 스프린트에 포함할 항목들을 선택합니다. 스크럼 팀은 이 과정에서 항목을 구체화할 수 있으며, 이는 이해도와 확신을 높이는 데 도움이 됩니다.
     • 스프린트 내에 완료할 수 있는 작업량을 정하는 것은 어려울 수 있습니다. 하지만 개발자들이 과거 성과, 향후 역량, 그리고 완료 기준에 대해 더 잘 알수록 스프린트 예측에 대한 확신을 가질 수 있습니다.
  3. How - 어떻게 선택된 작업들을 수행할 것인가?
     • 각각의 선택된 프로덕트 백로그 항목에 대해, 개발자들은 완료 기준을 충족하는 증가를 만들기 위해 필요한 작업을 계획합니다. 이는 일반적으로 프로덕트 백로그 항목을 하루 이내의 더 작은 작업 항목으로 분해하는 방식으로 이루어집니다. 이것은 전적으로 개발자들의 재량에 달려 있습니다. 다른 누구도 프로덕트 백로그 항목을 가치 있는 증가로 바꾸는 방법을 지시하지 않습니다.
     • 스프린트 목표, 스프린트에 선택된 프로덕트 백로그 항목, 그리고 이러한 항목을 제공하기 위한 계획을 통틀어 스프린트 백로그라고 합니다.
     • 스프린트 계획은 한 달 스프린트의 경우 최대 8시간으로 제한합니다. 스프린트 기간이 짧을수록 더 짧아집니다.

데일리 스크럼

• 데일리 스크럼의 목적은 스프린트 목표 달성 진행 상황을 점검하고 필요에 따라 스프린트 백로그를 수정하여 다음 날 작업 계획을 조정하는 것입니다.
• 데일리 스크럼은 스크럼 팀의 개발자들이 참여하는 15분간의 회의입니다. 프로덕트 오너 또는 스크럼 마스터가 스프린트 백로그 항목을 적극적으로 작업하고 있는 경우, 개발자 자격으로 참여합니다.
• 데일리 스크럼에서 중요한 것은 스프린트 목표 달성 진행 상황에 집중하고 다음 날 작업에 대한 실행 가능한 계획을 수립하는 것입니다. 이는 집중력을 높이고 자기 관리 능력을 향상시킵니다.
• 데일리 스크럼은 의사소통을 개선하고, 방해물을 파악하며, 신속한 의사결정을 촉진하여 결과적으로 추가 회의의 필요성을 줄여줍니다.
• 데일리 스크럼은 개발자들이 계획을 조정할 수 있는 유일한 시간은 아닙니다. 그들은 스프린트의 나머지 작업을 조정하거나 재계획하는 것에 대한 더 자세한 논의를 위해 하루 종일 자주 만납니다.

스프린트 리뷰

• 스프린트 리뷰의 목적은 스프린트의 결과를 점검하고 향후 개선 사항을 결정하는 것입니다. 스크럼 팀은 주요 이해관계자에게 작업 결과를 발표하고 프로덕트 목표 달성 진행 상황을 논의합니다.
• 스프린트 리뷰에서 스크럼 팀과 이해관계자들은 스프린트 기간 동안 달성한 내용과 환경 변화를 리뷰합니다. 이러한 정보를 바탕으로 참석자들은 향후 작업에 대해 협력합니다. 새로운 기회를 반영하여 프로덕트 백로그를 조정할 수도 있습니다. 스프린트 리뷰는 실무 중심의 회의이므로 단순히 발표만 하는 것이 아니라 실질적인 논의가 이루어져야 합니다.
• 스프린트 리뷰는 스프린트의 마지막에서 두 번째 이벤트이며, 한 달 스프린트의 경우 최대 4시간으로 제한됩니다.

스프린트 회고

• 스프린트 회고의 목적은 퀄리티와 효율성을 향상시킬 방법을 계획하는 것입니다.
• 스크럼 팀은 지난 스프린트의 진행 상황을 개인, 상호 작용, 프로세스, 도구 및 완료 기준 측면에서 점검합니다. 점검 요소는 작업 영역에 따라 다를 수 있습니다. 잘못된 방향으로 이끌었던 가정들을 파악하고 그 원인을 분석합니다. 스크럼 팀은 스프린트 동안 잘 진행된 부분, 발생한 문제, 그리고 그 문제들을 어떻게 해결했는지(또는 해결하지 못했는지)에 대해 논의합니다.
• 스크럼 팀은 효율성을 향상시키는 데 가장 도움이 될 만한 변경 사항들을 파악합니다. 가장 영향력 있는 개선 사항은 가능한 한 빨리 실행되며, 다음 스프린트의 백로그에 추가될 수도 있습니다.
• 스프린트 회고는 스프린트의 마무리 단계입니다. 한 달 스프린트의 경우 최대 3시간으로 시간 제한이 있습니다.

스크럼 아티팩트

• 스크럼 아티팩트는 작업 또는 가치를 나타냅니다. 스크럼 아티팩트는 핵심 정보의 투명성을 극대화하도록 설계되었습니다. 따라서 스크럼 아티팩트를 점검하는 모든 사람은 동일한 기준으로 결과를 해석할 수 있습니다.
• 각 아티팩트는 투명성을 높이고 진행 상황을 측정할 수 있는 기준이 되는 정보를 제공한다는 약속이 포함되어 있습니다.
  • 프로덕트 백로그의 경우 프로덕트 목표가 약속입니다.
  • 스프린트 백로그의 경우 스프린트 목표가 약속입니다.
  • 증가의 경우 완료 기준이 약속입니다.
• 이 약속들은 스크럼 팀과 이해관계자들에 경험주의와 스크럼 가치를 강화하기 위해 존재합니다.

프로덕트 백로그

• 프로덕트 백로그는 프로덕트 개선에 필요한 작업들을 순서대로 나열한 목록입니다. 프로덕트 백로그는 스크럼 팀이 수행할 작업의 기준이 되는 유일한 원천입니다.
• 스크럼 팀이 한 스프린트 내에 완료할 수 있는 프로덕트 백로그 항목들은 스프린트 계획 회의에서 선택 대상으로 고려됩니다. 일반적으로 프로덕트 백로그 정제 작업을 통해 이러한 투명성을 확보합니다. 프로덕트 백로그 정제는 프로덕트 백로그 항목을 더 작고 구체적인 항목으로 세분화하고 정의하는 과정입니다. 이는 설명, 순서, 크기 등의 세부 정보를 추가하는 지속적인 활동입니다. 속성은 작업 영역에 따라 달라지는 경우가 많습니다.
• 작업을 수행할 개발자는 작업의 크기를 결정할 책임이 있습니다. 프로덕트 오너는 개발자들이 절충안을 이해하고 선택하도록 지원함으로써 영향을 줄 수 있습니다.

약속: 프로덕트 목표

• 프로덕트 목표는 스크럼 팀이 계획을 수립하는 기준이 되는 프로덕트의 미래 상태를 설명합니다. 프로덕트 목표는 프로덕트 백로그에 포함됩니다. 프로덕트 백로그의 나머지 부분은 프로덕트 목표를 달성하는 데 필요한 "무엇"을 정의하기 위해 구성됩니다.

프로덕트는 가치를 제공하는 수단입니다. 프로덕트는 명확한 경계, 알려진 이해관계자, 잘 정의된 사용자 또는 고객을 가지고 있습니다. 프로덕트는 서비스이거나 물리적 프로덕트, 혹은 더 추상적인 개념일 수 있습니다.

프로덕트 목표는 스크럼 팀의 장기적인 목표입니다. 팀은 다음 목표를 수행하기 전에 하나의 목표를 달성하거나 포기해야 합니다.

스프린트 백로그

• 스프린트 백로그는 스프린트 목표(why), 스프린트에서 수행할 프로덕트 백로그 항목(what), 그리고 증가를 제공하기 위한 실행 가능한 계획(how)로 구성됩니다.
• 스프린트 백로그는 개발자들이 직접 작성하고 활용하는 계획입니다. 스프린트 목표 달성을 위해 개발자들이 스프린트 기간 동안 수행할 작업을 실시간으로 명확하게 보여주는 도구입니다. 따라서 스프린트 백로그는 스프린트 진행 과정에서 새로운 정보가 추가될 때마다 지속적으로 업데이트됩니다. 개발자들은 데일리 스크럼에서 진행 상황을 점검할 수 있도록 충분한 세부 정보를 포함해야 합니다.

약속: 스프린트 목표

• 스프린트 목표는 스프린트의 유일한 목표입니다. 스프린트 목표는 개발자들의 약속이지만, 목표 달성에 필요한 구체적인 작업 내용에는 유연성을 제공합니다. 또한 스프린트 목표는 스크럼 팀 구성원들이 각자 다른 목표를 추구하는 것이 아니라 협력하여 작업하도록 유도하고, 팀의 일관성과 집중력을 높여줍니다.
• 스프린트 목표는 스프린트 계획 회의에서 수립되어 스프린트 백로그에 추가됩니다. 개발자들은 스프린트 기간 동안 작업을 진행하면서 스프린트 목표를 염두에 둡니다. 만약 작업 내용이 예상과 다르게 진행될 경우, 개발자들은 프로덕트 오너와 협력하여 스프린트 목표에 영향을 주지 않고 스프린트 백로그의 범위를 스프린트 기간 내에 조정합니다.

증가

• 증가는 프로덕트 목표를 향한 구체적인 디딤돌입니다. 각 증가는 이전의 모든 증가에 더해지며, 철저한 검증을 거쳐 모든 증가가 서로 연동되도록 합니다. 가치를 제공하기 위해서는 증가가 사용 가능해야 합니다.
• 한 스프린트 내에서 여러 개의 증가가 생성될 수 있습니다. 모든 증가의 총합은 스프린트 리뷰에서 발표되어 경험적 검증을 지원합니다. 하지만 증가는 스프린트 종료 전에 이해관계자들에게 제공될 수도 있습니다. 스프린트 리뷰는 가치 출시를 막는 관문으로 여겨져서는 안 됩니다.
• 작업은 완료 기준을 충족하지 않으면 증가의 일부로 간주될 수 없습니다.

약속: 완료 기준

• 완료 기준은 프로덕트에 필요한 퀄리티 기준을 충족했을 때 증가의 상태를 공식적으로 기술한 것입니다.
• 프로덕트 백로그 항목이 완료 기준을 충족하는 순간, 증가가 탄생합니다.
• 완료 기준은 모든 구성원에게 증가의 일부로 완료된 작업에 대한 공통된 이해를 제공함으로써 투명성을 확보합니다. 프로덕트 백로그 항목이 완료 기준을 충족하지 못하면 릴리스하거나 스프린트 리뷰에서 발표할 수 없습니다. 대신, 향후 고려할 수 있게 하기 위해 프로덕트 백로그로 돌려보냅니다.
• 증가에 대한 완료 기준이 조직 표준의 일부인 경우, 모든 스크럼 팀은 최소한 해당 표준을 준수해야 합니다. 조직 표준이 아닌 경우, 스크럼 팀은 해당 프로덕트에 적합한 완료 기준을 자체적으로 수립해야 합니다.
• 개발자는 완료 기준을 준수해야 합니다. 여러 스크럼 팀이 하나의 프로덕트를 공동으로 개발하는 경우, 모든 팀은 동일한 완료 기준을 상호 합의하고 준수해야 합니다.

맺음말

• 스크럼은 무료이며 이 가이드에서 제공됩니다. 여기에 설명된 스크럼 프레임워크는 변경될 수 없습니다. 스크럼의 일부만 구현하는 것도 가능하지만, 그 결과는 스크럼이 아닙니다. 스크럼은 전체로서만 존재하며, 다른 기술·방법론·실천들을 담는 컨테이너로서 제대로 기능합니다.

이 문서의 원본 라이센스는 아래와 같습니다.

© 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

따라서, 번역본인 이 문서도 원본 문서의 라이센스와 동일한 CC BY-SA 4.0 라이선스로 배포합니다.