Ken Schwaber & Jeff Sutherland스크럼 가이드스크럼 완벽 가이드: 게임의 규칙2020 년 11 월스크럼 가이드의 목적
우리(켄 슈와버 & 제프 서덜랜드)는 1990 년대 초반에 스크럼 Scrum 을 개발하였다. 2010 년에는스크럼 가이드의 첫 번째 버전을 작성하여 전 세계의 사람들이 스크럼을 이해할 수 있도록 도왔다.
그 이후로 조금씩 기능을 업데이트하며 이 가이드를 발전시켜왔다. 우리는 함께 스크럼 가이드를후원한다.
스크럼 가이드는 스크럼의 정의를 담고 있다. 스크럼 프레임워크의 각 요소는 특정한 목적을 이루기위해 설계된 것이고, 스크럼으로 실현하려는 전체적인 가치와 결과에 필수적이다. 스크럼의 핵심설계와 발상을 변경하는 경우, 특정 요소를 배제하는 경우 또는 스크럼 규칙을 따르지 않는 경우에는어떤 문제가 있는지 알 수가 없고 스크럼의 이점을 충분히 살릴 수도 없다. 심지어 스크럼을 쓸모없는 것으로 만들 수도 있다.
세상이 점점 더 복잡해지면서 스크럼의 활용도 증가하고 있다. 감사하게도 스크럼이 그 뿌리가 되는소프트웨어 프로덕트 개발 영역을 넘어서, 여러 복잡한 업무를 수행하는 영역 들에도 적용되고 있다.
이에 따라 개발자들뿐만 아니라 연구원들, 분석가들, 과학자들과 같은 다른 영역의 전문가들이스크럼으로 업무를 한다. 우리는 단순하게 표현하기 위해 “개발자들 Developers” 이라는 단어를사용하지만 이것이 다른 영역의 업무 수행자들을 배제하는 것은 아니다. 만약 당신이 스크럼을 가치있게 활용하고 있다면 당신의 역할도 “개발자들” 에 포함된다고 생각할 수 있다.
스크럼을 사용하다 보면, 스크럼 가이드 상의 스크럼 프레임워크에 적합한 패턴, 프로세스, 통찰을새로 발견하고 적용하고 만들 수 있다. 그 내용들은 스크럼 가이드의 목적 범위를 벗어나는데,왜냐하면 상황에 민감하기도 하고 스크럼을 어떻게 사용하는 가에 따라 차이가 크기 때문이다.
스크럼 프레임워크 내에서 사용하는 그런 전술은 다양한데, 이 가이드에서 다루지는 않는다.
켄 슈와버 Ken Schwaber & 제프 서덜랜드 Jeff Sutherland 2020 년 7 월1

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

2스크럼 가이드의 목적 ................................................................................................................................. 1스크럼 정의.................................................................................................................................................. 5스크럼 이론.................................................................................................................................................. 5
투명성 ...................................................................................................................................................... 6
점검 .......................................................................................................................................................... 6
적응 .......................................................................................................................................................... 6스크럼 가치.................................................................................................................................................. 7스크럼 팀...................................................................................................................................................... 7개발자들 .................................................................................................................................................. 8프로덕트 오너.......................................................................................................................................... 8스크럼 마스터.......................................................................................................................................... 9스크럼 이벤트............................................................................................................................................ 10스프린트 ................................................................................................................................................ 11스프린트 계획........................................................................................................................................ 12데일리 스크럼........................................................................................................................................ 13스프린트 리뷰........................................................................................................................................ 14스프린트 회고........................................................................................................................................ 14스크럼 산출물............................................................................................................................................ 15프로덕트 백로그.................................................................................................................................... 15
약속: 프로덕트 목표 .......................................................................................................................... 16스프린트 백로그.................................................................................................................................... 16
약속: 스프린트 목표 .......................................................................................................................... 16
증가분 .................................................................................................................................................... 17
약속: 완료의 정의 .............................................................................................................................. 173마침글 ........................................................................................................................................................ 18감사의 말................................................................................................................................................ 18
사람..................................................................................................................................................... 18스크럼 가이드의 역사 ....................................................................................................................... 18한국어 번역자 감사의 말 .................................................................................................................. 19
용어집 ........................................................................................................................................................ 192017 스크럼 가이드에서 2020 스크럼 가이드로의 변경 사항 .............................................................. 20더 적어진 지시적인 표현 .................................................................................................................. 20하나의 프로덕트에 집중하는 하나의 팀 ......................................................................................... 20프로덕트 목표의 도입 ....................................................................................................................... 20스프린트 목표와 완료의 정의, 프로덕트 목표가 속하는 곳 Home ............................................... 20자율조직 Self-Organizing 을 넘어 자율관리 Self-Managing 로........................................................ 20스프린트 계획의 세 가지 주제 ......................................................................................................... 21더 다양한 독자들을 위한 전반적인 표현의 순화 ........................................................................... 214

