스프린트 리뷰는 어떻게 준비해야 하는가?

이 글은 아래 Mike Cohn의 블로그 글을 번역한 것입니다.

An Agenda for the Sprint Review

스프린트 리뷰 중에 메인 활동은 스프린트 기간 동안 구현된 기능을 데모하는 것이다. 그러나 잘 진행된 스프린트 리뷰는 데모 이외 더 많은 안건들이 포함되어있다. 스프린트 리뷰 시 진행하는 안건을 살펴보자.

 

참석자를 환영하고, 스프린트 리뷰를 위한 분위기를 조성하자

스프린트 리뷰는 제품 소유자(Product Owner)가 참석자를 환영하면서 시작한다. “스프린트 리뷰에 참석해주셔서 감사합니다.”처럼 간단한 인사 정도면 된다.

 

참석자들이 서로 잘 모른다면, 제품 소유자가 소개하는 시간을 별도로 마련해줘도 좋다.  제품 소유자는 마케팅 팀의 Joe가 마케팅 팀 소속이라는 것을 알지만, 팀 구성원은 그렇지 않을 수 있다.

 

종종 새로운 참석자가 스프린트 리뷰에 참석한다면 소개하는 시간이 도움이 될 것이다. 아마도, 마케팅팀의 Joe는 마케팅 기능과 관련된 스프린트 리뷰에만 참석할 것이다. 

 

소개는 매우 짧게 진행되어야 한다. “안녕하세요, 저는 마이크이고 개발자입니다. 장바구니 기능 개발을 담당하고 있습니다.” 정도면 충분하다. 더 짧게 “저는 마이크이고 개발자입니다.”라고 해도 좋다. 그러나, 팀 규모가 커지면 이해 관계자가 어떤 사람이 무엇을 맡고 있는지 알 수 있도록 몇 마디의 말을 덧붙이는 것이 도움이 될 수 있다.

 

환영 인사 및 서로 소개를 한 후에, 제품 소유자는 스프린트 리뷰의 그라운드룰이나 기대하는 바를 설명할 수 있다. 예를 들어, 몇몇 제품 소유자는 서로 존중하며 회의가 진행되면 좋겠다는 말을 해야겠다고 생각한다. 누군가가 기능을 구현한 방식을 선호하지 않는다면, “선호하는 방식이 아냐”라고 말하는 것은 괜찮다. 그러나 “바보 같은 방식이야”라고 하지는 말자. 그렇다, 우리는 이미 이런 것을 알고 있지만, 때로는 사람들에게 리마인드 할 필요가 있다.

 

참석자의 수와 많은 다른 요인에 따라, 참석자들이 개발한 것에 대한 피드백을 생각하는 동안 제품 소유자는 스프린트 리뷰가 기능을 재설계하는 시간은 아니라고 언급할 수 있다.

 

환영 인사, 참석자 소개에 이어서 그라운드룰을 공유하면, 다음 안건으로 넘어갈 시점이다.

 

데모할 것과 하지 않을 것을 설명하자

이 시점에서 많은 팀이 바로 뛰어들어 데모를 시작한다. 그 대신 제품 소유자가 무엇을 시연할 것이고, 시연하지 않을지에 대해 간단한 설명을 진행하는 것을 추천한다.

 

제품 소유자가 아이템 목록을 그냥 읽기만 하면 참석자들이 이해하기 어려우니, 모니터나 프로젝터를 통해 관련 내용을 띄우자. 또는 출력물을 원하는 사람들 위해 출력도 해두자.

 

나는 이것을 워드 문서로 준비하고 리뷰 전날까지 리뷰 참석이 가능한 사람들에게 이메일로 보내는 것을 선호한다. 이를 통해 사람들은 무슨 데모가 진행될지를 알 수 있다. 각 사람은 그때 데모가 진행될 것을 참고하여 스스로 참석여부를 결정할 수 있다.

 

