Sprint review: A step-by-step guide

스프린트 검토 미팅은 애자일 개발의 기본적인 세레모니로 특히 스크럼 프레임워크 내에서 이루어집니다. 보통 2~4주로 정해진 기간으로 진행하는 스프린트가 종료되었음을 의미하며 이 기간 동안 개발 팀은 제품 기능을 잠재적으로 제공 가능한 증분으로 제공합니다.

스프린트 검토에서는 개발 팀과 이해 관계자가 모여 스프린트 동안 완료한 작업을 검토하고 시연합니다. 개발한 기능을 선보이고 피드백을 수집하고 제품 비전 및 요구 사항에 정렬하는지 확인할 수 있는 기회를 제공합니다.

스프린트 검토의 주요 목표는 피드백을 수집하고 개발 프로세스의 다음 단계에서 투명성을 유지하는 것입니다. 다음과 같은 몇 가지 주요 목표가 있습니다.

완료한 작업 시연: 개발 팀이 제품 소유자, 고객 및 기타 관련 당사자를 포함한 주요 이해 관계자에게 스프린트 동안 완료한 기능을 시연합니다.

피드백 수집: 시연한 기능에 대해 이해 관계자가 피드백을 제공하여 팀이 후속 스프린트에서 작업을 효과적으로 조정하고 우선 순위를 지정할 수 있도록 합니다.

제품 비전과의 정렬: 스프린트 검토를 통해 완료한 작업이 전체 제품 비전 및 목표와 정렬되어 있는지 확인할 수 있습니다. 개발 노력과 스프린트 목표가 올바른 방향으로 나아가고 있는지 확인하는 데 도움이 됩니다.

성과 축하: 개발 팀에서 거둔 성과를 축하하고 노고와 헌신을 확인하는 기회를 가집니다.

개선 사항 파악: 스프린트 검토 중 논의와 관찰을 통해 개발 프로세스에서 개선해야 할 부분을 파악하고 향후 반복에서 해결할 수 있습니다.

간단히 말해서 스프린트 검토는 애자일 개발 프레임워크 내에서 공동 작업, 투명성 및 지속적 개선을 강화합니다. 열린 커뮤니케이션, 공동 작업 세션 및 제품 성공에 대한 공동 책임 문화를 조성할 수 있습니다.

스프린트 검토가 회고가 아니라면 정확히 무엇입니까? 스프린트 검토는 디자이너, 개발자 및 제품 소유자와 같은 스크럼 팀 전체의 노력을 보여줍니다. Atlassian에서는 스프린트 검토를 캐주얼한 방식으로 유지하는 것을 좋아합니다.

팀원은 비공식 데모를 위해 책상에 모여서 해당 반복에 대한 작업을 설명합니다. 질문하고 새로운 기능을 사용해 보고 피드백을 주는 시간입니다. 성공을 공유하는 것은 애자일 팀을 만드는 데 중요한 부분입니다.

팀이 생각하는 '완료의 정의'가 애자일 세레모니에 중요한 이유를 살펴보겠습니다.

Jira의 일반 사용자로서 작업을 '코드 검토'에서 '완료'로 옮기는 것보다 더 만족스러운 일은 없습니다. 이러한 전환은 하나의 팀으로서 달성하기 위해 시작한 작업이 완료되었다는 뜻입니다. 최종적으로 완료된 것입니다!

목표를 달성하고 작업을 완료하려면 올바른 계획, '완료에 대한 명확한 정의' 및 집중력 있는 실행 과정이 필요합니다. 대부분은 스프린트 계획 중에 이루어지지만 스프린트 검토와 스프린트를 성공적으로 해내려면 팀이 계획보다 조금 더 많은 작업을 수행해야 합니다. 작업 제공 및 '완료'의 의미에 대한 명확한 문화를 조성해야 합니다.

효과적인 팀은 각 프로젝트 및 모든 작업 항목에 명확한 프로세스와 개발 문화를 제공합니다. 다음 질문을 사용하여 프로세스를 평가하고 최적으로 진행되고 있는지 확인하세요.

• 구현 전에 제품 소유자, 디자이너 및 엔지니어링 팀이 스토리를 잘 정의했습니까?

• 모두가 팀의 엔지니어링 가치 및 문화를 이해하고 있습니까?

• 지속 가능한 애자일 개발을 장려하기 위해 코드 검토, 자동화된 테스트 및 지속적 통합과 관련된 명확한 정의 및 요구 사항이 마련되어 있습니까?

• 팀이 스토리를 완료한 후 버그가 드러납니까? 즉, '완료'라고 하면 최종적으로 '완료'된 것입니까?