스크럼 정의스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법 Adaptive solutions 을 활용하여가치를 창출하도록 도와주는 경량 Lightweight 프레임워크이다.
간단히 말해서 스크럼은 스크럼 마스터가 다음과 같은 환경을 조성하는 것이다:1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에정렬한다.
2. 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분 Increment of value (*증가분은 스크럼팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미한다. 번역자)으로 만들어 낸다.

3. 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4. 반복한다.
스크럼은 간단하다. 제시한 그대로 시도해 보고, 스크럼의 철학, 이론, 구조가 목표를 달성하고가치를 창출하는데 도움이 되는지 판단하기 바란다. 스크럼 프레임워크는 의도적으로 불완전하게오직 스크럼 이론을 구현하는데 필요한 부분만 정의하고 있다. 스크럼은 스크럼을 사용하는사람들의 집단지성을 기반으로 만들어진 것이다. 사람에게 상세한 지침을 주는 것 보다는 스크럼원칙은 사람들 간의 관계와 소통을 안내하는 것이다.
프레임워크 안에서 다양한 프로세스, 테크닉, 방법을 이용해 볼 수 있다. 기존의 실천법을 스크럼프레임워크 내에서 수행할 수 있다. 또한 스크럼으로 인해 기존의 업무 방식이 불필요해 질 수도있다. 현재의 관리, 환경, 업무 기법과 관련된 효과를 스크럼을 통해 가시화하여 개선을 할 수 있다.

스크럼 이론스크럼은 경험주의 Empiricism 와 린 씽킹 Lean thinking 을 기초로 한다. 경험주의는 경험과 관찰한것을 기반으로 한 의사 결정으로부터 지식을 얻는 것이다. 린 씽킹은 낭비를 줄이고 본질에 초점을맞추는 것이다.

5스크럼은 예측 최적화와 리스크 통제를 위해 반복적이고 점진적인 방식을 쓴다. 전체적으로 업무를수행하는데 필요한 모든 기술과 전문성을 갖출 수 있도록 사람들을 스크럼에 참여시키고, 필요에따라 그러한 기술을 공유하고 습득한다.
스크럼에는 점검과 적응을 하기 위한 네 개의 공식 이벤트(스프린트 계획, 데일리 스크럼, 스프린트 리뷰,스프린트 회고)가 이벤트의 하나인 스프린트 안에 포함된다. 이 이벤트들을 통해 경험주의적 스크럼의기둥인 투명성 Transparency, 점검 Inspection, 적응 Adaptation 을 현실로 실천한다.

투명성업무를 실행하거나 일의 결과물을 받는 사람들에게 신규 업무 프로세스와 일이 무엇인지는 반드시가시적이어야 한다. 스크럼에서는 세 가지 공식적인 산출물을 이해하고 그것을 기반으로 중요한결정을 한다. 산출물의 투명성이 낮은 경우에 하는 의사결정은 가치를 떨어뜨리고 리스크를 높일 수있다.
투명성을 제고해야 점검이 가능하다. 투명성이 없는 상태로 점검을 하는 것은 오해를 낳고 시간을낭비한다.

점검잠재적으로 바람직하지 않은 변화와 문제점을 발견하기 위해서는 스크럼 산출물과 달성하기로 한목표에 대한 진척을 반드시 자주 부지런하게 점검해야 한다. 이러한 점검을 쉽게 하기 위해 스크럼은다섯 가지 이벤트를 주기적으로 수행한다.
점검한 것을 바탕으로 적응(*팀이 어떤 것을 조정하고, 조정한 환경에 맞추어 나감 -번역자)을 할 수 있다. 적응을하지 않으면 점검은 무의미하다. 스크럼 이벤트는 점검을 통한 변화를 일으키기 위해 설계되었다.

적응만약에 프로세스의 어떤 측면이 수용 가능한 범위를 벗어나거나 그 결과물이 받아들일 수 있는수준이 아닌 경우, 진행하는 프로세스와 생산하고 있는 것들을 반드시 조정해야 한다. 더 이상의차이가 나는 것을 줄이기 위해 꼭 가능한 한 빨리 조정을 해야 한다.

6관계자들이 권한이 없거나 자율관리를 하지 못하는 경우, 적응은 더욱 어려운 일이 된다. 스크럼팀은 점검을 통하여 새로운 것을 학습한 순간에 바로 적응을 진행할 수 있어야 한다.

