스크럼 가이드북 2020

INTRO…

스크럼 가이드북의 저자인 켄 슈와버와 제프 슈덜랜드(Ken Schwaber, Jeff Sutherland)는 2020년 11월 18일 스크럼 가이드북 개정판을 세상에 릴리즈하였습니다.

이전 영문판에서 19페이지에 불과했던 이 문서는 이번 개정판에서는 불과 14페이지로 더욱 함축되었습니다.
스크럼 사용이 많아지고 애자일 프랙티스를 따르는 대표적인 프로젝트 방법론으로 자리매김함에 따라 구구절절 설명을 제시할 필요가 없어진 까닭일까요?
제 생각에는 스크럼이 더 많이 사용되고 더 널리 사용될수록 구체적이고 상세한 내용에 대한 설명을 제한함으로써, 다양한 상황의 프로젝트에 적합한 프로세스와 방법을 찾아 검토(inspection)하고 적응(adaptation)하라는 의도가 아닌가 생각됩니다. 한편으로는 이제 스크럼을 처음 접하는 사람들은 2017년도 개정판과 2020년 개정판을 모두 섭렵해야 스크럼을 제대로 이해하고 전체 맥락을 파악할 수 있게 되지 않을까 하는 우려도 듭니다.

14쪽자리 원문이 더욱 줄어든 덕분에 번역이 그리 어려울 것 같지 않아서, 이번 포스팅에 감히 한글어 번역본에 도전해 보았습니다. Papago의 힘으로 초벌 번역을 마치고, 원문과 비교하여 의미가 좀 더 잘 통할 수 있도록 의역하였습니다.
전문 번역가가 아닌 탓에 어설픈 문장들도 더러 있지만, 그동안 애자일 짬밥(?)이 늘어서인지 몇 년 전 스크럼 가이드북을 처음 읽어보며 도대체 뭔 뜻인지 알송달송 이해할 수 없었던 문장들도 이제는 문맥적으로 의미가 와닿게 해석할 수 있게 되었네요~ 😃

자, 이제부터 스크럼 가이드북 2020 내용으로 들어갑니다.

역자 Tips : 용어 정리
아직 한글어판 공식 버전이 나오지 않은 상태이므로, 본 글에서는 기존에 사용하던 용어를 아래와 같이 바꾸어 보았습니다.
• adaptation : 이전 한글 버전에서는 “적응”이라고 사용되었던 이란 용어를, 여기서는 조심스레 “조율“이라고 바꾸어 보았습니다. (더러는 적응이라는 단어가 적절해 보여 그냥 사용한 부분도 있구요..)
• Increment : 좀 더 자연스러운 한글 용어로 바꾸어보려 했지만, “증분(Increment)”이라는 용어는 여전히 대체불가입니다. 제품의 목적을 달성하기 위해 조금씩 완성되어 더해지는 결과물이라는 의미로 생각하며 용어 자체는 그냥 받아들여야 할 것 같습니다.
• Definition Of Done : 용어 그대로 “완료에 대한 정의”를 말하지만, 문장의 흐름이 보다 자연스러워 보이도록 “완료 기준“이라고 사용하였습니다.

스크럼 가이드의 목적

우리는 1990년대 초에 스크럼을 개발했다. 전 세계 사람들이 스크럼을 이해하는 것을 돕기 위하여 우리는 2010년 스크럼 가이드의 첫 번째 버전을 작성했다. 그 이후로도 우리는 작은 기능의 업데이트를 통해 가이드를 발전시켜 왔다. 우리는 함께, 이것을 후원한다.

스크럼 가이드에는 스크럼의 정의가 담겨 있다. 프레임워크의 각 요소는 스크럼으로 실현된 전체적인 가치와 결과에 필수적인 특정 목적을 갖고 있다. 스크럼의 핵심 디자인이나 아이디어를 바꾸거나 요소를 배제하거나, 스크럼의 규칙을 따르지 않는 것은, 문제를 덮고 스크럼의 이점을 제한하여 잠재적으로 쓸모 없게 만들기도 한다.

우리는 계속 성장하는 복잡한 세계에서 스크럼의 사용도 증가하고 있음을 보게 된다. 스크럼이 뿌리를 두고 있는 소프트웨어 제품 개발을 넘어, 본질적으로 복잡한 작업을 하고 있는 많은 도메인에서 스크럼이 채택되는 것을 보는 것은 우리를 겸허하게 만든다.
스크럼의 사용이 확산됨에 따라 개발자, 연구원, 분석가, 과학자, 그리고 다른 전문가들도 그 일을 하고 있다. 우리는 스크럼에서 “개발자”라는 단어를, 누군가를 배제하기 위해서가 아니라 단순화하기 위해서 사용하였다. 당신이 스크럼에서 가치를 얻고 있다면, 당신도 그 안에 포함되어 있다고 생각하기 바란다.