품질 및 완성도에 대한 팀의 문화는 모든 사용자 스토리, 엔지니어링 작업 항목 및 버그보다 우선되어야 합니다. 이 문화에는 팀이 소프트웨어에 접근하고 제공하는 방식이 반영되어 있습니다.

'완료'를 명확하게 정의하면 팀이 각 작업 항목의 최종 목표에 집중할 수 있습니다. 제품 소유자가 팀의 백로그에 작업을 추가하는 경우 이 프로세스의 핵심 부분은 허용 기준을 정의하는 것입니다. 사용자 스토리가 완료된다는 것은 어떤 뜻입니까?

Atlassian에서 Jira 팀은 Jira 내부의 나머지 사용자 스토리에 맞춰 허용 기준과 테스트 노트를 추적합니다. 이렇게 하면 팀 전체가 모든 이슈에 대한 성공을 명확하게 파악할 수 있습니다. 허용 기준과 테스트 노트란 무엇입니까?

• 허용 기준: 스토리를 만족스럽게 구현했는지 확인하기 위해 제품 소유자가 사용하는 메트릭입니다.

• 테스트 노트: 개발 엔지니어가 더 나은 기능 코드와 자동화된 테스트를 작성할 수 있도록 하는 품질 지원 팀의 짧고 집중적인 안내입니다.

구현 중에 이슈를 잘 정의하면 모두가 성공할 수 있습니다. Jira를 사용하면 일렬로 필드를 쉽게 추가할 수 있습니다. 관리자는 이슈의 관리자 버튼을 클릭합니다.

Atlassian의 핵심 가치 중 하나는 “하나의 팀으로 플레이”하는 것입니다. 스프린트 검토는 반복 중에 팀과 모두의 성과를 축하하기에 좋은 시간입니다. Atlassian에서는 일반적으로 금요일 오후에 스프린트 검토를 열어 사무실의 모든 직원이 주말 전에 긴장을 푸는 시간을 갖습니다.

스프린트 검토는 회고와 같은 것이 아니므로 반복 후 회고 전에 스프린트 검토를 진행해야 합니다. 외부 참가자는 언제든지 참여할 수 있지만 회의에는 일반적으로 제품 소유자, 전체 개발 팀 및 스크럼 마스터가 참여합니다. 모범 사례로써 회의에서 각 반복은 30분에서 1시간 정도 진행하는 것이 좋습니다.

스프린트 검토는 팀의 상태와 사기를 보호하기 때문에 Atlassian에서는 스프린트 검토를 매우 좋아합니다. 스프린트 검토에서 팀 구축은 매우 중요합니다. 검토는 적대적인 것이 아니며 시험도 아닙니다. 작업의 데모를 보여주고, 질문에 답변하며 피드백을 받는 팀 전체의 협업 이벤트입니다.

Atlassian의 최신 작업 코치인 Mark Cruth는 “스프린트 검토 중에 다양한 팀원이 기능을 시연하도록 하여 팀의 책임 의식을 장려하세요.”라고 제안합니다. “기능 리더를 사용하면 이들이 노력을 주도하면서 열심히 했다는 것을 보여주는 데 좋습니다.”

스프린트 검토가 팀 전체에서 긍정적인 활동이 되지 않는다면 다음 상황을 나타내는 것일 수 있습니다.

• 팀이 너무 많은 작업을 맡아서 반복 과정에서 완료하지 못함
  
  “스프린트 검토는 팀이 작업을 의미 있는 작은 산출물로 나누도록 장려하는 좋은 방법입니다.”라고 Cruth는 덧붙입니다. “완료하지 않은 작업은 검토하지 마세요. 애자일 매니페스토에 나와 있듯이 목표는 소프트웨어가 작동하도록 하는 것입니다.”
  

• 팀이 기존 기술 부채로 인해 어려움을 겪고 있음

• 새로운 버그가 코드베이스에 유입되지 않도록 하는 기능이 지속 가능한 방식으로 개발되지 않음

• 팀의 개발 관행이 최대한으로 조정되지 않음

• 제품 소유자가 반복 내에서 우선 순위를 변경하고 있으며 개발 팀은 범위 크리프로 인해 배제됨

참고: 모든 팀은 가끔 어려운 반복을 겪습니다. 시간을 내서 팀의 회고에서 반복이 변경되는 이유를 이해하고 향후의 이슈를 해결하기 위한 계획을 세우세요.

팀이 분산되어 있는 회사는 여러 지역에 걸쳐 애자일 세레모니를 확장하는 것과 관련하여 특별한 어려움을 안고 있습니다. 스프린트 검토도 예외는 아닙니다.

