The Definitive Guide to Scrum: The Rules of the Game

공모전 제안서를 냈다.

제안서 결과 발표날까지 무엇을 해야 하는지에 대해서 정리하고 있다.

 

프로젝트 계획 단계에서 효과적인 프로젝트 관리 방법에 대해 고민하다가, 현재 우리 팀의 상황을 정리해보았다.

1. 소규모 팀

2. 요구사항이 안정적이지 않음

3. 프로젝트 기간 동안 비대면으로 진행되기 때문에 효율적인 커뮤니케이션이 필요

 

이에 가장 부합하는 방법론으로 정보처리기사에서 자주 출제되는(..) 스크럼이 문득 떠올랐다.

다시 찾아보니 우리 팀에게 필요한 방법론이라고 생각되어 스크럼의 공식 문서를 읽고 내용을 정리해보았다.

 

---

Index

1. 스크럼 정의 Scrum Definition

2. 스크럼 이론 Scrum Theory

3. 스크럼 가치 Scrum Values

4. 스크럼 팀 Scrum Team

5. 스크럼 이벤트 Scrum Events

6. 스크럼 산출물 Scrum Artifacts

---

1. 스크럼 정의 Scrum Definition

스크럼은 사람, 팀, 그리고 조직이 복잡한 문제에 대한 적응형 해결방안 Adaptive solutions 을 통해 가치를 창출할 수 있도록 돕는 경량 프레임워크입니다.
간단히 말해, 스크럼은 다음과 같은 환경을 조성하기 위해 스크럼 마스터를 필요로 합니다.

1. 제품 책임자(PO)는 복잡한 문제에 대한 작업을 프로덕트 백로그에 정리합니다.
2. 스크럼 팀은 스프린트 동안 작업의 일부를 인크리먼트(Increment)로 전환합니다.
3. 스크럼 팀과 이해관계자는 결과를 검토하고 다음 스프린트에 맞춰 조정합니다.
4. 반복

스크럼은 간단합니다. 있는 그대로 시도해 보고 스크럼의 철학, 이론, 그리고 구조가 목표 달성과 가치 창출에 도움이 되는지 확인합니다. 스크럼 프레임워크는 의도적으로 불완전하며, 스크럼 이론을 구현하는 데 필요한 부분만 정의합니다. 스크럼은 사용하는 사람들의 집단 지성을 기반으로 구축됩니다. 스크럼의 규칙은 사람들에게 자세한 지침을 제공하는 대신, 그들의 관계와 상호작용을 안내합니다. 프레임워크 내에서 다양한 프로세스, 기술, 그리고 방법을 사용할 수 있습니다. 스크럼은 기존 관행을 포괄하거나 불필요하게 만듭니다. 스크럼은 현재 관리, 환경, 그리고 작업 기법의 상대적인 효과를 가시화하여 개선이 가능하도록 합니다.

 

2. 스크럼 이론 Scrum Theory

스크럼은 경험주의와 린 Lean 사고방식에 기반을 두고 있습니다. 경험주의는 지식이 경험과 관찰에 기반한 의사 결정에서 비롯된다고 이야기합니다. 린 사고방식은 낭비를 줄이고 핵심에 집중합니다. 스크럼은 예측 가능성을 최적화하고 위험을 제어하기 위해 반복적이고 점진적인 접근 방식을 사용합니다.

스크럼은 작업을 수행하는 데 필요한 모든 기술과 전문 지식을 갖춘 사람들로 구성된 그룹을 참여시키고, 필요에 따라 이러한 기술을 공유하거나 습득합니다.
스크럼은 스프린트라는 하나의 이벤트 내에서 검사 및 적응을 위한 네 가지 공식 이벤트를 결합합니다. 이러한 이벤트는 투명성, 검사, 적응이라는 경험적 스크럼의 핵심 원칙을 구현하기 때문에 효과적입니다.

 

투명성 Transparency
새로운 프로세스와 작업은 작업을 수행하는 사람과 받는 사람 모두에게 투명해야 합니다. 스크럼을 사용하면 중요한 의사 결정은 세 가지 공식 산출물의 인식된 상태를 기반으로 합니다. 투명성이 낮은 산출물은 가치를 떨어뜨리고 위험을 증가시키는 의사 결정으로 이어질 수 있습니다. 투명성은 검사를 가능하게 합니다. 투명성 없는 검사는 오해의 소지가 있고 낭비적입니다.

 

