프로덕트에 집중하는 팀. 스크럼 가이드 요약
스크럼 프레임워크
본 글은 Ken Schwaber와 Jeff Sutherland의 Scrum Guide 를 요약하여 작성했습니다. 잘못된 부분이 있으면 댓글 남겨주세요.
목차
스크럼 정의와 가치
스크럼 팀
스크럼 이벤트
프로덕트 백로그
들어가기 전에,
스크럼은 켄 슈와버 & 제프 서덜랜드에 의해 1990년대 초반에 개발했다. 2010년에 스크럼 가이드의 첫 번째 버전을 배포했고 지속적으로 업데이트해왔다고 한다. 이 기간 동안 다수의 소프트웨어 개발 회사에서 스크럼을 채택했고 이후에는 복잡한 문제를 해결하고 생산성을 높이기 위해 금융, 의료 등의 타 분야까지 활용하고 있다고 한다.
스크럼 정의와 가치
사람과 팀, 조직이 복잡한 문제에 적합한 해결책을 활용하여 가치를 창출할 수 있도록 도와주는 프레임워크다. 스크럼 프레임워크를 활용하기 위한 환경은 아래와 같다.
PO는 문제 해결을 위한 백로그를 우선순위에 따라 정렬한다.
스프린트 동안 발생하는 백로그를 추가한다.
프로덕트 팀은 이해관계자들과 결과를 회고하고 다음 스프린트를 준비한다.
반복
스크럼 프레임워크는 업무를 수행하는 큰 틀에서 정의를 내릴 수 있고 상세한 부분은 조직별로 적합한 방법을 도입하여 진행해야 한다. 회고는 다음 스프린트에서 개선할 내용을 적용시켜 지속적으로 스크럼을 개선해나가야 한다. 이를 실천하기 위해 아래와 같은 사항을 지켜져야 한다.
투명성
스크럼은 경험과 관찰을 통해 의사 결정을 하고, 낭비를 줄여 본질에 초점을 맞추는 데에 집중한다. 모든 업무는 가시적이어야 하고 투명성이 낮은 경우 의사결정의 가치는 떨어지고 시간을 낭비하여 리스크가 높아진다.
점검
스크럼의 목표와 산출물에 대해 자주 점검해야 한다. 점검을 진행하는 목적은 개선 사항을 찾아 적용하기 위함이다. 개선을 하지 않으면 스크럼을 점검하는 것은 무의미하다.
개선
프로세스 안에서 수용 가능한 범위를 벗어나거나 받아들일 수 있는 수준이 아닌 경우, 점검을 통해 도출한 개선사항을 가능한 한 빨리 적용해야 한다.
마지막으로, 스크럼 팀은 도전에 열린 마음을 가져야 하고 각각의 팀원은 개인의 능력을 갖춘 독립적인 존재임을 서로 간 존중을 필요로 한다.
스크럼 팀
단 하나의 프로덕트 목표에 집중하는 전문가들의 모임인 스크럼 팀은 적은 수의 인원인 PO, 개발자, 디자이너 등으로 구성된다. 하위 조직이 없고 수직 구조로 이뤄져있지 않다. 따라서 각 구성원들은 매 스프린트마다 가치를 만들어낼 기술이 있고 자율적으로 누가, 무엇을, 언제, 어떻게 할 것인지 결정한다.
적은 수의 인원이지만 스프린트 동안 가치를 창출해낼 수 있을 만큼의 충분한 규모를 가져야 한다. 일반적으로 10명 혹은 이보다 적다. 대부분 작은 구성원으로 이뤄져 있는 팀이 소통을 더 잘하고 생산적이다. 규모가 너무 커지게 될 경우 다수의 팀으로 재구성할 것을 권하고 동일한 프로덕트의 목표로 하여 백로그를 공유해야 한다.
PO는 프로덕트의 가치를 극대화하고 백로그를 효과적으로 관리하는 데 책임이 있다.
프로덕트의 명쾌한 목표를 세우고 소통하는 것
프로덕트 백로그를 생성하고 투명하게 소통하는 것
프로덕트 백로그를 우선순위에 따라 정렬하는 것
프로덕트 백로그를 가시적이고 이해가 잘 되도록 만드는 것
최종 책임은 PO가 갖고, 성공적으로 일을 하기 위해서 조직 전체가 그의 결정을 존중해야 한다. PO가 내린 결정은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인할 수 있다. 또한, 팀의 스크럼을 효율적으로 만들어야 할 책임이 있다. 이를 실천하기 위해 아래와 같은 사항을 준수해야 한다.
스프린트 진행 간 생기는 새로운 백로그를 만드는 데 집중할 수 있도록 돕는 것
프로세스에 방해가 되는 장애물을 제거하는 것
긍정적이고 생산적으로, 그리고 정해진 시간 안에 완료하는 것
요구 혹은 필요에 의해 이해관계자와 협업을 촉진하는 것
이해관계자와 팀의 장벽을 제거하는 것
스크럼 이벤트
스프린트 플래닝, 데일리 스크럼
스프린트 리뷰, 스프린트 회고
스프린트는 꾸준하게 진행하기 위해 한 달 혹은 주 단위의 기간으로 고정돼서 진행한다. 하나의 스프린트가 끝나는 즉시 새로운 스프린트를 시작해야 한다.
모든 스프린트 기간 동안 아래와 같은 사항을 준수해야 한다.
스프린트 목표 달성을 방해하는 변경은 하지 않는다.
스프린트의 품질을 떨어뜨려서는 안 된다.
필요한 수준까지 프로덕트 백로그를 정제해야 한다.
명확한 범위를 설정해야 하고 필요한 경우 협의해야 한다.
스프린트를 진행하는 이유는 적어도 한 달에 한 번은 프로덕트 목표 진척도를 점검하고 조정할 수 있기 때문이다. 이를 통해 향후 진척도에 대한 예측 정확도를 높일 수 있다. 스프린트의 기간은 짧을수록 더 많이 학습할 수 있고 리스크를 제한할 수 있다.
스프린트 플래닝
프로덕트 팀 전체가 스프린트 계획에 참여한다. 이 계획을 통해 스프린트 동안 수행할 업무를 선정하기 때문에 PO는 프로덕트의 목표를 달성하기 위해 논의할 내용을 준비한다. 스프린트 계획 단계에서는 아래와 같은 주제를 다루게 된다.
주제 1. 이 스프린트가 '왜' 가치가 있는가?
프로덕트의 가치와 효용성을 어떻게 높일 수 있는지 PO가 제안한다. 이후 팀원들이 협력하여 스프린트의 목표를 정의하고 이 목표는 계획 단계가 마치기 전에 결정되어야 한다.
주제 2. 이 스프린트의 '끝(Done)'은 무엇인가?
팀 구성원들과 PO가 논의하여 이번 스프린트에서 포함할 백로그를 선정한다. 팀은 이 백로그를 정제하는 과정에서 팀 모두가 이해하고 확신을 가질 수 있도록 한다. 한 스프린트 내에서 할 일의 범위를 정하는 것은 쉽지 않지만, 지난 스프린트 성과와 다음 스프린트에 수용할 수 있는 업무량에 대해 지속적으로 알아갈수록 다음 스프린트 예측 시 확신을 가져갈 수 있다.
주제 3. 선정한 백로그를 '어떻게' 완료할 것인가?
선정된 모든 백로그로 개발자들은 수행할 업무를 계획한다. 이 과정은 개발자들의 재량이다. 대체로 백로그를 하루 안에 수행할 수 있도록 세분화하며 다른 누구도 개발자들에게 정해주어서는 안 된다.
데일리 스크럼
데일리 스크럼은 보통 같은 시각, 같은 장소에서 15분 정도로 진행한다. 스프린트의 목표 대비 진척도를 점검하고 필요시 스프린트 백로그를 조정할 수 있다. 이를 통해 팀 내 커뮤니케이션에 긍정적인 영향을 주고 프로덕트 목표에 방해되는 장애물을 식별할 수 있다. 따라서, 신속하게 의사 결정을 할 수 있도록 돕고 궁극적으로 일에 집중할 수 있는 환경을 조성할 수 있다.
백로그 조정 혹은 계획 변경에 대한 논의는 무조건 데일리 스크럼에서만 해야 하는 것은 아니기 때문에 자주 만나고 논의하는 것이 중요하다.
스프린트 리뷰
스프린트의 결과를 점검하고 향후 개선 사항을 결정하는 데 목적이 있고 이해관계자들에게 결과물과 진척도를 보여줄 수도 있다.
리뷰를 진행하는 동안 팀과 이해관계자는 해당하는 스프린트를 통해 이뤄낸 성과와 비즈니스 환경의 변화를 검토한다. 이를 기반으로 다음 액션을 논의하고 새로운 기회 창출을 위해 백로그를 수정할 수도 있다.
스프린트 회고
다음 스프린트의 효율을 높이기 위한 방법을 계획하는 데 목적이 있다. 각 팀원들과 커뮤니케이션을 통해 지난 스프린트를 점검한다. 잘못된 방향으로 가게 된 경우 원인을 찾아내고 잘 진행되었는지에 대해 논의도 필요하다. 문제를 직면했던 상황을 설명하고 어떻게 풀어냈는지에 대해 의견을 나눌 수도 있다.
회고를 통해 가장 효율을 극대화할 수 있는 변화를 찾아야 하고 가장 임팩트가 큰 개선책을 최우선으로 고려해야 한다. 회고를 끝으로 스프린트가 종료된다.
프로덕트 백로그
프로덕트 백로그는 개발 기간 동안 실행해야 할 업무를 우선순위에 따라 정렬한 목록이다. 스프린트 계획에서 선택할 수 있도록 준비하고 팀이 스프린트 내 완수할 수 있어야 한다. 항상 투명성을 확보해야 하고 정제하는 과정에서 구체적으로 정의해야 한다.
참고자료
