스크럼(Scrum)과 스프린트(Sprint)
[코드스테이츠 PMB 11] Ep29. 스크럼 가이드 2020
'스크럼 가이드(Scrum Guide)'는 Ken Schwaber(켄 슈와버)와 Jeff Sutherland(제프 서덜랜드)가 1990년대 초반에 스크럼을 개발한 이후, 2010년에 스크럼 가이드의 첫 번째 버전을 작성하여 전 세계의 사람들이 스크럼을 이해할 수 있도록 문서화한 결과물이다.
그 이후로 조금씩 기능을 업데이트하며 가이드를 발전시켜왔으며 2020년 11월 18일에 스크럼 가이드를 새로 업데이트했다. 오늘은 '스크럼 가이드'를 읽고 스크럼(Scrum)과 스프린트(Sprint)에 대해 정리해보는 시간을 가졌다. 스크럼 가이드는 아래 링크를 통해 다운로드할 수 있다.
1. 스크럼 정의
스크럼(Scrum)은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 경량 프레임워크이다.
풀어서 설명하자면, 팀이 중심이 되어 개발의 효율성을 높이는 일종의 프로세스 프레임워크이다. 짧은 주기 단위(Sprint)로 기획에서 배포까지 진행하고, 이를 지속적으로 반복하면서 효율적인 협업이 이루어지도록 한다.
프레임워크 안에서 다양한 프로세스, 테크닉, 방법을 이용해 볼 수 있다. 기존의 업무 프로세스를 스크럼 프레임워크 내에서 수행할 수 있으며, 스크럼으로 인해 기존의 업무 방식이 불필요해질 수도 있다. 현재의 관리, 환경, 업무 기법과 관련된 효과를 스크럼을 통해 가시화하여 개선을 할 수 있다.
스크럼 이론
스크럼은 경험주의와 린 씽킹을 기초로 한다. 경험주의는 경험과 관찰한 것을 기반으로 한 의사 결정으로부터 지식을 얻는 것이다. 린 씽킹은 낭비를 줄이고 본질에 초점을 맞추는 것이다.
스크럼은 예측 최적화와 리스크 통제를 위해 반복적이고 점진적인 방식을 쓴다. 전체적으로 업무를 수행하는데 필요한 모든 기술과 전문성을 갖출 수 있도록 사람들을 스크럼에 참여시키고, 필요에 따라 그러한 기술을 공유하고 습득한다.
2. 스크럼 팀
스크럼 팀은 스크럼 조직의 기본 단위로 적은 수의 인원으로 구성된다. 스크럼 팀은 한 명의 스크럼 마스터, 한 명의 프로덕트 오너, 개발자들로 구성된다. 스크럼 팀 내에는 하부 팀이나 수직구조가 없으며 스크럼 팀은 하나의 프로덕트 목표에 동시에 집중하는 전문가들의 모임이다.
스크럼 팀은 교차 기능(cross-functional)을 수행하므로 팀 구성원들이 매 스프린트의 가치를 창출하는 데에 필요한 모든 기술들을 보유하고 있다. 또한 자체 관리 기능을 수행하므로 누가 무엇을 언제 어떻게 수행할 것인지 내부적으로 결정한다.
스크럼 팀은 민첩성을 유지할 수 있을 만큼 작으며 한 스프린트 내에서 의미 있는 작업을 완료할 수 있을 만큼 충분한 크기여야 한다. 일반적으로 10명 또는 그보다 적은 수의 인원으로 구성된다. 일반적으로 소규모 팀이 의사소통을 더 잘하고 더 생산적이다. 스크럼 팀이 너무 커지면, 하나의 동일한 프로덕트에 초점을 맞춘 여러 개의 응집력 있는 스크럼 팀으로 재구성하는 것을 고려해야 한다. 따라서 동일한 프로덕트 목표와 프로덕트 백로그, 프로덕트 오너를 공유해야 한다.
개발자들(Developers)
개발자들은 매 스프린트마다 사용 가능한 점진적 개선품을 개발하는 데 전념하는 사람들이다. 개발자들은 항상 다음의 사항들에 책임을 갖는다.
스프린트와 스프린트 백로그에 대한 계획을 세우는 것
완료의 정의를 준수하여 품질을 높여가는 것
스프린트 목표를 위해 매일 계획을 조정
전문가로서 서로 책임을 지는 것
프로덕트 오너(Product Owner)
프로덕트 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 프로덕트 오너는 프로덕트 백로그를 효과적으로 관리하는데, 다음 사항들을 포함한다.
프로덕트 목표를 세우고 명쾌하게 소통하는 것
프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
프로덕트 백로그 아이템을 우선순위에 따라 정렬
프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
프로덕트 오너는 위의 작업을 직접 하거나 다른 사람들에게 그 책임을 위임할 수 있지만, 최종 책임은 프로덕트 오너가 진다. 프로덕트 오너가 성공적으로 일을 하기 위해서는 조직 전체가 그의 결정을 존중해야 한다. 프로덕트 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인할 수 있다.
스크럼 마스터(Scrum Master)
스크럼 마스터는 스크럼 가이드에 정의된 대로 스크럼을 확립하는 것에 책임이 있다. 그들은 스크럼 팀과 조직의 모든 구성원이 스크럼 이론과 실천법을 이해하도록 돕는다.
스크럼 마스터는 스크럼 팀을 효율적으로 만들 책임이 있으며, 스크럼 팀이 스크럼 프레임워크 내에서 실천법을 향상시키도록 한다. 스크럼 마스터는 스크럼 팀과 더 큰 조직을 위해 봉사하는 진정한 리더이다. 스크럼 마스터는 스크럼 팀을 위해 다음과 같은 다양한 방법으로 스크럼 팀을 지원한다.
팀원들이 자율적으로 관리하고 교차 기능(cross-functionality)에 대해 코칭하는 것
스크럼 팀이 완료의 정의를 충족하는 높은 가치의 결과물을 만드는 데에 집중하도록 돕는 것
스크럼 팀의 진척에 방해가 되는 장애물을 제거하는 것
모든 스크럼 이벤트가 긍정적이고 생산적으로 이루어지는 것, 그리고 정해진 시간 안에 마치도록 보장하는 것
스크럼 마스터가 프로덕트 오너를 위해 일하는 방법
효과적인 프로덕트 목표 정의와 프로덕트 백로그 관리 방법을 돕는 것
스크럼 팀이 명확하고 간결한 프로덕트 백로그 아이템의 필요성을 이해하도록 돕는 것
복잡한 환경에 대해 경험주의적으로 프로덕트 계획을 수립하도록 돕는 것
요구 또는 필요에 따라 이해관계자와의 협업을 촉진하는 것
스크럼 마스터가 조직을 위해 일하는 방법
조직이 스크럼을 채택하는 경우, 조직을 리드하고 교육하고 코칭하는 것
조직 내에 스크럼을 실행하는 것을 계획하고 조언하는 것
조직 구성원들과 이해관계자들이 복잡한 작업에 대한 경험주의 접근법을 이해하고 활용하도록 돕는 것
이해관계자들과 스크럼 팀 간의 장벽을 제거하는 것
출처: https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/3. 스프린트
스프린트(Sprint)는 '단거리 질주'라는 사전적 의미를 가지며, 모든 팀원이 정해진 기간 동안 정해진 태스크를 전력 질주하듯 집중해서 업무를 수행하는 것을 의미한다.
스프린트 기간은 한 달 이하의 고정된 기간으로 짧게 설정된다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다. 스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행하며, 스크럼의 프로세스는 아래와 같다.
1) 스프린트 계획
스프린트 계획을 통해서 해당 스프린트 동안 수행할 업무를 선정한다. 스크럼 팀 전체가 참여하여 계획을 한다. 프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요한 백로그와 그것들이 프로덕트 목표와 어떻게 연결되는지를 참여자들이 논의할 수 있도록 준비해야 한다. 스크럼 팀에 조언을 해줄 수 있는 다른 사람을 스프린트 계획에 초청할 수도 있다.
2) 데일리 스크럼
데일리 스크럼의 목적은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것이다. 데일리 스크럼은 스크럼 팀의 개발자들만 참여하는 15 분 길이의 이벤트이다. 복잡성을 줄이기 위해 같은 시각에 같은 장소에서 스프린트 기간의 모든 근무일마다 수행한다.
3) 스프린트 리뷰
스프린트 리뷰의 목적은 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것이다. 스크럼 팀은 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트 목표 대비 진척을 보여준다.
스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토한다. 이 정보에 기초하여 참여자들은 다음으로 무엇을 할 것인지 협력하여 논의한다. 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다.
4) 스프린트 회고
스프린트 회고의 목적은 품질과 효율을 높이기 위한 방법들을 계획하는 것이다. 스크럼 팀은 팀원 개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행되었는지를 점검한다. 팀이 잘못된 방향으로 가게 된 원인을 찾아낸다. 스프린트 동안 잘 된 점, 발생한 문제, 문제 해결 방법에 대해 논의한다.
스크럼 팀은 효율을 향상시키기 위해 가장 도움이 되는 개선사항을 찾고, 가장 영향이 큰 개선책을 최우선으로 고려해야 한다. 다음 스프린트를 위해 스프린트 백로그에 추가할 수도 있다. 스프린트 회고를 마지막으로 스프린트가 종료된다.
4. 스크럼 산출물
스크럼의 산출물은 업무 또는 가치를 나타내며, 핵심 정보의 투명성을 극대화할 수 있다. 따라서 이를 검토하는 모든 사람은 적응/개선을 위한 동일한 기반 정보를 얻는다.
각 산출물은 측정 가능한 진척에 집중하고 투명성을 높이는 정보를 제공할 것을 명확하게 하는 약속을 담고 있다.
프로덕트 백로그에는 프로덕트 목표가 있다.
스프린트 백로그에는 스프린트 목표가 있다.
증가분에는 완료의 정의가 있다.
프로덕트 백로그
프로덕트 백로그는 프로덕트를 향상시키기 위한 것으로 발생하는 업무를 우선순위에 따라 정렬한 목록이다. 프로덕트 백로그 아이템은 스프린트 계획 이벤트 때에 선택할 준비가 되어 있어야 하며 스크럼 팀이 한 스프린트 안에 완료할 수 있는 것이다.
개발자들은 프로덕트 백로그 아이템의 크기를 결정하는 데에 책임을 진다. 프로덕트 오너는 개발자들이 절충안 trade-offs을 이해하고 선택하도록 도움을 줄 수 있다.
약속 : 프로덕트 목표
프로덕트 목표는 스크럼 팀이 목표로 삼아 계획하는 프로덕트의 미래 상태를 말한다. 프로덕트 목표는 프로덕트 백로그 안에 포함되어 있다.
프로덕트는 가치를 전달하기 위한 수단이며, 명확한 범위와 알려진 이해관계자, 잘 정의된 사용자 또는 고객을 가지고 있다. 프로덕트는 일종의 서비스나 실체가 있는 제품 또는 더 추상적인 형태의 것일 수 있다.
프로덕트 목표는 스크럼팀의 장기적인 목표이다. 스크럼 팀은 다음 목표를 맡기 전에 하나의 목표를 반드시 달성해야(또는 포기해야) 한다.
스프린트 백로그
스프린트 백로그는 스프린트 목표(왜), 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음(무엇을), 증가분을 전달하기 위한 실행할 수 있는 계획(어떻게)으로 구성되어 있다.
스프린트 백로그는 개발자들에 의한 개발자들을 위한 계획이다. 매우 가시적이며, 개발자들이 스프린트 목표를 달성하기 위해 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는 그림이다.
약속 : 스프린트 목표
스프린트 목표는 스프린트에 대한 단 하나의 목표이다. 스프린트 목표 또한 일관성을 유지하고 집중할 수 있게 하며, 스크럼 팀이 독립적으로 일하기보다는 함께 일하는 것을 장려한다. 스프린트 목표는 스프린트 계획 이벤트 동안에 정해져서 스프린트 백로그에 추가된다. 스프린트 동안 개발자들은 스프린트 목표를 계속해서 유념하며 일을 해야 한다.
증가분
증가분은 프로덕트 목표로 향하는 단단한 디딤돌 역할을 한다. 각각의 증가분은 모든 이전에 누적된 증가분에 더해진다. 가치를 제공하기 위해 증가분은 반드시 사용 가능한 것이어야 하며, 수행한 업무가 완료의 정의를 충족하지 않으면 증가분에 포함될 수 없다
약속 : 완료의 정의
완료의 정의는 증가분이 프로덕트에 요구된 품질 기준을 충족하는 상태를 정식으로 표현하는 말이다. 하나의 프로덕트 백로그 아이템이 완료의 정의를 충족하는 순간에 하나의 증가분이 탄생한다.
'스크럼 가이드'를 통해 애자일의 대표적인 프레임워크인 스크럼과 스크럼의 프로세스인 스프린트, 스크럼 팀에 대해 살펴보았다. 애자일에 대해 알아갈수록 흥미롭게 느껴진다. 짧은 주기로 민첩하게, 즉각적인 소통과 피드백을 반복적으로 거쳐 만들어진 프로덕트는 어떤 것들이 있을까.
현실적으로는 우리나라 스타트업계에서 빠른 주기의 스프린트로 스크럼을 진행하고 제품 목표를 달성하는 것은 쉽지 않을 듯하다. 현실과 이상은 다른 법이며, 각각의 조직과 구성원, 제품의 특성, 목표에 따라 스크럼을 적절히 적용할 수 있는지 여부도 차이가 날 것이라고 생각한다. (스크럼 마스터라는 직책도 사실상 우리나라에서는 존재하지 않는 것으로 알고 있다.)
그럼에도 우리나라 스타트업 중에서 애자일 방식의 잘된 사례와 스크럼 실행 케이스들을 접해보고 싶다. 애자일 프로세스에서 가장 중요한 건 아마도 커뮤니케이션 측면일 거라 생각되는데 그 부분에 좀 더 집중해 찾아봐야겠다.
참고자료