점검 Inspection
스크럼 아티팩트와 합의된 목표 달성을 위한 진행 상황은 잠재적으로 바람직하지 않은 변동이나 문제를 감지하기 위해 자주 그리고 부지런히 검사해야 합니다. 검사를 돕기 위해 스크럼은 5가지 이벤트 형태로 주기를 제공합니다.
점검는 적응을 가능하게 합니다. 적응 없는 검사는 무의미한 것으로 간주됩니다. 스크럼 이벤트는 변화를 유도하도록 설계되었습니다.

적응 Adaption
프로세스의 어떤 측면이라도 허용 가능한 한계를 벗어나거나 결과물이 수용할 수 없는 경우, 적용되는 프로세스 또는 생산되는 자료를 조정해야 합니다. 조정은 추가적인 편차를 최소화하기 위해 가능한 한 빨리 이루어져야 합니다.

관련자들에게 권한이 부여되지 않았거나 자체 관리가 이루어지지 않으면 적응이 더욱 어려워집니다. 스크럼 팀은 검사를 통해 새로운 것을 배우는 순간 적응해야 합니다.

 

3. 스크럼 가치 Scrum Values

스크럼을 성공적으로 활용하려면 사람들이 다음 다섯 가지 가치를 더욱 능숙하게 실천하는 데 달려 있습니다.

헌신 Commitment, 집중 Focus, 개방성 Openness, 존중 Respect, 용기 Courage

 

스크럼 팀은 목표 달성과 상호 지원에 전념합니다. 스크럼 팀의 주요 목표는 스프린트에서 목표를 향해 최선의 진전을 이루는 것입니다. 스크럼 팀과 이해관계자는 작업과 과제에 대해 개방적인 마음으로 소통합니다. 스크럼 팀원들은 서로를 존중하며, 유능하고 독립적인 사람으로 함께 일하는 사람들로부터 존중받습니다. 스크럼 팀원들은 옳은 일을 하고 어려운 문제를 해결할 용기를 가지고 있습니다. 이러한 가치는 스크럼 팀의 업무, 행동, 그리고 태도에 대한 방향을 제시합니다. 스크럼 팀의 의사 결정, 단계, 그리고 스크럼 활용 방식은 이러한 가치를 강화해야 하며, 약화시키거나 훼손해서는 안됩니다. 스크럼 팀원들은 스크럼 이벤트와 아티팩트를 다루면서 이러한 가치를 배우고 탐구합니다. 스크럼 팀과 함께 일하는 사람들이 이러한 가치를 구체화할 때, 투명성, 검사, 적응이라는 스크럼의 경험적 핵심 원칙들이 현실화되어 신뢰를 구축합니다.

 

4. 스크럼 팀 Scrum Team

스크럼의 기본 단위는 소규모 팀, 즉 스크럼 팀입니다. 스크럼 팀은 한 명의 스크럼 마스터 Scrum Master, 한 명의 제품 책임자 Product Owner, 그리고 개발자 Developer로 구성됩니다. 스크럼 팀 내에는 하위 팀이나 계층 구조가 없습니다. 스크럼 팀은 한 번에 하나의 목표, 즉 제품 목표에 집중하는 전문가들로 구성된 응집력 있는 단위입니다.

스크럼 팀은 교차 기능적(cross-functional)입니다. 즉, 팀원들은 각 스프린트마다 가치를 창출하는 데 필요한 모든 기술을 보유하고 있습니다. 또한 자체 관리(self-managing)가 가능하므로 누가, 언제, 어떻게 할지 내부적으로 결정합니다.

스크럼 팀은 민첩성을 유지할 수 있을 만큼 작지만, 스프린트 내에서 상당한 작업을 완료할 수 있을 만큼 큰 규모이며, 일반적으로 10명 이하로 구성됩니다. 일반적으로 소규모 팀은 의사소통이 더 잘되고 생산성이 더 높다는 것을 발견했습니다. 스크럼 팀의 규모가 너무 커지면, 동일한 제품에 집중하는 여러 개의 응집력 있는 스크럼 팀으로 다시 구성하는 것을 고려해야 합니다. 따라서 각 팀은 동일한 제품 목표, 프로덕트 백로그, 제품 책임자를 공유해야 합니다.