스크럼을 사용함에 따라 본 문서에 기술된 대로 스크럼 프레임워크에 적합한 패턴, 프로세스 및 통찰력을 찾아 적용하고 고안할 수 있다. 그런 것들에 대한 상세한 설명은 문맥에 따라 민감하고 스크럼을 사용하는 곳마다 차이가 나기 때문에 스크럼 가이드의 용도를 벗어난다. 스크럼 프레임워크 내에서 사용하기 위한 패턴, 프로세스, 통찰에 대한 전술 등은 매우 다양하며 다른 어딘 가에 설명되어 있다.

스크럼의 정의

스크럼은 사람, 팀, 조직이 복잡한 문제에 대한 적응형 솔루션을 통해 가치를 창출할 수 있도록 돕는 경량 프레임워크다.
간단히 말해 스크럼은 스크럼 마스터 가 다음과 같은 환경을 조성하도록 요구한다.

1. 제품 책임자는 복잡한 문제에 대한 작업을 제품 백로그로 요구(order)한다.
2. 스크럼 팀은 스프린트 동안 작품의 선택을 가치 상승으로 바꾼다.
3. 스크럼 팀과 그 이해관계자는 결과를 검사하고 다음 스프린트에 맞게 조정한다.
4. 반복한다.

스크럼은 간단하다. 있는 그대로 사용해 보고 그것의 철학, 이론, 구조가 목표를 달성하고 가치를 창출하는 데 도움이 되는지 판단하라. 스크럼 프레임워크는 스크럼 이론을 구현하는 데 필요한 부분만 정의했을 뿐, 의도적으로 불완전하다. 스크럼은 그것을 사용하는 사람들의 집단 지성에 의해 만들어진다. 스크럼 규칙들은 사람들에게 상세한 지시를 제공하기 보다는 그들의 관계와 상호작용을 가이드한다.
프레임워크 내에서 다양한 프로세스, 기술 및 방법을 사용할 수 있다. 스크럼은 기존의 관행을 모두 아우르기도 하고 또는 그것들을 불필요하게 만들기도 한다. 스크럼은 개선이 이루어질 수 있도록 현재의 관리방식, 환경, 작업 기법의 상대적 효능을 가시화한다.

스크럼 이론(Scrum Theory)

스크럼은 경험주의와 린(lean) 사고에 기초한다. 경험론에서는 지식(knowledge)은 관찰된 것에 근거한 결정과 경험한 것으로부터 나온다고 주장한다. 린 사고는 낭비를 줄이고 본질적인 것에 초점을 맞춘다.
스크럼은 예측 가능성을 최적화하고 위험을 제어하기 위해 반복적이고 점진적인 접근방식을 채택한다. 스크럼은 모든 기술과 전문지식을 총체적으로 가지고 있는 사람들과 함께 일을 하고 필요에 따라 그러한 기술을 공유하거나 습득한다.
스크럼은 검사 및 적응을 위한 4개의 공식 이벤트 및 그것들을 아우르는 스프린트로 결합되어 있다. 이러한 이벤트들은 투명성, 검사, 적응이라는 경험주의 스크럼의 특성을 구현한 것이기 때문에 효과가 있다.

투명성(Transparency)

새로운 프로세스와 작업은 작업 결과를 받는 사람 뿐 아니라, 작업을 수행하는 사람에게도 가시적으로 보여져야 한다. 스크럼에서는, 중요한 결정이 3가지 공식 산출물(제품 백로그, 스프린트 백로그, 완료 기준)에 대한 인식 상태에 따라 이루어진다.
투명성이 떨어지는 결과물은 산출물의 가치를 감소시키고 위험을 증가시키는 결정으로 이어질 수 있다. 투명성은 인스펙션(Inspection)을 활성화시킨다. 투명성이 없다면, 인스펙션은 잘못된 길로 가게 되며 낭비이다.

검사(Inspection)

잠재적으로 바람직하지 않은 변형이나 문제를 발견하기 위하여 스크럼 산출물 및 진행상태가 합의된 목표를 향하고 있는지, 자주 그리고 성실하게 점검(Inspection)하는 것이 필요하다.
스크럼은 인스펙션에 도움을 주기 위해 5가지 이벤트 형식을 제공한다.
인스펙션은 조율(Adaptation)을 활성화시킨다. 조율을 동반하지 않은 인스펙션은 무의미하다. 스크럼 이벤트들은 변화를 유발하도록 설계되어 있다.

조율(adaptation)

