스크럼 이벤트 (scrum guide 2020으로 부터)

 

아래는 켄슈워버 Ken Schwaber, 제프서덜랜드 Jeff Sutherland가 작성한 스크럼 가이드의 2020년 버전의 일부를 옮겨놓은 것입니다. 가이드를 작성하고 번역한 모든 분에게 감사의 말씀을 드립니다.

 

아래의 글로 나누어 옮겨둡니다.

• 스크럼의 정의과 가치
• 스크럼팀과 역할자들
• 스크럼 이벤트
• 스크럼 산출물
• 마침글

---

스크럼 이벤트

 

스프린트는 다른 모든 이벤트들을 담는 컨테이너라 할 수 있다. 각 스크럼이벤트는 스크럼 산출물을 점검하고 적응하는 공식적인 활동이고, 필요한 투명성을 확보할 수 있도록 특별하게 설계되었다. 규정된 이벤트들을 진행하지 못하는 경우에는 점검과 적응의 기회를 잃게 된다. 스크럼 이벤트들은 주기적이고 반복적인 활동이기 때문에 또 다른 미팅을 할 필요성을 줄여준다.

 

복잡성을 최대한 줄이기 위해 모든 이벤트는 같은 시각 같은 장소에서 한다.

 

스프린트 (Sprint)

 

스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다.

 

스프린트는 꾸준함을 갖기 위해 한달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트이다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.

 

스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다.

 

스프린트 기간 동안에는:

• 스프린트 목표 달성을 저해하는 변경을 해서는 안된다;
• 품질을 떨어뜨려서는 안된다;
• 필요한 수준까지 프로덕트 백로그를 정제해야 한다;
• 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.

 

스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다. 각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.

 

진척을 예측하는 데에는 번 다운 Burn-downs 차트, 번 업 Burn-ups 차트, 누적 흐름도 Cumulative flows 와 같은 다양한 방식이 있다. 이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는 못한다. 복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다. 단지 지금까지 무엇이 발생했는지를 토대로 앞으로의 결정을 내릴 수 있다.

 

스프린트목표가 효력이없게 되면, 스프린트를취소할 수있다. 오직프로덕트 오너만이스프린트를 취소할 결정권을 갖는다.

 

스프린트 계획 (Sprint Planning)

 

스프린트 계획을 통해서 해당 스프린트 동안 수행할 업무를 선정한다. 스크럼 팀 전체가 참여하여 계획을 한다.

 

프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요한 아이템들, 그리고 그것들이 프로덕트 목표와 어떻게 연결되는지를 참여자들이 논의할 수 있도록 준비해야 한다. 스크럼 팀에 조언을 해줄 수 있는 다른 사람을 스프린트 계획에 초청할 수도 있다.

스프린트 계획은 다음과 같은 주제를 다룬다:

 

✓주제 1: 이 스프린트가 왜 가치가 있는가?

 

프로덕트 오너가 이번 스프린트에서 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지를 제안한다. 전체 스크럼 팀원들이 협력해서 스프린트 목표를 정의한다. 스프린트 목표를 정의할 때에는 이 스프린트가 이해관계자들에게 중요한 이유를 담아야 한다. 스프린트 목표는 반드시 스프린트 계획을 마치기 전에 결정되어야 한다.

 

✓주제 2: 이 스프린트의 완료 Done 는 무엇인가?

 

프로덕트 오너와 논의를 하면서 개발자들이 이번 스프린트에 포함할 프로덕트 백로그 아이템을 선정한다. 스크럼 팀은 이 과정 중에 프로덕트 백로그 아이템을 정제할 수 있다. 이를 통해 내용을 더 정확히 이해하고, 할 일에 대한 확신을 가질 수 있다.

 

한 스프린트 내에 얼마나 완료할 수 있을지를 정한다는 것은 쉬운 일은 아니다. 그렇지만, 개발자들이 그들의 지난 성과와 다음 번에 수용 가능한 업무량, 완료의 정의 Definition of Done 에 대해 많이 알면 알수록 그들이 스프린트를 예측할 때에 더 확신을 가질 수 있을 것이다.

 

✓주제 3: 선정한 일을 어떻게 완료할 것인가?

 

