오늘은 애자일하게 일하기 위해서 많이 활용되는 스크럼을 PM, 그리고 PO로서 잘 진행하려면 어떻게 해야하는지 스크럼 가이드를 살펴보려고 합니다.
프로덕트 오너(PO), 프로덕트 매니저(PM)로서 스크럼 관리를 하려면
PO이나 PM은 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖고 있습니다. 이를 달성하기 위한 세부적인 수행 방법은 조직의 상황 등에 따라서 다릅니다.
일반적으로 스크럼은 팀이 중심이 되어, 개발의 효율성을 높이며, 목표를 달성하기 위해 사용되는 프레임워크이기 때문에 각각의 스프린트 순서가 진행됨에 따라서 PO/PM은 아래와 같은 사항을 각각 유의하여 스크럼을 관리할 수 있어야 한다고 보여집니다.
스프린트 계획
- 잘 정의된 목표를 기반으로 문제 해결에 있어서 필요한 업무의 우선순위 선정
- 이러한 우선 순위에 따라서 프로덕트 백로그 정렬
- 스프린트 목표를 구현할 수 있도록 각각의 요구사항을 task 단위로 나누기
- Task를 각 담당자들이 나눠서 작업을 수행하도록 만들기
- 특히, 핵심 기능 위주로 빠르게 개발할 수 있는 형태로 스코프를 최대한 잘게 쪼개고 실제로 구축될 수 있도록 만들기
- 스프린트 목표가 효력이 없게 되면, 스프린트를 취소할 수 있어야 함
이 중에서 프로덕트 백로그를 효과적으로 관리하는 부분에서도 PO/PM에게 책임이 있습니다. 이 때 아래 사항들을 포함한다고 합니다:
- 프로덕트 목표를 세우고 이를 바탕으로 팀원 간 명확하게 소통하는 것
- 프로덕트 백로그 아이템을 생성하고 개발자들과 분명하게 소통하는 것
- 프로덕트 백로그 아이템을 우선순위에 따라 정렬
- 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
데일리 스크럼
- 스프린트 백로그 아이템을 맡아 활동적으로 업무를 하고 있을 때, 개발자들만 참여하는 15 분 길이의 데일리 스크럼에 참여함
- 참여할 때, 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정
스프린트 리뷰
- 목적: 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정
- 이해관계자들과 함께 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토
- 논의한 내용을 바탕으로 다음으로 무엇을 할 것인지 협력하여 이야기를 나눌 수 있도록 하고, 필요한 경우 프로덕트 백로그를 수정할 수 있어야 함. 그리고 이 부분을 PO/PM이 결정.
스프린트 회고
- 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게진행되었는지를 점검
- 무엇이 잘 되었는지, 어떤 문제를 만나고 어떻게 풀었는지/풀지 못했는지 의견을 나눔
- 회고 과정이 원활하게 진행되도록 주관하고, 가장 도움이 되는 변화를 찾아서 다음 스프린트에 적용할 수 있도록 이끔
PO/PM은 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표하고 있습니다. 이러한 이해관계자들의 요구에 맞는 백로그들을 우선순위에 따라 정렬한 뒤 원활하게 스크럼이 진행되도록 하는 모든 부분에 대한 책임이 있습니다. 전체를 바라보고, 목표에 맞게 스프린트가 잘 이루어지기 위해서 각각의 요소, 전체의 요소 모두 고려해야 한다는 점이 참 어려워보이네요. 하지만 PO/PM은 조직과 프로덕트의 비전과 목표에 맞는 결과물을 내기 위해서 열심히 달리는 사람인 만큼 전체를 보는 눈을 기르고, 이러한 전체를 잘 굴러갈 수 있도록 세부적인 요소들을 잘 챙길 수 있도록 성장해야 겠다고 생각되네요.
스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점
먼저 스프린트란, 프로젝트를 빠른 시간 안에 효율적으로 개발하고 해결하는 단기간 프로젝트 개발 방법론입니다. 이러한 스프린트가 원활히 진행되기 위해서는 아래와 같은 요소가 중요하게 고려된다고 합니다.
- 1주~2주 길게는 한 달 정도의 기간으로 고정된 기간 동안 진행해야 한다.
- 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.
- 스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다.
또한, 스프린트를 진행하는 기간 안에는 다음과 같은 부분을 명심해야 한다고 합니다.
- 스프린트 목표 달성을 저해하는 변경을 해서는 안된다
- 품질을 떨어뜨려서는 안된다
- 필요한 수준까지 프로덕트 백로그를 정제해야 한다
- 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다
- 진척을 예측하는 데에는 번 다운 Burn-downs 차트, 번 업 Burn-ups 차트, 누적 흐름도 Cumulative flows 와 같은 다양한 방식이 있지만 경험주의의 중요성을 대체하지는 못한다.
애자일하게 일하기 위해서 진행하는 스프린트는 확실히 애자일한 업무 방식의 장점을 많이 끌어올린다고 생각됩니다. 고객의 반응과 피드백, 그리고 변화하는 시장 상황을 캐치하고, 이에 최대한 빠르게 대응할 수 있게 만들기 때문이죠. 이를 위해 팀원들 간 가장 효율적으로 협력할 수 있는 방법을 제안하고 있다고 보여집니다. 시장과 고객의 반응에 빠르게 대응하고 싶은데 어떻게 해야할지 모를 때, 이렇게 참고할 수 있는 프레임워크가 있어 일견 든든하기도 합니다. 어떻게 해야하는지 방법을 모르면 방법을 찾기 위해 우왕좌왕하다가 시기를 놓치는 경우도 분명 발생할 수 있다고 보거든요. 물론 이 스프린트를 모든 기업이나 조직에 바로바로, 전적으로 적용할 수 없지만, 고객 관점에서 더 적합한 솔루션을 제안할 수 있는 PO/PM으로서 역할을 해내기 위해서 나의 업무 방식에 일부 차용할 수 있는 부분은 없을지 고민해봐야 겠다고 생각이 들었습니다.
참고
https://scrumguides.org/scrum-guide.html
'도담한 Product Manager 성장기 > 내맘대로 분석 모음' 카테고리의 다른 글
Jira로 적용 가능한 애자일의 원칙 [W8D4_코드스테이츠 PMB 12기] (0) | 2022.07.04 |
---|---|
'타입스(Types)'의 백로그를 관리한다 가정해보자 [W8D1&3_코드스테이츠 PMB 12기] (0) | 2022.06.29 |
'당근마켓 관심목록 추가' 가능 다시보기 [W7D4_코드스테이츠 PMB 12기] (0) | 2022.06.28 |
카카오톡 Open API 살펴보기 [W7D3_코드스테이츠 PMB 12기] (0) | 2022.06.24 |
모바일 웹 vs 웹 앱 vs 하이브리드 앱 vs 네이티브 앱 [W7D2_코드스테이츠 PMB 12기] (0) | 2022.06.24 |
댓글