Scrum Guide 2020
Ken Schwaber와 Jeff Sutherland는 2020년 11월18일에 스크럼 가이드(Scrum Guide)를 새로 업데이트 했습니다. Scrum Guide 2020은 어려운 언어를 제거하거나 완화하여 스크럼을 최소한의 충분한 Framework로 되돌리는 것을 목표로 합니다.
- 원문 : The Scrum Guide 2020
- 참고로 Scrum guide 원문에는 그림이 없습니다. 따라서 추가된 이미지들은 이해를 돕기 위해 추가했을 뿐 반드시 따라야하는 규범이 아닙니다.
- 구글 번역기 기반으로 의역하였고, 일부 부연설명을 추가하였습니다.
새로운 스크럼 가이드는“How” 보다는 “Why”에 더 중점을 두고 있습니다. 하물며 daily scrum의 어제 한일, 오늘 할일, 장애 요소 같은 대표적인 공유 방법도 제거하였습니다. 모든 방법이 모든 조직에 맞는것은 아닙니다. why를 위해 각 조직에 맞는 방법을 지속적으로 탐구하라는 의미입니다. 물론 scrum은 여전히 scrum입니다. 스크럼은 여전히 공동 목표를 위해 한팀으로 협력하는 것입니다.
규범에 따라 이 event는 어떻게 하는것인지? 이 task는 누구의 역할인지? 이 회의에는 PO가 참석하는지 안하는지 등 scrum guide에 어떻게 써 있는지가 중요한게 아닙니다. 앞으로는 scrum 정신에 맞게 Scrum Master들의 새로운 practice를 탐구하고 적용하는 역량이 더 중요해질것 같습니다. (즉 지식 전달자가 아닌 참여하는 진정한 리더)
1. Scrum 정의
Scrum은 사람, 팀 및 조직의 복잡한 문제를 적응형 해결방법을 통해 가치를 창출하는데 도움이되는 경량 프레임워크입니다.
간단히 말해서 스크럼은 다음과 같은 환경을 조성하기 위해 스크럼 마스터가 필요합니다.
- Product Owner(PO, 제품 소유자)는 복잡한 문제에 대한 작업을 제품 백로그로 지시/요청(order)합니다.
- 스크럼 팀은 스프린트 기간동안 선택한 작업을 더 나은 가치로 전환합니다.
- 스크럼 팀과 이해관계자는 작업 결과를 검사하고 다음 스프린트를 위해 조정합니다.
- 계속 반복
스크럼은 간단합니다. 스크럼의 철학, 이론 및 구조가 목표를 달성하고 가치를 창출하는데 도움이되는지 확인하며 시도하세요. 스크럼 프레임워크는 의도적으로 불완전하며 스크럼 이론을 구현하는데 필요한 부분만 정의합니다. 스크럼은 그것을 사용하는 사람들의 집단 지성에 의해 구축됩니다. 사람들에게 자세한 지침을 제공하는 대신 스크럼 규칙은 관계와 상호작용을 안내합니다.
프레임워크 내에서 다양한 프로세스, 기술 및 방법을 사용할 수 있습니다. 스크럼은 기존 실천방법(practice)으로 수행하거나, 기존 관행을 불필요하게 만들 수도 있습니다. 스크럼은 현재의 관리, 환경 및 작업 기술의 상대적인 효율성을 가시화하여 개선 할 수 있습니다.
2. Scrum 이론
스크럼은 경험주의와 린 사상(Lean Thinking)에 기반을두고 있습니다. 경험주의는 지식이 경험에서 비롯되며 관찰 된 것에 따라 결정을 내립니다. 린 사고는 낭비를 줄이고 필수 사항에 집중합니다.
Scrum은 반복적이고 점진적인 접근 방식을 사용하여 예측 가능성을 최적화하고 위험을 제어합니다.
2.1. Transparency (투명성)
프로세스와 작업은 작업 결과를 받는 사람 뿐만 아니라 작업을 수행하는 사람도 볼 수 있어야합니다. 투명성이 낮은 산출물(artifacts)는 가치를 감소시키고 위험을 증가시키는 결정으로 이어질 수 있습니다.
투명성은 검사(inspection)를 가능하게합니다. 투명성이 없는 검사는 오해를 야기하며 낭비입니다.
2.2. Inspection(검사)
Scrum 산출물과 협의 된 목표를 향한 진행 상황을 자주 그리고 부지런히 검사하여 잠재적으로 바람직하지 않은 변동이나 문제를 감지해야합니다.
검사는 적응(adaptation)을 가능하게 합니다. 적응하는데 사용하지 않는 검사는 무의미합니다. 스크럼 이벤트는 변화를 유발하도록 설계되었습니다.
2.3. Adaptation(적응)
프로세스가 허용 범위를 벗어나거나 제품의 결과가 허용되지 않는 경우 적용되는 프로세스 또는 생산되는 재료를 조정해야합니다. 범위를 벗어나는 편차를 최소화하기 위해 가능한 빨리 조정해야합니다.
관련된 사람들이 권한이 없거나 스스로 관리(self-managing)하지 않으면 적응이 더 어려워집니다. 스크럼 팀은 검사를 통해 새로운 것을 배우는 순간 바로 적응해야합니다.(부연 : 기존에는 self-organization이였고, 현재는 self-managing으로 변경)
3. Scrum Values(Scrum의 가치)
스크럼을 성공적으로 사용하기 위해서는 5 가지 가치를 보다 능숙하게 적용하는데 달려 있습니다.
Commitment, Focus, Openness, Respect, and Courage
스크럼 팀은 목표를 달성하고 서로를 지원하기 위해 노력합니다. 그들의 주된 초점은 이러한 목표를 향해 가능한 최선의 진척을 내기위해 Sprint의 작업에 있습니다. 스크럼팀과 이해관계자는 작업과 과제에 대해 열려 있습니다. 스크럼 팀 구성원은 서로를 유능하고 독립적인 사람으로 존중하며 함께 일하는 사람들에게 존경을받습니다. 스크럼 팀 구성원은 올바른 일을하고 어려운 문제를 해결할 용기가 있습니다.
이러한 가치는 작업, 행동 및 행동과 관련하여 스크럼 팀에 방향을 제시합니다. 내린 결정, 취한 조치 및 스크럼 사용 방식은 이러한 가치를 감소 시키거나 약화시키지 말고 강화해야합니다. 스크럼 팀 구성원은 스크럼 이벤트 및 아티팩트를 사용하면서 가치를 배우고 탐구합니다. 스크럼 팀과 함께 일하는 사람들이 이러한 가치를 구현할 때 투명성, 검사 및 적응이라는 경험적 스크럼 기둥이 신뢰 구축에 생명을 불어 넣습니다.
(부연 설명 : 2020에서는 아래 5가지에 대해 용어 언급만 있고, 설명은 없어서 예전 자료 넣었습니다.)
- 약속 : 팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 팀에 약속하며, 이를 달성 위해 필요한 모든 권한을 부여하라!
(설명 : 개인보다는 팀 성과 달성이 우선이고, Value 있는 SW를 개발 할 수 있게 최대한 지원과 권한이 필요하다.) - 집중 : 할 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라!
(설명 : 한번에 하나의 일부터 마무리하고, 업무에 집중 할 수 있도록 불필요한 회의 참석은 지양하며, 루틴한 반복 작업은 제거 하거나 자동화해야 한다.) - 투명성/개방성 : 프로젝트에 대한 모든 내용을 투명하게 공개하라!
(설명 : 제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않고 도움을 요청한다.) - 존중 : 경력과 경험이 사람을 만든다. 팀원들을 존중하라!
(설명 : 개개인별로 장단점이 있고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을것이다.) - 용기 : 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라!
(설명 : 해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다. 또한 도전적으로 시도해보는 용기와 완료 할 수 없는 업무량이라고 모두 말 할 수 있어야 한다.)
4. Scrum Team
Scrum의 기본 단위는 소규모 팀인 Scrum Team입니다. 스크럼 팀은 한명의 Scrum Master(스크럼 마스터), 한명의 Product owner(제품소유자), 개발자들로 구성됩니다. 스크럼 팀 내에는 하위 팀들이나 계층이 없습니다. 한 번에 하나의 목표인 제품 목표에 초점을 맞춘 응집력있는 전문가 단위입니다.(부연 : 과거에는 스크럼 팀내에 PO, SM, Devlopment Team이라고 되어 있었지만, 현재는 모두가 한 team의 의미로 dev team을 developers로 변경)
스크럼 팀은 교차 기능(cross-functional)을 수행하므로 구성원이 각 스프린트의 가치를 창출하는 데 필요한 모든 기술을 보유하고 있습니다. 또한 자체 관리 기능을 수행하므로 누가 무엇을 언제 어떻게 수행하는지 내부적으로 결정합니다.
스크럼 팀은 민첩성을 유지할 수 있을만큼 작으며 Sprint 내에서 중요한 작업을 완료 할 수있을 만큼 큽니다 (일반적으로 10 명 이하). 일반적으로 소규모 팀이 더 잘 의사 소통하고 더 생산적이라는 사실을 발견했습니다. 스크럼 팀이 너무 커지면 각각 동일한 제품에 초점을 맞춘 여러 개의 응집력있는 스크럼 팀으로 재구성하는 것을 고려해야합니다. 따라서 동일한 제품 목표, 제품 백 로그 및 제품 소유자를 공유해야합니다.
스크럼 팀은 이해관계자의 협업, 확인, 유지 관리, 운영, 실험, 연구, 개발, 기타 필요한 모든 제품 관련 활동을 담당합니다. 조직은 자체 작업을 관리 할 수 있도록 구성되고 권한을 부여받습니다. 지속 가능한 속도로 Sprint에서 작업하면 스크럼 팀의 집중력과 일관성이 향상됩니다.
전체 스크럼 팀은 모든 스프린트에서 가치 있고 유용한 완성된 결과(증분, increment)를 만들 책임이 있습니다. 스크럼에서 스크럼 팀은 개발자, 제품 소유자 및 스크럼 마스터의 세 가지 특정 책임(accountability)을 정의합니다.
4.1. Developers(Dev, 개발자들)
개발자는 각 스프린트마다 사용 가능한 점진적 개선품을 개발하는데 전념하는 스크럼 팀의 사람들입니다. 개발자는 항상 다음에 대해 책임을집니다.
- 스프린트, 스프린트 백로그에 대한 계획 수립
- Definition of Done(완료 정의)를 준수하여 품질을 준수
- Sprint Goal을 향해 매일 계획을 조정
- 전문가로서 서로에게 책임(accountable)을 소유(holding)
4.2. Product Owner(PO, 제품 소유자)
제품 소유자는 스크럼 팀의 작업으로 인한 제품의 가치를 극대화 할 책임이 있습니다. 제품 소유자는 다음과 같은 효과적인 제품 백로그(Prodcut Backlog)관리에 대해서도 책임을집니다.
- Product Goal(제품 목표)을 작성하고 명시적으로 전달
- 제품 백로그 항목을 생성하고 명확하게 전달
- 제품 백로그 항목을 지시(ordering)
- 제품 백로그가 투명하고, 시각화하여, 이해가 되도록 보장
제품 소유자는 위의 작업을 다른 사람에게 책임을 위임 할 수 있지만, 그 책임을 집니다. 제품 소유자가 성공하려면 전체 조직이 자신의 결정을 존중해야합니다. 이러한 결정은 제품 백로그의 내용 및 주문과, Sprint Review를 통해 검사 가능한 수준의 증분을 통해 볼 수 있습니다.
제품 소유자는 위원회가 아니라 한 사람입니다. 제품 소유자는 제품 백로그에서 많은 이해관계자의 요구사항을 정의합니다. 제품 백로그를 변경하려는 사람들은 제품 소유자를 설득해야 합니다. (부연 설명 : 상위권자나 위원회에서 책임은 안지고 훈수만 두면, PO는 자신있게 결정을 못하고 결국 배는 산으로 갑니다.)
4.3. Scrum Master(SM, 스크럼 마스터)
스크럼 마스터는 스크럼 가이드에 정의 된대로 스크럼을 정착시킬 책임이 있습니다. 그들은 스크럼 팀과 조직 내에서 모든 사람들이 스크럼 이론과 실습을 이해하도록 돕습니다.
스크럼 마스터는 스크럼 팀의 효율성에 대한 책임이 있습니다. 그들은 스크럼 팀이 스크럼 프레임워크 내에서 실천법(practice)을 개선합니다.
스크럼 마스터는 스크럼 팀과 더 큰 조직에 봉사하는 진정한 리더입니다.
스크럼 마스터는 다음과 같은 여러 가지 방법으로 스크럼 팀을 지원합니다.
- self-management(스스로 관리)와 cross-functionality(교차 기능)에 대해 팀원을 코칭(부연 설명 : 과거 self-organization이 아닌 self-management로 Scrum 가이드 2020에서 변경)
- 스크럼 팀이 Definition of Done(완료조건 정의)을 충족하는 높은 가치의 결과물(Increment)을 지속적으로 만드는 데 집중하도록 지원
- 스크럼 팀의 진행에 장애물을 제거
- 모든 스크럼 이벤트가 긍정적이고 생산적으로 타임박스(timebox) 내에 끝나도록 보장
스크럼 마스터가 제품 소유자에게 제공하는 서비스
- 효과적인 제품 목표 정의 및 제품 백로그 관리 방법을 도움
- 스크럼 팀이 명확하고 간결한 제품 백로그 항목의 필요성을 이해하도록 지원
- 복잡한 환경에 대한 경험적 제품 계획 수립을 지원
- 요청 또는 필요에 따라 이해 관계자와의 협업을 촉진
스크럼 마스터가 조직에 제공하는 서비스
- 조직의 스크럼 적용을 리딩, 훈련 및 코칭
- 조직 내에서 스크럼을 실행하기 위한 계획 및 조언
- 직원과 이해관계자가 복잡한 작업에 대한 경험적 접근 방식을 이해하고 실행하도록 지원
- 이해관계자와 스크럼 팀 간의 장벽 제거
5. Scurm Event(스크럼 활동)
스프린트는 이벤트들(sprint planning, daily scrums, sprint review, sprint retrospective)로 이루어집니다. Scrum의 각 이벤트는 scrum 산출물(artifact)을 검사하고 조율 할 수 있는 공식적인 기회입니다. 이러한 이벤트는 필요한 투명성을 제공하도록 특별히 설계되었습니다. 규정된대로 이벤트를 운영하지 않으면 검토 및 적응할 기회를 잃게됩니다. 이벤트는 Scrum에서 규칙을 생성하고 Scrum에 정의되지 않은 회의의 필요성을 최소화하는데 사용됩니다.
최적으로 일하고 복잡성을 줄이기 위해 모든 이벤트는 같은 시간과 장소에서 개최됩니다.
5.1. Sprint(스프린트)
스프린트는 아이디어가 가치로 바뀌는 스크럼의 중심(원문 : heartbeat)입니다. 일관성을 유지하기 위해 한 달 이하의 고정 길이로 수행합니다. 새로운 스프린트는 이전 스프린트 종료 직후에 시작됩니다. sprint planning, daily scrums, sprint review, sprint retrospective를 포함하여 제품 목표를 달성하는데 필요한 모든 작업은 sprint내에서 이루어집니다.
(부연 : heartbeat라는 표현은 아마도, Sprint는 속도 보다는 사람마다 적절한 심박수가 있는것처럼 몸전체의 리듬을 강조한 것 같습니다.)
스프린트를 수행하는 동안 :
- 스프린트 목표 달성을 위태롭게하는 변경을 하지 않음
- 품질을 저하시켜 스프린트를 종료시키지 않음
- 제품 백로그는 필요에 따라 정제
- 범위를 명확히하고 product owner와 재협상 할 수 있음
스프린트는 적어도 매월 제품 목표에 대한 진행 상황을 점검하고 조정하여 예측 가능성을 지원합니다. 스프린트의 기간이 너무 길면 스프린트 목표가 무효화되고 복잡성이 증가하며 위험이 증가 할 수 있습니다. 더 짧은 스프린트를 사용하여 더 많은 학습주기를 생성하고 비용과 노력의 risk를 더 작은 시간 프레임으로 제한 할 수 있습니다. 각 스프린트는 짧은 프로젝트로 생각 해도 됩니다.
번 다운, 번 업 또는 누적 흐름도와 같은 진행 상황을 예측하는 다양한 방법이 있습니다. 유용하다고 입증되었지만 경험주의의 중요성을 대체하지는 않습니다. 복잡한 환경에서 어떤 일이 일어날지는 알 수 없습니다. 이미 일어난 일만 미래 지향적 의사결정에 사용될 수 있습니다. 스프린트 목표가 변경되면 스프린트가 취소 할 수 있습니다. PO(제품 소유자)만이 sprint를 취소 할 권한이 있습니다.
5.2. Sprint Planning(스프린트 계획)
sprint planning은 전체 backlog 중에 해당 sprint에 수행 할 작업을 배정합니다. 이 계획은 전체 스크럼 팀이 함께 공동 작업에 의해 결정됩니다.
product owner는 참석자가 가장 중요한 제품 백로그 항목과 제품 목표에 매핑하는 방법에 대해 토론 할 준비가 되었는지 확인합니다. 스크럼 팀은 조언을 위해 다른 사람들을 sprint planning 회의에 초대 할 수도 있습니다.
Sprint Planning은 다음 주제를 다룹니다.
주제 1 : [Why]이 Sprint가 가치있는 이유는 무엇입니까?
제품 소유자는 현재 sprint에서 제품의 가치와 유용성을 높일 수있는 방법을 제안합니다. 그런 다음 전체 스크럼 팀이 협력하여 스프린트가 이해 관계자에게 가치를 전달하는 스프린트 목표를 정의합니다. 스프린트 계획이 종료되기 전에 스프린트 목표를 확정해야합니다.
(부연 : 2017은 what, how만 있었지만, 2020에 why가 추가되었으며, 이것을 명확하게 하지 않으면 value가 아닌 단순히 해야할 일인 output에 집중하게 됩니다. 그러면 일은 했지만 그 value가 발생되지 않습니다.)
주제 2 : [What]이 Sprint를 통해 무엇을 할 수 있습니까?
PO와의 논의를 통해 개발자는 제품 백로그에서 현재 sprint에 포함 할 항목을 선택합니다. 스크럼 팀은 이 과정을 통해 이해도와 자신감을 높일 수 있습니다. 스프린트 내에서 완료 할 수있는 양을 선택하는 것은 어려울 수 있습니다. 그러나 개발자가 과거의 개발 속도, 개발양, 완료조건 정의에 대해 더 많이 알 수록 Sprint 예측에 더 확신을 갖게됩니다.
주제 3 : [How]선택한 작업은 어떻게 완료됩니까?
선택한 각 제품 백로그 항목에 대해 개발자는 완료 정의(Definition of Done, DoD)를 충족하는 개선된 결과를 만드는데 필요한 작업을 계획합니다. 이는 종종 제품 백로그 항목을 하루 이하의 작은 작업 항목으로 분해하여 수행됩니다. 이것이 수행되는 방법은 개발자의 단독 재량입니다. 아무도 제품 백로그 항목을 가치있게 증가시키는 방법을 알려주지 않습니다.
(부연 : 개인적으로는 완료정의를 제대로 합의하지 못하면 sprint review때 PO는 “최소한 이건 기본으로 할 줄 알았다”, 개발자는 “그것까지는 그 시간내에는 불가능하다” 라고 하면서 언쟁하게 됩니다.)
해당 sprint 목표를 달성하기 위해 선택된 제품 백로그 항목을 sprint backlog라고 합니다. sprint planning은 1개월 sprint에 대해 최대 8 시간으로 타임박스가 지정됩니다. 스프린트 기간이 짧아질 수록 이벤트 시간도 더 짧아집니다.
5.3. Daily Scrum(일일 스크럼)
데일리 스크럼(부연 : 또는 Standup meeting)의 목적은 스프린트 목표에 대해 진행 상황을 확인하고 필요에 따라 스프린트 백로그를 조정하여 예정된 작업을 조정하는 것입니다.
데일리 스크럼은 스크럼 팀 개발자를 위한 15 분동안의 이벤트입니다. 혼란을 줄이기 위해 Sprint의 모든 근무일에 같은 시간과 장소에서 수행합니다. 제품 소유자 또는 스크럼 마스터가 sprint backlog의 항목에 대해 적극적으로 작업하는 경우에는 참여합니다.
(부연 : 같은 팀이 아니라 제3자라고 생각하는 사람이 참여를 하면 팀이 아닌 본인에게 필요한 것 중심으로 물어보며 보고 자리처럼됩니다. 그러면 개발자에게 필요한 event가 안되어 개발자는 시간이 아깝다고 생각하며 Daily scurm을 오래 지속하지 못합니다.)
개발자는 데일리 스크럼이 스프린트 목표 달성에 초점을 맞추고 다음 작업을위한 실행 가능한 계획을 생성하는 한 원하는 구조와 기술을 선택할 수 있습니다. 이것은 초점을 만들고 자기 관리를 향상시킵니다. 데일리 스크럼은 커뮤니케이션을 개선하고 장애를 식별하며 빠른 의사 결정을 촉진하고 결과적으로 다른 회의의 필요성을 제거합니다.
데일리 스크럼은 개발자가 계획을 조정할 수있는 유일한 시간이 아닙니다. 그들은 종종 Sprint의 나머지 작업을 조정하거나 재계획하는 것에 대해 더 자세한 논의를 위해 때로는 하루 종일 만납니다.
(부연설명 : 2020 가이드에는 아래의 3가지 Question을 제거하였습니다. 이유는 만약 이 3가지 답변으로만 공유해야 한다면, 좀 더 스스로 목표(goal)을 향한 업무에 초점이 아닌 일일 상태 보고 회의처럼 될 수 있습니다. 그리고 각 조직의 특성에 따라 더 좋은 방법을 탐구하여 적용하는 것을 권장합니다.)
5.4. Sprint Review(스프린트 검토)
sprint review(스프린트 리뷰)의 목적은 sprint의 결과(output)를 점검하고, (goal에 맞도록) 향후에 적응/개선 할지 여부를 결정하는 것입니다. 스크럼 팀은 주요 이해관계자들에게 작업 결과를 제시하고 제품 목표에 대한 진행 상황을 논의합니다.
이벤트가 진행되는 동안 스크럼 팀과 이해 관계자는 sprint에서 수행 한 작업과 환경에서 변경된 사항을 검토합니다. 이 정보를 기반으로 참석자들은 다음에 수행 할 작업에 대해 공동 작업을합니다. 제품 백로그는 새로운 기회를 충족하기 위해 조정될 수도 있습니다. sprint review는 작업 세션이며 스크럼 팀은 프레젠테이션에 제한을 두지 않아야합니다.
sprint review는 sprint의 마지막에서 두 번째 이벤트이며 1 개월 Sprint 동안 최대 4 시간까지 타임박스가 적용됩니다. 스프린트 주기가 짧은 경우에는 일반적으로 sprint review시간을 더 짧게합니다.
5.5. Sprint Retrospective(스프린트 회고)
sprint retrospective의 목적은 품질과 효과를 높이는 방법을 계획하는 것입니다.
스크럼 팀은 개인, 상호 작용, 프로세스, 도구 및 완료 정의와 관련하여 마지막 스프린트가 어떻게 진행되었는지 점검(inspection)합니다. inspection 요소는 종종 작업 영역에 따라 달라집니다. 그들이 잘못된 길로 가게 된 원인을 찾습니다. 스크럼 팀은 sprint 동안 잘 된 점, 발생한 문제, 문제 해결 방법에 대해 논의합니다.
(부연 : 문제해결 방법은 없이 발생한 문제만 이야기하다보면 팀 분위기가 안좋아지고 회고를 계속 안하게 됩니다.)
스크럼 팀은 효율성 향상에 가장 유용한 개선사항을 식별합니다. 가장 효과적인 개선사항은 가능한 빨리 수행하여 문제를 해결합니다. 다음 스프린트를 위해 스프린트 백로그에 추가 될 수도 있습니다.
(부연 : action item으로 도출하고, 해결되는지 추적을 하지 않으면, 의견수렴만 하고 실제 문제해결은 되지 않아 무의미해집니다.)
sprint retrospective를 통해 sprint가 종료됩니다. 1 개월 스프린트에 대해 최대 3 시간까지 타임 박스가 적용됩니다. 짧은 스프린트의 경우 일반적으로 더 짧게 할 수 있습니다.
6. Scrum Artifacts(스크럼 산출물)
스크럼의 산출물은 작업이나 가치를 나타내며, 핵심 정보의 투명성을 극대화할 수 있습니다. 따라서 이를 검토하는 모든 사람은 적응/개선을 위한 동일한 기반을 갖습니다.
각 산출물에는 투명성을 높이고, 진척을 측정 할 수있는 정보를 제공한다는 약속이 포함되어 있습니다.
- 제품 백로그의 경우 제품 목표입니다.
- 스프린트 백로그의 경우 스프린트 목표입니다.
- 증분(개선된 결과)의 경우 완료의 정의(definitio of done)입니다.
이러한 약속은 스크럼 팀과 이해관계자의 경험주의와 스크럼 가치를 강화하기 위해 존재합니다.
6.1. Product Backlog(제품 백로그)
제품 백로그는 제품을 개선하는데 필요한 항목의 우선순위 목록입니다. 스크럼 팀이 사용하는 유일한 작업의 소스입니다.
한 스프린트 내에서 스크럼 팀이 수행 할 수있는 product backlog 항목은 sprint planning 이벤트에서 선택할 준비가 되어 있어야 합니다. 일반적으로 product backlog는 정제 활동 후에 투명성을 얻습니다. 제품 백로그 세분화는 product backlog 항목을 더 작은 더 정확한 항목으로 분류하고 추가로 정의하는 작업입니다. 설명, 요청(order) 및 크기와 같은 세부 정보를 추가하기 위한 지속적인 활동입니다. 속성은 종종 작업 영역(domain)에 따라 다릅니다.
작업을 수행 할 개발자가 작업의 크기 조정을 담당합니다. 제품 소유자는 개발자의 trade-off(하나를 선택하면 하나는 포기)를 이해하고, 작업을 선택 할 수 있게 지원함으로써 개발자에게 영향을 줄 수 있습니다. (부연 : 개발자와 PO는 서로를 이해하고 협의를 통해 작업 선정)
약속 : 제품 목표(Product Goal)
제품 목표는 스크럼 팀이 계획을 세울 대상이 될 수있는 제품의 미래 상태를 설명합니다. 제품 목표는 제품 백로그와 함께합니다. 나머지 제품 백로그는 제품 목표를 달성 할 “무엇”을 정의하기 위해 나타납니다.
제품은 가치를 전달하는 수단입니다. 명확한 경계, 알려진 이해관계자, 잘 정의 된 사용자 또는 고객이 있습니다. 제품은 서비스, 실제 제품 또는 좀 더 추상적 인 것일 수 있습니다.
제품 목표는 스크럼 팀의 장기적인 목표입니다. 그들은 다음 목표를 취하기 전에 하나의 목표를 달성 (또는 포기)해야합니다.
6.2. Sprint Backlog(스프린트 백로그)
스프린트 백로그는 스프린트 목표(why), 스프린트를 위해 선택된 제품 백로그 항목의 집합(what), 그리고 개선된 결과(increment)를 제공하기위한 실행 가능한 계획(how)으로 구성됩니다.
스프린트 백로그는 개발자를 위한 계획입니다. 개발자가 sprint 목표를 달성하기 위해 sprint 중에 수행 할 작업을 매우 눈에 잘 띄게 실시간 그림으로 보여줍니다. 결과적으로 스프린트 백로그는 더 많은 정보가 학습됨에 따라 스프린트 내내 업데이트됩니다. 데일리 스크럼에서 진행 상황을 조사 할 수있을만큼 자세한 정보가 있어야합니다.
약속 : 스프린트 목표(Sprint Goal)
sprint goal은 sprint의 단일 목표입니다. 스프린트 목표는 개발자의 약속이지만 이를 달성하는데 필요한 정확한 작업 측면에서 유연성을 제공합니다. 스프린트 목표는 또한 일관성과 집중력을 창출하여 스크럼 팀이 서로 별도의 계획(initiative)이 아닌 함께 일하도록 장려합니다.
스프린트 목표는 스프린트 계획 작업을 하면서 생성한 다음 스프린트 백로그에 추가됩니다. 개발자는 스프린트를 수행 할 때는 스프린트 목표를 염두에 둡니다. 작업이 예상과 다른 것으로 밝혀지면 제품 소유자와 협력하여 sprint 목표에 영향을 주지 않는 범위에서 sprint 내의 sprint backlog 범위를 협상합니다.
6.3. Increment(증분, 개선된 결과)
Increment는 제품 목표를 향한 구체적인 디딤돌입니다. 각 증분은 모든 이전 증분에 추가되며 철저하게 확인되어 모든 증분이 함께 작동하는지 확인합니다. 가치(value)를 제공하려면 Increment를 사용(실행)할 수 있어야합니다.
아마도 하나의 스프린트 내에서 여러개의 증분이 만들어질 것입니다. 통합된 증분은 sprint review시 보여지게 될것입니다. 그러나 증분은 스프린트가 종료되기 전에 이해관계자에게 제공 될 수 있습니다. sprint review는 가치를 공개하는 관문(gate)으로 간주되어서는 안됩니다.
작업은 완료 정의(Definition of Done, DoD)를 충족하지 않는 한 증분의 일부로 간주 될 수 없습니다.
약속 : 완료의 정의(Definitnion of Done)
완료의 정의는 제품에서 요구하는 품질(측정)을 만족할 때의 증분 상태에 대한 공식적인 설명입니다.
제품 백로그 항목이 완료 정의를 충족해야 작업 완료가 됩니다.
완료의 정의는 Increment의 일부로 완료된 작업에 대한 이해를 모든 사람에게 제공하여 투명성을 만듭니다. 제품 백로그 항목이 완료 정의를 충족하지 않는 경우 해당 항목을 출시하거나 sprint review에 제출할 수도 없습니다. 대신 나중에 고려할 수 있도록 제품 백로그로 돌아갑니다.
증분에 대한 완료 정의가 조직 표준의 일부인 경우 모든 스크럼 팀은 최소한 이를 따라야합니다. 조직 표준이 아닌 경우 스크럼 팀은 제품에 적합한 완료 정의를 작성해야합니다.
개발자는 완료 정의를 준수해야합니다. 하나의 제품에 대해 함께 작업하는 여러 스크럼 팀이있는 경우 동일한 정의의 완료를 상호 정의하고 준수해야합니다.
(부연 : sprint goal을 충족하는 definition of done에 따라 증분(increment)을 개발합니다. 따라서 product goal은 product backlog를 위한 약속이고, sprint goal은 sprint backlog를 위한 약속이며, definition of done은 increment를 위한 약속입니다.)
© 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.