스크럼 가치스크럼의 성공적인 활용은 사람들이 얼마나 다섯 가지 가치를 잘 지키는 가에 따라 좌우된다:약속 Commitment, 집중 Focus, 열린 마음 Openness, 존중 Respect, 용기 Courage스크럼 팀은 목표를 달성하는 것과 서로 협력할 것을 약속한다. 팀원들은 이러한 약속을 지키기 위해스프린트 동안 최상으로 가능한 진전을 만드는 일에 최우선적으로 집중한다. 스크럼 팀과이해당사자들은 일과 도전에 열린 마음을 가져야 한다. 스크럼 팀원들은 팀원 개개인이 능력을 갖춘독립적인 존재임을 서로 존중해야 한다. 스크럼 팀과 함께 일하는 외부인들도 스크럼 팀을 존중해야한다. 스크럼 팀은 힘든 문제를 해결할 때 올바른 일을 하는 용기를 가져야 한다.
스크럼의 다섯 가지 가치는 스크럼 팀이 일하고 결정하고 행동하는 방향을 제시한다. 이 가치들을강화하는 방식으로 스크럼을 사용하고 의사 결정을 해 나가야 한다. 스크럼 팀원들은 스크럼이벤트와 산출물을 만들어 내는 과정을 통해 스크럼의 가치를 배우고 탐구한다. 스크럼 팀과 함께일하는 사람들에게 스크럼 가치가 체화 될 때에 경험주의적인 스크럼의 세 가지 기둥인 투명성, 점검,적응이 살아 움직이게 되고 신뢰를 쌓아가게 된다.

스크럼 팀스크럼 조직의 기본이 되는 단위인 스크럼 팀은 적은 수의 인원으로 구성된다. 스크럼 팀은 한 명의스크럼 마스터, 한 명의 프로덕트 오너, 그리고 개발자들로 구성된다. 스크럼 팀 내에는 하부 팀이나수직구조가 없다. 스크럼 팀은 하나의 프로덕트 목표에 동시에 집중하는 전문가들의 모임이다.
스크럼 팀은 교차기능적이다. 그 의미는 팀 구성원들이 매 스프린트마다 가치를 만드는 데에 필요한모든 기술들을 가지고 있다는 것이다. 그들은 자율관리팀으로 구성원 내부적으로 누가 무엇을 언제어떻게 할 것인지 결정한다.

7스크럼 팀은 민첩할 수 있도록 작지만, 한 스프린트 내에 의미 있는 일을 완료할 수 있을 만큼 충분한크기여야 한다. 일반적으로 10 명 또는 그보다 적은 수의 인원으로 구성된다. 지금까지 보면 대개작은 팀이 소통을 더 잘 하고 더 생산적이다. 만약 스크럼 팀이 너무 커지면, 이들을 다수의 스크럼팀으로 재구성하는 것을 고려해야 하고, 각 팀은 하나의 동일한 프로덕트에 집중하도록 화합해야한다. 그렇게 하여 동일한 프로덕트 목표와 프로덕트 백로그, 프로덕트 오너를 공유해야 한다.
스크럼 팀은 프로덕트와 관련한 모든 활동들에 책임을 진다. 이해관계자와의 협력, 검증, 유지보수,운영, 실험, 연구개발과 같이 필요한 모든 것들에 대해서다. 그들은 서로 화합하며 스스로 일을관리할 수 있는 권한을 조직으로부터 부여 받는다. 매 스프린트 마다 지속가능한 속도로 일하는 것이스크럼 팀의 집중과 꾸준함을 향상시킨다.
스크럼 팀 전체는 매 스프린트마다 가치 있고 유용한 증가분을 만들어내는 것에 책임을 진다.
스크럼은 스크럼 팀 내에 세 가지 특정한 직책을 정의한다: 개발자들, 프로덕트 오너, 스크럼 마스터개발자들스크럼 팀의 개발자들은 매 스프린트마다 사용 가능한 증가분의 모든 부분을 만드는 것에 전념하는사람들이다.
개발자들이 갖추어야 하는 특정한 기술들은 종종 범위가 넓고 업종에 따라 다양하다. 그렇지만,개발자들은 항상 다음의 사항들에 책임을 갖는다:⚫

스프린트 동안의 계획을 세우는 것, 스프린트 백로그;⚫

완료의 정의를 준수하여 품질을 높여가는 것;⚫

스프린트 목표를 위해 그들의 계획을 매일마다 조정함;⚫

전문가로서 서로 책임을 지는 것.

프로덕트 오너
프로덕트 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 이 업무를수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있다.

8프로덕트 오너는 프로덕트 백로그를 효과적으로 관리하는 것에도 책임이 있는데, 다음 사항들을포함한다:⚫ 프로덕트 목표를 세우고 명쾌하게 소통하는 것;⚫ 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것;⚫ 프로덕트 백로그 아이템을 우선순위에 따라 정렬;⚫ 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것.
프로덕트 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임한다. 어떤식으로 하든지 최종 책임은 프로덕트 오너가 갖는다.
프로덕트 오너가 성공적으로 일을 하기 위해서는 조직 전체가 반드시 그의 결정을 존중해야 한다.
프로덕트 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해확인할 수 있다. 또한 스프린트 리뷰 때에 점검 가능한 증가분을 통해서도 볼 수 있다.
프로덕트 오너는 한 사람이지 여럿으로 구성된 위원회가 아니다. 프로덕트 오너는 프로덕트백로그와 연관된 많은 이해관계자들의 요구를 대표한다. 프로덕트 백로그를 변경하고 싶은사람들은 프로덕트 오너를 설득하여야 한다.

