스크럼 (애자일 개발 프로세스)

1. 개요

스크럼은 1986년 처음 소개된 제품 개발 프레임워크로, 럭비의 스크럼에서 유래하여 유연하고 자유로운 개발 방식을 특징으로 한다. 소프트웨어 개발을 위해 시작되었지만, 현재는 적응형 솔루션 및 제품 개발 전반에 적용된다. 스크럼 팀, 제품 백로그, 스프린트, 인크리먼트 등의 요소로 구성되며, 투명성, 검사, 적응을 통해 경험주의에 기반한 개발을 수행한다. 스크럼은 팀 내 역할 분담, 스프린트 계획, 일일 스크럼 회의, 스프린트 리뷰, 스프린트 회고 등을 통해 진행되며, 스크럼반, 스크럼 오브 스크럼, 대규모 스크럼과 같은 확장 및 변형된 형태도 존재한다.

2. 역사

스크럼의 역사는 1986년 하버드 비즈니스 리뷰에 실린 다케우치 히로타카와 노나카 이쿠지로의 논문 "새로운 신제품 개발 게임"에서 시작되었다. 이 논문에서 럭비의 스크럼 방식을 차용하여 팀이 협력하여 목표를 달성하는 새로운 제품 개발 방식을 제시하였다.

1993년 제프 서덜랜드와 동료들은 소프트웨어 개발에 스크럼 방식을 도입하였고, 1995년 켄 슈와버와 함께 스크럼을 공식화하여 발표하였다. 이후 스크럼은 애자일 소프트웨어 개발 선언의 기반이 되었으며, 2002년에는 스크럼 얼라이언스(Scrum Alliance)가 설립되어 스크럼 관련 인증 체계가 구축되었다.

2009년 이후, 켄 슈와버와 제프 서덜랜드는 "스크럼 가이드"를 통해 스크럼의 정의와 해설을 제공하고 있으며, 지속적인 개선을 통해 스크럼은 발전하고 있다. 스크럼은 현재 소프트웨어 개발뿐만 아니라 다양한 분야에서 활용되고 있다.

2.1. 기원

이 방법은 일본 히토쓰바시 대학의 노나카 이쿠지로와 다케우치 히로타카가 1986년 1~2월 Harvard Business Review에 올린 "The New New Product Developement Game"The New New Product Developement Game^영어에서 시작된다. 1991년 디그라스(DeGrace)와 슈탈(Stahl)은 "Wicked Problems, Righteous Solutions"Wicked Problems, Righteous Solutions^영어에서 스크럼을 처음 언급했다. 처음 노나카와 타케우치가 스크럼을 만들때의 목표는 공업품의 개발이었으나, 1995년 켄 슈와버가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 제프 서덜랜드, 존 스컴니오테일스(John Scumniotales), 그리고 제프 맥케나(Jeff McKenna)는 Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불렀다.

1986년 하버드 비즈니스 리뷰에 실린 다케우치 히로타카와 노나카 이쿠지로의 논문 "새로운 신제품 개발 게임"The New New Product Development Game^영어에서 소프트웨어 개발에 "스크럼"이라는 용어를 사용하기 시작했다. 자동차, 복사기, 프린터 산업의 제조 회사 사례 연구를 바탕으로, 저자들은 속도와 유연성을 높이기 위한 새로운 제품 개발 방식을 제시했다. 그들은 이 방식을 럭비 방식이라고 불렀는데, 이는 이 프로세스가 팀이 "단위로 거리를 이동하려고 노력하며 공을 주고받는" 여러 겹치는 단계를 거쳐 작동하는 단일 교차 기능 팀을 포함하기 때문이다. 저자들은 나중에 그들의 저서 지식 창조 기업The Knowledge-Creating Company^영어에서 스크럼을 발전시켰다.

1990년대 초, 켄 슈와버는 자신의 회사인 어드밴스드 개발 메소드(Advanced Development Methods)에서 스크럼이 될 방식을 사용했다. 제프 서덜랜드, 존 스컴니오테일스, 제프 맥케나는 Easel Corporation에서 비슷한 방식을 개발했으며, 이 방식을 "스크럼"이라는 용어로 지칭했다. 서덜랜드와 슈와버는 나중에 그들의 아이디어를 스크럼으로 공식적으로 알려진 단일 프레임워크로 통합하기 위해 함께 일했다. 1995년에 슈와버와 서덜랜드는 스크럼을 테스트하고 지속적으로 개선하여 연구 논문을 발표했고, 2001년에는 애자일 소프트웨어 개발 선언을 발표했다. 슈와버는 또한 듀폰 연구소와 델라웨어 대학교에서 바바툰데 오구나이케와 협력하여 스크럼을 개발했다. 오구나이케는 제품 관리가 경험적 실천에 기반하지 않으면 초기 조건이 변경될 때 소프트웨어 개발 프로젝트가 종종 실패할 수 있다고 믿었다.

