---

여러 팀의 조율과 계획이란 무엇일까요? 놀라실 수도 있습니다!

Scrum of Scrum

이 과정의 지난 장을 보고 나면 여러 Scrum Team이 효율적으로 함께 일하도록 어떻게 조율하는지 궁금하실 수 있습니다.

당연한 질문이며 저희는 그 답도 다루고자 했습니다.

Scrum of Scrum 회의

Scrum of Scrum 회의는 Daily Scrum 회의와 비슷합니다. 다만 Scrum of Scrum 회의는 개별 Scrum Team 구성원의 업무가 아니라 Scrum Team 자체에 집중합니다.

Scrum-of-Scrums는 선택적인 조율 실천이며 추가적인 공식 Scrum 이벤트가 아닙니다. 팀은 매일 15분의 시간 제한을 선택할 수 있습니다. 더 많은 조율이 필요한 상황이라면 30~60분 회의도 하나의 예입니다. 형식이 유용한지 점검해야 합니다.

조율 질문 예시

• 팀은 어제 무엇을 했는가?
• 팀은 오늘 무엇을 할 계획인가?
• 팀의 진척을 방해하거나 늦추는 장애물이 있는가?

이 답변은 다른 팀에도 영향을 주는 사용자 스토리와 상호 의존성을 포함해야 합니다.

여기서 설명한 역사적인 조율 방식에서는 Chief Scrum Product Owner와 Lead Scrum Master가 Scrum-of-Scrums 회의를 공동으로 진행할 수 있습니다. 이는 선택적인 조직 직책이며 추가적인 Scrum 책임은 아닙니다. 또는 둘 중 한 사람이 회의 진행을 맡거나 서로 돌아가며 맡을 수도 있습니다.

공동 Sprint Review 회의

모든 Scrum Team이 참여하는 공동 Sprint Review 회의는 필수가 아니지만 매우 유익할 수 있습니다. 팀은 여전히 Sprint Review의 목적을 충족해야 합니다. 하나의 제품을 만드는 팀들은 이해관계자와 함께 통합 결과를 점검하며 별도의 현지 회의가 의무적인 중복 이벤트인 것은 아닙니다.

공동 Sprint Review 회의에는 Scrum Team 대표와 공유 제품에 책임을 지는 Product Owner가 참여합니다. 이해관계자도 결과 점검에 참여합니다.

Scrum Team은 선호에 따라 대표를 순환할 수도 있습니다. 이 예시의 선택적 Lead Scrum Master처럼 지정한 진행자가 공동 Review의 효과를 높일 수 있습니다.

공동 Sprint Review 회의에서 모든 Scrum Team은 책임지는 Product Owner, 지원 제품 연락 담당자, 관련 이해관계자에게 출시 가능한 제품 Increment를 시연할 수 있습니다.

이렇게 공동 Sprint Review 회의는 두 가지 목적을 충족합니다.

1. 모든 Scrum Team이 전체 프로젝트의 현재 상태를 함께 파악합니다.
2. 모든 Scrum Team이 작업에 대한 피드백을 수집하고 다음 Sprint Planning 회의에서 이를 고려할 기회를 얻습니다.

공동 Sprint Retrospective

공동 Sprint Review 회의와 마찬가지로 공동 Sprint Retrospective 회의도 필수는 아니지만 매우 유익할 수 있습니다.

공동 Sprint Retrospective 회의가 각 Scrum Team이 진행해야 하는 Sprint Retrospective를 대체하지는 않는다는 점에 유의하세요.

공동 Sprint Retrospective 회의에는 Scrum Team 대표들이 참여합니다. Scrum Team은 재량에 따라 대표를 순환할 수 있습니다.

이 예시의 선택적 Lead Scrum Master 같은 지정 조율자가 공동 Sprint Retrospective를 진행할 수 있습니다. 이 회의는 더 큰 Scrum 프로젝트 조직이 Scrum Framework를 사용하는 방식에서 개선 가능성을 찾고 실행하는 것을 목표로 합니다.