스크럼 팀은 이해관계자 협업, 검증, 유지 관리, 운영, 실험, 연구 개발 등 제품 관련 모든 활동을 담당합니다. 조직은 스크럼 팀을 체계적으로 관리하고 권한을 부여하여 업무를 관리합니다. 지속 가능한 속도로 스프린트에 참여하면 스크럼 팀의 집중력과 일관성이 향상됩니다.

전체 스크럼 팀은 매 스프린트마다 가치 있고 유용한 인크리먼트(Increment)를 만들어야 할 책임이 있습니다. 스크럼은 스크럼 팀 내에 개발자, 제품 책임자, 그리고 스크럼 마스터라는 세 가지 구체적인 책임을 정의합니다.

 

개발자 Developer
개발자는 스크럼 팀에서 각 스프린트에서 사용 가능한 인크리먼트의 모든 측면을 만드는 데 전념하는 사람들입니다. 개발자에게 필요한 구체적인 기술은 종종 광범위하며 작업 영역에 따라 달라집니다. 하지만 개발자는 항상 다음 사항에 대한 책임을 집니다.

• 스프린트 계획(스프린트 백로그) 작성
• 완료 정의 준수를 통한 품질 향상
• 스프린트 목표에 맞춰 매일 계획을 조정
• 전문가로서 서로에게 책임감을 부여

제품 소유자 Product Owner; PO
제품 소유자는 스크럼 팀의 작업으로 인해 발생하는 제품의 가치를 극대화할 책임이 있습니다. 이를 수행하는 방식은 조직, 스크럼 팀 및 개인에 따라 매우 다를 수 있습니다. 제품 소유자는 효과적인 제품 백로그 관리에 대한 책임도 집니다. 여기에는 다음이 포함됩니다.

• 제품 목표 개발 및 명시적 전달
• 제품 백로그 항목 생성 및 명확한 전달
• 제품 백로그 항목 정렬
• 제품 백로그의 투명성, 가시성 및 이해도 확보

제품 소유자는 위의 작업을 직접 수행하거나 다른 사람에게 책임을 위임할 수 있습니다. 어떤 경우든 제품 소유자는 책임을 집니다.

제품 소유자가 성공하려면 전체 조직이 그들의 결정을 존중해야 합니다. 이러한 결정은 제품 백로그의 내용 및 순서, 그리고 스프린트 검토 시 검토 가능한 인크리먼트를 통해 확인할 수 있습니다.

제품 소유자는 위원회가 아닌 한 사람입니다. 제품 소유자는 제품 백로그에 있는 여러 이해관계자의 요구를 대변할 수 있습니다. 제품 백로그를 변경하려는 사람들은 제품 소유자를 설득하여 변경할 수 있습니다.

 

스크럼 마스터 Scrum Master; SM
스크럼 마스터는 스크럼 가이드에 정의된 스크럼을 구축할 책임이 있습니다. 스크럼 마스터는 스크럼 팀과 조직 내 모든 구성원이 스크럼 이론과 실무를 이해하도록 지원함으로써 이를 수행합니다.

스크럼 마스터는 스크럼 팀의 효과성에 대한 책임을 집니다. 스크럼 마스터는 스크럼 프레임워크 내에서 스크럼 팀의 실무를 개선할 수 있도록 지원함으로써 이를 수행합니다.

스크럼 마스터는 스크럼 팀과 더 큰 조직을 위해 봉사하는 진정한 리더입니다.

스크럼 마스터는 다음과 같은 여러 가지 방식으로 스크럼 팀에 봉사합니다:

• 팀원들에게 자기 관리 및 교차 기능(Cross-Functionality)에 대한 코칭을 제공합니다.
• 스크럼 팀이 완료 정의(Definition of Done)를 충족하는 고부가가치 증분(Increment)을 만드는 데 집중할 수 있도록 지원합니다.
• 스크럼 팀의 진행을 방해하는 요소를 제거합니다.
• 모든 스크럼 이벤트가 긍정적이고 생산적이며 정해진 시간 내에 완료되도록 보장합니다.