스크럼 마스터스크럼 마스터는 스크럼 가이드에 정의된 대로 스크럼을 확립하는 것에 책임이 있다. 스크럼마스터는 스크럼 팀과 조직의 모든 구성원이 스크럼 이론과 실천법을 이해하도록 돕는다.
스크럼 마스터는 스크럼 팀을 효율적으로 만들 책임이 있다. 스크럼 프레임워크 안에서 스크럼 팀이그들의 실천법을 향상시키도록 한다.
스크럼 마스터는 스크럼 팀과 더 큰 조직을 위해 봉사하는 진정한 리더이다.
스크럼 마스터는 스크럼 팀을 위해 다양한 방법으로 일하는데, 다음을 포함한다:⚫ 팀원들이 자율관리를 하고 교차기능적이 되도록 코칭 하는 것;

9⚫ 스크럼 팀이 완료의 정의를 충족하여 높은 가치를 갖는 증가분을 만드는 데에 집중할 수있도록 돕는 것;⚫ 스크럼 팀의 진척에 방해가 되는 장애물을 제거하는 것;⚫ 모든 스크럼 이벤트들이 열리는 것과 긍정적이고 생산적으로 이루어 지는 것, 그리고 정해진시간 안에 마치는 것을 보장하는 것.
스크럼 마스터는 프로덕트 오너를 위해 다양한 방법으로 일하는데, 다음을 포함한다:⚫ 효과적인 프로덕트 목표 정의와 프로덕트 백로그 관리를 위한 기술을 찾는 것을 돕는 것;⚫ 스크럼 팀이 명확하고 간결한 프로덕트 백로그 아이템의 필요성을 이해하도록 돕는 것;⚫ 복잡한 환경에 대해 경험주의적으로 프로덕트 계획을 수립하도록 돕는 것;⚫ 요구 또는 필요에 따라 이해관계자와의 협업을 촉진하는 것.
스크럼 마스터는 조직을 위해 다양한 방법으로 일하는데, 다음을 포함한다:⚫ 조직이 스크럼을 채택하는 경우, 조직을 리드하고, 교육하고 코칭 하는 것;⚫ 조직 내에 스크럼을 실행하는 것을 계획하고 조언하는 것;⚫ 조직 구성원들과 이해관계자들이 복잡한 환경에 경험주의 접근법을 이해하고 활용하도록돕는 것;⚫ 이해관계자들과 스크럼 팀들 사이의 장벽을 제거하는 것.

스크럼 이벤트스프린트는 다른 모든 이벤트들을 담는 컨테이너라 할 수 있다. 각 스크럼 이벤트는 스크럼 산출물을점검하고 적응하는 공식적인 활동이고, 필요한 투명성을 확보할 수 있도록 특별하게 설계되었다.
규정된 이벤트들을 진행하지 못하는 경우에는 점검과 적응의 기회를 잃게 된다. 스크럼 이벤트들은주기적이고 반복적인 활동이기 때문에 또 다른 미팅을 할 필요성을 줄여준다.
복잡성을 최대한 줄이기 위해 모든 이벤트는 같은 시각 같은 장소에서 한다.

10스프린트
스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다.
스프린트는 꾸준함을 갖기 위해 한달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트이다. 새로운스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.
스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트목표를 달성하기 위해 필요한 모든 업무를 수행한다.
스프린트 기간 동안에는:⚫ 스프린트 목표 달성을 저해하는 변경을 해서는 안된다;⚫ 품질을 떨어뜨려서는 안된다;⚫ 필요한 수준까지 프로덕트 백로그를 정제해야 한다;⚫ 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.
스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로리스크를 한정시킬 수 있다. 각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.
진척을 예측하는 데에는 번 다운 Burn-downs 차트, 번 업 Burn-ups 차트, 누적 흐름도 Cumulative flows와 같은 다양한 방식이 있다. 이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는못한다. 복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다. 단지 지금까지 무엇이 발생했는지를토대로 앞으로의 결정을 내릴 수 있다.
스프린트 목표가 효력이 없게 되면, 스프린트를 취소할 수 있다. 오직 프로덕트 오너만이 스프린트를취소할 결정권을 갖는다.