2002년, 슈와버는 다른 사람들과 함께 스크럼 얼라이언스(Scrum Alliance)를 설립하고 Certified ScrumCertified Scrum^영어 인증 시리즈를 구축했다. 2009년 말에 슈와버는 스크럼 얼라이언스를 떠났고, 이후 병행하는 Professional ScrumProfessional Scrum^영어 인증 시리즈를 감독하는 Scrum.org을 설립했다. 2009년 이후, 스크럼 가이드(The Scrum Guide)The Scrum Guide^영어라는 공개 문서가 슈와버와 서덜랜드에 의해 출판되고 업데이트되었다. 이 문서는 여섯 번 개정되었으며, 가장 최근 버전은 2020년 11월에 출판되었다.

2.2. 소프트웨어 개발 방법론으로의 발전

이 방법은 일본 히토쓰바시 대학의 노나카 이쿠지로와 다케우치 히로타카가 1986년 1~2월 Harvard Business Review에 올린 〈The New New Product Developement Game〉에서 시작된다. 그 후 1991년 디그라스(DeGrace)와 슈탈(Stahl)은 〈Wicked Problems, Righteous Solutions〉에서 스크럼을 처음 언급했다. 처음 노나카와 타케우치가 스크럼을 만들 때의 목표는 공업품의 개발이었으나, 1995년 켄 슈와버(Ken Schwaber)가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 제프 서덜랜드(Jeff Sutherland), 존 스컴니오테일스(John Scumniotales), 그리고 제프 맥케나(Jeff McKenna)는 Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불렀다.

소프트웨어 개발에서 "스크럼"이라는 용어의 사용은 1986년 하버드 비즈니스 리뷰에 실린 다케우치 히로타카와 노나카 이쿠지로의 〈새로운 신제품 개발 게임〉이라는 논문에서 비롯되었다. 자동차, 복사기, 프린터 산업의 제조 회사 사례 연구를 바탕으로 저자들은 속도와 유연성을 높이기 위한 새로운 제품 개발 방식을 제시했다. 그들은 이 방식을 럭비 방식이라고 불렀는데, 이는 이 프로세스가 팀이 "단위로 거리를 이동하려고 노력하며 공을 주고받는" 여러 겹치는 단계를 거쳐 작동하는 단일 교차 기능 팀을 포함하기 때문이다. 저자들은 나중에 그들의 저서 《지식 창조 기업》에서 스크럼을 발전시켰다.

1990년대 초, 켄 슈와버는 자신의 회사인 어드밴스드 개발 메소드(Advanced Development Methods)에서 스크럼이 될 방식을 사용했다. 제프 서덜랜드, 존 스컴니오테일스, 그리고 제프 맥케나는 Easel Corporation에서 비슷한 방식을 개발했으며, 이 방식을 "스크럼"이라는 용어로 지칭했다. 서덜랜드와 슈와버는 나중에 그들의 아이디어를 스크럼으로 공식적으로 알려진 단일 프레임워크로 통합하기 위해 함께 일했다. 슈와버와 서덜랜드는 스크럼을 테스트하고 지속적으로 개선하여 1995년에 연구 논문을 발표했고, 2001년에는 애자일 소프트웨어 개발 선언을 발표했다. 슈와버는 또한 듀폰 연구소와 델라웨어 대학교에서 바바툰데 오구나이케와 협력하여 스크럼을 개발했다. 오구나이케는 제품 관리가 경험적 실천에 기반하지 않으면 초기 조건이 변경될 때 소프트웨어 개발 프로젝트가 종종 실패할 수 있다고 믿었다.

2002년, 슈와버는 다른 사람들과 함께 스크럼 얼라이언스(Scrum Alliance)를 설립하고 Certified Scrum 인증 시리즈를 구축했다. 슈와버는 2009년 말에 스크럼 얼라이언스를 떠났고, 이후 병행하는 Professional Scrum 인증 시리즈를 감독하는 Scrum.org을 설립했다. 2009년 이후, 《스크럼 가이드》(The Scrum Guide)라는 공개 문서가 슈와버와 서덜랜드에 의해 출판되고 업데이트되었다. 이 문서는 여섯 번 개정되었으며, 가장 최근 버전은 2020년 11월에 출판되었다.

3. 스크럼의 특징

스크럼은 특정 언어나 방법론에 의존하지 않고, 넓은 응용 범위를 가진 개발 기법이다. 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특징을 갖는다.

* 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
* 개발 주기는 30일 정도로 조절하고, 개발 주기마다 실제 동작할 수 있는 결과를 제공한다.
* 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공한다.
* 날마다 15분 정도 회의를 갖는다.
* 항상 팀 단위로 생각한다.
* 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지한다.

스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하는 것은 어렵다는 인식에서 출발한다. 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션(adaptive solutions^영어) 접근 방식을 취한다. 스크럼은 솔루션 개발 프레임워크이므로, 그 목적은 개발된 솔루션을 통해 가치를 창출하는 것이다.

스크럼의 핵심 기본 원칙은 프로젝트 개발 과정에서 고객이 요구 사항이나 필요 사항을 변경할 수 있다는 인식이다. 예상치 못한 변경 사항에 대해 계획에 기반한 방식으로 대처하는 것은 쉽지 않다. 따라서 스크럼은 경험에 기반한 접근 방식을 채택한다. 문제를 충분히 이해하거나 정의할 수 없으므로, 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.