해결에 여러 Scrum Team의 관심과 협업이 필요한 모든 문제(자세한 내용: 여러 Scrum 팀)를 이 회의에서 강조해야 합니다. 해결 경로를 계획하고 일정을 정하며 후속 점검해야 합니다.

여러 팀의 계획: 글로벌 Scrum Product Backlog

여러 팀이 같은 제품을 만들 때는 책임지는 단일 Product Owner 아래 하나의 Product Goal과 Product Backlog를 공유합니다. 이 강의에서는 그 공통 보기를 글로벌 Scrum Product Backlog라고 부릅니다. 지원 제품 연락 담당자와 팀들이 내용을 정제하도록 도울 수 있지만 책임은 해당 Product Owner에게 있습니다.

팀별 Backlog

필요하면 글로벌 Scrum Product Backlog의 사용자 스토리를 더 팀에 특화된 사용자 스토리로 나눌 수 있습니다.

이 세부사항은 팀별 작업 보기와, 선택한 뒤에는 각 팀의 Sprint Backlog에서 관리할 수 있습니다. 이러한 보기는 같은 제품의 독립적으로 우선순위를 정하는 Product Backlog가 되는 대신 공유 Product Backlog를 참조합니다. 이 참조를 통해 Scrum Team은 사용자 스토리가 프로젝트의 큰 그림에서 맡는 역할과 제공하는 고객 가치를 볼 수 있습니다.

Sprint 일정

분산 Scrum 프로젝트 환경에서 여러 Scrum Team의 작업을 동기화하는 방식에는 두 가지 선택지가 있습니다.

• 동기식 Sprint
• 비동기식 Sprint

첫 번째는 동기식 Sprint입니다. 모든 팀이 같은 날 Sprint를 시작하고 끝냅니다.

동기식 Sprint는 Scrum Team의 소통과 조율을 비교적 쉽게 하므로 보통 선호하는 접근입니다.

동기식 Sprint

또 다른 선택지는 비동기식 Sprint입니다. Sprint가 같은 날 시작하고 끝나지 않습니다. 비동기식 Sprint의 장점은 개별 Scrum Team의 모든 Scrum 의식을 같은 날 진행할 필요가 없다는 것입니다. 이를 통해 Product Owner와 지원 조율 담당자가 다른 Scrum Team의 Sprint Planning, Sprint Review, Sprint Retrospective 이벤트에 참여하고 요청받으면 지원할 수 있습니다.

한 팀이 다른 팀에 서비스를 제공하는 경우 비동기식 Sprint에는 추가적인 장점이 있습니다.

비동기식 Sprint

위 그림의 좋은 예시를 살펴보겠습니다. 팀 A(공급 팀)의 작업을 팀 B(주관 팀)의 결과물에 통합해야 합니다. 비동기식 Sprint를 활용하면 팀 A는 팀 B보다 먼저 Sprint를 끝낼 수 있습니다. 따라서 팀 B(주관 팀)는 자체 Sprint가 끝나기 전에 팀 A(공급 팀)의 결과물을 가져와 자신의 작업에 통합할 수 있습니다.

노력 추정

팀은 공동 계획에 도움이 된다면 피보나치식 포인트나 티셔츠 크기 같은 공통 크기 산정 규칙을 선택할 수 있습니다. Scrum이 이를 요구하지는 않으며 한 팀의 포인트나 속도가 다른 팀과 자동으로 비교 가능한 것은 아닙니다.

공통 규칙이 유용하다면 개발자의 크기 산정 책임을 유지하면서 공유 Product Backlog에 일관되게 적용하세요.

컴포넌트 팀의 추정에는 특별히 주의해야 합니다. 컴포넌트 팀은 보통 기능 팀의 사용자 스토리에 서비스를 제공합니다. 따라서 자체 Sprint Planning 회의와 추정 중 필요한 지원과 설명을 받아야 합니다.