11스프린트 계획스프린트 계획을 통해서 해당 스프린트 동안 수행할 업무를 선정한다. 스크럼 팀 전체가 참여하여계획을 한다.
프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요한 아이템들, 그리고 그것들이 프로덕트목표와 어떻게 연결되는지를 참여자들이 논의할 수 있도록 준비해야 한다. 스크럼 팀에 조언을 해줄수 있는 다른 사람을 스프린트 계획에 초청할 수도 있다.
스프린트 계획은 다음과 같은 주제를 다룬다:주제 1: 이 스프린트가 왜 가치가 있는가?
프로덕트 오너가 이번 스프린트에서 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지를제안한다. 전체 스크럼 팀원들이 협력해서 스프린트 목표를 정의한다. 스프린트 목표를 정의할때에는 이 스프린트가 이해관계자들에게 중요한 이유를 담아야 한다. 스프린트 목표는 반드시스프린트 계획을 마치기 전에 결정되어야 한다.
주제 2: 이 스프린트의 완료 Done 는 무엇인가?
프로덕트 오너와 논의를 하면서 개발자들이 이번 스프린트에 포함할 프로덕트 백로그 아이템을선정한다. 스크럼 팀은 이 과정 중에 프로덕트 백로그 아이템을 정제할 수 있다. 이를 통해 내용을 더정확히 이해하고, 할 일에 대한 확신을 가질 수 있다.
한 스프린트 내에 얼마나 완료할 수 있을지를 정한다는 것은 쉬운 일은 아니다. 그렇지만,개발자들이 그들의 지난 성과와 다음 번에 수용 가능한 업무량, 완료의 정의 Definition of Done 에대해 많이 알면 알수록 그들이 스프린트를 예측할 때에 더 확신을 가질 수 있을 것이다.
주제 3: 선정한 일을 어떻게 완료할 것인가?
개발자들은 선정한 모든 프로덕트 백로그 아이템들을 가지고, 완료의 정의를 충족하는 증가분을만드는 데에 필요한 업무들을 계획한다. 대체적으로 이것은 프로덕트 백로그 아이템을 하루 안에12완료할 수 있는 크기로 더 작게 세분화하는 것으로 이루어진다. 중요한 것은 이 과정은 절대적으로
개발자들의 재량이다. 다른 누구도 개발자들에게 프로덕트 백로그 아이템을 어떻게 증가분으로
만들지에 대해 정해주어서는 안된다.
스프린트 목표, 스프린트를 위해 선정한 프로덕트 백로그 아이템들, 그리고 이것을 완료하는 것에대한 계획을 모두 포함하여 스프린트 백로그라고 한다.
스프린트 계획은 최대 시간이 정해진 Timeboxed 이벤트로 일 개월 기간의 스프린트인 경우 8 시간이넘지 않도록 한다. 스프린트 기간이 더 짧은 경우 보통 스프린트 계획 시간도 더 짧다.

데일리 스크럼데일리 스크럼의 목적은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을변경하여 스프린트 백로그를 조정하는 것이다.
데일리 스크럼은 스크럼 팀의 개발자들만 참여하는 15 분 길이의 이벤트이다. 복잡성을 줄이기 위해같은 시각에 같은 장소에서 스프린트 기간의 모든 근무일 마다 수행한다. 만약 프로덕트 오너나스크럼 마스터도 스프린트 백로그 아이템을 맡아 활동적으로 업무를 하고 있다면 개발자들의일원으로 데일리 스크럼에 참여할 수 있다.
개발자들이 실행하는 데일리 스크럼이 스프린트 목표 대비 진척과 다음 근무일에 실행할 수 있는계획을 만드는 것에 초점을 두는 한, 개발자들은 어떤 방식이나 기법으로도 데일리 스크럼을 진행할수 있다. 이로써 일에 집중하고 자율관리 팀으로서의 능력을 향상시킨다.
데일리 스크럼은 팀의 소통을 향상시키고 팀이 가지고 있는 장애물을 식별하며 신속한 의사 결정을촉진하여 별도로 다른 미팅을 할 필요성을 줄여준다.
개발자들이 계획 변경에 대한 논의를 반드시 데일리 스크럼에서만 해야 하는 것은 아니다. 아무 때나자주 만나서 더 상세하게 남은 스프린트의 업무를 조정하거나 다시 계획하는 논의를 진행하면 된다.

13스프린트 리뷰스프린트 리뷰의 목적은 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것이다.
스크럼 팀은 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트 목표 대비 진척을 보여준다.
스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스환경에서 변한 것이 무엇인지를 검토한다. 이 정보에 기초하여 참여자들은 다음으로 무엇을 할것인지 협력하여 논의한다. 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다.
스프린트 리뷰는 이와 같은 활동을 하는 시간이므로 발표만 하고 끝나지 않도록 해야 한다.
스프린트 리뷰는 스프린트의 끝에서 두 번 째로 하는 이벤트이다. 최대 시간이 정해진 이벤트로 일개월 기간의 스프린트인 경우 4 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우, 보통스프린트 리뷰 시간도 더 짧다.

스프린트 회고스프린트 회고의 목적은 품질과 효율을 높이기 위한 방법들을 계획하는 것이다.
스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난스프린트가 어떻게 진행 되었는지를 점검한다. 업무 영역 별로 점검하는 사항들은 차이가 날 수 있다.
팀이 잘못된 방향으로 가게 된 가정들을 확인하고, 그것들의 근본 원인을 찾아낸다. 스크럼 팀은무엇이 잘 진행되었는지에 대해서도 논의한다. 어떤 문제를 만났고 그 문제를 어떻게 풀었는지(또는풀지 못했는지)에 대해 의견을 나눈다.
스크럼 팀은 그들의 효율을 향상시키기 위해 가장 도움이 되는 변화를 찾아야 한다. 가장 영향이 큰개선책을 최우선으로 고려해야 한다. 이런 개선책을 다음 스프린트에 수행하도록 스프린트백로그에 추가할 수도 있다.
스프린트 회고를 마지막으로 스프린트가 종료된다. 최대 시간이 정해진 이벤트로 일 개월 기간의스프린트인 경우 3 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우, 보통 스프린트 회고시간도 더 짧다.