스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이러한 자기 조직화를 실현하기 위해서는 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 매일 직접 만나 서로 소통하고, 프로젝트의 규율을 지켜야 한다.

스크럼은 최소한의 가볍고 간결한 공정의 틀(프로세스 프레임워크)만 제공한다. 즉, 스크럼은 개발 흐름, 핵심 이벤트만을 정의한다. 실제 솔루션 개발에서는 스크럼 프레임워크에 따라 전체적인 구체적인 절차를 구축한다.

스크럼은 경험주의에 기반한다. 스크럼은 작은 실천을 반복하여 경험을 창출하고, 그 경험에 기반하여 판단하고 지식을 얻음으로써 제품의 미래를 더욱 정확하게 예측하고 불확실성을 제어할 수 있다는 철학을 가지고 있다.

이러한 철학을 실현하기 위해 스크럼에는 세 가지 기둥이 있다.

* 투명성(transparency^영어)
* 검사(inspection^영어)
* 적응(adaptation^영어)

스크럼에서는 투명성을 통해 팀 전체에 현 상황이 올바르게 공유되고, 제품이 빈번하게 검사되어 이상이 빠르게 발견되며, 이에 적응하여 제품 및 프로세스가 수정되기를 기대한다.

4. 스크럼 팀

스크럼 팀은 스크럼의 기본 단위가 되는 작은 팀이다. 스크럼 팀은 제품 책임자, 개발자, 스크럼 마스터의 세 가지 역할로 구성된다.

스크럼 팀은 스포츠 팀처럼 기능한다. 각 구성원은 높은 전문성을 가지면서 자신의 포지션에 얽매이지 않고, 하나의 목표를 향해 모든 구성원이 하나의 팀으로서 협력한다. 즉, 매니지먼트, 엔지니어링, 디자인 등 다양한 전문 분야를 가진 전문가가 분야에 구애받지 않고, 하나의 제품 목표에 초점을 맞춰 제품 개발을 수행하는 팀이 스크럼 팀이다.

스크럼 팀은 제품 목표 달성에 필요한 모든 활동에 대한 책임과 권한을 가진다. 개발에 있어서 어떤 구성원이 무엇을, 언제, 어떻게 수행할지는 스크럼 팀 자신이 결정하고 자기 관리한다. 가치 있는 결과물(제품 목표 달성)을 만들어내는 것에 관해 팀으로서 이해 관계자에게 설명 책임을 진다.

스크럼 팀은 적응형 제품을 개발하므로, 적응에 필요한 속도를 확보하기 위해 1개 팀당 10명 이하가 권장된다.

스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하는 것은 어렵다는 인식에서 출발한다. 스크럼의 핵심 기본 원칙은 프로젝트 개발 과정에서 고객이 요구 사항이나 필요 사항을 변경할 수 있다는 인식이다. 따라서 스크럼은 경험에 기반한 접근 방식을 채택하여, 문제를 충분히 이해하거나 정의할 수 없을때 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.

스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이러한 자기 조직화를 실현하기 위해서는 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 모든 팀원이 매일 직접 만나 서로 소통하고, 프로젝트의 규율을 지켜야 한다.

4.1. 제품 책임자 (Product Owner)

각 스크럼 팀에는 한 명의 제품 책임자(Product Owner)가 있다. 제품 책임자는 제품 개발의 비즈니스 측면에 집중하며, 이해 관계자 및 팀과의 연락에 대부분의 시간을 할애한다. 이 역할은 주로 제품의 이해 관계자, 고객의 목소리, 또는 위원회의 요구 사항을 나타내며 비즈니스 결과 전달에 대한 책임을 진다. 제품 책임자는 제품 백로그를 관리하며, 팀이 제공하는 가치를 최대화할 책임이 있다. 그들은 팀의 기술적 해결책을 지시하지 않지만, 대신 팀 구성원 간의 합의를 구하려고 시도할 수 있다.

스크럼 팀과 이해 관계자 간의 주요 연락 담당자로서, 제품 책임자는 발표, 프로젝트 정의 및 진행 상황, RIDA(위험, 장애물, 의존성 및 가정), 자금 조달 및 일정 변경, 제품 백로그 및 프로젝트 거버넌스 등을 포함한 다양한 책임을 수행한다. 제품 책임자는 필요한 경우, 팀 구성원의 의견 없이 스프린트를 취소할 수도 있다.

프로덕트 오너(Product Owner^영어)는 제품의 총책임자이다. 고객의 의사를 대표하는 역할을 맡는다. 비즈니스 관점(ROI 등)에서 프로젝트에 문제가 없음을 보장하는 역할을 한다. 고객의 요구 사항을 제품 백로그에 우선순위를 정하여 반영한다.

4.2. 스크럼 마스터 (Scrum Master)