스크럼 마스터는 다음을 포함한 여러 가지 방식으로 제품 책임자(Product Owner)를 지원합니다:

• 효과적인 제품 목표 정의 및 제품 백로그 관리 기법을 찾도록 지원합니다.
• 스크럼 팀이 명확하고 간결한 제품 백로그 항목의 필요성을 이해하도록 지원합니다.
• 복잡한 환경에 대한 경험적 제품 계획 수립을 지원합니다.
• 요청 또는 필요에 따라 이해관계자 협업을 촉진합니다.

스크럼 마스터는 다음을 포함한 여러 가지 방식으로 조직에 기여합니다:

• 조직의 스크럼 도입을 주도, 교육 및 코칭합니다.
• 조직 내 스크럼 구현을 계획하고 자문합니다.
• 직원과 이해관계자가 복잡한 작업에 대한 경험적 접근 방식을 이해하고 실행하도록 지원합니다.
• 이해관계자와 스크럼 팀 간의 장벽을 제거합니다.

 

5. 스크럼 이벤트 Scrum Events

스프린트는 다른 모든 이벤트를 위한 컨테이너입니다. 스크럼의 각 이벤트는 스크럼 산출물을 검토하고 수정할 수 있는 공식적인 기회입니다. 이러한 이벤트는 필요한 투명성을 확보하기 위해 특별히 설계되었습니다. 규정된 대로 이벤트를 운영하지 않으면 검토 및 수정 기회를 잃게 됩니다. 스크럼에서 이벤트는 규칙성을 확보하고 스크럼에 정의되지 않은 회의의 필요성을 최소화하기 위해 사용됩니다. 복잡성을 줄이기 위해 모든 이벤트는 동일한 시간과 장소에서 진행되는 것이 가장 좋습니다.

 

스프린트 Sprint
스프린트는 스크럼의 핵심으로, 아이디어가 가치로 전환되는 과정입니다.
스프린트는 일관성을 유지하기 위해 한 달 이하의 고정 기간으로 진행됩니다. 새로운 스프린트는 이전 스프린트가 종료된 직후
시작됩니다.
스프린트 계획, 데일리 스크럼, 스프린트 검토, 스프린트 회고를 포함하여 제품 목표 달성에 필요한 모든 작업은 스프린트 내에서 진행됩니다.
스프린트 기간 동안:

• 스프린트 목표를 저해할 수 있는 변경은 하지 않습니다.
• 품질이 저하되지 않습니다.
• 필요에 따라 프로덕트 백로그를 개선합니다.
• 더 많은 정보를 습득함에 따라 제품 담당자와 범위를 명확히 하고 재협상할 수 있습니다.

스프린트는 최소 한 달에 한 번씩 제품 목표 달성을 위한 진행 상황을 점검하고 조정함으로써 예측 가능성을 높입니다. 스프린트의 기간이 너무 길면 스프린트 목표가 무효화되고, 복잡성이 증가하며, 위험이 커질 수 있습니다. 짧은 스프린트를 사용하면 학습 주기를 늘리고 비용 및 노력 위험을 더 짧은 기간으로 제한할 수 있습니다. 각 스프린트는 단기 프로젝트로 간주될 수 있습니다.

번다운, 번업, 누적 흐름 등 진행 상황을 예측하는 다양한 방법이 있습니다. 이러한 방법들은 유용성이 입증되었지만, 경험주의의 중요성을 대체할 수는 없습니다. 복잡한 환경에서는 앞으로 무슨 일이 일어날지 알 수 없습니다. 이미 발생한 일만 미래 지향적인 의사 결정에 활용할 수 있습니다.

스프린트 목표가 더 이상 유효하지 않게 되면 스프린트가 취소될 수 있습니다. 제품 담당자만이 스프린트를 취소할 권한을 가집니다.

 

스프린트 계획 Sprint Planning
스프린트 계획은 스프린트에서 수행할 작업을 계획함으로써 스프린트를 시작합니다. 이 계획은 전체 스크럼 팀의 협업을 통해 작성됩니다.
제품 책임자는 참석자들이 가장 중요한 제품 백로그 항목과 제품 목표에 대한 매핑 방식을 논의할 수 있도록 준비합니다. 스크럼 팀은 또한 다른 사람들을 스프린트 계획에 초대하여 조언을 제공할 수 있습니다.