예를 들어 Jira 팀은 시드니부터 그단스크, 샌프란시스코까지 전 세계에 팀원을 두고 있습니다. 팀이 분산되어 있지만 스프린트 검토는 팀 문화에서 중요한 부분을 차지합니다. 팀원들은 비공식 동영상을 만들어 팀 전체가 볼 수 있도록 Confluence 페이지에서 공유합니다.

“Loom과 같은 도구를 사용하여 검토를 기록하고 전 세계의 다른 팀원으로부터 피드백을 수집하세요.”라고 Cruth는 설명합니다. “우리는 비동기식 세상에서 일하고 있으므로 비동기식 공동 작업의 관점에서 스프린트 검토에 접근하세요.”

이러한 비공식 동영상을 통해 시차에도 불구하고 모두가 개발 프로젝트 진행률에 대한 최신 정보를 얻을 수 있습니다. 개발자가 직접 기능 데모를 보면 다음과 같은 두 가지 방식으로 팀이 강화됩니다.

• 제품 이해: 팀 전체가 기능의 의도, 근거 및 구현에 대해 설명을 받게 되어 제품 전체에 대한 모두의 이해가 넓어집니다.

• 팀 구축: 동영상은 팀 전반에서 더 개인적인 관계를 형성해 줍니다. 제품의 모든 측면을 누가 만들었는지 알 수 있습니다. 이 관행으로 만들어진 연결 고리는 지역에 관계없이 팀을 더 긴밀하고 응집력 있게 만들어 줍니다.

스프린트 검토를 애자일 개발 프로세스에 통합하여 얻을 수 있는 중요한 이점 중 하나는 제품에 대한 조정 가능성 및 유연성 향상입니다. 완료한 작업을 정기적으로 검토하면 팀은 이해 관계자의 변화하는 요구 사항 및 선호 사항에 대한 중요한 인사이트를 얻습니다.

스프린트 검토는 개발 팀 및 이해 관계자 사이에 반복적인 피드백 루프를 형성합니다. 이 반복적인 특성 덕분에 실시간 피드백을 기반으로 제품을 신속하게 조정 및 개선하여 변화하는 시장 수요 및 사용자 요구 사항에 제품이 정렬된 상태를 유지할 수 있습니다.

스프린트 검토 중에 진행 중인 작업을 보여주면 팀은 개발 주기 초기에 잠재적인 이슈 또는 오해를 파악할 수 있습니다. 일찍 발견하면 이슈를 신속하게 해결하여 나중에 더 큰 문제로 확대되지 않도록 할 수 있습니다.

스프린트 검토는 반복적인 제품 개선을 위한 플랫폼을 제공합니다. 이해 관계자의 피드백을 수집하면 팀에서 기능의 우선 순위를 지정하고 경로를 수정하고 필요한 경우 제품의 방향을 전환하여 시장에서의 관련성 및 경쟁력을 확보할 수 있습니다.

오늘날의 역동적인 비즈니스 환경에서는 우선 순위 및 시장 상황이 순식간에 변할 수 있습니다. 스프린트 검토를 통해 팀은 작업의 우선 순위를 다시 지정하고 새로 생겨나는 기회 또는 문제에 따라 프로젝트 목표를 조정하여 이러한 변화에 적응할 수 있습니다.

스프린트 검토는 이해 관계자가 개발 프로세스에서 의견을 내도록 권한을 부여합니다. 이해 관계자는 검토 과정에 적극적으로 참여하고 피드백을 제공하여 책임 의식을 갖고 제품 성공에 기여하여 더 높은 참여 및 강화된 공동 작업으로 이어집니다.

전반적으로 스프린트 검토를 통해 얻을 수 있는 향상된 조정 가능성 및 유연성 덕분에 팀은 변화하는 시장 역학, 고객 선호 사항 및 비즈니스 요구 사항에 빠르게 대응할 수 있습니다. 유연성을 받아들이면 비즈니스는 경쟁 우위를 유지하고 이해 관계자의 변화하는 기대에 정렬된 제품을 제공할 수 있습니다.

For teams new to sprint reviews, there's a strong temptation to let them bleed into the retrospective. However, a sprint review is an independent ceremony from a sprint retrospective.

Take the time to enjoy the fruits of your labor. Liberally celebrate accomplishments. Effective sprint reviews build up the team's morale and motivation. This idea of celebration is so important to the Jira team that we've incorporated “go ahead, celebrate” into our vision statement.

Get started for free with Jira's scrum template