스크럼은 스크럼 마스터에 의해 촉진되며, 스크럼 마스터의 역할은 스크럼 이론과 실천에 대해 팀을 교육하고 코칭하는 것이다. 스크럼 마스터는 전통적인 팀 리더 또는 프로젝트 매니저와는 다른 역할과 책임을 갖는다. 스크럼 마스터의 책임에는 코칭, 목표 설정, 문제 해결, 감독, 계획, 백로그 관리 및 의사 소통 촉진 등이 있다. 반면에, 전통적인 프로젝트 매니저는 종종 관리와 관련된 책임을 갖지만 스크럼 마스터는 그렇지 않다. 스크럼 팀은 프로젝트 매니저를 포함하지 않아 개발자 간의 자기 조직화를 극대화한다.

스크럼 팀(Scrum Team^영어)은 스크럼의 기본 단위가 되는 작은 팀이다.

스크럼 마스터(Scrum Master^영어)는 스크럼 프레임워크가 올바르게 적용되도록 보장하는 역할을 한다. 주요 업무는 팀 내부 및 외부 조직 간 조율(퍼실리테이션)과 외부 방해 요소를 해결하는 것이다. 기존의 프로젝트 매니저가 이 역할을 수행하는 경우가 많지만, 프로젝트 자체를 관리하지는 않는다.

4.3. 개발자 (Developers)

스크럼에서 "개발자" 또는 "팀원"이라는 용어는 연구원, 설계자, 디자이너, 프로그래머 등 제품 개발 및 지원에 역할을 하는 모든 사람을 지칭한다.

스크럼 팀(Scrum Team^영어)은 스크럼의 기본 단위가 되는 작은 팀이다. 스크럼 팀은 스포츠 팀처럼 각 구성원이 높은 전문성을 가지면서도 자신의 포지션에 얽매이지 않고, 하나의 목표를 향해 모든 구성원이 하나의 팀으로서 협력하는 것을 의미한다. 즉, 매니지먼트, 엔지니어링, 디자인 등 다양한 전문 분야를 가진 전문가들이 분야에 구애받지 않고, 하나의 제품 목표에 초점을 맞춰 제품 개발을 수행하는 팀이 스크럼 팀이다.

스크럼 팀은 제품 목표 달성에 필요한 모든 활동에 대한 책임과 권한을 가진다. 즉, 개발에 있어서 어떤 구성원이 무엇을, 언제, 어떻게 수행할지는 스크럼 팀 자신이 결정하고 자기 관리한다. 가치 있는 결과물(제품 목표 달성)을 만들어내는 것에 관해 팀으로서 이해 관계자에게 설명 책임을 진다.

스크럼 팀은 적응형 제품을 개발하므로, 적응에 필요한 속도를 확보하기 위해 1개 팀당 10명 이하의 크기가 권장된다.

스크럼 팀에는 다음과 같은 3가지 명확한 역할과 책임이 정의된다. 개발자(Developer^영어)는 각 [스프린트]에서 활용 가능한 [인크리먼트]의 모든 측면을 생성하는 역할을 담당한다. 개발자에게 필요한 특정 기술은 광범위하며, 작업 영역에 따라 달라진다.

5. 스크럼의 진행 (워크플로우)

스크럼은 30일(일반적인 권장 기간이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가짐)간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행하는 방식이다.

스크럼 진행 시 중요 요소는 다음과 같다.

* 제품 백로그(Product Backlog): 개발할 제품에 대한 요구 사항 목록
* [[스프린트 (애자일 개발 프로세스)|스프린트]](Sprint): 반복적인 개발 주기 (회사에서 정하는 이터레이션이 개발 주기가 된다. 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1스프린트이다)
* 스프린트 계획 회의(Sprint Planning Meeting): 스프린트 목표와 스프린트 백로그를 계획하는 회의
* 스프린트 백로그(Sprint Backlog): 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
* 일일 스크럼 회의(Daily Scrum Meeting): 날마다 진행되는 미팅 (어제 한 일, 오늘 할 일, 장애 현상 등을 공유)
* 실행 가능한 제품(shippable product) 개발: 스프린트의 결과로써 나오는 실행 가능한 제품

스크럼은 상기 요소들을 아래와 같은 순서에 따라 진행시킨다.

1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율한다. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
3. 스프린트 목표를 구현 가능하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5. 매 회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해한다.
6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
7. 스프린트 기간 중 다음 스프린트를 준비하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.

이러한 진행 방식과 더불어, 개발 팀원 이외에 아래와 같은 직책(역할)이 정의되어 있다.

* [[제품 책임자]](Product Owner): 제품 백 로그를 정의하여 우선순위를 정해 준다.
* [[스크럼 마스터]](Scrum Master): 프로젝트 관리자(코치)

스크럼 마스터는 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자는 스프린트 목표와 백로그 등의 결정에 있어 중심이 되는 상위 관리자이다. 제품 책임자가 독단적으로 목표를 결정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 정한다.

이런 과정을 거친 뒤, 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해 나가게 된다. 보통 각 작업들은 4시간에서 16시간 정도 걸리도록 정한다. 작업을 정하고 할당하는 데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행된다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고받게 되고, 끈끈한 협업 체계를 가지게 된다.

스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하기 어렵다는 인식에서 출발한다. 대안적인 접근 방식은 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션이다. 스크럼은 솔루션 개발 프레임워크이므로, 개발된 솔루션을 통해 가치를 창출하는 것이 목적이다.