스프린트 계획은 다음과 같은 주제를 다룹니다:

주제 1: 이 스프린트가 왜 가치 있는가? Why is this Sprint valuable?
제품 책임자는 현재 스프린트에서 제품의 가치와 유용성을 어떻게 높일 수 있는지 제안합니다. 그런 다음 전체 스크럼 팀은 스프린트가 이해관계자에게 왜 가치 있는지를 전달하는 스프린트 목표를 정의하기 위해 협력합니다. 스프린트 목표는 스프린트 계획이 종료되기 전에 확정되어야 합니다.

주제 2: 이번 스프린트에서 무엇을 할 수 있는가? What can be Done this Sprint?
제품 책임자와의 논의를 통해 개발자는 제품 백로그에서 현재 스프린트에 포함할 항목을 선택합니다. 스크럼 팀은 이 과정에서 이러한 항목을 개선하여 이해도와 자신감을 높일 수 있습니다.

스프린트 내에서 완료할 수 있는 작업을 선택하는 것은 어려울 수 있습니다. 하지만 개발자가 과거 성과, 향후 역량, 그리고 완료 정의에 대해 더 많이 알수록 스프린트 예측에 대한 확신을 가질 수 있습니다.

주제 3: 선택된 작업은 어떻게 완료될 것인가? How will the chose work get done?
선택된 각 제품 백로그 항목에 대해 개발자는 완료 정의(Definition of Done)를 충족하는 인크리먼트를 생성하는 데 필요한 작업을 계획합니다. 이는 일반적으로 제품 백로그 항목을 하루 이하의 작은 작업 항목으로 분해하는 방식으로 이루어집니다. 이러한 작업 방식은 개발자의 단독 재량에 달려 있습니다. 제품 백로그 항목을 가치 있는 인크리먼트로 변환하는 방법을 개발자 외에는 아무도 알려주지 않습니다.

 

스프린트 목표, 스프린트에 선택된 프로덕트 백로그 항목, 그리고 이를 제공하기 위한 계획을 통틀어 스프린트 백로그라고 합니다.

스프린트 계획은 한 달 스프린트의 경우 최대 8시간으로 제한됩니다. 더 짧은 스프린트의 경우 이벤트는 일반적으로 더 짧습니다.

 

데일리 스크럼 Daily Scrum
데일리 스크럼의 목적은 스프린트 목표 달성을 위한 진행 상황을 점검하고 필요에 따라 스프린트 백로그를 수정하며, 예정된 작업을 조정하는 것입니다.

일일 스크럼은 스크럼 팀 개발자들을 위한 15분 분량의 이벤트입니다. 복잡성을 줄이기 위해 스프린트 기간 중 매일 같은 시간과 장소에서 진행됩니다. 제품 책임자 또는 스크럼 마스터가 스프린트 백로그의 항목을 적극적으로 작업하는 경우, 개발자 자격으로 참여합니다.
개발자는 데일리 스크럼이 스프린트 목표 달성을 위한 진행 상황에 초점을 맞추고 다음 날 작업을 위한 실행 가능한 계획을 수립하는 한, 원하는 구조와 기법을 선택할 수 있습니다. 이를 통해 집중력을 높이고 자기 관리를 향상시킬 수 있습니다.
일일 스크럼은 의사소통을 개선하고, 장애물을 파악하고, 신속한 의사 결정을 촉진하며, 결과적으로 별도의 회의가 필요하지 않도록 합니다.
일일 스크럼이 개발자가 계획을 조정할 수 있는 유일한 시간은 아닙니다. 그들은 종종 하루 종일 회의를 하며 스프린트의 나머지 작업을 조정하거나 재계획하는 것에 대해 더 자세히 논의합니다.

 