14스크럼 산출물
스크럼의 산출물은 업무 또는 가치를 나타낸다. 그것들은 핵심 정보의 투명성을 극대화하도록 설계되었으므로, 모두가 산출물을 점검하는 것은 적응을 하기 위한 동일한 기반 정보를 얻는 것이다.
각 산출물은 측정 가능한 진척에 집중하고 투명성을 높이는 정보를 제공할 것을 명확하게 하는약속을 담고 있다:⚫ 프로덕트 백로그에는 프로덕트 목표가 있다.
⚫ 스프린트 백로그에는 스프린트 목표가 있다.
⚫ 증가분에는 완료의 정의가 있다.
이런 약속들의 목적은 스크럼 팀과 이해관계자들에게 경험주의와 스크럼 가치를 강하게 갖도록하기 위한 것이다.

프로덕트 백로그프로덕트 백로그는 프로덕트를 향상시키기 위한 것으로 발생하는 업무를 우선순위에 따라 정렬한
목록이다. 프로덕트 백로그는 스크럼 팀이 실행하는 업무를 제공하는 유일한 출처 single source 이다.
프로덕트 백로그 아이템은 스프린트 계획 이벤트 때에 선택할 수 있도록 준비된 것으로 스크럼 팀이한 스프린트 안에 완료할 수 있는 것이다. 보통 할 일들을 정제한 이후에 스프린트 계획을 할 수 있는수준의 투명성을 확보할 수 있다. 프로덕트 백로그 정제는 프로덕트 백로그 아이템을 구체적으로
정의하여 보다 명확하게 일을 작은 단위로 나누는 것이며, 설명, 우선순위에 따른 정렬, 크기와 같은세부 사항들을 지속적으로 추가하는 활동이다. 속성 항목들은 주로 업무 영역에 따라 다를 수 있다.
개발자들은 프로덕트 백로그 아이템의 크기를 결정하는 데에 책임을 진다. 프로덕트 오너는개발자들이 절충안 trade-offs 을 이해하고 선택하도록 도움을 줄 수 있다.

15

약속: 프로덕트 목표프로덕트 목표는 스크럼 팀이 목표로 삼아 계획하는 프로덕트의 미래 상태를 말한다. 프로덕트목표는 프로덕트 백로그 안에 포함되어 있다. 프로덕트 백로그의 나머지는 “무엇” 이 프로덕트목표를 충족할 것인지에 대한 정의를 나타낸다.

프로덕트는 가치를 전달하기 위한 수단이며, 명확한 범위와 알려진 이해관계자, 잘 정의된사용자 또는 고객을 가지고 있다. 프로덕트는 일종의 서비스나 실체가 있는 제품 또는 더추상적인 형태의 것일 수 있다.
프로덕트 목표는 스크럼 팀의 장기적인 목표이다. 스크럼 팀은 다음 목표를 맡기 전에 하나의 목표를반드시 달성해야(또는 포기해야) 한다.

스프린트 백로그스프린트 백로그는 스프린트 목표(왜), 스프린트를 위해 선택된 프로덕트 백로그 아이템들의모음(무엇을), 증가분을 전달하기 위한 실행할 수 있는 계획(어떻게)으로 구성되어 있다.
스프린트 백로그는 개발자들에 의한 개발자들을 위한 계획이다. 매우 가시적이며, 개발자들이
스프린트 목표를 달성하기 위해 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는그림이다. 따라서 스프린트 백로그는 스프린트 기간 동안 더 알게 된 것만큼 업데이트 된다.
스프린트 백로그는 데일리 스크럼 때 진척을 확인할 수 있을 만큼 세부 내용이 충분해야 한다.

약속: 스프린트 목표스프린트 목표는 스프린트에 대한 단 하나의 목표이다. 스프린트 목표가 개발자들이 한 약속이지만,그것을 달성하기 위해 정확히 어떤 일을 할지를 정하는 것에 대해서는 융통성을 가질 수 있게 한다.
스프린트 목표 또한 일관성을 유지하고 집중할 수 있게 하며, 스크럼 팀이 독립적으로 일하기 보다는함께 일하는 것을 장려한다.
스프린트 목표는 스프린트 계획 이벤트 동안에 정해져서 스프린트 백로그에 추가된다. 스프린트동안 개발자들은 스프린트 목표를 계속해서 유념하며 일을 해야 한다. 만약 기대했던 것과는 다르게16업무가 수행되고 있으면, 개발자들은 프로덕트 오너와 함께 스프린트 목표에는 영향을 주지 않는선에서 이번 스프린트의 스프린트 백로그 범위를 협상해야 한다.