만약 프로세스의 어떤 측면들이 허용 범위를 벗어나거나 결과물이 수용 불가능하다면, 적용되고 있는 프로세스 또는 생산되고 있는 재료를 조정(adjustment)해야 한다. 조정은 더 이상의 이탈(deviation)을 최소화하기 위해 가능한 한 빨리 이루어져야 한다.
관련자들이 권한을 위임 받지 못했거나 자기 관리(self-managing)가 되지 않을 때 조율(adaptation)은 더욱 어려워진다. 스크럼 팀은 인스펙션을 통해 무언가 새로운 것을 알게 되었다면, 그 순간 바로 조율을 해야 할 것이다.

스크럼의 가치(values)

스크럼의 성공적인 사용은 사람들이 5가지 가치에 더 익숙해지는 것에 따라 좌우된다.
헌신(Commitment), 집중(Focus), 개방(Openness), 존중(Respect), 용기(Courage)
스크럼 팀은 목표를 달성하고 서로 지원하는 것에 헌신한다. 목표를 향해 최대한 나아갈 수 있도록 만들기 위해 스프린트 작업에 대해 우선적으로 집중한다. 스크럼 팀과 이해당사자들은 프로젝트의 (맡은) 작업과 어려운 도전들에 대하여 개방적이다. 스크럼 팀원들은 각각 능력 있고 독립적인 사람이라는 부분에서 서로를 존중하며, 함께 일하는 사람들에 의해서도 그런 방식으로 존중받는다. 스크럼 팀원들은 옳은 일을 할 수 있고 어려운 문제를 해결할 수 있는 용기를 가지고 있다.

이러한 가치들은 스크럼 팀의 작업과 행동, 행위에 대한 방향을 제시한다. 의사결정을 하거나, 어떤 조치를 취할 때, 그리고 스크럼을 사용하는 방식에서 이러한 가치를 줄이거나 약화시키는 것이 아니라 강화해야 한다. 스크럼 팀원들은 스크럼 이벤트와 산출물을 가지고 작업면서 그 가치를 배우고 경험한다. 스크럼 팀 및 그리고 그들과 함께 일하는 사람들에 의해 이러한 가치들이 구체화된다면, 투명성, 인스펙션, 조율이라는 경험적 스크럼의 주축들은 신뢰 구축에 핵심적 역할을 할 것이다.

스크럼 팀(Scrum Team)

스크럼의 기본 단위는 작은 크기의 스크럼 팀이다. 스크럼 팀은 스크럼 마스터(Scrum master) 1명, 제품 책임자(Product Owner) 1명, 개발자들(Developers)로 구성된다. 스크럼 팀 내에는 하위 팀이나 계층이 없다. 팀은 한 번에 하나의 목표, 즉 제품 목표에 초점을 맞춘 전문가들로 이루어진 응집력 있는 단위이다.

스크럼 팀은 상호 기능적(cross-functional)이어야 하는데, 구성원들이 각각의 스프린트 가치를 창출하는 데 필요한 모든 기술을 가지고 있다는 것을 의미한다. 그들은 또한 누가 무엇을, 언제, 어떻게 하는지를 내부적으로 결정한다는 의미로 자기 관리(self-managing) 조직이라 한다.

스크럼 팀의 크기는 민첩성을 유ㄹ지할 수 있을 만큼 충분히 작으면서 또한 스프린트 내에서 중요한 작업을 완료할 수 있을 만큼 충분히 커야 하는데, 보통 10명 이하이다. 일반적으로, 우리는 작은 팀들이 더 잘 소통하고 더 생산적이라는 것을 발견했다. 스크럼 팀이 너무 커지면, 서로 같은 제품에 초점을 맞춘 여러 개의 응집력 있는 스크럼 팀으로 재편하는 것을 고려해야 한다. 그런 경우, 동일한 제품 목표, 제품 백로그 및 제품 책임자를 공유하게 된다.

스크럼 팀은 이해관계자와 협업, 검증, 유지보수, 운영, 실험, 연구 개발 및 기타 필요한 모든 제품 관련 활동을 담당한다. 그들은 조직에서 그들 자신의 업무를 관리할 수 있도록 구조화되고 권한을 부여 받는다. 여러 스프린트에서 지속 가능한 속도로 작업하는 것은 스크럼 팀의 집중력과 일관성을 향상시킨다.

스크럼 팀 전체는 매 스프린트마다 유용한 증분(Increment)을 만들어낼 책임이 있다. 스크럼은 스크럼 팀 내에서 개발자, 제품 책임자, 스크럼 마스터의 세 가지 역할에 대한 책임을 다음과 같이 구체적으로 정의하였다.