스프린트 검토 Sprint Review
스프린트 검토의 목적은 스프린트 결과를 검토하고 향후 수정 사항을 결정하는 것입니다. 스크럼 팀은 주요 이해관계자에게 작업 결과를 발표하고 제품 목표 달성을 위한 진행 상황을 논의합니다.
스프린트 검토 기간 동안 스크럼 팀과 이해관계자는 스프린트에서 달성된 사항과 환경의 변화를 검토합니다. 이 정보를 바탕으로 참석자들은 다음 단계에 대해 협업합니다. 제품 백로그는 새로운 기회에 맞춰 조정될 수 있습니다. 스프린트 검토는 작업 세션이며, 스크럼 팀은 이를 프레젠테이션으로만 제한해서는 안 됩니다.
스프린트 검토는 스프린트의 마지막에서 두 번째 단계이며, 한 달 스프린트의 경우 최대 4시간으로 제한됩니다. 스프린트가 더 짧은 경우 일반적으로 더 짧은 시간 동안 진행됩니다.

 

스프린트 회고 Sprint Retrospective
스프린트 회고의 목적은 품질과 효과성을 향상시킬 방법을 계획하는 것입니다.
스크럼 팀은 지난 스프린트가 개인, 상호작용, 프로세스, 도구 및 완료 정의 측면에서 어떻게 진행되었는지 검토합니다. 검토 대상 요소는 업무 영역에 따라 종종 다릅니다. 오류로 이어졌던 가정들을 파악하고 그 원인을 분석합니다. 스크럼 팀은 스프린트 기간 동안 무엇이 잘 되었는지, 어떤 문제가 발생했는지, 그리고 그 문제들이 어떻게 해결되었는지(또는 해결되지 않았는지) 논의합니다.
스크럼 팀은 효과성 향상에 가장 도움이 되는 변경 사항을 파악합니다. 가장 큰 영향을 미치는 개선 사항은 가능한 한 빨리 해결합니다. 이러한 개선 사항은 다음 스프린트의 스프린트 백로그에 추가될 수도 있습니다.
스프린트 회고는 스프린트를 마무리하는 단계입니다. 한 달 스프린트의 경우 최대 3시간으로 시간이 제한됩니다. 스프린트가 더 짧은 경우 일반적으로 이벤트 기간이 더 짧습니다.

 

6. 스크럼 산출물 Scrum Artifacts

스크럼의 산출물은 작업 또는 가치를 나타냅니다. 주요 정보의 투명성을 극대화하도록 설계되었습니다. 따라서 산출물을 검토하는 모든 사람은 동일한 적응 기준을 갖습니다.
각 산출물에는 투명성을 높이고 진행 상황을 측정할 수 있는 집중력을 높이는 정보를 제공하겠다는 약속이 포함되어 있습니다.

• 프로덕트 백로그의 경우 프로더트 목표가 있습니다.
• 스프린트 백로그의 경우 스프린트 목표가 있습니다.
• 인크리먼트의 경우 완료라는 정의가 있습니다.

이러한 약속은 스크럼 팀과 이해관계자의 경험주의와 스크럼 가치를 강화하기 위해 존재합니다.

 

프로덕트 백로그 Product Backlog
프로덕트 백로그는 제품 개선에 필요한 사항들을 체계적으로 정리한 목록입니다. 스크럼 팀이 수행하는 작업의 유일한 원천입니다.

스크럼 팀이 한 스프린트 내에서 수행할 수 있는 프로덕트 백로그 항목들은 스프린트 계획 단계에서 선택될 준비가 된 것으로 간주됩니다. 일반적으로 활동을 개선한 후 이러한 투명성을 확보하게 됩니다. 프로덕트 백로그 개선 Product Backlog refinement 은 프로덕트 백로그 항목을 더 작고 정확한 항목으로 세분화하고 정의하는 작업입니다. 이는 설명, 순서, 크기 등의 세부 정보를 추가하는 지속적인 활동입니다. 속성은 작업 영역에 따라 달라지는 경우가 많습니다.

작업을 수행하는 개발자는 크기 조정을 담당합니다. 제품 책임자는 개발자가 장단점을 이해하고 선택하도록 지원함으로써 개발자에게 영향을 미칠 수 있습니다.

 

• 약속: 제품 목표 Commitment: Product Goal
  제품 목표는 스크럼 팀이 계획할 수 있는 제품의 미래 상태를 설명합니다. 제품 목표는 프로덕트 백로그에 있습니다. 나머지 제품 백로그는 제품 목표를 달성할 "무엇"을 정의하기 위해 나타납니다.
  제품은 가치를 전달하는 수단입니다. 명확한 경계, 알려진 이해관계자, 명확하게 정의된 사용자 또는 고객이 있습니다. 제품은 서비스, 물리적 제품 또는 더 추상적인 것일 수 있습니다.
  제품 목표는 스크럼 팀의 장기적인 목표입니다. 다음 목표를 수행하기 전에 하나의 목표를 달성(또는 포기)해야 합니다.

