'PO, PM'으로서 스크럼, 스프린트 과정의 요약
1. 프로덕트 매니저로서 스크럼을 관리하는 과정에서 필요한 업무 요소
1) 스크럼의 최고 책임자인 프로덕트 오너의 주요 업무
: 프로덕트 오너의 스크럼 관리를 위한 주요 업무와 특징을 살펴보겠습니다.
[PO의 주요 업무]
프로덕트 목표를 세우고 명쾌하게 소통하는 것
프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
프로덕트 백로그 아이템을 우선순위에 따라 정렬
프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
[PO의 주요 특징]
위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임
최종 책임은 프로덕트 오너가 갖는다
성공적으로 일을 하기 위해서는 조직 전체가 반드시 그의 결정을 존중
프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인
스프린트 리뷰 때에 점검 가능한 증가분
프로덕트 오너는 한 사람
프로덕트 백로그와 연관된 이해관계자들의 요구를 대표
2) 프로덕트 매니저가 스크럼내에서 가지는 역할에 대해 필자의 의견
우선 스크럼은 소프트웨어 개발 방법론 중 하나 입니다. 팀이 일정 기간 동안 서로 협업하여 프로젝트를 완성하는 방식입니다. 스크럼의 구성요소는 제품 소유자, 스크럼 팀, 스프린트, 스프린트 회고전, 일별 스크럼, 스크럼 보드가 있습니다. 여기서 PO는 프로덕트 목표를 세우고, 백로그 아이템을 생성하고 아이템을 우선순위에 따라 정렬하고 투명하고 가시적으로 이해가 잘 되도록 선두주자로 일을 수행합니다.
PM은 그 곳에서 PO와 긴밀하게 협업하고 보완해야 할 것입니다. PO가 세운 프로덕트 목표를 구성원들이 받아들이지 않는다면, 이를 보완한 자료, 데이터, 사용자 목소리 등 다양한 방법을 통해 목표가 타당하다는 근거 자료를 보충해야 할 것입니다. 같은 목표를 바라보는 스크럼 팀을 구성하기 위해 확실한 근거 + 필요성을 제시해주는 PM이 되어야 할 것입니다.
그리고, 백로그의 관리를 해야하는데 앞장서야겠습니다. PO가 백로그의 우선순위를 결정한다면 PM은 백로그를 관리해야 할 것입니다. 회의 시간에 나온 안건을 무분별하게 백로그에 쌓아두어 심리적인 안정감의 용도로 활동되면 안되겠습니다. 단기 목표에 부합하는 백로그만을 모아두어 우선순위로 해결할 수 있는 양과 규모를 설정해야 할 것입니다. 또, 백로그는 하나의 완성된 유저 스토리로서 작성되어 완결성을 지녀 완성도 높은 백로그를 구성하도록 도와야 겠습니다.
3) 스크럼 팀의 다섯 가지의 가치
스크럼 팀은 다섯 가지의 가치를 통해 일을하고 행동하는 방향을 제시하는 요소는 다음과 같습니다. 스크럼 실행 방식도 중요하지만, 구성원들이 스크럼에 대해 생각하는 5가지 가치를 구성원이 모인 팀이라면 더욱 효과적으로 스크럼 팀이 목표를 향해 달려갈 수 있겠습니다. 그것에는 약속, 집중, 열린 마음, 존중, 용기라는 5가지 요소가 필수 적입니다.
- 약속(commitment): 스크럼 팀은 목표를 달성하는 것과 서로 협력할 것을 약속한다.
- 집중(focus): 팀원들은 스프린트 동안 최상으로 가능한 진전을 만드는 일에 최우선적으로 집중한다.
- 열린 마음(openness): 스크럼 팀과 이해관계자들은 일과 도전에 열린 마음을 가져야 한다.
- 존중(respect): 팀원 개개인이 능력을 갖춘 독립적인 존재임을 서로 존중해야 한다.
- 용기(courage): 힘든 문제를 해결할 때 올바른 일을 하는 용기를 가져야 한다.
4) 스크럼의 진행 순서
- PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정합니다.
- PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 합니다.
- 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당합니다.
(PO는 기능과 우선순위에 대한 권한이 있고,
특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만,
실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요)
- 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가집니다.
- 매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 합니다.
- 제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면,
스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖습니다.
(스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동)
- 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖습니다.
2. 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점
1) 스프린트의 배경과 준비사항
스프린트는 구글 수석디자이너 제이크 냅이 고안한 기획실행법으로, 팀원들과 토론을 통해 도출된 아이디어를 단기간 내에 프로토타입으로 제작하고 테스트하여 중요한 문제들에 대한 답을 찾아가는 과정입니다. 상품이나 서비스 혹은 조직이 당면한 문제에 대해 단기간 내에 시뮬레이션하여 시간과 자원을 효과적으로 사용할 수 있는 개발 방식으로 특히, 스타트업에서는 실제로 제품을 구축하고 실시하는 위험한 과정에 착수하기 전에 자신들이 제대로 가고 있는지 확인해볼 방법을 제시합니다.
스프린트를 실행하기 전 준비사항에는 과제, 팀, 시간, 장소, 진행자가 필요합니다. 진행자라면 PO와 PM이 되겠습니다.
- 과제 : 해결해야 할 문제 및 과제를 확인합니다.
- 팀 : 과제를 해결하기 위해 여러 분야의 전문가들로 팀을 구성합니다. (4~8명)
- 시간 : 과제 해결에만 집중할 수 있도록 일정(Full time days)을 확보합니다. 스프린트를 진행하려면 많은 에너지와 집중이 필요합니다.
- 장소 : 무수한 아이디어들을 적을 수 있는 회의실을 준비합니다.
- 진행자 : 스프린트 절차 전체를 관리하고, 회의를 이끌고 상황을 봐가며 토론을 종합하고 정리하는 역할을 수행합니다.
2) PO로서의 스프린트과정
스프린트는 팀이 일정량의 작업을 완료하는 시간이 정해진 짧은 기간입니다. 스프린트는 스크럼과 애자일 방법론의 핵심이며, 올바른 스프린트는 애자일 팀이 더 적은 수고를 통해 더 나은 소프트웨어를 제공하는 데 도움이 됩니다.
PO는 5일이란 짧은 기간 안에 집중하여 설정한 문제점에 대한 솔루션을 아이데이션 하고, 전체적인 지도를 만들고 아이디어 스케치를하며 가장 좋은 솔루션을 완성해야합니다. 그리고 그 솔루션을 통해 최종적으로 고객의 피드백까지 받아야 합니다. 스프린트를 통해 PO는 제품을 빠르고 자주 출시를 할 수 있음으로서 소비자의 요구에 빠르게 대응할 수 있겠습니다.
3) PO로서 스프린트 과정에서 해야할 일과 하지말아야 할 일
스프린트를 진행하는 과정에서 PO는 어떤 것을 해야하고, 어떤 것을 하지 말아야 할까요? 가장 중요한 것을 방향성이겠습니다. 방향을 잘 잡는 PO가 있어야 팀 구성원들이 목표를 향해 빠르게 달려갈 수 있는 확신을 가질 수 있겠습니다. 결정과 계획을 협업툴을 통해 사용하며, 효율성을 극대화해야하며, 구성원들의 가능성을 바탕으로 일의 계획을 세워야 할 것입니다. 불확실성이 높은 스토리는 세분화하거나, 확실성이 낮은 작업이라면 재구성해야할 것입니다.
[To do]
- 팀이 스프린트 목표와 성공을 측정하는 방법을 설정하여 모두를 공동의 목표를 향해 정렬해 갈 수 있습니다.
- 우선 순위와 종속성이 잘 정리되어 있는지 확인합니다. 제대로 관리하지 않을 경우 프로세스가 틀어질 수 있습니다.
- 스프린트 계획 회의를 사용하여 완료해야 할 작업에 대한 자세한 내용을 더합니다. 팀 구성원들이 스프린트에 포함되는 모든 스토리, 버그 및 작업에 대한 작업을 구상하도록 유도합니다.
- 결정과 계획을 세웠으면 Jira 와 같은 프로젝트 관리 또는 협업 도구에서 정보를 가져오고, 누구나 쉽고 빠르게 확인할 수 있어야 합니다.
[Not To Do]
- 너무 많은 스토리를 가져오거나, 속도를 과대 평가하거나, 스프린트에서 완료할 수 없는 작업을 가져오지 말아야 합니다.
- 품질 또는 기술적 가능성을 생각해야합니다. 버그 및 엔지니어링 상태와 같은 QA 및 기능 이외의 작업에 대한 시간을 책정하세요.
- 팀에서 스프린트의 작업에 대해 불분명해서는 안 됩니다. 명확하게 파악하고 모든 팀원이 같은 방향으로 움직여야 합니다. (속도<방향)
- 알 수 없는 부분이 많거나 위험도가 높은 작업을 수락말고, 불확실성이 높은 스토리를 세분화하고, 다음 스프린트를 위해 작업의 일부를 남겨 둡시다.
- 속도, 확실성이 낮은 작업 또는 예상보다 큰 것 같은 작업과 같이 팀에 우려 사항이 있으면 무시하지 마세요. 문제를 해결하고, 필요한 경우 다시 보정합니다.
출처
[1] https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Korean.pdf