스크럼은 어떻게 움직이는가 — 다섯 가지 이벤트

역할이 누구인지는 알겠다. 제품 백로그가 무엇인지도 이해했다. 그런데 스크럼이 실제로 어떻게 '돌아가는' 건지는 아직 막막하다.

그 리듬을 만드는 것이 스크럼의 다섯 가지 이벤트다. 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고, 그리고 이 모든 것을 담는 그릇인 스프린트. 각각은 독립된 회의가 아니라, 하나의 반복 주기를 이루는 부분들이다.

스프린트, 흔들리지 않는 최소 단위

스프린트(Sprint)는 스크럼의 심장이다. 보통 1~4주 사이의 고정된 기간 동안 팀이 하나의 목표를 향해 집중하는 주기다. 나머지 네 가지 이벤트는 모두 이 스프린트 안에서 일어난다.

왜 짧아야 하는가. 방향이 틀렸다는 걸 알기 위해서다. 6개월짜리 계획을 끝까지 실행하고 나서야 "이게 아니었네"를 알면 이미 늦다. 2주마다 확인하면 최대 2주치의 실수만 생긴다. 스프린트가 짧을수록, 잘못된 방향에서 빨리 돌아올 수 있다.

스프린트 중에는 목표가 바뀌지 않는다. 스프린트가 시작된 뒤에는 스프린트 목표를 쉽게 흔들지 않는다. 급한 요청이 생기면 보통 다음 스프린트의 백로그에 넣는다. 팀의 집중을 지키기 위한 울타리다.

스프린트가 시작될 때 팀 전체가 모여 이번 스프린트에서 무엇을 할지 결정하는 회의가 스프린트 계획(Sprint Planning) 이다.

두 가지를 결정한다. 첫째는 목표다. PO가 제품 백로그에서 우선순위가 높은 항목들을 가져오고, 팀과 함께 이번 스프린트의 목표를 정한다. 단순히 할 일 목록이 아니라, 이번 스프린트가 끝났을 때 우리가 달성했다고 말할 수 있는 것이 무엇인지를 합의하는 자리다.

둘째는 방법이다. 개발팀이 선택한 항목들을 어떻게 구현할지 구체적인 작업으로 쪼갠다. 이 결과물이 스프린트 백로그가 된다.

스프린트 계획에서 자주 실수하는 부분이 있다. 의욕적으로 너무 많이 담는 것이다. 팀의 현실적인 속도를 반영하지 않은 계획은 스프린트 말에 압박과 불완전한 결과물로 이어진다.

데일리 스크럼(Daily Scrum)은 매일 같은 시간, 같은 장소에서 15분 이내로 진행하는 짧은 동기화다. 자주 오해받는 이벤트이기도 하다.

진행 보고가 아니다. SM이나 팀장에게 어제 뭘 했는지 알리는 자리가 아니라, 팀원들이 서로 방향을 맞추는 자리다. 전통적으로 세 가지 질문을 썼다.

어제 무엇을 했는가
오늘 무엇을 할 것인가
방해가 되는 것이 있는가

최근 스크럼 가이드에서는 이 형식을 강제하지 않는다. 중요한 건 스프린트 목표를 향해 제대로 가고 있는지 확인하는 것이다. 형식보다 목적이 먼저다.

15분을 엄격하게 지키는 이유도 여기 있다. 이 자리는 문제를 해결하는 시간이 아니다. 문제가 있다는 걸 확인하는 시간이다. 더 깊이 논의가 필요하면 데일리 스크럼이 끝난 뒤 관련된 사람끼리 따로 만난다.

스프린트가 끝나면 이해관계자들과 함께 결과물을 확인하는 스프린트 리뷰(Sprint Review) 가 열린다.

개발팀이 이번 스프린트에서 만든 것을 보여주고, 이해관계자들이 피드백을 준다. 이 피드백은 제품 백로그에 반영되어 다음 스프린트의 방향에 영향을 미친다. 고객이나 비즈니스 팀과의 대화가 제품의 방향을 조정하는 핵심 장치다.

중요한 건 완성된 것 중심으로 보여준다는 점이다. "거의 다 됐는데 약간만 더" 상태인 기능은 리뷰의 중심이 될 수 없다. 이해관계자가 판단해야 할 것은 실제로 사용할 수 있는 증분이다.

