스크럼 가이드 간단하게 살펴보기 | 코드스테이츠 PMB 13기

W8D2

스크럼 가이드 학습하기

스크럼을 관리하는 것에 필요한 업무에는 무엇이 있는가?
스프린트가 진행되는 과정에서 중요한 것은 무엇인가?

 

 

---

 

  용어 짚고가기  

📍 PO는 제품의 지속적인 성장을 위해 애자일 팀에서 제품을 관리하는 데 중점을 둔 역할에서 시작한 개념. 프로덕트에 대한 로드맵, 전체 일정을 관리하고 개발, 디자인 등 관계된 사람들과 업무를 조율하며, 우선순위 등을 결정한다

📍PM은 제품의 비전을 설정하고 고객 문제를 해결하는 제품의 제작 방향을 결정하는 것에서 시작한 개념. 조직 내에서 제품 개발에 관련된 연구, 선택, 추진 등의 제품 관리 활동을 하는 전문가

📍 제품 백로그는 출시하려는 제품에 필요하다고 알려진 모든 요구사항에 대한 우선 순위화된 목록. 제품 책임자와 스크럼 팀이 이해할 수 있는 수준의 개요와 설명을 포함한다.

 

 

---

 

 

  스크럼 팀 내 PO의 역할  

 

스크럼 팀은 스크럼 마스터, 프로덕트 오너 그리고 다수의 개발자로 구성됩니다. 팀 안에는 별도의 하위 팀이 존재하지 않으며, 수평적인 구조를 가지고 있습니다. 스크럼 팀은 그 자체로 하나의 프로덕트를 제작할 수 있는 전문가들로 구성되어 있습니다. 스크럼 팀은 이해관계자 설득, 유지보수, 운영 등 그들이 담당하고 있는 프로덕트와 관련된 모든 활동에 책임을 가집니다. 그 중에서도 프로덕트 오너는 제품 백로그를 효과적으로 관리하는 것을 책임집니다. 제품 백로그를 관리하기 위해 PO는 아래와 같은 업무들을 수행합니다.

 

• 이해관계자들과 합의된 제품 목표를 세우고 공유함
• 제품 백로그를 생성하고 우선순위에 따라서 정렬함
• 스크럼 팀원 및 이해관계자들이 이해하기 쉽도록 제품 백로그를 명확하게 작성함

 

프로덕트 오너는 백로그 관리의 최종 책임자이기 때문에 팀 전체는 PO의 의사결정을 존중해야 합니다. 여기서 PO의 의사결정이란, 백로그 간의 우선순위와 정렬 방식 등을 말합니다. 따라서 제품 백로그를 변경하고 싶을 경우에는 PO를 설득해야 합니다.

 

 

  스프린트의 조건과 관리 도구  

 

스크럼은 반복되는 스프린트 활동으로 구성됩니다. 스프린트란 2주~4주 간의 시간 범위를 설정하는 타임 박스 프레임워크입니다. 하나의 스프린트를 마치면 팀은 회고의 시간을 가진 뒤 곧바로 새로운 단위의 스프린트에 돌입하게 됩니다. 하나의 스프린트 기간 동안 스크럼 팀은 프로덕트 목표를 달성하기 위한 업무들에 집중합니다. 스크럼은 합의된 시간(하나의 스프린트 기간)내에 목표로 설정한 업무를 최대한 완수하는 것을 목표로 합니다. 이 같은 스크럼의 성격 때문에 스프린트는 아래와 같은 조건들을 만족해야 합니다.

 

• 스프린트 목표 달성을 저해하는 변경사항은 배제한다
• 제품의 품질을 떨어뜨리면 안된다
• 필요 수준까지 제품 백로그를 정제해야 한다. (무엇을 해야하고 하지 말아야 하는지 잘 골라내야 한다)
• 업무 범위를 명확하게 해야하며 필요시 PO와 논의 후 합의해야 한다.

 

스프린트 기간은 보통 한 달 미만의 길이이기 때문에 제품팀은 적어도 달에 한 번씩 프로덕트 목표 달성도를 점검하고 목표치를 조정할 수 있습니다. 목표 달성도를 점검하고 예측하기 위해서 사용하는 방식으로는 번 다운 차트burn down chart와 번 업burn up chart 차트 등의 다양한 것들이 있습니다. 번 다운 차트는 모든 일이 완료되는 시점을 예측하기 좋은 도구입니다. 번 업 차트는 번 다운 차트와 추구하는 목적은 동일하지만, '할 일이 얼마큼 남았는지' 확인하기에 좋은 번 다운 차트와는 다르게 '그동안 우리가 얼마큼 해야 할 일을 완수했는지' 확인하기에 유용한 자료입니다. 

 

번 다운 차트https://ko.wikipedia.org/wiki/%EB%B2%88_%EB%8B%A4%EC%9A%B4_%EC%B0%A8%ED%8A%B8

 

번 업 차트 https://www.wrike.com/blog/what-is-a-burn-up-chart/

 

 

스프린트 기간을 지나치게 길게 잡을 경우에는 스프린트 본래의 목적이 퇴색되며, 업무 복잡도와 리스크가 커집니다. 아니면 제품의 목표가 사라지거나 짧은 시간 동안 팀이 스프린트 하는 것이 효용이 낮을 경우, PO는 스프린트를 취소할 수 있습니다. 

 

 

---

 

  정리하며  

 

스프린트는  소규모의 팀을 이끌고 전력질주 하는 것이기 때문에 PM의 커뮤니케이션 역량이 더욱 강조된다고 생각합니다. PM은 제품팀 구성원과 진정성 있게 소통하며 지속적으로 팀의 상태를 체크하고, 상태에 따라 적절한 백로그 수준을 유지해야 합니다. PM으로서의 최악의 상황은 제품팀의 컨디션(capacity)을 제대로 파악하지 못한 채 스프린트를 강행하다 제품 성과가 기대에 미치지 못했을때 팀원들로부터 '그러게 그건 하지 않는게 좋았다니까요' 식의 핀잔 또는 평가를 듣는 것이라고 생각합니다. 그러니 PM은 이런 상황을 방지하기 위해 피상적인 대화가 아니라 시간과 노력을 들여 센스 있게 의사소통할 줄 알아야 합니다. 그 결과 제품팀과 이해관계자가 제시하는 여러 요구사항들 간의 합의점을 적절하게 찾아내야 할 것입니다. 

 

수많은 방법론과 프레임워크가 있지만 결국 중요한 것은 함께 일하는 사람인 것 같습니다. 같이 일하고 싶은 사람들과 전력질주 끝에 괄목할 만한 성과를 내는 것만큼 이상적인 회사생활이 또 있을까요? 저 또한 누군가에게 함께 일하고 싶은 사람인지 되돌아보게 되는 것 같습니다.