스크럼은 "문제에 대한 해결책 열거", "우선순위가 높은 해결책을 일정 기간 동안 팀에서 실행", "결과 검사에 기반한 조정", "그 반복"을 실현할 수 있는 환경을 만든다. 스크럼의 핵심 기본 원칙은 프로젝트 개발 과정에서 고객의 요구 사항이나 필요 사항을 변경할 수 있다는 인식이다. 예상치 못한 변경 사항에 대해 계획에 기반한 방식으로 대처하는 것은 쉽지 않다. 따라서 스크럼은 경험에 기반한 접근 방식을 채택한다. 즉, 문제를 충분히 이해하거나 정의할 수 없으므로, 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.

스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이러한 자기 조직화를 실현하기 위해서는 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 모든 팀원이 매일 직접 만나 서로 소통하고, 프로젝트의 규율을 지켜야 한다.

스크럼은 경험주의(투명성, 검사, 적응)를 실현하기 위해 산출물과 이벤트를 정의한다. 이러한 프레임워크를 따름으로써 팀과 제품의 투명성이 향상되고, 올바른 검사가 정기적으로 이루어지며, 빠른 적응이 일어나 좋은 제품이 만들어진다.

5.1. 스프린트 (Sprint)

스크럼에서 스프린트(Sprint)는 팀 구성원들이 특정 목표를 달성하기 위해 작업하는 고정된 기간을 의미한다. 각 스프린트는 일반적으로 1주에서 4주 사이이며, 2주가 가장 일반적이다. 스프린트의 결과는 기능적인 결과물, 즉 증분 방식으로 개발이 이루어진 제품이다.

각 스프린트는 스프린트 목표가 정의되는 스프린트 계획 이벤트로 시작하며, 다음 두 가지 이벤트로 종료된다.

* 스프린트 검토: 이해 관계자에게 피드백을 얻기 위해 진행 상황을 보여준다.
* 스프린트 회고: 다음 스프린트에 대한 교훈과 개선 사항을 식별한다.

만약 스프린트가 비정상적으로 종료되면, 종료 이유를 검토하는 새로운 스프린트 계획을 수행한다.

스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 실현하기 어렵다는 인식에서 출발한다. 따라서 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션 개발 방식을 택한다. 이러한 적응형 솔루션을 팀에서 개발하기 위한 규칙과 프레임워크가 바로 스크럼이다. 스크럼은 솔루션 개발 프레임워크이므로, 개발된 솔루션을 통해 가치를 창출하는 것이 목적이다.

스크럼은 "문제에 대한 해결책 열거", "우선순위가 높은 해결책을 일정 기간 동안 팀에서 실행", "결과 검사에 기반한 조정", "그 반복"을 실현할 수 있는 환경을 만든다. 스크럼의 핵심은 프로젝트 개발 과정에서 고객의 요구 사항 변경을 당연하게 여기는 것이다. 예상치 못한 변경에 대해 계획에 기반한 방식으로 대처하기 어렵기 때문에, 스크럼은 경험에 기반한 접근 방식을 채택한다. 즉, 문제를 충분히 이해하거나 정의할 수 없으므로, 나타나는 요구 사항에 신속하게 대응하기 위한 팀의 능력을 극대화하는 데 집중한다.

스크럼은 팀이 자발적으로 조직적으로 행동하도록 한다. 이를 위해 모든 팀원이 물리적으로 같은 장소에 있거나, 긴밀한 온라인 공동 작업을 통해 매일 직접 만나 소통하고, 프로젝트의 규율을 지켜야 한다.

스크럼은 경험주의(투명성, 검사, 적응)를 실현하기 위해 산출물과 이벤트를 정의한다. 이러한 프레임워크를 통해 팀과 제품의 투명성이 향상되고, 올바른 검사가 정기적으로 이루어지며, 빠른 적응이 일어나 좋은 제품이 만들어진다.

스프린트 목표(Sprint Goal)는 스프린트가 제품 개선을 통해 제공하는 가치의 목표이다. 스프린트의 목적은 스프린트 목표 그 자체이다. 만들어지는 제품(what)이나 제품 개발 절차(how)뿐만 아니라, 창출하고 싶은 성과 즉 가치(why)에 주목하기 위해 스프린트 목표가 설정된다. 상황 변화로 설정된 스프린트 목표가 더 이상 쓸모 없게 된 경우, 해당 스프린트는 중단된다.

5.1.1. 스프린트 계획 (Sprint Planning)

스크럼에서 스프린트는 반복적인 개발 주기를 의미하며, 일반적으로 1주에서 4주 사이의 기간을 가진다. 스프린트 계획 회의는 각 스프린트의 시작 시점에 열리며, 이 회의를 통해 해당 스프린트의 목표와 스프린트 백로그를 계획한다.

스프린트 계획 회의는 다음과 같은 순서로 진행된다.