역자 Tips
금번 2020 개정판에서 가장 크게 바뀐 부분 중 하나는 “자기 조직화(self-organized)” 대신 “자기 관리(self-managing)“라는 용어로 바뀌었다는 점입니다.
두 용어의 의미가 각각 어떤지는 위키디피아에 자세한 설명이 나와 있습니다만, 애자일에서 이야기하는 주도적, 자율적, 책임과 헌신을 하는 팀이라는 의미에는 self-managing라는 용어가 좀 더 가까와 보이는 것 같습니다.

개발자(Developers)

개발자는 스크럼 팀의 각 스프린트 증가의 사용 가능한 측면을 생성하기 위해 헌신하는 사람들이다.
개발자들이 필요로 하는 특정한 기술은 종종 광범위하고 일의 영역에 따라 다를 것이다.

그러나 개발자는 항상 다음 사항에 대해 책임을 진다.

• 스프린트와 스프린트 백로그 계획 수립
• ‘완료’의 정의를 엄수함으로써 품질을 준수
• 스프린트 목표를 향해 매일 계획을 조정
• 전문가로서 각각의 책임감 유지

역자 Tips
이번 개정판에서 바뀐 또 하나의 변화는 개발팀(Development Team) 대신에 개발자(Developers)라고 부르는 것입니다.
저자는 글 서두에서 보다 단순화하기 위한 목적으로 “개발자”라는 용어를 사용하기로 했다고 밝혔습니다.
저 역시 현장에서 스크럼팀과 개발팀이 뭐가 다른지 설명하는 것이 번거롭기도 하고, 개발팀보다는 개발자라는 용어를 더 자주 사용하는 경우가 많았으니, 이번 개정판에서는 매우 실용적인 반영이 이루어진 것 같습니다.

제품 책임자(Product Owner)

제품 책임자는 스크럼 팀의 작업으로 인한 제품의 가치를 극대화할 책임이 있다. 이렇게 하는 방법은 조직, 스크럼 팀 및 개인에 따라 크게 다를 수 있다.

또한 제품 책임자는 다음을 포함하여 효과적인 제품 백로그 관리에 대한 책임을 진다.

• 제품 목표 개발 및 명시적 커뮤니케이션
• 제품 백로그 항목 생성 및 명확한 커뮤니케이션
• 제품 백로그 항목 순위화 및
• 제품 백로그가 투명하고 가시적이며 이해되도록 보장

제품 책임자는 위의 작업을 수행하거나 다른 사람에게 책임을 위임할 수 있다. 그럼에도 불구하고, 제품 책임자의 역할(accountability)은 유지된다.

제품 책임자가 성공적으로 역할하기 위해서는, 조직 전체가 그들의 결정을 존중해야 한다. 이러한 결정들은 제품 백로그의 내용과 우선순위를 만드는 데에서 나타난다. 또한 스프린트 리뷰의 결과물 점검을 통해서도 드러날 수 있다.

제품 책임자는 위원회가 아니라 한 사람이다. 제품 책임자는 제품 백로그에서 다수의 이해관계자 요구를 대표할 수 있다. 제품 백로그를 변경하고 싶은 사용자가 있다면 제품 책임자를 설득하여 그렇게 할 수 있다.

스크럼 마스터(Scrum Master)

스크럼 마스터는 스크럼 가이드에 정의된 대로 스크럼을 정착시킬 책임이 있다. 그들은 그 책임감을 가지고 스크럼 팀과 조직 내 모든 사람들이 스크럼 이론과 실행을 이해하도록 돕는다. 스크럼 마스터는 스크럼 팀의 효과성에 대한 책임이 있다. 스크럼 팀이 스크럼 프레임워크 내에서 관행을 개선할 수 있도록 지원함으로써 이를 실현한다.

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

스크럼 마스터는 스크럼 팀에 다음과 같은 여러 가지 방법으로 서비스를 제공한다.

• 자기관리(self-management) 및 교차기능(cross-functional) 코칭
• 스크럼 팀이 완료 정의(DoD)를 충족하는 고부가가치의 증분을 지속적으로 만드는 것을 집중할 수 있도록 지원
• 스크럼 팀 진행에 방해가 되는 장애물 제거를 촉구
• 모든 스크럼 이벤트가 수행되고 타임박스 내에 긍정적이고 생산적이 되도록 보장

스크럼 마스터는 다음과 같은 여러 가지 방법으로 제품 책임자에게 서비스를 제공한다.

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

스크럼 마스터는 다음과 같은 여러 가지 방법으로 조직에 서비스를 제공한다.