다음 표는 각 제품 백로그 항목에 포함하고자 하는 정보를 보여준다. 미팅 중에 필요에 따라 변경할 수 있지만, 데모하는 순서대로 작성하는 것을 추천한다.

항목에 대한 설명이 먼저 들어간다. 이 곳에 사용자 스토리 또는 다른 설명을 작성한다. 다음으로 항목의 크기를 작성하자. 일반적으로 스토리 포인트를 작성한다. 그다음은 항목의 진행상태를 적성한다. 주로 항목이 완료되었는지 여부를 작성하지만 남길만한 중요한 정보도 함께 남긴다. 마지막으로 항목을 데모를 진행할지 여부를 나타내는 열을 포함하자.

 

여러분은 팀이 데모하지 않을 항목이 포함되어 있는 것에 대해 의아하게 생각할 것이다. 위의 예시 표에 몇 가지 예제가 있다. 분명히, 스프린트에 진행하는 것으로 계획했지만, 중간에 중단한 항목은 시연할 수 없다. 한 화면에서 하나의 문자를 업데이트하는 아주 간단한 버그를 수정 것도 있는데 이것도 또한 시연으로 잡혀 있지 않다.

 

몇 명의 참가자가 데모 목록에 없는 것을 보고 싶어 할 수 있다. 그런 일이 발생하면 다른 모든 항목과 함께 항목을 데모하라. 여러분은 뭔가 보여주는 것을 피하려 하지 않고, 정말로 피드백을 필요로 하지 않는 것들을 보여주지 않음으로써 사람들의 시간을 존중하려고 노력하는 것이다.

 

위의 샘플에서, 스프린트 중에 하나의 제품 백로그 항목이 추가되었음을 알았다. 스프린트에 계획된 것들과 구분하기 위해 스프린트 중에 추가된 항목을 표시하는 것은 좋은 아이디어라고 생각한다. 항목을 자주 추가하는 경우 초기 열을 추가하고 P (계획됨) 또는 A (추가됨)를 입력하는 것을 생각해보자.

 

각 항목이 리뷰 참석자에 의해 받아들여졌는지, 또는 릴리즈 준비가 됐는지를 나타내는 데 사용할 수 있도록 맨 오른쪽에 하나의 열을 고려하고 싶을 수도 있다. 이러한 유형의 결정이 스프린트 리뷰 중에 일어난다면 위와 같은 것을 고려하자.

 

항목들을 소개하는 부분에 너무 많은 시간을 소비하지 말자. 목표는 이 항목에 대한 피드백을 얻거나, 계획된 항목이 부분적으로만 구현된 이유에 대해서 얘기하려는 게 아니다. 이것은 미팅의 나머지 시간을 위한 목차 일뿐이다. 제품 소유자 가이 목록을 발표한 후, 스프린트 리뷰의 메인 순서로 이동하자. 즉, 데모를 진행하는 것이다.

 

새로운 기능을 데모하자

이것이 스프린트 리뷰의 핵심이다. 그리고 이미 스프린트 리뷰를 하고 있다면, 이것이 여러분이 하고 있는 유일한 부분일 가능성이 높다.

 

리뷰 동안에, 미팅 참석자에게 보여줬던 항목을 차례대로 진행하자. 스프린트 리뷰의 목적은 피드백을 얻는 것임을 명심하자.

 

누가 데모해야 하는지에 대한 엄격한 룰은 없다. 어떤 경우에는 제품 소유자가 진행한다. 특히 어려운 이해 관계자를 대상으로 리뷰할 때 제품 소유자가 진행하는 것을 권장한다. 하지만 다른 경우에는 팀 구성원이 직접 작업한 특정 제품 백로그 항목을 데모할 것이다. 어떤 방법도 좋다. 팀을 위해 가장 잘 맞는 것을 찾도록 실험해보자.

 

주요 이벤트를 토론하자