증가분증가분은 프로덕트 목표로 향하는 단단한 디딤돌 역할을 한다. 각각의 증가분은 모든 이전에 누적된증가분에 더해진다. 모든 증가분들이 합쳐져서 함께 작동하는 것을 보장할 수 있을 만큼 철저하게검증된 것이어야 한다. 가치를 제공하기 위해 증가분은 반드시 사용 가능한 것이어야 한다.
한 스프린트 내에 복수의 증가분들이 만들어질 수 있다. 증가분들의 합은 스프린트 리뷰 때에소개되어 경험주의를 가능하게 한다. 하지만, 증가분은 스프린트의 종료 전에 이해관계자에게전달될 수 있으므로, 스프린트 리뷰를 가치의 증가분을 배포하기 위한 관문으로 여겨서는 안된다.
수행한 업무가 완료의 정의를 충족하지 않으면 증가분에 포함될 수 없다.

약속: 완료의 정의완료의 정의는 증가분이 프로덕트에 요구된 품질 기준을 충족하는 상태를 정식으로 표현하는말이다.
하나의 프로덕트 백로그 아이템이 완료의 정의를 충족하는 순간에 하나의 증가분이 탄생한다.
완료의 정의는 어떤 일을 완료된 증가분으로 간주할 수 있는지 모두와 이해를 공유함으로써
투명성을 높인다. 만약 프로덕트 백로그 아이템이 완료의 정의를 충족하지 않으면, 그것을배포하거나 스프린트 리뷰 때 보여줄 수 없다. 대신 나중에 고려할 수 있게 프로덕트 백로그로되돌려 보낸다.
증가분에 대한 완료의 정의가 조직의 표준에 속하는 경우에는 모든 스크럼 팀들은 반드시 최소한이것을 기본으로 따라야 한다. 반면에 조직의 표준이 아닌 경우에는 스크럼 팀은 반드시 프로덕트에적절한 완료의 정의를 만들어야 한다.
개발자들은 완료의 정의를 따라야 한다. 만약에 하나의 프로덕트를 복수의 스크럼 팀들이 함께작업한다면, 그들은 반드시 동일한 완료의 정의를 공동으로 정의하고 준수해야 한다.
17마침글
스크럼은 무료이며 이 가이드를 통해 제공하고 있다. 여기에 서술된 스크럼 프레임워크는 변경할 수없다. 스크럼의 일부만을 시행하는 것은 가능하지만, 그것을 스크럼이라고 할 수는 없다. 스크럼은가이드를 완전히 수행하는 것만 스크럼이라 할 수 있으며 다른 기법, 방법론, 실천법들을 담는컨테이너 로서도 잘 활용할 수 있다.

감사의 말사람
스크럼에 기여한 수천 명의 사람들 중에, 우리는 초창기에 중요한 역할을 했던 사람들을 선정해야한다: 제프 서덜랜드 Jeff Sutherland 는 제프 맥케나 Jeff McKenna, 존 스컴니오테일즈 John
Scumniotales 와 작업을 하였고, 켄 슈와버 Ken Schwaber 는 마이크 스미스 Mike Smith, 크리스 마틴
Chris Martin 과 작업을 하였으며, 그리고 다른 모든 이들이 함께 작업을 하였다. 많은 다른 사람들이뒤이어 기여를 하였으며, 그들의 도움이 없었다면 스크럼은 지금처럼 개선되지 못했을 것이다.

스크럼 가이드의 역사켄 슈와버와 제프 서덜랜드는 1995 년에 OOPSLA 컨퍼런스에서 스크럼을 처음으로 공동 발표하였다.
그 이전에 켄과 제프가 수년에 걸쳐 학습한 핵심 내용을 문서화 한 것으로, 대중에 공개한 첫 번째공식적인 스크럼의 정의였다.
스크럼 가이드는 제프 서덜랜드와 켄 슈와버에 의해 30 년이 넘는 시간동안 발전하고 진화하며지속되어 온 스크럼 문서화 작업의 결과물이다. 이 밖의 자료들은 스크럼 프레임워크를 보완하는패턴, 프로세스, 통찰을 제시하고 있는데, 이를 활용하여 생산성과 가치, 창조성, 결과에 대한만족도를 높일 수 있다.
스크럼의 완전한 역사는 다른 곳에 기술되어 있다. 가장 먼저 스크럼을 시도하고 증명한 것으로우리가 인정하고 있는 Individual Inc., Newspage, Fidelity Investments, IDX (현 GE Medical) 에 영광을돌린다.