• 스크럼을 채택한 조직의 리더쉽, 교육 및 코칭
• 조직 내에서 스크럼 구현 계획 및 자문
• 복합 작업에 대해 직원 및 이해관계자의 이해를 돕고 경험적 접근법을 사용할 수 있도록 함
• 이해관계자와 스크럼 팀 간의 장벽 제거

스크럼 이벤트들(Scrum Events)

스프린트는 다른 모든 이벤트를 위한 컨테이너다. 스크럼의 각 이벤트는 스크럼 산출물을 검사(inspect)하고 조율(adapt)하기 위한 공식적인 기회다. 이 이벤트들은 필요한 투명성이 활성화되도록 특별히 고안된 것들이다.
규정된 대로 이벤트를 운영하지 않을 경우, 검사 및 조율의 기회를 잃게 된다. 이벤트들은 규칙성을 만들고 스크럼에 정의되지 않은 미팅에 대한 요구를 최소화하기 위해 사용된다.

복잡성을 줄이기 위해 모든 이벤트는 같은 시간과 장소에서 개최하는 것이 최적이다.

스프린트(Sprint)

스프린트는 아이디어들이 가치로 변하도록 만들어주는 스크럼의 심장박동(heartbeat)과 같은 것이다.
일관성을 유지하기 위해 하나의 스프린트는 1개월 이하의 고정 길이를 가지며, 이전 스프린트가 종료되는 즉시 새로운 스프린트가 시작된다.
스프린트 계획(Sprint Planning), 일일 스크럼(Daily Scrums), 리뷰(Sprint Review) 및 회고(Sprint Retrospective)를 포함하여 제품 목표를 달성하는 데 필요한 모든 작업은 각 스프린트 내에서 이루어진다.

스프린트 중에는 :

• 스프린트 목표에 대해 위협을 줄 수 있는 어떠한 변경도 허용되지 않는다.
• 제품 품질을 낮추어서는 안된다.
• 제품 백로그는 필요에 따라 다듬어 간다.
• 스프린트가 진행되며 더 많은 것을 이하하게 되면, 개발팀은 범위를 제품 책임자와 함께 범위를 보다 명확히 하거나 재협상을 할 수 있다.

스프린트는 최소한 한달에 한번 제품 목표를 향한 진행 상황의 검사 및 조율을 보장하며, 이렇게 함으로써 예측을 가능하게 한다. 스프린트 길이가 너무 길면 스프린트 목표는 무용지물이 되고 복잡성이 증가하여 위험도 증가할 수 있다. 짧은 스프린트를 사용하면 더 많은 학습 주기를 생성하여 비용과 공수의 위험(risk)을 더 작은 시간 프레임으로 제한할 수 있다. 각 스프린트는 짧은 주기의 프로젝트로 간주할 수 있다.

번-다운(burn-down), 번-업(burn-up) 또는 누적 흐름과 같이 진행 상황을 예측하기 위해서 다양한 방법이 존재하는데, 이런 방법들의 유용성이 입증되었음에도 불구하고, 경험론의 중요성을 대신할 수는 없다. 복잡한 환경에서는 어떤 일들이 일어날지 알 수 없다. 오직 이전에 한번이라도 발생했던 사건만이 미래를 예측하는 의사결정에 사용될 수 있다.

스프린트 목표가 쓸모 없게 되면 스프린트를 취소할 수 있는데, 제품 책임자만이 스프린트를 취소할 권한을 갖는다.

스프린트 계획 수립(Sprint Planning)

스프린트 계획은 제품 백로그로부터 현재 스프린트 내에 수행할 작업을 배정함으로써 스프린트를 가동시킨다. 이 계획은 스크럼 팀 전체의 공동 작업을 통해 도출된다. 제품 책임자는 참석자들이 가장 중요한 제품 백로그 항목들을 제품 목표에 어떻게 매핑해야 할지 논의할 수 있도록 준비시켜야 한다. 스크럼 팀은 또한 팀 외부의 다른 사람들을 스프린트 계획에 참여시켜 조언을 얻을 수도 있다. 스프린트 계획 수립은 다음 주제를 다룬다.

주제 1: 왜(Why) 이 스프린트가 가치있는가?
제품 책임자는 제품이 가치와 사용성을 현재 스프린트에서 어떻게 증가시킬 수 있는지를 제안한다. 왜 이 스프린트가 이해당사자들에게 가치가 있는지가 전달될 수 있도록 전체 스크럼 팀이 함께 스프린트 목표를 정의한다. 스프린트 목표는 스프린트 계획이 종료되기 전에 확정되어야 한다.