완료된 제품 백로그 항목에 대해 모두 데모를 진행한 후에 스프린트 중에 발생한 주요 이벤트 또는 문제에 대해 논의하자.

 

이 토론은 제품 소유자 또는 스크럼 마스터가 수행할 수 있다. 나는 두 방법 모두 똑같이 잘 동작한다는 것을 발견했다. 그러나 나는 스크럼 마스터가 이 안건을 진행하는 게 좋겠다는 생각 한다.

 

지금까지 스프린트 리뷰 대부분 순서에서 제품 소유자는 스크럼 마스터보다 더 많은 이야기를 했다. 스크럼 마스터가 이 안건을 수행할 수 있도록 하는 것이 좋은 균형임을 발견했다. 또한, 이것은 엄격하게 제품보다 프로세스에 대한 논의가 더 많으므로 스크럼 마스터의 영역에서 좀 더 자세히 다루어질 수 있다.

 

다음 스프린트에 예정된 제품 백로그 항목을 소개하자

스프린트 리뷰 안건의 마지막은 제품 백로그 중에서 다음 할 일에 대한 토론을 진행한다. 스프린트 리뷰의 목적은 현재 스프린트의 작업에 대한 피드백을 얻기 위한 것이므로 다음 스프린트에서 수행할 작업에 종종 영향을 미친다.

 

예를 들어 검토 참여자가 새 화면의 모습을 선호하면, 제품 소유자는 제품의 다른 부분을 새 디자인으로 변경하는 작업을 앞 당길 수 있다. 반면에, 참석자들이 기능 구현 방법을 선호하지 않았다면, 아마도 다음 스프린트에 신규 아이템을 시작하는 대신에 참석자가 선호하지 않았던 그 이슈를 수정해야 할 것이다.

 

제품 소유자는 제품 백로그에서 다음 스프린트에서 진행할 후보 아이템들을 제시함으로써 이 토론을 시작합니다. 제품 소유자는 다음과 같이 말할 수 있습니다. “화면에서 다음에 진행할 10 가지 아이템을 보실 수 있는데, 오늘 얘기된 것들을 추가하고 싶습니다. 3번 아이템으로 추가하겠습니다.”

 

그런 다음 제품 소유자는 해당 아이템에 대한 참석자의 의견을 요청한다. 그러나 제품 소유자가 이러한 의견을 토대로 스프린트 리뷰 중에 우선순위를 결정하는 것을 권장하지는 않는다. 그 이유로는 여러 개가 있다. 제품 소유자는 리뷰에서 나온 내용에 대해 생각할 시간이 필요할 수 있다. 또는 리뷰 미팅에서 요청된 변경 사항에 대해 제품 소유자는 팀에게 소요되는 추정 시간을 확인해달라고 할 수 있다. 등등. 이러한 이유로 우선순위를 결정하는 대신, 제품 소유자는 스프린트 리뷰 중에 의견을 요청한 다음, 리뷰 미팅 후에 결정한다.

 

회의를 마치자

모든 사람들에게 참여에 대한 감사 인사와 함께 마무리하자. 스프린트의 작업을 진행한 팀에 감사를 표하는 것을 고려하자. 가끔은 스프린트 중에 우수하게 업무를 수행한 팀 멤버 한 두 명을 칭찬하는 것을 고려하자. 모든 사람에게 다음 리뷰가 언제 어디서 진행되는지 알리자.

 

스프린트 리뷰 후

실제 리뷰의 안건은 아니지만, 누군가 팀에서 사용하고 있는 시스템에 새로운 제품 백로그를 입력해야 한다. (포스트잇 등 물리적 카드를 사용한다면 벽에 게시하자)

 

여러분은 어떻게 리뷰를 진행하시나요?

스프린트 리뷰를 어떻게 하는지 알려주세요. 위에서 언급되지 않은 다른 것이 있나요? 이 단계 중 일부를 건너뛸 수 있습니까? 여러분의 생각을 공유해주세요.