# 제품 책임자(PO)가 제품 백로그의 우선순위를 설명하고, 개발팀과 함께 이번 스프린트에서 어디까지 작업할지 조율한다. 이때 선정된 제품 백로그 항목들이 이번 스프린트의 목표가 된다.
# 스프린트 목표를 달성하기 위해 필요한 구체적인 작업 목록(스프린트 백로그)을 팀에서 작성하고, 각 팀원에게 작업을 할당한다.

스프린트 백로그의 각 작업은 보통 4시간에서 16시간 정도 소요되도록 정하며, 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행된다. 이러한 과정을 통해 팀원들은 활발하게 의사를 교환하고 협업 체계를 강화한다.

5.1.2. 일일 스크럼 (Daily Scrum)

5.1.3. 스프린트 리뷰 (Sprint Review)

스프린트 리뷰는 팀이 완료한 작업을 이해관계자들과 공유하고, 피드백, 기대치, 향후 계획에 대해 협의하는 회의이다. 스프린트 리뷰에서는 완료된 결과물을 이해관계자들에게 시연한다. 스프린트 리뷰의 권장 시간은 스프린트 1주일에 1시간이다.

스프린트 검토는 n주(스프린트 주기)마다 이루어지며, 스프린트 성과(인크리먼트)를 검사 대상으로 한다. 이때 제품 목표를 확약/검사 기준으로 삼아 제품 백로그에 적응 반영한다.

5.1.4. 스프린트 회고 (Sprint Retrospective)

스크럼 팀 구성원들이 스프린트의 강점과 약점, 향후 개선 분야, 그리고 지속적 프로세스 개선 활동을 내부적으로 분석하는 별도의 회의이다.

5.2. 백로그 정비 (Backlog Refinement)

백로그 정비는 팀 구성원들이 향후 스프린트를 위해 백로그를 수정하고 우선순위를 정하는 과정이다. 이는 새로운 스프린트 시작 전에 별도의 단계로 수행되거나, 팀 구성원이 스스로 진행하는 지속적인 과정으로 수행될 수 있다. 백로그 정비에는 큰 작업을 더 작고 명확한 작업으로 세분화하고, 성공 기준을 명확히 하며, 변화하는 우선순위와 반환값을 수정하는 작업이 포함될 수 있다.

6. 스크럼 산출물 (Artifacts)

스크럼 팀은 프로젝트를 진행하며 수행한 작업을 문서화하여 제품 개발을 관리하는데, 이러한 수단을 아티팩트라고 부른다. 스크럼 아티팩트는 총 7가지가 있지만, 가장 일반적인 3가지는 제품 백로그, 스프린트 백로그, 인크리먼트이다.

스크럼은 복잡한 문제에 대한 완벽한 솔루션을 한 번에 만들기 어렵다는 인식에서 출발한다. 대신, 불완전한 솔루션을 빠르게 제시하고, 이를 통해 학습하고 개선하는 적응형 솔루션 방식을 사용한다. 스크럼은 이러한 적응형 솔루션을 개발하기 위한 가벼운 프레임워크이며, 개발된 솔루션을 통해 가치를 창출하는 것을 목표로 한다.

6.1. 제품 백로그 (Product Backlog)

제품 백로그는 수행해야 할 작업의 세분화된 목록이며, 팀이 제품을 위해 유지 관리하는 요구 사항(예: 소프트웨어 기능, 버그 수정 및 비기능적 요구 사항)의 정렬된 목록을 포함한다. 제품 백로그의 순서는 작업의 긴급성에 해당한다. 백로그 항목의 일반적인 형식에는 사용자 스토리와 유스 케이스가 포함된다. 제품 백로그에는 또한 제품 소유자의 비즈니스 가치 평가와 팀의 제품 노력 또는 복잡성에 대한 평가가 포함될 수 있으며, 이는 반올림된 피보나치 수열을 사용하는 플래닝 포커의 스토리 포인트로 표현될 수 있다. 이러한 추정치는 제품 소유자가 타임라인을 측정하는 데 도움을 주며, 제품 백로그 항목의 순서에 영향을 미칠 수 있다.

제품 소유자는 위험, 비즈니스 가치, 종속성, 규모 및 타이밍과 같은 고려 사항을 기반으로 제품 백로그 항목을 유지 관리하고 우선 순위를 정한다. 백로그 상단의 우선 순위가 높은 항목은 개발자가 작업할 수 있도록 더 자세하게 세분화되는 반면, 백로그 아래쪽의 작업은 더 모호할 수 있다.

프로덕트 골(Product Goal)은 프로덕트의 미래 상태이며, 미래의 프로덕트 사용이 창출해야 할 가치이다. 골은 평가 가능하며, 모두에게 공유되고, 한 번에 하나만 설정된다.

프로덕트 골은 프로덕트의 목표이다. 이를 통해 스크럼 팀은 프로덕트 골의 실현을 목표로 계획을 수립할 수 있다. 프로덕트 골은 평가 가능하며, 이를 통해 프로덕트의 진척 상황을 검토할 수 있으며, 프로덕트가 적응할 수 있다. 프로덕트 골은 팀과 이해관계자에게 공유된다. 이를 통해 팀은 제공해야 할 가치를 파악하고 "왜(why) 이것을 개발하는가"를 이해하며, 목적 의식을 가진 자율적인 개발이 가능해진다. 프로덕트 골은 한 번에 하나만 설정된다. 이를 통해 팀은 단일 골에 집중할 수 있다.