스프린트 백로그 Sprint Backlog
스프린트 백로그는 스프린트 목표(Why), 스프린트를 위해 선택된 프로덕트 백로그 항목 세트(What), 그리고 인크리먼트를 제공하기 위한 실행 가능한 계획(How)으로 구성됩니다.
스프린트 백로그는 개발자가 작성하고 개발자를 위한 계획입니다. 이는 개발자가 스프린트 목표를 달성하기 위해 스프린트 기간 동안 수행해야 할 작업을 매우 명확하게 보여주는 실시간 그림입니다.
따라서 스프린트 백로그는 스프린트 기간 동안 더 많은 정보를 습득함에 따라 업데이트됩니다 데일리 스크럼에서 진행 상황을 검토할 수 있을 만큼 충분한 세부 정보가 포함되어야 합니다.

• 약속: 스프린트 목표 Commitment: Sprint Goal
  스프린트 목표는 스프린트의 유일한 주제입니다. 스프린트 목표는 개발자의 약속이지만, 목표 달성에 필요한 정확한 작업량 측면에서 유연성을 제공합니다. 또한, 스프린트 목표는 일관성과 집중력을 높여 스크럼 팀이 별도의 이니셔티브가 아닌 함께 작업하도록 돕습니다.
  스프린트 목표는 스프린트 계획 단계에서 생성되어 스프린트 백로그에 추가됩니다. 개발자는 스프린트 기간 동안 작업하면서 스프린트 목표를 염두에 둡니다. 작업 내용이 예상과 다를 경우, 제품 담당자와 협력하여 스프린트 목표에 영향을 미치지 않고 스프린트 내에서 스프린트 백로그의 범위를 협상합니다.

인크리먼트 Increment

> 스크럼 팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미.

인크리먼트는 제품 목표를 향한 구체적인 디딤돌 역할입니다. 각 인크리먼트는 이전 인크리먼트에 추가되며 철저히 검증되어 모든 인크리먼트가 함께 작동하는지 확인합니다. 가치를 제공하기 위해 인크리먼트는 반드시 사용 가능해야 합니다.

스프린트 내에 여러 개의 인크리먼트를 생성할 수 있습니다. 인크리먼트의 합계는 스프린트 검토 시 제시되므로 경험주의를 뒷받침합니다. 그러나 인크리먼트는 스프린트 종료 전에 이해관계자에게 전달될 수 있어서 스프린트 리뷰는 가치를 전달하기 위한 통과 절차로 여겨져서는 안 됩니다.

완료 정의를 충족하지 않는 작업은 인크리먼트로 간주될 수 없습니다.

• 약속: 완료 정의 Commitment: Definition of Done
  완료 정의는 제품에 필요한 품질 기준을 충족하는 인크리먼트의 상태를 공식적으로 설명하는 것입니다.
  프로덕트 백로그 항목이 완료 정의를 충족하는 순간, 인크리먼트가 생성됩니다.
  완료 정의는 인크리먼트의 일부로 완료된 작업에 대한 공통된 이해를 모든 사람에게 제공함으로써 투명성을 확보합니다. 프로덕트 백로그 항목이 완료 정의를 충족하지 못하면 스프린트 검토에서 릴리스되거나 발표될 수 없습니다. 대신, 향후 검토를 위해 제품 백로그로 반환됩니다.
  인크리먼트의 완료 정의가 조직의 표준에 포함되어 있다면, 모든 스크럼 팀은 최소한 그 기준을 따라야 합니다. 조직 표준이 아닌 경우에는, 각 스크럼 팀이 제품에 적합한 완료 정의를 직접 작성해야 합니다.
  개발자는 완료 정의를 준수해야 합니다. 여러 스크럼 팀이 하나의 제품을 위해 함께 작업하는 경우, 각 팀은 동일한 완료 정의를 상호 정의하고 준수해야 합니다.

 

출처

https://scrumguides.org/scrum-guide.html

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100