주제 2: 무엇이(What) 이 스프린트에 완료되어야 하는가?
개발자는 제품 책임자와의 논의를 통해 제품 백로그에서 현재 스프린트에 포함할 항목을 선택한다. 스크럼 팀은 이러한 과정을 통해 백로그 항목들을 정제함으로써, 이해력과 자신감을 높인다.
스프린트 내에서 완료할 수 있는 양을 선택하는 것은 어려울 수 있다. 그러나 개발자가 과거의 성과, 앞으로의 용량, 그리고 ‘완료 정의’에 대해 더 많이 알수록 스프린트 예측에 더욱 확신을 갖게 될 것이다.

주제 3: 어떻게(How) 선택한 작업들을 완료할 것인가?
선택한 각 제품 백로그 항목에 대하여 개발자는 정의된 완료 기준(DoD)을 충족하는 결과물(Increments)을 만드는 데 필요한 작업을 계획한다. 종종 제품 백로그 항목을 하루 이하의 더 작은 작업 항목으로 분해하기도 한다. 이러한 작업이 어떻게 이루어지는지는 전적으로 개발자들의 재량에 달려있다. 아무도 그들에게 제품 백로그 항목을 가치 있는 결과물로 바꾸는 방법을 알려주지 않는다.

스프린트 목표 및 스프린트에 대해 선택된 제품 백로그 항목, 그리고 이를 전달하는 계획을 모두 아울러 스프린트 백로그라고 한다.
스프린트 계획을 수립하는 시간의 타임박스는 1개월짜리 스프린트의 경우 최대 8시간까지이다. 스프린트 길이가 짧아질수록, 이 이벤트 또한 짧아진다.

역자 Tips
이전 개정판에서 what과 how에만 집중하였던 스프린트 계획 수립 이벤트는, why에 대해서도 정의하도록 새로운 내용이 추가되었습니다. 사실 why가 먼저 정의되어야 자연스럽게 what과 how도 명확해지는 법입니다. 이 부분은 각 스프린트의 목적(Sprint Goal)과도 연결되는 내용입니다.

일일 스크럼(Daily Scrum)

일일 스크럼의 목적은 스프린트 목표를 향한 진행 상황을 점검하고 필요에 따라 스프린트 백로그를 조율(adapt)하여 향후 예정된 작업을 조정하는 것이다.

일일 스크럼은 스크럼 팀의 개발자들을 위한 15분짜리 이벤트다. 복잡성을 줄이기 위해 스프린트 작업중에는 동일한 시간과 장소에서 실시한다. 제품 책임자 또는 스크럼 마스터가 스프린트 백로그의 항목에 대해 적극적으로 일하고 있다면, 그들 또한 개발자로 참여하고 있는 것이다.

개발자는 일일 스크럼이 스프린트 목표를 향한 진전에 초점을 맞추고 다음 작업을 위한 조치 계획을 세우기만 한다면, 다양한 구조와 기술을 선택할 수 있다. 이는 집중을 만들고 자기 관리를 향상시킨다.

일일 스크럼은 커뮤니케이션을 개선하고, 장애를 식별하며, 신속한 의사 결정을 촉진하고, 결과적으로 다른 추가적인 회의의 필요성을 없앤다.

일일 스크럼만이 개발자들의 계획을 조정할 수 있는 유일한 시간이 아니다. 그들은 종종 하루 종일 만나 스프린트의 나머지 작업을 조율하거나 다시 계획하는 것에 대해 좀 더 자세한 논의를 한다.

스프린트 리뷰(Sprint Review)

스프린트 리뷰의 목적은 스프린트의 결과를 검사하고 앞으로 어떻게 조율할지를 결정하는 것이다. 스크럼 팀은 핵심 이해 관계자들에게 작업 결과를 제시하고 제품 목표를 향한 진행 상황을 논의한다.

이벤트 기간 동안 스크럼 팀과 이해관계자는 스프린트에서 달성한 것과 주변 환경에서 변화가 있는지를 검토한다. 이 정보를 바탕으로 참석자들은 다음에 무엇을 해야 하는지에 대해 협력한다. 또한 제품 백로그는 새로운 기회를 충족하도록 조정될 수 있다. 스프린트 리뷰 자체가 작업 세션이며 스크럼 팀은 이를 프리젠테이션하는 것으로 국한하여서는 안 된다.
스프린트 리뷰는 스프린트의 마지막 이벤트 중 두 번째 이벤트로, 1개월짜리 스프린트 동안 최대 4시간의 타임박스를 가진다. 짧은 스프린트의 경우, 리뷰 시간도 짧아진다.

스프린트 회고(Sprint Retrospective)

스프린트 회고의 목적은 품질과 효과를 높이기 위한 방법을 계획하는 것이다.
스크럼 팀은 개인, 상호작용, 프로세스, 도구 및 이들의 정의와 관련하여 마지막 스프린트가 어떻게 진행되었는지 살펴본다. 점검 요소는 작업 영역에 따라 달라진다.