예를 들어, 택시 서비스가 내걸는 "고객은 평균 7분 안에 택시를 잡을 수 있다"는 정량적으로 평가 가능한 사용자 경험이며, 프로덕트 골에 적합하다.
프로덕트 백로그(Product Backlog^영어)는 프로덕트가 지향하는 모습과 그렇게 되기 위한 요소의 목록이다. 프로덕트 백로그는 프로덕트 골과 프로덕트 백로그 항목으로 구성된다。

프로덕트 백로그 항목(PBI)은 프로덕트 골을 달성하기 위한 "무언가(what)"의 정의이며, 이상적인 형태에 필요한 요소를 나타낸다. PBI는 비용과 고객 가치가 추정되고 우선순위를 가진다. 프로덕트에 대한 요구사항은 항상 변화한다. 예를 들어 변화를 일으키는 요소로는 프로덕트의 사용 및 성장, 시장의 피드백, 비즈니스 요구사항 및 환경 변화, 기술의 등장 등이 있다. 프로덕트에 대한 요구사항의 변화에 대응하여 프로덕트 백로그는 "적응"한다. 즉, 프로덕트 백로그의 항목은 요구사항의 변화에 응답하여 변화한다. 프로덕트 백로그를 업데이트함으로써, 제품은 항상 적절하고 경쟁력을 가지며 편리한 방향으로 개발된다.

프로덕트 백로그의 최종 결정과 책임은 프로덕트 오너에게 있으며 존중된다. 프로덕트 백로그에 접근하는 방식(오너 주도 또는 팀 협업)은 프로젝트에 따라 다르다. 또한 PBI가 가져야 할 구체적인 항목은 각 프로젝트마다 정의된다(스크럼은 어디까지나 프레임워크이다).

프로덕트 백로그 리파인먼트 스프린트 기간 동안 팀은 프로덕트 백로그의 건전성을 유지하기 위한 회의를 연다. 프로덕트 백로그의 건전성을 나타내는 지표로, INVEST가 자주 사용된다.

스크럼은 제품 목표 달성을 유일한 목적으로 삼아 훌륭한 솔루션/제품 개발을 가능하게 한다. 하지만 그 전제로서 제품 목표, 즉 제공하는 가치의 질이 모든 것을 좌우한다. 가치가 없는 제품 목표(무가치한 가치)를 달성하는 완벽한 제품이 완성되어도, 그것은 가치를 창출하지 못한다. 따라서 좋은 제품 목표를 설계하는 다양한 기법이 스크럼 프레임워크와 함께 채택될 수 있다.

제품 목표는 종종 제품의 비전(Vision^영어)에서 연역된다. 제품의 비전은 기업이 내세우는 이상적인 모습이다. 제품은 점차 개선되면서 비전을 향해 나아가기 때문에, 여러 상태를 거치게 된다. 제품 목표는 그 하나하나의 상태에 대응한다.

제공해야 할 가치가 불확실한 단계에서는 제품 목표 자체를 탐색할 필요가 있다(참고: 제품 개발). 그 경우, 적응적인 가치 탐색을 수행한다. 소프트웨어 프로토타이핑을 통해 MVP를 만들고 가치를 탐색한다. 린 스타트업은 그것을 실현하는 방법론 중 하나이다. 제품 관리는 가치 탐색에서 개발까지를 포함한 관리이다.

제품 목표가 불확실한 경우, 제품 목표를 설정하는 것 자체가 의미를 갖는다. 왜냐하면 제품 목표가 갖는 특성(장기 목표·단일·측정 가능·공개)은 구체적이며, 이해 관계자와의 논의를 내용 있는 것으로 만들기 때문이다.

제품 목표의 최종 결정은 제품 책임자의 책임이다. 그 과정에서 스크럼 팀을 참여시키는 것은 현장의 감각·지혜를 끌어내고 또한 팀의 더욱더 자기 관리를 촉진한다는 의미에서 유의미하다. 목표는 달성해야 할 목표이지만, 실제로 사용자가 손에 넣는 것은 개발된 증분 전체인 제품이다.

6.2. 스프린트 백로그 (Sprint Backlog)

스프린트 백로그는 개발자가 특정 스프린트에서 처리하도록 의도된 제품 백로그의 하위 집합이다. 개발자는 과거 성과를 사용하여 각 스프린트 역량을 평가하고, 스프린트를 채우기에 적절하다고 판단되는 작업으로 이 백로그를 채운다. 스크럼 접근 방식은 특정 개인이나 리더가 개발자에게 할당하지 않은 작업을 스프린트 백로그에 포함한다. 팀원은 백로그 우선순위와 자신의 능력 및 역량에 따라 필요에 따라 작업을 가져와 자체적으로 조직한다.