스프린트 리뷰는 발표 준비를 위한 회의가 아니다. 여기에 공을 많이 들이는 팀일수록 개발 시간을 빼앗기고 있을 가능성이 높다.

스프린트 리뷰 직후에 오는 스프린트 회고(Sprint Retrospective) 는, 제품이 아닌 팀의 일하는 방식을 돌아보는 시간이다.

리뷰와 회고를 혼동하는 경우가 많다. 리뷰는 "무엇을 만들었는가"를 보고, 회고는 "어떻게 일했는가"를 본다. 이해관계자는 리뷰에 참여하지만 회고는 스크럼 팀 안에서만 진행한다. 솔직한 대화가 가능하기 위해서다.

보통 세 가지를 중심으로 이야기한다.

잘 된 것은 무엇인가
개선할 것은 무엇인가
다음 스프린트에서 실제로 바꿀 것은 무엇인가

마지막 질문이 핵심이다. 문제를 발견하고도 "다음에 보자"며 미루는 팀은 회고를 하는 것이 아니라 불만을 모으고 있는 것이다. 회고에서 나온 개선 항목은 다음 스프린트에 바로 반영되어야 한다.

많은 팀이 스프린트 말에 지쳐서 회고를 건너뛴다. 그리고 다음 스프린트에서 같은 문제를 반복한다. 회고 없는 스크럼은 속도만 높이면서 같은 실수를 반복하는 구조다.

스크럼을 도입했는데 오히려 더 힘들어졌다는 팀이 있다. 이유는 대부분 비슷하다.

데일리 스크럼이 상태 보고가 된다. 관리자가 참여하면 자연스럽게 보고 형식이 된다. 15분짜리 회의가 스트레스가 되고, 팀원들은 어제 한 일을 설명하는 데 집중한다.

스프린트 목표가 없다. 백로그 항목을 그냥 이번 스프린트에 넣으면, 스프린트는 할 일 목록이 된다. 목표가 없으면 우선순위도 없고, 스프린트가 끝나도 팀이 무엇을 이뤘는지 알기 어렵다.

스프린트 중에 요구사항이 계속 바뀐다. 이해관계자나 PO가 진행 중에 항목을 추가하거나 변경하면 팀은 집중할 수 없다. 이 문제는 대부분 다음 스프린트를 위한 백로그가 준비되지 않아서 생긴다.

회고를 건너뛴다. 가장 흔하고 가장 비싼 실수다. 회고가 사라지면 팀은 같은 문제를 반복하면서도, 그 문제가 반복되고 있다는 사실을 공식적으로 마주하지 못한다.

스크럼은 팀의 프레임워크지만, 1인 개발자나 프리랜서도 그 구조를 빌려올 수 있다.

1~2주 단위의 스프린트를 정하고, 그 안에서 할 일을 골라 집중한다. 매일 어제 한 것과 오늘 할 것을 짧게 정리한다. 스프린트가 끝나면 무엇을 완성했는지 확인하고, 다음에는 무엇을 다르게 할지 가볍게 돌아본다.

완전한 스크럼을 혼자 돌릴 수는 없다. PO도 SM도 혼자인 상황에서 역할은 뒤섞인다. 하지만 짧은 주기로 작은 목표를 완성하고, 돌아보고, 조정하는 리듬은 혼자서도 만들 수 있다. 그리고 그것이 스크럼에서 가장 본질적인 부분이다.

스프린트가 반복되면서 팀에게는 리듬이 생긴다.

처음 몇 번의 스프린트는 어색하다. 데일리 스크럼이 어색하고, 회고에서 할 말을 찾기 어렵고, 스프린트 계획이 계획대로 되지 않는다. 그래도 반복한다. 잘못된 부분이 보이면 다음 회고에서 고친다.

스크럼은 완벽한 프로세스가 아니다. 팀이 반복 속에서 자신들에게 맞는 방식을 찾아가는 도구다. 이 리듬이 자리 잡히면, 변화가 와도 팀은 흔들리지 않고 다음 스프린트를 향해 나아갈 수 있다.

결국 스크럼이 만드는 것은 회의가 아니라, 계속 배우는 팀의 리듬이다.