스크럼 가이드™
스크럼에 대한 확실한 가이드:
게임의 규칙
개발하고 유지하는 건스크럼 제작자인 켄 슈와버와 제프 서더랜드가 함.
목차
스크럼 가이드의 목적..................................................................................................................... 3
스크럼의 정의.................................................................................................................................. 3
스크럼의 사용.................................................................................................................................. 4
스크럼 이론..................................................................................................................................... 4
스크럼의 가치들.............................................................................................................................. 6
스크럼 팀......................................................................................................................................... 7
제품 책임자................................................................................................................................. 7
개발팀 .......................................................................................................................................... 8
스크럼 마스터.............................................................................................................................. 9
스크럼 이벤트 모임 ...................................................................................................................... 10
스프린트..................................................................................................................................... 10
스프린트 계획............................................................................................................................ 12
일일 스크럼............................................................................................................................... 14
스프린트 리뷰............................................................................................................................ 15
스프린트 회고 미팅 .................................................................................................................. 16
스크럼 산출물................................................................................................................................ 17
제품 백로그............................................................................................................................... 17
스프린트 백로그........................................................................................................................ 18
제품 증분................................................................................................................................... 19
산출물 투명성................................................................................................................................ 20
“완료”의 정의............................................................................................................................ 20
맺음말 ............................................................................................................................................ 21
감사의 말....................................................................................................................................... 21
사람............................................................................................................................................ 21
번역............................................................................................................................................ 21
역사............................................................................................................................................ 22
스크럼 가이드 2016 년 기준 2017 년도 변경 내역 ................................................................... 23
스크럼은 복잡한 제품을 개발하고, 배포하고, 유지하는 데 사용할 수 있는 프레임워크입니다.
본 가이드는 스크럼의 정의를 설명하고 있으며, 이는 스크럼 구성원의 역할, 이벤트, 산출물
그리고 이들을 하나로 묶을 수 있는 규칙들로 구성됩니다. 켄 슈와버(Ken Schwaber)와 제프
서더랜드(Jeff Sutherland)가 스크럼을 개발하였고, 본 스크럼 가이드는 그들이 작성하여
제공하고 있습니다. 본 가이드는 그들의 책임으로 후원되고 있습니다.
스크럼 (명사): 가장 가치 있는 제품을 생산적이고 창의적으로 배포하기 위하여 복잡하게
얽힌 적응적 문제들(complex adaptive problems)을 다룰 수 있도록 하는 프레임워크.
스크럼은:
• 간단하고,
• 이해하기 쉽지만,
• 마스터하기는 어려운 프레임워크 입니다
스크럼은 1990 년대 초반부터 복잡한 제품에 대한 작업을 관리하는 데 사용된 프로세스
프레임워크입니다. 스크럼은 프로세스나 테크닉 혹은 규정된 방법론은 아닙니다. 오히려
다양한 프로세스와 테크닉들을 사용하는 데 도움을 주는 프레임워크입니다. 스크럼은 제품
관리와 실제 작업 기술의 상대적인 능률의 차이를 분명하게 보여 줌으로써 제품과 팀, 작업
환경을 지속해서 개선할 수 있습니다.
스크럼 프레임워크는 스크럼 팀과 그들이 관련된 역할, 이벤트, 산출물, 그리고 규칙들로
구성됩니다. 프레임워크의 각 구성 요소들은 특정한 사용 목적이 있으며 이는 스크럼을
성공적으로 수행하기 위한 필수 요소들입니다.
스크럼의 규칙들은 역할, 이벤트, 산출물들이 서로 간의 관계와 상호작용에 따라 유기적으로
운영되도록 결합하는 역할을 합니다. 이러한 스크럼의 규칙들은 본문에서 계속 다뤄질
것입니다.
스크럼 프레임워크를 사용하기 위한 구체적인 전략들은 매우 다양하므로 본 문서에서
개별적으로 다루지는 않습니다.
스크럼은 맨 처음 제품을 관리하고 개발하려고 만들어졌습니다. 1990 년대 초반에 시작된
스크럼은 전 세계적으로 널리 사용되고 있습니다.
1. 실행 가능한 시장과 기술, 제품 기능을 조사하고 식별합니다.
2. 제품과 개선사항을 개발합니다.
3. 하루에도 여러 번, 자주, 제품과 개선사항을 배포합니다.
4. 제품 사용을 위해 클라우드(온라인, 보안, 주문형)와 기타 운영 환경을 개발하고
살아있게 합니다.
5. 제품을 유지하고 살아있게 합니다.
스크럼은 개인과 사회에서, 소프트웨어 개발뿐 아니라 하드웨어, 임베디드 소프트웨어, 상호
작용 기능의 네트워크, 자율주행 차량, 학교, 정부, 마케팅, 조직 운영 및 일상생활에서
사용되고 있습니다.
기술과 시장, 환경의 복잡성과 그들 간에 상호 작용이 급격하게 증가함에 따라 복잡성을
다루는 스크럼의 유용함이 매일 증명됩니다.
스크럼은 반복적이고 점진적인 지식 이전에 특히 효과적이라는 것을 증명했습니다. 스크럼은
이제 제품, 서비스, 상위 조직 관리에 널리 사용됩니다.
각각의 팀은 매우 유연하고 적응력이 뛰어납니다. 이러한
강점은 수천 명의 작업과 작업 제품을 단일팀, 몇 개 팀, 많은 팀 그리고 네트워크 팀 안에서
개발하고, 출시하고, 운영하고, 지속시키는 것이 계속 운영되도록 합니다. 그들은 정교한 개발
구조와 타겟의 배포 환경을 통해 협업하고 상호운용합니다.
본 스크럼 가이드에서 "개발하다(develop)" 혹은 "개발(development)"이라는 용어를 사용하는
경우, 앞서 언급한 유형과 같은 복잡한 작업을 의미합니다.스크럼의 핵심은 작은 팀입니다.
스크럼은 경험적 프로세스 관리 이론, 혹은 경험주의(empiricism) 이론에 기반을 두고
있습니다. 경험주의 이론에 의하면 지식은 경험과 우리가 이미 알고 있는 것에 기반을 둔
의사 결정으로부터 온다고 여겨집니다. 스크럼은 예측을 최적화하고 위험요소를 제어하기
위해 반복적(iterative)이고 점진적인(incremental) 접근 방법을 사용합니다.
경험적 프로세스 관리를 수행하는 데 필요한 세 가지 축은 투명성(transparency),
검토(inspection), 그리고 적응(adaptation)입니다.
투명성 (Transparency)
프로세스의 중요한 부분들은 결과에 대한 책임이 있는 사람들에게 반드시 가시화되어야
합니다. 투명성은 프로세스의 중요한 부분들을 공통 표준으로 정의함으로써, 검토자들은
무엇이 보이는지에 대하여 공통된 이해를 공유하도록 합니다.
예를 들면,
• 프로세스에 사용되는 공통 언어를 모든 참여자가 반드시 공유해야 하고,
• 작업을 수행하는 사람들과 점진적 작업 결과를 검토하는 사람들은 “완료(Done)”에 대한
공통된 정의를 공유해야 합니다.
검토 (Inspection)
스크럼 사용자들은 주기적으로 스크럼 산출물을 검토하여 변경 사항을 찾아내야 합니다.
이러한 검토 과정을 일에 방해가 될 정도로 너무 자주 해서는 안 됩니다. 산출물을 검토하는
것은 작업이 진행되는 시점에 숙련된 검토자에 의해 성실하게 이루어질 때 가장
효과적입니다.
적응 (Adaptation)
만약 사용되는 프로세스가 허용 기준 한도를 넘어 결과 제품이 승인되지 않을 것을 검토자가
확인했다면, 그 프로세스나 진행 중인 작업을 조정하는 과정이 필요합니다. 이러한 조정
작업은 이탈(deviation)을 최소화하기 위해 가능한 한 빠르게 이루어져야 합니다.
스크럼에서는 검토와 적응을 위하여 스프린트 안에 다음 네 가지의 공식적인 이벤트(미팅)를
규정하고 있으며, 이는 본 문서의 스크럼 이벤트 모임(the Scrum Events) 섹션에 기술되어
있습니다.
• 스크럼 계획
• 일일 스크럼
• 스프린트 리뷰
• 스크럼 회고
스크럼의 가치들
스크럼 팀이 약속, 용기, 집중, 개방성, 존중의 가치들을 체화하였을 때 스크럼의 핵심축인
투명성, 검토, 적응이 자리를 잡게 되고 팀의 모든 사람 간의 신뢰가 쌓이게 됩니다. 스크럼
팀원들은 스크럼 이벤트, 역할, 산출물들을 가지고 일하면서 이러한 가치들을 배우고
탐구합니다.
스크럼을 잘 사용하는 것은 이 다섯 가지 가치들을 얼마나 더 잘 터득하느냐에 따라
좌우됩니다. 스크럼 팀의 개개인들은 팀의 목표를 달성하고자 책임감을 느끼고 일을 합니다.
스크럼 팀원들은 올바른 것을 수행하기 위한 용기를 가지고 어려운 문제들을 해결합니다.
모든 사람은 스프린트의 일과 스크럼 팀의 목표에 집중합니다. 스크럼 팀과 프로젝트에
관련된 모든 사람은 프로젝트에 필요한 일들과 그것을 달성하기 위해 넘어야 할 난관들이
투명하게 공유될 것을 함께 동의합니다. 스크럼 팀원들은 각자가 독립적이고 일을 성취할
능력이 있음을 서로 존중합니다.
스크럼 팀
스크럼 팀은 제품 책임자, 개발팀, 스크럼 마스터로 구성되어 있습니다. 스크럼 팀은 자기
조직화 (self-organizing) 되어 있으며 교차 기능적(cross-functional)입니다. 자기 조직화한
팀들은 외부의 누군가에 의해 지시 당하기보다는, 팀의 작업을 어떻게 하면 최상으로
수행할지 스스로 선택합니다. 교차 기능팀은 팀 외부의 누군가에 의지하지 않고 자신들의
작업을 수행하는 데 필요한 모든 주요 역량을 소유하고 있습니다. 이러한 스크럼 팀의 모습은
유연성(flexibility)과 창의성 (creativity), 생산성(productivity)을 최적화하기 위하여
설계되었습니다. 스크럼 팀이 앞에서 서술한 스크럼의 사용들, 그리고 복잡한 작업에도 아주
효과적으로 적용되는 것이 입증되었습니다.
스크럼 팀은 피드백의 기회를 극대화하기 위해 반복적(iteratively)이고 점진적으로 제품을
배포합니다. 매 스프린트에서 “완료"된 기능의 증분을 지속해서 추가하여 제품을 배포
(incremental deliveries)하는 것은 잠재적으로 유용하고 사용할 수 있는 제품이 언제든지
있다는 것을 보장합니다.
제품 책임자
제품 책임자는 제품의 가치와 개발팀의 작업 결과를 최상으로 만들 책임을 갖습니다. 이
역할을 어떻게 수행할 것인지는 조직, 스크럼 팀, 혹은 개인에 따라 매우 다양한 방법이 있을
수 있습니다.
제품 책임자는 제품 백로그 관리를 담당하는 유일한 사람입니다. 제품 백로그 관리는 다음과
같습니다.
• 제품 백로그 항목들을 분명하게 설명;
• 목표와 미션을 가장 성공적으로 달성할 수 있도록 제품 백로그에 있는 항목들을 우선 순위화;
• 개발팀이 수행하는 작업의 가치를 최적화;
• 제품 백로그가 가시적이고, 투명하고, 모두가 이해했는지를 확인하고, 스크럼 팀이 다음 스프린트에 무슨 작업을 해야 하는지 제시;
• 개발팀이 제품 백로그 항목들에 대하여 필요한 만큼 올바르게 이해하고 있는지 확인.
위에 언급된 항목들은 제품 책임자가 수행하거나 개발팀이 수행할 수도 있지만, 최종 책임은
제품 책임자에게 있습니다.
제품 책임자는 한 사람이지 위원회가 아닙니다. 제품 책임자는 제품 백로그에 대하여
위원회가 원하는 것을 대변할 수는 있지만, 위원회 멤버가 제품 백로그 항목의 우선순위를
변경하길 원할 경우에는 반드시 제품 책임자를 설득해야 합니다.
제품 책임자가 본인의 일을 성공적으로 수행하기 위해서는 조직의 모든 사람이 제품
책임자의 결정을 존중해 주어야 합니다. 제품 책임자의 결정은 그 내용이 잘 보여야 하고
제품 백로그에 우선순위가 정해져 있어야 합니다. 개발팀에게 다른 요구 사항으로 작업하도록
강요할 수 있는 사람은 아무도 없습니다.
개발팀
개발팀은 매 스프린트에서 “완료”된 기능을 지속해서 추가하여 잠재적으로 출시 가능한
제품을 배포할 수 있는 전문가들로 구성됩니다. 이러한 “완료"된 기능은 스프린트 리뷰를
위해 필수적입니다. 그리고 이 점진 개발 과정에는 오직 개발팀 멤버들만 참여할 수
있습니다.
개발팀은 스스로 일을 구성하고 관리할 수 있는 조직으로 구성될 뿐만 아니라 이러한 권한도
위임받았습니다. 그 결과로 얻어진 시너지 효과는 개발팀 전체의 능률과 효과를
최적화합니다.
개발팀은 다음과 같은 특성이 있습니다.
• 개발팀은 자기 조직화 팀입니다. 스크럼 마스터를 포함하여 누구도 어떻게 해야 제품
백로그를 출시 가능한 기능이 되도록 점진적으로 만들어낼지 개발팀에 지시할 수
없습니다.
• 개발팀은 완성된 기능을 점진적으로 추가하여 제품을 만드는 데 필요한 모든 기술이 있는
교차 기능 팀입니다.
• 스크럼에는 각자 수행하는 일에 상관없이 개발팀 멤버들이 별도의 다른 직함은 가지지
않습니다.
• 스크럼에는 개발팀 안에 하위 팀(sub-teams)이 없습니다. 설령, 테스트, 아키텍처, 운영,
또는 비즈니스 분석과 같은 도메인에 대한 지식이 필요하더라도 하위 팀을 따로 두지
않습니다.
• 개발팀 내의 각 개발자는 특정 기술이나 전문 분야가 있을 수 있지만, 제품에 대한
책임은 개발팀 전체에 있습니다.
개발팀 크기
최적의 개발팀 크기는 민첩하게 대응할 수 있도록 충분히 작고, 한 스프린트 안에서 의미
있는 작업을 끝낼 수 있을 정도로 충분히 커야 합니다. 3 명 미만의 개발팀은 서로 간의
교류가 적기 때문에 결과적으로 적은 생산성을 얻게 됩니다. 작은 규모의 개발팀은 팀 내부에
필요한 기술 역량이 없을 수 있으므로 스프린트를 수행하는 동안 기술적인 제약이 발생하여
출시할 수 있는 기능이 포함된 제품 증분을 배포하지 못할 수도 있습니다. 9 명 이상의
개발팀은 너무 많은 상호 협조를 요구합니다. 큰 규모의 개발팀은 경험적 프로세스를
활용하기에는 너무 복잡합니다. 제품 책임자와 스크럼 마스터는 그들이 스프린트 백로그
작업에 참여하지 않는 이상 개발팀 인원수에 포함되지 않습니다.
스크럼 마스터
스크럼 마스터는 스크럼 가이드에 따라 스크럼을 장려하고 지원할 책임을 갖습니다. 이를
위해, 스크럼 마스터들은 모두가 스크럼의 이론과 실천, 규칙, 그리고 가치들을 잘 이해할 수
있도록 도와야 합니다.
스크럼 마스터는 스크럼 팀을 도와주는 리더(servant-leader)입니다. 스크럼 마스터는 스크럼
팀 외부에 있는 이들이 스크럼 팀과 어떤 상호작용이 도움 되고, 어떤 것이 도움 되지
않는지에 대한 이해를 돕는 역할을 합니다. 스크럼 마스터는 이러한 사람들 간의 상호작용이
스크럼 팀에서 만들어낸 제품의 가치가 최상이 되는 방향으로 바뀔 수 있도록 도움을 줍니다.
스크럼 마스터가 제품 책임자를 위해 하는 일들
스크럼 마스터는 제품 책임자를 다음과 같은 여러 방법으로 도와야 합니다.
• 목표, 개발 및 제품 도메인을 스크럼 팀의 모든 사람이 이해할 수 있도록 확인;
• 제품 백로그를 효과적으로 관리하기 위한 기술 찾기;
• 제품 백로그 항목들이 명확하고 간결할 필요가 있다는 것을 스크럼 팀이 이해할 수
있도록 도움;
• 경험적인 환경(empirical environment)에서 사용하는 제품 계획을 이해;
• 최상의 가치를 내기 위해 제품 백로그를 어떻게 조정해야 할지를 제품 책임자가 알고
있는지 확인함;
• 애자일(agility)의 이해와 실행;
• 요청이나 필요에 따라 스크럼 이벤트를 원활하게 진행.
스크럼 마스터가 개발팀을 위해 하는 일들
스크럼 마스터는 개발팀을 다음과 같은 여러 방법으로 도와야 합니다.
• 자기 조직화한 교차 기능 팀으로 거듭나기 위한 개발팀 코칭;
• 개발팀이 가치 있는 제품들을 만들어 낼 수 있도록 도움;
• 개발팀의 개발 진행에 있어 장애 요소들을 제거;
• 요청이나 필요에 따라 스크럼 이벤트를 원활하게 진행;
• 스크럼이 아직 완전히 자리 잡지 않고 이해되지 않은 조직 환경에서의 개발팀 코칭.
스크럼 마스터가 조직을 위해 하는 일들
스크럼 마스터는 조직을 다음과 같은 여러 가지 방법으로 도와야 합니다.
• 해당 조직에 스크럼이 잘 자리 잡을 수 있도록 안내하고 코칭;
• 조직 내에서 스크럼 실행을 계획;
• 직원 및 이해 관계자들이 스크럼과 경험적 제품 개발에 대해 잘 이해하고 확립할 수
있도록 도움;
• 스크럼 팀의 생산성을 향상하기 위한 변화 만들기;
• 조직에서 스크럼 적용의 효과를 높이기 위해 다른 스크럼 마스터들과 협력.
스크럼 이벤트 모임
스크럼은 정해진 이벤트 미팅을 정기적으로 가짐으로써 스크럼에 정의되지 않은 다른 미팅을
최소화합니다. 모든 이벤트 모임은 정해진 시간(time-boxed) 안에 끝내야 하며, 각 이벤트는
최대 소요 시간이 정해져 있습니다. 일단 스프린트가 시작되면, 그 소요 시간은 고정되어
줄어들거나 늘어날 수 없습니다. 이벤트 미팅의 목적이 달성되면 정해진 시간 전에 미팅을
끝낼 수 있습니다. 단, 프로세스 내에 시간 낭비 없이 충분한 시간이 사용되었음을 보장해야
합니다.
스프린트 내에 포함된 각각의 스크럼 이벤트들은 무엇인가를 검토하고 적응하기 위한
공식적인 기회입니다. 이러한 이벤트들은 투명성과 검토할 수 있도록 특별히 설계되었습니다.
이들 중 하나라도 빠진다면, 투명성이 감소하고 검토와 적응할 기회를 잃게 됩니다.
스프린트
스프린트는 스크럼의 핵심으로, 한 달 또는 그 미만의 정해진 시간 동안 계획한 기능들을
“완료”하여 사용할 수 있고 출시 가능한 “제품 증분”으로 만들어 냅니다. 스프린트는
일반적으로 전체 개발 기간에 변하지 않는 고정된 기간으로 진행됩니다. 새로운 스프린트는
그 이전 스프린트가 끝남과 동시에 시작됩니다.
스프린트는 스프린트 계획, 일일 스크럼, 개발 작업, 스프린트 리뷰, 스프린트 회고로
구성됩니다.
스프린트 동안,
• 스프린트 목표를 이루는데 위협을 줄 수 있는 어떠한 변경도 허용되지 않습니다.
• 제품의 품질 목표를 낮추지 않습니다.
• 스프린트가 진행되면서 개발 범위에 대한 이해가 커짐에 따라, 개발팀은 제품 책임자와
함께 개발 범위를 명확히 하거나 재협상할 수 있습니다.
각 스프린트는 한 달 미만의 프로젝트라고 할 수 있습니다. 프로젝트처럼 스프린트를 통해
무엇인가를 성취합니다. 각 스프린트에는 무엇을 만들 것인지에 대한 목표, 그것을 만들기
위해 어떻게 설계하고 유연한 계획을 세워갈지, 그리고 작업내용과 점진적 결과 제품이
있어야 합니다.
스프린트는 최대 한 달로 제한됩니다. 스프린트 기간이 너무 길어지면 무엇을 만들어야
하는지에 대한 정의가 변하거나, 복잡도가 증가하거나, 위험이 증가할 수 있습니다.
스프린트는 적어도 매달의 진행 상황에 대한 검토와 적응을 보장하기 때문에 제품에 대한
예측이 가능합니다. 또한, 스프린트는 한 달 미만의 비용으로 위험을 제한할 수 있습니다.
스프린트의 취소
스프린트는 스프린트 기간이 종료되기 전에 취소될 수 있습니다. 단, 제품 책임자만이
스프린트를 취소할 권한을 가지고 있지만, 제품 책임자가 제품 이해 관계자들이나 개발팀,
혹은 스크럼 마스터의 영향을 받아 스프린트 취소를 결정할 수도 있습니다.
만약 스프린트 목표가 더는 유효하지 않다면 스프린트가 취소될 수 있습니다. 이러한 상황은
회사가 추구하는 방향이 바뀌거나, 시장이나 기술의 상황이 바뀌었을 경우 발생할 수
있습니다. 일반적으로는 주어진 상황에 스프린트가 더는 의미가 없어졌을 때 취소되어야
합니다. 하지만 스프린트 기간이 짧은 것 때문에 취소하는 것은 사실상 거의 의미가
없습니다.
스프린트가 취소되면, 이미 완성되어 “완료”된 제품 백로그 아이템들을 검토합니다. 만약 그
작업물의 일부가 출시 가능한 상태이면, 제품 책임자는 일반적으로 그것들을 수용하고 제품에
포함합니다. 모든 미 완료 상태의 제품 백로그 아이템들은 재추정하여 제품 백로그 목록으로
다시 들어갑니다. 미 완료된 제품 백로그 아이템들을 위해 수행된 작업은 빠르게
쓸모없어지므로 재추정을 자주 해주어야 합니다.
스프린트를 취소하는 것은 모든 사람이 또 다른 스프린트를 시작하기 위하여 스프린트
계획에 재편성됨으로 리소스를 소비하게 됩니다. 스프린트의 취소는 종종 스크럼 팀에 큰
충격을 주지만, 이는 매우 드문 경우입니다.
스프린트 계획
스프린트에서 수행되어야 할 작업을 스프린트 계획 미팅에서 정합니다. 이 계획은 전체
스크럼 팀의 공동 작업으로 만들어집니다.
스프린트 계획은 1 개월 스프린트를 기준으로 최대 8 시간을 제안합니다. 더 짧은 스프린트를
위해서는 보통 더 짧은 스프린트 계획 미팅을 합니다. 스크럼 마스터는 팀이 스프린트 계획
미팅을 했는지, 모든 참여자가 그 목적을 제대로 이해했는지 확인해야 합니다. 스크럼
마스터는 스프린트 계획 미팅이 주어진 시간 안에 끝나도록 스크럼 팀을 교육합니다.
스프린트 계획은 다음의 질문에 답해야 합니다.
• 이 스프린트에서 배포 가능한 제품 증분은 무엇인가?
• 제품 증분을 성공적으로 배포하는 데 필요한 작업이 무엇인가?
첫 번째 토픽: 이번 스프린트에서 무엇을 할 수 있는가?
개발팀은 스프린트 동안 개발할 수 있는 기능을 예상하는 작업을 합니다. 제품 책임자는
스프린트에서 달성해야 할 목표와 그 목표 달성을 위해 스프린트에서 완료해야 할 제품
백로그 항목에 대해 개발팀과 토론합니다. 전체 스크럼 팀은 스프린트에서 해야 할 작업을 더
잘 이해할 수 있도록 서로 협력합니다.
스프린트 계획 미팅을 시작하려면 제품 백로그, 가장 최근의 제품 증분, 스프린트 동안의
개발팀 가용 인력 예상, 개발팀의 과거 생산성 자료가 준비되어야 합니다. 스프린트에서
개발할 제품 백로그 항목 수는 전적으로 개발팀이 결정합니다. 스프린트 동안 개발팀이
무엇을 얼마나 해낼 수 있을지는 개발팀 스스로만 평가할 수 있습니다. 개발팀이 이번
스프린트에서 완료할 제품 백로그 항목을 정한 다음에는 전체 스크럼 팀이 스프린트 목표를
정합니다.
스프린트 계획 미팅에서 스크럼 팀은 스프린트 목표를 작성합니다. 스프린트 목표는 제품
백로그를 구현함으로써 스프린트 동안 달성하고자 하는 목표입니다. 또, 이 목표는 개발팀이
왜 제품 증분을 만들고 있는지에 대한 가이드를 제공합니다.
두 번째 토픽: 선택된 작업을 어떻게 완료하나?
스프린트 목표를 정하고 스프린트에서 수행할 제품 백로그 아이템을 선택한 후, 개발팀은
이번 스프린트에서 이 기능들을 어떻게 “완료”된 제품 증분으로 구현할지 결정합니다.
스프린트에서 선택된 제품 백로그 아이템과 그것들을 완료하여 배포하기 위한 계획을 합쳐
스프린트 백로그라고 부릅니다.
개발팀은 일반적으로 제품 백로그를 작동하는 제품 증분으로 만드는 데 필요한 시스템과
작업을 설계하는 것부터 시작합니다. 이러한 작업의 크기나 예상되는 노력은 다양할 수
있습니다. 그러나, 개발팀은 다음 스프린트에서 수행할 수 있다고 생각되는 것들을 예측하여
스프린트 계획 미팅에서 충분한 양의 작업을 계획합니다. 미팅을 마치기 전에 개발팀은
스프린트 첫날에 작업할 일들을 하루 혹은 그 미만의 시간 단위로 계획합니다. 개발팀은
스프린트 계획 미팅 동안 그리고 스프린트 진행 중 스프린트 백로그의 작업을 각자 맡아
수행하도록 자율적으로 조직, 운영합니다.
제품 책임자는 스프린트에 선택된 제품 백로그 항목들을 명확히 하고, 절충안(trade-offs)을
찾는 데 도움을 줄 수 있습니다. 작업량이 너무 많거나 너무 적을 경우, 개발팀은 제품
책임자와 제품 백로그 항목들을 재협상할 수 있습니다. 개발팀은 기술이나 전문지식에 대한
조언을 얻기 위하여 다른 사람들을 미팅에 초대할 수 있습니다.
스프린트 계획 미팅을 끝나기 전에, 개발팀은 자기 조직화 팀으로서 스프린트 목표를
달성하기 위해 어떻게 작업할 것이고 어떻게 예상되는 제품 증분을 만들어 낼 것인지 제품
책임자와 스크럼 마스터에게 설명할 수 있어야 합니다.
스프린트 목표
스프린트 목표는 제품 백로그 항목을 개발함으로써 이루어질 수 있습니다. 이러한 목표는
개발팀이 왜 제품 증분을 만들고 있는지에 대한 가이드를 제공합니다. 이 목표는 스프린트
계획 미팅에서 정합니다. 스프린트 목표는 개발팀에게 스프린트에서 개발할 기능에 대하여
약간의 유연성을 제공합니다. 선택된 제품 백로그 항목들은 하나의 일관된 기능이 되고,
이것이 종종 스프린트 목표가 될 수 있습니다. 또한, 스프린트 목표는 개발팀이 별도로
일하지 않고 함께 일할 수 있도록 묶어주는 역할을 합니다.
개발팀은 작업을 진행하면서 스프린트 목표를 늘 염두에 두어야 합니다. 스프린트 목표를
달성하기 위해 개발팀은 기능과 기술을 구현합니다. 스프린트 진행 중, 만약 그 작업이
개발팀이 예상했던 것과 다른 경우, 개발팀은 이번 스프린트에서 진행하기로 했던 스프린트
백로그를 제품 책임자와 재협상합니다
일일 스크럼
일일 스크럼은 개발팀을 위해 15 분으로 시간이 고정된 미팅입니다. 일일 스크럼은 스프린트
진행 중에 매일 모여서 개발팀이 다음 24 시간 동안 해야 할 작업을 계획합니다. 이 미팅은
지난 일일 스크럼 모임부터 수행한 작업을 검토하고 다음 스프린트 작업을 예측하여 팀
협업과 성능을 향상하게 됩니다. 일일 스크럼은 복잡성을 줄이기 위해 매일 같은 시각 같은
장소에서 이루어집니다.
개발팀은 일일 스크럼을 통해 스프린트가 목표에 맞게 진행이 되고 있는지, 또 스프린트
백로그에 있는 작업이 잘 완성되고 있는지 검토합니다. 일일 스크럼은 개발팀이 스프린트
목표를 달성할 수 있는 확률을 최적화합니다. 매일 일일 스크럼을 통해, 개발팀은 자기
조직화 팀으로서 스프린트 목표를 달성하기 위해 어떻게 함께 협력할 것이고, 이번
스프린트에서 예상했던 제품 증분을 만들어 낼 수 있을지 알고 있어야 합니다.
미팅의 구조는 개발팀이 정하며 스프린트 목표를 향한 진전에 초점을 맞춘다면 다양한
방식으로 수행될 수 있습니다. 일부 개발팀에서는 질문을 사용하고, 일부는 토론을 기반으로
합니다. 다음은 사용할 수 있는 예제입니다.
• 나는 어제 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 했는지?
• 나는 오늘 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 할 것인지?
• 나 혹은 개발팀이 스프린트 목표 달성을 하는데 방해요소가 있는지?
전체 개발팀이나, 팀원들은 종종 일일 스크럼 미팅이 끝나자마자 더 상세한 의논을 하거나
스프린트 작업에 대한 조정 및 재계획을 하기 위하여 추가적인 미팅을 할 수 있습니다.
스크럼 마스터가 개발팀이 일일 스크럼 미팅을 하도록 보장해야 하지만 미팅은 개발팀이
책임을 갖고 수행해야 합니다. 스크럼 마스터는 일일 스크럼 미팅이 15 분 안에 끝나도록
개발팀을 교육해야 합니다.
일일 스크럼은 개발팀을 위한 내부 미팅입니다. 스크럼 마스터는 다른 사람들의 참여가
미팅에 방해가 되지 않도록 보장해야 합니다.
일일 스크럼은 커뮤니케이션을 증진하고, 다른 추가적인 미팅들을 제거하고, 개발에 방해되는
요소들을 확인하여 없애고, 빠른 의사결정을 강조하고 촉진하며, 개발팀의 견문을 높여줍니다.
이것이 바로 스크럼의 핵심인 “검토와 적응” 미팅입니다.
스프린트 리뷰
스프린트 리뷰는 제품 증분을 검토하고, 필요에 따라 제품 백로그를 적합하게 수정하고자 매
스프린트의 끝에 수행합니다. 스프린트 리뷰에서 스크럼 팀과 제품 이해관계자들은 이번
스프린트에서 무엇이 완료되었는지에 대해 함께 확인합니다. 이 스프린트 리뷰 결과와
스프린트 수행 중 변경된 제품 백로그를 고려하여, 미팅 참석자들은 제품 가치를 최적화하기
위해 다음에 무엇을 해야 할지 함께 의논합니다. 이 스프린트 리뷰는 비공식 미팅입니다. 즉,
경과보고 미팅이 아니고 완료된 제품 증분을 발표함으로 피드백을 얻고 서로 간의 협력을
촉진하기 위한 미팅입니다.
스프린트 리뷰는 1 개월 스프린트를 기준으로 최대 4 시간을 제안합니다. 더 짧은 스프린트를
위해서는 보통 더 짧은 스프린트 리뷰 미팅을 합니다. 스크럼 마스터는 팀이 스프린트 리뷰
미팅을 했는지, 모든 참석자가 그 목적을 제대로 이해했는지 확인해야 합니다. 스크럼
마스터는 스프린트 리뷰 미팅이 주어진 시간 안에 끝나도록 스크럼 팀을 교육합니다.
스프린트 리뷰는 다음의 내용을 포함합니다.
• 미팅에는 스크럼 팀과 제품 책임자가 초대한 핵심 제품 이해관계자들이 참석합니다.
• 제품 책임자가 “완료”된 제품 백로그 아이템과 “완료”되지 못한 아이템을 설명합니다.
• 개발팀은 스프린트 동안 무엇이 잘 진행되었는지, 무슨 문제가 있었는지, 어떻게 문제들을
해결했는지 논의합니다.
• 개발팀은 “완료”된 작업을 시연하고 그 제품 증분에 대한 질문에 답변합니다.
• 제품 책임자는 현재 남아있는 제품 백로그를 설명하고, (필요하다면) 현재까지의 진행
상황을 바탕으로 가능한 예상 목표 및 제품 전달 날짜를 계획합니다.
• 전체 그룹이 다음에 무엇을 할지 함께 의논하여 스프린트 리뷰 미팅이 다음 스프린트
계획에 가치 있는 조언을 제공합니다.
• 제품의 시장이나 잠재적 사용처가 어떻게 변했는지 그리고 다음에 해야 할 가장 가치
있는 일들은 무엇인지 검토합니다.
• 다음 제품 출시 기능이나 성능에 대한 - 일정, 예산, 잠재적 기능, 그리고 시장에 대해
검토합니다.
스프린트 리뷰의 결과는 다음 스프린트에서 진행해야 할 제품 백로그를 재구성하는 것입니다.
제품 백로그는 새로운 기회를 위해 전체적으로 조정될 수 있습니다.
스프린트 회고 미팅
스프린트 회고 미팅은 스크럼 팀이 자신을 스스로 되돌아보고 다음 스프린트 동안 무엇을
개선할 수 있을지 계획할 기회를 제공합니다.
스프린트 회고 미팅은 스프린트 리뷰 미팅 후 그리고 다음 스프린트 계획 미팅 전에
수행됩니다. 이 미팅은 1 개월 스프린트를 기준으로 최대 3 시간을 제안합니다. 더 짧은
스프린트일 경우에 더 짧은 스프린트 회고 미팅을 합니다. 스크럼 마스터는 팀이 스프린트
회고 미팅을 했는지, 모든 참석자가 그 목적을 제대로 이해했는지 확인해야 합니다.
스크럼 마스터는 미팅이 긍정적이고 생산적으로 진행되도록 유지해야 합니다. 스크럼
마스터는 회고 미팅이 주어진 시간 안에 끝나도록 스크럼 팀을 교육해야 합니다. 스크럼
마스터는 스크럼 프로세스에 대한 책임을 갖고 개발팀의 동료 멤버로서 미팅에 참여합니다.
스프린트 회고 미팅의 목적은 다음과 같습니다.
• 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토;
• 잘 된 것들 그리고 개선의 여지가 있는 주요 항목들을 알아내고 순위화;
• 스크럼 팀이 작업을 수행하는 방법에 대한 개선을 실천할 수 있도록 계획을 수립.
스크럼 마스터는 스크럼 팀이 스크럼 프로세스 프레임워크 안에서 그 개발 프로세스와 실천
방안이 다음 스프린트에 좀 더 효과적이고 즐겁게 수행할 수 있도록 개선하는 것을
장려합니다. 각 스크럼 회고 미팅에서, 스크럼 팀은 제품 또한 조직 내 표준에 어긋나지 않는
한도에서 필요에 따라 작업 과정들을 개선하거나 “완료”의 정의를 조정함으로써 제품 품질을
높일 방법들을 계획합니다.
스크럼 회고 미팅이 끝날 무렵, 스크럼 팀은 다음 스프린트에 실천할 개선 사항들을 확인해야
합니다. 이러한 개선 사항들을 다음 스프린트에서 실천하는 것이 바로 스크럼 팀 자체를
검토하고 개선되는 방향으로 팀을 조정하는 것입니다. 비록 개선은 언제든지 이루어질 수
있지만, 스프린트 회고 미팅이 검토와 적응에 집중할 수 있는 공식적인 기회를 제공합니다.
스크럼 산출물
스크럼 산출물은 작업 또는 제품의 가치를 묘사함으로써 검토와 적응을 할 수 있도록
투명성과 기회를 제공합니다. 스크럼에서 정의된 산출물들은 주요 정보의 투명성을
최대화하여 모든 사람이 산출물에 대해 같은 이해를 하도록 구체적으로 설계됐습니다.
제품 백로그
제품 백로그는 제품에 필요하다고 알려진 모든 요구사항에 대한 우선 순위화된 목록입니다.
또한, 제품 백로그는 제품에 대한 모든 변경 요구사항을 포함하는 단 하나의 소스입니다.
제품 책임자가 제품 백로그 (내용, 가용성, 우선 순위화 등)에 대한 책임을 갖고 있습니다.
제품 백로그는 요구사항에 대한 완성본이 아닙니다. 제품 백로그의 초기 개발은 주로 팀이
이미 잘 알고 가장 잘 이해하고 있는 요구사항에 기반을 두어 이루어집니다. 제품 백로그는
제품으로 진화하고, 그 제품이 사용될 환경으로 함께 진화합니다. 제품 백로그는
유동적입니다. 제품 백로그는 시장에서 적합하고 경쟁력 있고 유용한 제품을 만드는 데
필요한 것이 무엇인지 파악하기 위해 끊임없이 변화합니다. 제품이 존재한다면, 제품
백로그도 존재합니다.
제품 백로그는 제품의 다음 배포에 추가로 포함될 모든 피처, 기능, 요구사항, 개선사항,
그리고 수정할 버그들을 나열합니다. 제품 백로그 항목들은 각각에 대한 설명, 우선순위, 예상
견적 등을 포함합니다. 제품 백로그 항목들은 종종 그것이 “완료"되었을 때 완료되었음을
증명해 줄 테스트에 대한 설명을 포함하고 있습니다. 제품이 사용되고 가치를 얻어 시장에서
피드백을 받으면서 제품 백로그는 커지고 더욱 완전해집니다. 요구사항은 항상 변하기 때문에
제품 백로그는 살아있는 산출물입니다. 비즈니스 요구사항이나 시장 환경, 기술 등의 변화는
제품 백로그의 변화를 일으킬 수 있습니다.
종종 여러 스크럼 팀들이 같은 제품을 만들기 위해 함께 일합니다. 그 제품을 만들기 위해
해야 할 작업을 설명하는데 단 하나의 제품 백로그가 사용됩니다. 어떤 제품 백로그 특성이
백로그 항목들을 그룹화하는 데 사용될 수 있습니다.
제품 백로그 상세화(Refinement)는 제품 백로그 항목들에 대한 상세한 내용, 견적, 그리고
우선순위를 추가하는 활동입니다. 이는 제품 책임자와 개발팀이 제품 백로그 항목들을
상세화하기 위해 협력하는 지속적인 과정입니다. 제품 백로그 상세화 중에, 각 항목을
검토하고 수정합니다. 스크럼 팀은 언제 어떻게 제품 백로그 상세화 작업을 완료할지
결정합니다. 상세화 작업을 위해서 보통 개발팀 전체 가용 시간의 10% 미만을 사용합니다.
하지만, 제품 백로그 아이템들은 제품 책임자의 재량에 따라 언제든지 업데이트될 수
있습니다.
높은 순위의 제품 백로그 항목들이 일반적으로 낮은 순위의 항목들보다 좀 더 명확하고
상세합니다. 제품 백로그 항목이 더 명확하고 상세할수록 더 정확한 개발 견적을 얻을 수
있고, 낮은 순위의 제품 백로그 일수록 상세화가 덜 되어 있습니다. 다음 스프린트를 위해
개발팀에 할당될 제품 백로그 항목들은 각 항목이 스프린트 기간 내에 합리적으로 “완료”될
수 있도록 다듬어집니다. 한 스프린트 내에 개발팀에 의해 “완료”될 수 있는 제품 백로그들은
스프린트 계획에서 선택할 수 있는 “준비된(Ready)” 항목들로 여겨집니다. 제품 백로그
항목들은 일반적으로 위에 기술된 상세화 단계들을 통해 “준비”된 항목으로서의 투명성을
얻게 됩니다.
개발팀은 모든 개발 견적에 대한 책임을 집니다. 제품 책임자가 개발팀의 이해를 돕고
절충안을 선택하는 데 도움을 줌으로써 예상되는 개발 견적에 영향을 끼칠 수는 있지만, 최종
견적은 실제 작업을 수행하는 사람들이 설정합니다.
목표를 향한 진행 상황 모니터링
전체 개발 목표에 도달하기 위해 남은 총작업량은 언제든지 계산될 수 있습니다. 제품
책임자는 적어도 스프린트 리뷰마다 남아있는 총작업량을 추적합니다. 제품 책임자는 목표로
한 날짜까지 작업을 완료하도록 진행 상황을 평가하기 위해 남아있는 총작업량을 이전
스프린트 리뷰에서 남아있던 작업량과 비교합니다. 이러한 정보는 제품과 관련된 모든 이해
관계자에 투명하게 공개됩니다.
번다운(burn-downs)이나 번업(burn-ups) 같은 다양한 트렌드 분석 예상 도구들이 진행
상황을 예측하기 위해 사용됩니다. 이러한 도구들이 유용하다고 알려져 있습니다만, 경험주의
이론의 중요성을 대체하지는 못합니다. 복잡한 환경에서는 무슨 일이 발생할지 알 수
없습니다. 단지 지금까지 이미 발생했던 일이 앞으로 의사 결정을 하는 데 사용될 수
있습니다.
스프린트 백로그
스프린트 백로그는 스프린트를 위해 선택된 제품 백로그 항목들의 집합이며 더불어 제품
증분을 배포하고 스프린트 목표를 실현하기 위한 계획서입니다. 스프린트 백로그는 무슨
기능이 다음 제품 증분에 포함될지, 그 기능을 “완료”된 제품 증분으로 배포하는 데 필요한
작업이 무엇인지를 개발팀이 예상한 작업 목록입니다.
스프린트 백로그는 개발팀이 스프린트 목표를 달성하는 데 필요한 모든 작업을 투명하게
보이도록 합니다. 지속적인 개선을 하기 위해 스프린트 백로그에 이전 회고 미팅에서 나온 첫
우선순위의 프로세스 개선 항목을 최소 하나 이상 포함합니다.
스프린트 백로그는 그 진행 상황을 일일 스크럼 미팅에서 이해할 수 있을 만큼 충분히
상세화된 계획서입니다. 개발팀은 스프린트가 진행되는 동안 스프린트 백로그를 수정하고
추가적인 백로그 항목들을 만들 수 있습니다. 개발팀의 작업이 계획대로 진행되고 스프린트
목표 달성에 필요한 작업을 더 많이 알게 되면서 이러한 스프린트 백로그 항목들을 추가할
수 있습니다.
새로운 작업이 필요하면 개발팀은 그것을 스프린트 백로그에 추가합니다. 이 작업이
수행되거나 완료됨에 따라 남아있는 작업량의 추정치를 업데이트합니다. 계획한 항목 중에
불필요한 것으로 판단된 것들은 제거됩니다. 단지 개발팀만이 스프린트 동안에 스프린트
백로그를 변경할 수 있습니다. 스프린트 백로그는 높은 가시성을 제공하고, 스프린트에서
완료될 작업에 대해 실시간으로 진행 상황을 보여주며, 스프린트 백로그는 오로지 개발팀만이
소유합니다.
스프린트 진행 모니터링
스프린트 진행 중에 언제든지 남아있는 스프린트 백로그의 총작업량을 알 수 있습니다.
개발팀은 최소한 매일 진행되는 일일 스크럼 미팅에서 스프린트 목표를 달성하기 위해
남아있는 총작업량을 추적해야 합니다. 스프린트를 진행하면서 남은 작업량을 추적함으로써
개발팀은 전체 진행 상황을 관리할 수 있습니다.
제품 증분
제품 증분은 스프린트에서 완료된 모든 제품 백로그 항목들의 집합이고 이전에 수행된 모든
스프린트에서 생산된 제품 증분의 가치를 포함합니다. 스프린트가 종료되는 시점에,
스프린트에서 생산된 새로운 제품 증분은 반드시 “완료” 상태여야 하며, 이는 제품이 사용
가능한 상태여야 한다는 것이고, 스크럼 팀이 “완료” 정의를 준수했다는 것을 의미합니다.
경험주의를 바탕으로 스프린트 끝에서 생산된 제품 증분은 검사할 수 있고 완료된
제품입니다. 제품 증분은 비전 또는 목표를 위해 한 단계 더 나아갑니다. 이는 제품 책임자가
제품을 출시할 것인지에 대한 결정 여부와 관계없이 사용 가능한 상태여야 합니다.
산출물 투명성
스크럼은 투명성에 기초하고 있습니다. 가치 최적화와 위험 관리는 인지 가능한 산출물에
기초하여 결정합니다. 완전한 투명성을 기초로 한 결정은 탄탄한 기반을 가집니다. 반면,
산출물들이 다소 불완전한 투명성을 가진다면, 이를 기반으로 한 결정들은 가치는 줄이고
위험은 증가시키는 결함을 가질 수 있습니다.
스크럼 마스터는 산출물들이 완전한 투명성을 가졌는지 알기 위해 제품 책임자, 개발팀,
그리고 다른 관련된 사람들과 함께 일해야 합니다. 불완전한 투명성을 극복하기 위한 다양한
방법들이 있습니다. 투명성이 부족한 경우, 스크럼 마스터는 모든 사람이 투명성을 높이기
위해 가장 적절한 방법을 적용할 수 있도록 도와주어야 합니다. 스크럼 마스터는 산출물들을
검토하고, 패턴을 감지하고, 어떠한 이야기들이 오고 가는지 주의 깊게 듣고, 예상되는 결과와
실제 결과의 차이점을 감지함으로써 불완전한 투명성을 발견할 수 있습니다.
스크럼 마스터의 역할은 산출물들의 투명성을 높이기 위해 스크럼 팀 및 이해관계 조직들과
함께 일을 하는 것입니다. 이러한 일은 주로 배우고, 확신을 주고, 변화하도록 하는 일들을
포함합니다. 투명성은 하룻밤 만에 이루어지는 것이 아니라 하나의 과정입니다.
“완료”의 정의
제품 백로그 항목이나 제품 증분이 “완료”되었다고 할 때, 모든 사람이 “완료”의 의미가
무엇인지 이해하고 있어야 합니다. “완료”의 정의가 스크럼 팀에 따라 매우 다양할 수
있지만, 스크럼 팀의 멤버들은 작업이 완료된다는 것에 대해 공통된 이해를 하고 있어야
투명성을 보장할 수 있습니다. 이것이 스크럼 팀의 “완료”의 정의이며, 작업이 제품
증분으로서 완료되었을 때 확인하기 위해 사용됩니다.
“완료”에 대한 정의는 개발팀이 스프린트 계획 미팅에서 얼마나 많은 제품 백로그 항목들을
선택할 수 있을지에 대해 같은 기준을 제시합니다. 각 스프린트의 목적은 스크럼 팀의 “완료”
정의를 고수하여 잠재적으로 출시 가능한 기능이 탑재된 제품 증분을 배포하는 것입니다.
개발팀은 스프린트마다 제품 기능의 증분을 배포합니다. 이러한 제품 증분은 사용 가능하며,
제품 책임자가 즉시 제품 기능으로 출시하도록 결정할 수 있습니다. 만약, 제품 증분에 대한
“완료” 정의가 개발 조직의 규약, 표준, 또는 가이드라인의 일부분이라면, 모든 스크럼 팀들은
최소한 그 완료 정의를 따라야 합니다. 하지만, 만약 “완료”의 정의가 개발 조직의 규약으로
명시되어 있지 않다면 스크럼의 개발팀은 제품에 따라 적절한 “완료”의 정의를 규정해야
합니다. 만약 여러 스크럼 팀들이 하나의 시스템이나 제품 출시를 위해 함께 일을 한다면,
모든 스크럼 팀의 개발팀들은 공통된 “완료”의 정의를 가져야 합니다.
각 제품 증분은 이전에 완료된 모든 제품 증분들에 추가되어 철저하게 테스트 되고, 모든
제품 증분들이 함께 작동하는지 보장해야 합니다.
스크럼 팀들이 성숙해 짐에 따라 더 높은 품질을 위해 “완료”의 정의는 더욱 엄격한 기준이
포함되도록 확장될 것입니다. 확장된 새로운 “완료”의 정의에서 이전의 정의에 없던 새로운
작업을 발견할 수도 있습니다. 각각의 제품이나 시스템은 각각의 작업을 완료하기 위한
표준으로서 “완료”의 정의를 가지고 있어야 합니다.
맺음말
스크럼은 무료이며 본 가이드를 통해 제공됩니다. 스크럼의 역할, 이벤트, 산출물, 그리고
규칙들은 변경될 수 없으며, 이 중 일부만 채택하여 사용하는 것은 가능하지만 그 결과는
완전하지 않습니다. 스크럼 프레임워크의 모든 것이 함께 사용될 때 비로소 올바른
스크럼이라고 할 수 있으며, 다른 기술, 방법론, 실천 방법 등의 컨테이너로도 사용할 수
있습니다.
감사의 말
사람
스크럼에 기여한 수천 명의 사람 중, 초기에 자리를 잡을 수 있도록 중요한 역할을 해온
사람들을 선정하고자 합니다. 우선, 제프 맥케나(Jeff McKenna), 존 스컴니오텔스(John
Scumniotales) 와 함께 일해 온 제프 서더랜드(Jeff Sutherland) 와 마이크 스미스(Mike
Smith), 크리스 마틴(Chris Martin)과 함께 일해 온 켄 슈와버(Ken Schwaber), 그리고 함께
일해온 모든 이들에게 감사를 전합니다. 많은 사람이 그들의 뒤를 이어 계속해서 스크럼에
기여하였고, 그들의 도움 없이는 스크럼은 현재의 모습처럼 다듬어질 수 없었을 것입니다.
번역
본 가이드는 켄 슈와버와 제프 서더랜드가 작성한 영문 원본으로부터 번역되었습니다. 본
가이드는 유을수(Sue Ryu), 김재욱(Jaewook Kim), 백미진(Mijin Baek), 한주영(Jooyung Han)에
의해 번역되었습니다.
역사
스크럼은 1995 년까지 스크럼을 함께 작업해 온 켄 슈와버와 제프 서더랜드가 1995 년
OOPSLA 컨퍼런스에서 처음 발표하였습니다. 그 발표에서 켄과 제프가 몇 년 동안 스크럼을
통해 배운 것들을 문서로 만들고 스크럼의 공식적인 정의를 처음으로 공개했습니다.
스크럼의 역사는 여러 곳에 기술되어 있지만, 최초로 시도하고 다듬었던 사람들에게 영예를
돌리자면 여러 개인, 회사들, Newspage, Fidelity Investments, 그리고 IDX(현재 GE Medical)가
있습니다.
스크럼은 켄 슈와버와 제프 서더랜드에 의해 20 년 이상 개발되고 변화되고 지속되며 본
스크럼 가이드로 문서화 되었습니다. 다른 소스들은 스크럼 프레임워크을 보완하는 패턴,
프로세스, 통찰력을 제공합니다. 이러한 것들이 생산성과 가치, 창의성, 그리고 결과의
만족도를 높여줄 것입니다.
스크럼 가이드 2016 년 기준 2017 년도 변경 내역
1. 스크럼의 사용 섹션 추가
스크럼은 맨 처음 제품을 관리하고 개발하려고 만들어졌습니다. 1990 년대 초반에 시작된
스크럼은 전 세계적으로 널리 사용되고 있습니다.
1. 실행 가능한 시장과 기술, 제품 기능을 조사하고 식별합니다.
2. 제품과 개선사항을 개발합니다.
3. 하루에도 여러 번, 자주, 제품과 개선사항을 배포합니다.
4. 제품 사용을 위해 클라우드(온라인, 보안, 주문형)와 기타 운영 환경을 개발하고
살아있게 합니다.
스크럼은 개인과 사회에서, 소프트웨어 개발뿐 아니라 하드웨어, 임베디드 소프트웨어, 상호
작용 기능의 네트워크, 자율주행 차량, 학교, 정부, 마케팅, 조직 운영 및 일상생활에서
사용되고 있습니다.
기술과 시장, 환경의 복잡성과 그들 간에 상호 작용이 급격하게 증가함에 따라 복잡성을
다루는 스크럼의 유용함이 매일 증명됩니다.
스크럼은 반복적이고 점진적인 지식 이전에 특히 효과적이라는 것을 증명했습니다. 스크럼은
이제 제품, 서비스, 상위 조직 관리에 널리 사용됩니다.
스크럼의 핵심은 작은 팀입니다. 각각의 팀은 매우 유연하고 적응력이 뛰어납니다. 이러한
강점은 수천 명의 작업과 작업 제품을 단일팀, 몇 개 팀, 많은 팀 그리고 네트워크 팀 안에서
개발하고, 출시하고, 운영하고, 지속시키는 것이 계속 운영되도록 합니다. 그들은 정교한 개발
구조와 타겟의 배포 환경을 통해 협업하고 상호운용합니다.
본 스크럼 가이드에서 "개발하다(develop)" 혹은 "개발(development)"이라는 용어를 사용하는
경우, 앞서 언급한 유형과 같은 복잡한 작업을 의미합니다.
2. 스크럼 마스터의 역할을 더 명확히 하도록 섹션 문구 변경
스크럼 마스터는 스크럼 가이드에 따라 스크럼을 장려하고 지원할 책임을 갖습니다. 이를
위해, 스크럼 마스터들은 모두가 스크럼의 이론과 실천, 규칙, 그리고 가치들을 잘 이해할 수
있도록 도와야 합니다.
스크럼 마스터는 스크럼 팀을 도와주는 리더(servant-leader)입니다. 스크럼 마스터는 스크럼
팀 외부에 있는 이들이 스크럼 팀과 어떤 상호작용이 도움 되고, 어떤 것이 도움 되지
않는지에 대한 이해를 돕는 역할을 합니다. 스크럼 마스터는 이러한 사람들 간의 상호작용이
스크럼 팀에서 만들어낸 제품의 가치가 최상이 되는 방향으로 바뀔 수 있도록 도움을 줍니다.
3. 스크럼 마스터가 제품 책임자를 위해 하는 일 섹션 추가
목표, 개발 및 제품 도메인을 스크럼 팀의 모든 사람이 이해할 수 있도록 확인
4. 일일 스크럼의 첫 번째 문단 업데이트
일일 스크럼은 개발팀을 위해 15 분으로 시간이 고정된 미팅입니다. 일일 스크럼은 스프린트
진행 중에 매일 모여서 개발팀이 다음 24 시간 동안 해야 할 작업을 계획합니다. 이 미팅은
지난 일일 스크럼 모임부터 수행한 작업을 검토하고 다음 스프린트 작업을 예측하여 팀
협업과 성능을 향상하게 됩니다. 일일 스크럼은 복잡성을 줄이기 위해 매일 같은 시각 같은
장소에서 이루어집니다.
5. 일일 스크럼의 목적을 더 명확히 하기 위해 일일 스크럼 섹션에
포함되어 있던 내용 업데이트
미팅의 구조는 개발팀이 정하며 스프린트 목표를 향한 진전에 초점을 맞춘다면 다양한
방식으로 수행될 수 있습니다. 일부 개발팀에서는 질문을 사용하고, 일부는 토론을 기반으로
합니다. 다음은 사용할 수 있는 예제입니다.
• 나는 어제 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 했는지?
• 나는 오늘 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 할 것인지?
• 나 혹은 개발팀이 스프린트 목표 달성을 하는데 방해요소가 있는지?
6. 정해진 시간(time box)의 의미를 명확히 하기 위해 추가
“최대(at most)”라는 단어를 사용하여 이벤트가 가져야 하는 확실한 길이에 대한 의문을
없애고, 대신 이벤트에 할당 된 최대 시간을 제시했다.
7. 스프린트 백로그 섹션에 추가
지속적인 개선을 하기 위해 스프린트 백로그에 이전 회고 미팅에서 나온 첫 우선순위의
프로세스 개선 항목을 최소 하나 이상 포함합니다.
증분 섹션을 명확히 하기 위해 추가
경험주의를 바탕으로 스프린트 끝에서 생산된 제품 증분은 검사할 수 있고 완료된
제품입니다. 제품 증분은 비전 또는 목표를 위해 한 단계 더 나아갑니다.