스프린트 백로그는 스프린트 계획이다. 여기에는 이 스프린트에서 실현하고자 하는 성과 (스프린트 목표), 이를 위해 필요한 PBI, PBI를 생성하는 절차 계획이 포함된다. 스프린트 백로그는 데일리 스크럼에서 진척 상황을 검사할 수 있을 정도로 상세해야 한다. 스프린트 백로그는 스프린트 계획 회의에서 생성되며, 상황 변화에 따라 적응한다.

6.3. 인크리먼트 (Increment)

인크리먼트(Increment^영어)는 스프린트 목표를 충족하는, 잠재적으로 릴리스 가능한 스프린트 결과물이다. 인크리먼트는 완료된 모든 스프린트 백로그 항목으로 구성되며, 이전 모든 스프린트의 작업과 통합된다.

인크리먼트는 제품 목표를 향한 구체적인 성과물이다. 인크리먼트를 쌓아 올려 이상적인 형태의 제품이 실현된다. 인크리먼트의 원료는 PBI(제품 백로그 항목)이다. 즉, 아이디어인 PBI를 개발자가 구현하여 인크리먼트가 된다. 작업 중인 중간 산출물은 인크리먼트가 아니며, "완료의 정의"를 충족해야 인크리먼트가 된다. 인크리먼트는 릴리스 가능해야 한다.

완료의 정의(Definition of Done^영어)는 PBI 완성품이 충족해야 하는 품질 기준이다.

7. 스크럼의 확장 및 변형

스크럼은 다양한 목표를 달성하기 위해 여러 상황에 맞춰 자주 조정되거나 적용된다. 스크럼은 전체 제품 개발 생명 주기를 다루지 않기 때문에, 다른 소프트웨어 개발 방법론과 결합하여 사용하기도 한다. 또한, 여러 스크럼 실무자들은 특정 문제나 조직에 스크럼을 적용하거나 조정하는 방법에 대한 더 자세한 기술을 제안해 왔으며, 이러한 기술을 건축 및 소프트웨어의 디자인 패턴과 유사하게 '패턴'이라고 부르기도 한다.

7.1. 스크럼반 (Scrumban)

스크럼반은 스크럼과 칸반을 기반으로 하는 소프트웨어 생산 모델이다. 각 작업 단계를 설명하기 위해, 같은 공간에서 작업하는 팀은 종종 포스트잇이나 큰 화이트보드를 사용한다. 칸반 모델을 통해 팀은 작업 단계와 제한 사항을 시각화할 수 있다.

7.2. 스크럼 오브 스크럼 (Scrum of Scrums)

스크럼 오브 스크럼은 동일한 제품에 대해 조정하는 여러 팀을 위해 스크럼을 확장하여 운영하는 기술이다. 스크럼 오브 스크럼 데일리 스크럼 회의에는 각 개별 팀에서 선택된 대표자가 참여하며, 이들은 개발자 또는 스크럼 마스터일 수 있다. 조정 도구로서 스크럼 오브 스크럼은 팀이 팀 전체의 위험, 방해 요소, 종속성 및 가정(RIDA)을 집단적으로 처리할 수 있도록 하며, 이는 자체 백로그에서 추적될 수 있다.

7.3. 대규모 스크럼 (Large-Scale Scrum, LeSS)

크레이그 래먼과 바스 보드가 개발한 대규모 스크럼(Large-Scale Scrum, LeSS)은 다양한 규칙과 지침을 통해 스크럼을 확장하는 제품 개발 프레임워크이다. 이 프레임워크는 두 단계로 구성된다. 첫 번째 단계는 최대 8개 팀을 위해 설계되었으며, 두 번째 단계인 'LeSS Huge'는 수백 명의 개발자가 참여하는 개발을 수용할 수 있다.

8. 비판

일부에서는 매일 스크럼과 스크럼 검토와 같은 스크럼 이벤트가 생산성을 저해하고 실제 생산적인 작업에 더 잘 사용될 수 있는 시간을 낭비한다고 주장해 왔다. 스크럼은 파트타임 또는 지리적으로 떨어진 팀, 혼자 또는 작업 그룹에서 일하는 것이 더 나은 고도로 전문화된 구성원을 가진 팀, 점진적이고 개발 테스트에 적합하지 않은 팀에게 어려움을 야기하는 것으로도 관찰되었다. 체계적 검토 결과, 분산 소프트웨어 개발에서 "분산 스크럼은 전반적인 프로젝트 성공에 긍정적이든 부정적이든 아무런 영향을 미치지 않는다"는 사실이 밝혀졌다.

마틴 파울러는 애자일 소프트웨어 개발 선언의 저자 중 한 명으로, "애자일의 가치와 원칙을 무시하는" "가짜 애자일" 관행과 "프로세스와 도구보다 개인과 상호 작용"을 중시하고 작업 수행자가 작업 방식을 결정하고 필요에 따라 프로세스를 변경할 수 있도록 하는 애자일 원칙에 반하는 "애자일 산업 복합체"의 방법 강요를 비판했다.

2016년 9월, 애자일 소프트웨어 개발 선언의 서명자인 론 제프리스는 "다크 스크럼"이라고 칭하며 "스크럼은 프로그래머에게 매우 위험할 수 있다"고 말했다.