그들을 그릇된 길로 이끌었던 가정들이 있었는지 확인하고 원인을 탐색한다. 스크럼 팀은 스프린트 동안 잘 된 일, 발생한 문제, 그리고 그러한 문제들이 어떻게 해결되었는지(또는 어떻게 해결되지 않았는지)에 대해 토론한다.
스크럼 팀은 효과 개선을 위해 가장 도움이 되는 개선사항을 식별한다. 가장 영향도가 큰 개선사항이라면 가능한 한 빨리 시도되어야 한다. 다음 스프린트를 위해 스프린트 백로그에 추가될 수도 있다.

스프린트 회고를 통해 스프린트를 마무리한다. 그것은 1개월짜리 스프린트의 경우 최대 3시간까지 타임박스로 되어 있다. 짧은 스프린트의 경우, 일반적으로 회고시간도 더 짧아진다.

스크럼 산출물(Scrum Artifacts)

스크럼의 산출물은 작업 또는 가치를 의미한다. 이는 핵심 정보들이 최대한 투명하도록 설계되었기 때문에, 이것을 점검하는 사람들은 모두 동일한 기준으로 조정할 수 있다.

각 산출물은 다음에 설명할 약속들을(commitments) 포함하는데, 이는 투명성을 향상시키고 진행 상황을 측정하는 데에 집중할 수 있도록 필요한 정보를 제공한다.

• 제품 백로그의 경우, 제품 목표가 약속이 된다.
• 스프린트 백로그의 경우, 스프린트 목표가 약속이 된다.
• 증분의 결과물(Incremental)의 경우, 완료 조건 (Definition Of Done)이 약속이다.

이러한 약속은 스크럼 팀과 이해당사자들을 위한 경험주의와 스크럼 가치를 강화하기 위해 필요하다.

제품 백로그(Product Backlog)

제품 백로그는 제품 개선을 위해 필요한 항목을 순위화 하여 나타낸 목록이다. 스크럼 팀이 사용해야 하는 유일한 작업 소스이다.

한 스프린트 내에서 스크럼 팀이 수행할 수 있는 제품 백로그 항목은 스프린트 계획 이벤트에서 선택되도록 준비되어야 한다. 그 정도의 투명성을 얻기 위해서 제품 백로그는 보통 정제 활동이 필요하다. 제품 백로그 정제는 제품 백로그 항목을 더 작은 정밀한 항목으로 세분화하여 정의하는 것이다. 이것은 지속적인 활동을 통해 설명, 순서, 크기와 같은 세부사항이 추가된다. 보통 이런 속성들은 어떤 작업 영역인지에 따라 다르다.

작업을 수행하게 될 개발자는 사이징에 대해 책임이 있다. 제품 소유자는 개발자가 절충안(trade-offs)을 이해하고 선택할 수 있도록 도움으로써 개발자에게 영향을 줄 수 있다.

약속: 제품 목표(Commitment: Product Goal)
제품 목표는 스크럼 팀이 계획을 세우기 위한 대상으로써 제공되어야 하는 제품의 미래 상태에 대해서 기술한다. 제품 목표는 제품 백로그 안에 들어간다. 제품 백로그의 나머지 내용들은 그 제품 목표를 달성하기 위한 “무엇(what)”을 정의하는 것으로 채워진다.
제품은 가치를 전달하는 수단이며, 명확한 경계와 알려진 이해관계자, 잘 정의된 사용자 또는 고객을 가진다. 제품은 서비스, 물리적 제품이 될 수 있으며 좀 더 추상적인 것일 수 있다.
제품 목표는 스크럼 팀의 장기 목표이다. 그들은 다음 목표를 수행하기 전에 한 가지 목표를 달성(또는 포기)해야 한다.

역자 Tips
제품 백로그 안에 제품 목표가 담기도록 개정이 되었네요.
기존의 정의에서는 제품 백로그가 제품이 가져야 하는 기능 목록 정도로만 이해되었다면, 이번에는 제품 목표가 담김으로써 그 기능이 각각 어떠한 목적으로 필요하며 동작해야 하는지가 좀 더 명확하게 이해될 수 있도록 하는 것 같습니다.
제품백로그=유저스토리 측면에서도 유저스토리 작성 규칙과 일치하게 된 것으로 보입니다. ☞ 유저스토리 작성 방법

스프린트 백로그(Sprint Backlog)

스프린트 백로그는 스프린트 목표(why), 스프린트에 대해 선택한 제품 백로그 항목 집합(what) 및 증가분 전달을 위한 실행 가능한 계획(how)으로 구성된다.