개발자들은 선정한 모든 프로덕트 백로그 아이템들을 가지고, 완료의 정의를 충족하는 증가분을 만드는 데에 필요한 업무들을 계획한다. 대체적으로 이것은 프로덕트 백로그 아이템을 하루 안에 13 완료할 수 있는 크기로 더 작게 세분화하는 것으로 이루어진다. 중요한 것은 이 과정은 절대적으로 개발자들의 재량이다. 다른 누구도 개발자들에게 프로덕트 백로그 아이템을 어떻게 증가분으로 만들지에 대해 정해주어서는 안된다.

 

스프린트 목표, 스프린트를 위해 선정한 프로덕트 백로그 아이템들, 그리고 이것을 완료하는 것에 대한 계획을 모두 포함하여 스프린트 백로그라고 한다.

 

스프린트 계획은 최대 시간이 정해진 Timeboxed 이벤트로 일 개월 기간의 스프린트인 경우 8 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우 보통 스프린트 계획 시간도 더 짧다.

 

데일리 스크럼 (Daily Scrum)

 

데일리 스크럼의 목적은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것이다.

 

데일리 스크럼은 스크럼 팀의 개발자들만 참여하는 15 분 길이의 이벤트이다. 복잡성을 줄이기 위해 같은 시각에 같은 장소에서 스프린트 기간의 모든 근무일 마다 수행한다. 만약 프로덕트 오너나 스크럼 마스터도 스프린트 백로그 아이템을 맡아 활동적으로 업무를 하고 있다면 개발자들의 일원으로 데일리 스크럼에 참여할 수 있다.

 

개발자들이 실행하는 데일리 스크럼이 스프린트 목표 대비 진척과 다음 근무일에 실행할 수 있는 계획을 만드는 것에 초점을 두는 한, 개발자들은 어떤 방식이나 기법으로도 데일리 스크럼을 진행할 수 있다. 이로써 일에 집중하고 자율관리 팀으로서의 능력을 향상시킨다.

 

데일리 스크럼은 팀의 소통을 향상시키고 팀이 가지고 있는 장애물을 식별하며 신속한 의사 결정을 촉진하여 별도로 다른 미팅을 할 필요성을 줄여준다.

 

개발자들이 계획 변경에대한 논의를반드시 데일리 스크럼에서만 해야 하는 것은 아니다. 아무 때나 자주 만나서 더 상세하게 남은 스프린트의 업무를 조정하거나 다시 계획하는 논의를 진행하면 된다.

 

스프린트 리뷰 (Sprint Review)

 

스프린트 리뷰의 목적은 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것이다. 스크럼 팀은 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트 목표 대비 진척을 보여준다.

 

스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토한다. 이 정보에 기초하여 참여자들은 다음으로 무엇을 할 것인지 협력하여 논의한다. 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다. 스프린트 리뷰는 이와 같은 활동을 하는 시간이므로 발표만 하고 끝나지 않도록 해야 한다.

 

스프린트 리뷰는 스프린트의 끝에서 두 번 째로 하는 이벤트이다. 최대 시간이 정해진 이벤트로 일 개월 기간의 스프린트인 경우 4 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우, 보통 스프린트 리뷰 시간도 더 짧다.

 

스프린트 회고 (Sprint Retrospective)

 

스프린트 회고의 목적은 품질과 효율을 높이기 위한 방법들을 계획하는 것이다.

 

스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게진행되었는지를 점검한다. 업무 영역 별로 점검하는사항들은 차이가 날 수 있다. 팀이 잘못된 방향으로 가게 된 가정들을 확인하고, 그것들의 근본 원인을 찾아낸다. 스크럼 팀은 무엇이 잘 진행되었는지에 대해서도 논의한다. 어떤 문제를 만났고 그 문제를 어떻게 풀었는지(또는 풀지 못했는지)에 대해 의견을 나눈다.

 

스크럼 팀은 그들의 효율을 향상시키기 위해 가장 도움이 되는 변화를 찾아야 한다. 가장 영향이 큰 개선책을 최우선으로 고려해야 한다. 이런 개선책을 다음 스프린트에 수행하도록 스프린트 백로그에 추가할 수도 있다.

 

스프린트 회고를 마지막으로 스프린트가 종료된다. 최대 시간이 정해진 이벤트로 일 개월 기간의 스프린트인 경우 3 시간이 넘지 않도록 한다. 스프린트 기간이 더 짧은 경우, 보통 스프린트 회고 시간도 더 짧다.