18한국어 번역자 감사의 말본 스크럼 가이드 (2020) 한글판은 위 감사의 말에 소개된 개발자들로부터 제공된 영어 원문을번역한 것이다. 번역 참여자는 김영민 Youngmin Kim, 박종하 Jonghah Park, 조동형 Donghyung
Cho 이며, 박찬희 Chanhee Park 와 강필승 Philseung Kang 이 리뷰를 하였다.
대표 연락처: 김영민 francis.youngmin.kim@gmail.com
이전 버전의 한글판 번역자들에게도 감사를 드린다.
2013, 2017 : Scrum Korean ( scrum-korean1@googlegroups.com - 유을수 Sue Ryu, 김재욱 Jae Kim,백미진 Mijin Baek )용어집원문 단어번역한 표현원문 단어번역한 표현Adaptation

적응Product Backlog

프로덕트 백로그Artifacts

산출물Product Backlog Item프로덕트 백로그 아이템Backlog Refinement백로그 정제Product Goal프로덕트 목표Commitment

약속Product Owner프로덕트 오너Container컨테이너Scrum스크럼

Cross-functional교차기능적

Scrum Events스크럼 이벤트

Daily Scrum데일리 스크럼

Scrum Master스크럼 마스터

Definition of Done완료의 정의Scrum Team스크럼 팀Developers개발자들Self-Management

자율관리Empirical

경험주의적

Sprint스프린트

Empiricism

경험주의Sprint Backlog

스프린트 백로그Focus

집중

Sprint Goal스프린트 목표

Increment증가분

Sprint Planning스프린트 계획Inspection점검Sprint Retrospective스프린트 회고Openness열린 마음

Sprint Review스프린트 리뷰

Practice실천법Transparency투명성Product프로덕트Work할 일, 업무19

2017 스크럼 가이드에서 2020 스크럼 가이드로의 변경 사항더 적어진 지시적인 표현스크럼 가이드는 시간이 흐르면서 조금씩 더 지시적이 되었다. 2020 버전은 지시적인 표현을 삭제하거나부드럽게 표현하여 스크럼이 프레임워크로서 최소한으로도 충분하도록 되돌리는 것을 목표로 하였다.
예를 들어, 데일리 스크럼의 질문들을 삭제, 프로덕트 백로그 아이템의 속성들에 대해 부드럽게 표현,스프린트 백로그 속의 회고 아이템에 대해 부드럽게 표현, 스프린트 취소 부분에 대해 부드럽게 표현한 것등이다.

하나의 프로덕트에 집중하는 하나의 팀이것의 목적은 한 팀 안에서 프로덕트 오너와 개발팀 Dev Team 사이를 “대리인 proxy”이나 “우리와그들”로 나누어 행동하게 하는 개념을 제거하는 것이었다. 이제는 동일한 목표에 집중하는 각기 다른 세가지의 직책으로 이루어진 단 하나의 스크럼 팀만이 있다: 프로덕트 오너 PO, 스크럼 마스터 SM, 개발자들Developers프로덕트 목표의 도입2020 스크럼 가이드는 스크럼 팀이 더 큰 가치의 목표에 집중할 수 있게 하는 프로덕트 목표 개념을도입한다. 매 스프린트는 프로덕트를 전체 프로덕트 목표에 더 가깝도록 만들어야 한다.

스프린트 목표와 완료의 정의, 프로덕트 목표가 속하는 곳 Home이전의 스크럼 가이드는 스프린트 목표와 완료의 정의에 대해 확실한 정체성을 두지 않고 설명하고 있었다.
그것들은 특정한 산출물은 없으면서도 어느 정도는 산출물에 종속되었다. 프로덕트 목표의 추가와 함께,2020 버전은 이 부분에 보다 더 명확함을 제시한다. 세 가지 산출물 각각은 이제 ‘약속’을 담고 있다.
프로덕트 백로그에는 프로덕트 목표가, 스프린트 백로그에는 스프린트 목표가, 증가분에는 완료의정의(이제는 따옴표를 쓰지 않는다)가 그 약속으로 포함된다. 이것은 각 산출물의 투명성을 높이고 진척을내기 위한 집중을 하게 한다.

자율조직 Self-Organizing 을 넘어 자율관리 Self-Managing 로이전의 스크럼 가이드는 개발팀을 누가 어떻게 일을 할 것인지 정하는 자율조직으로 언급하였다. 2020버전에는 보다 더 스크럼 팀에 초점을 맞추어 누가 어떻게 어떤 일을 할 것인지 결정하는 자율관리를강조한다.

20스프린트 계획의 세 가지 주제기존 스프린트 계획의 주제인 “무엇”과 “어떻게”에 추가적으로 2020 스크럼 가이드는 스프린트 목표가되는 세 번째 주제인 “왜”를 강조한다.

더 다양한 독자들을 위한 전반적인 표현의 순화2020 스크럼 가이드는 불필요하고 복잡한 표현들을 제거할 뿐만 아니라 IT 업무(예를 들어, 테스팅 Testing,시스템 System, 디자인 Design, 요구사항 Requirement 등)로 여겨질 수 있는 어떠한 표현들도 남지 않도록제거하는 데에 중점을 두었다. 스크럼 가이드는 이제 13 페이지(영어 원문 기준) 밖에 되지 않는다.

21