스프린트 백로그는 개발자에 의한 계획이며 동시에 개발자를 위한 계획이다. 이것은 개발자들이 스프린트 목표 달성을 위해 스프린트 기간 동안 수행하려고 계획한 작업들에 대해 매우 가시적이고 실시간으로 드러나게 된다. 결과적으로, 스프린트 백로그는 더 많은 것이 획득됨에 따라 스프린트 내내 업데이트된다. 일일 스크럼에서 진행 상황을 점검할 수 있을 정도로 상세한 내용을 담고 있어야 한다.

약속: 스프린트 목표 (Commitment: Sprint Goal)
스프린트 목표(Goal)는 스프린트의 유일한 목적이다. 스프린트 목표는 개발자들에 의한 약속이지만, 그것을 성취하기 위해 필요한 정교한 작업 측면에서는 유연성을 제공한다. 스프린트 목표는 또한 응집력과 집중력을 키우고, 스크럼 팀이 분리된 채로 일하지 않고 함께 작업할 수 있도록 촉진한다.
스프린트 목표는 스프린트 계획 이벤트에서 설정되고 나서 스프린트 백로그에도 추가된다. 개발자는 스프린트 목표를 염두에 두면서 스프린트 동안 작업한다. 작업이 예상과 다른 것으로 판명될 경우, 제품 책임자와 협력하여 스프린트 목표에 영향을 주지 않는 범위 내에서 스프린트 백로그 범위를 협상한다.

증분(Increment)

증분들은 제품 목표를 향한 구체화되는 걸음이다. 각 증분은 이전 증분에 추가되며 철저히 검증되어 모든 증분이 함께 작동하는지 확인한다. 가치를 제공하기 위해서 증분은 쓸모 있어야 한다.

스프린트 내에서 여러 증분을 생성할 수 있다. 증분들의 합은 스프린트 리뷰에 제시(presentation)되는데 이는 경험주의를 바탕으로 하는 것이다. 단, 스프린트가 완전히 종료되기 전에 이해당사자에게 증분이 전달되어야 한다. 스프린트 리뷰를 증분의 가치에 대한 릴리즈 관문으로 간주하지 말아야 한다. 완료 정의를 충족하지 않는다면, 작업 자체가 증분의 일부로 여겨져서도 안 된다.

약속: 완료 기준 (Definition of Done)
완료 기준(Definition of Done)은 제품에 필요한 품질 수치를 충족했을 때의 증분 상태(state of increment)에 대한 공식적 명세이다.
제품 백로그 항목이 완료 기준을 충족하는 순간 증분이 탄생한다.

“완료 기준”은 증분을 구성하는 데 어떤 작업이 완료되어야 할지 모든 사람에게 공통된 이해를 제공함으로써 투명성을 만든다. 제품 백로그 항목이 완료 기준을 충족하지 못한다면, 스프린트 리뷰에서 릴리스되거나 제시될 수 없다. 추후에 다시 한번 고려될 수 있도록 제품 백로그로 돌아간다. 증분에 대한 완료 기준이 조직 표준의 일부인 경우, 모든 스크럼 팀은 최소한으로 이를 따라야 한다. 조직 표준이 아닌 경우 스크럼 팀은 반드시 제품에 적합한 완료 기준을 생성해야 한다. 개발자는 완료의 정의를 준수해야 한다. 하나의 제품에 대해 여러 스크럼 팀이 함께 작업하는 경우, 동일한 완료 기준을 상호 정의하고 준수해야 한다.

역자 Tips
이전 버전에서 제품 백로그에 언급되었던 완료기준(Definition of Done)이 “증분”에 대한 설명 안으로 옮겨갔습니다.
종종 완료기준을 간과한 채로 제품의 증분들이 생산되기 때문일까요?
완료기준을 충족하지 않는 것들은 제품의 증분으로 간주해서는 안된다는 내용이 강조되는 것으로 보아서 “완료기준”은 제품백로그를 설명하기 위한 것이 아니라, 제품의 가치를 증가시키는 증분의 필수불가결한 요소로 보아야 할 것 같습니다.

End Notes

스크럼은 무료로 제공되며 본 가이드를 통해 제시된다. 스크럼 프레임워크는 여기에 요약되어 있는 그대로이며, 불변하다. 스크럼의 일부만 구현하는 것도 가능하겠지만, 그 결과는 결코 스크럼이 아니다. 스크럼은 전체로만 존재하지만, 다른 기술이나 방법론, 실천법들을 위한 컨테이너와 같은 역할도 가능하다.

포스팅의 원문은 다음 링크에 있습니다.
The Scrum Guide (The Definitive Guide to Scrum : The Rules of the Game)

< EOF >