brunch

You can make anything
by writing

C.S.Lewis

by Carol Mar 18. 2022

애자일하게 일하는 프로덕트 오너가
꼭 알아야 할 스크럼

코드스테이츠 PMB 10기


이전글에서 제품개발 방법론 중 "애자일(Agile)"을 소개했다. 오늘은 프로덕트 오너(또는 프로덕트매니저)가 애자일하게 일하기 위한 대표적인 방식인 스크럼 프레임워크를 다뤄보고자 한다. 아래의 웹사이트에서 제공하는 스크럼 가이드를 한국어로 다운받아서 PO/PM에게 필요한 개념을 정리해보았다.





1. 스크럼이란?

원래 럭비에서 쓰이던 용어인 스크럼(Scrum)은 목적지에 도달하기 위해 하나로 뭉쳐 움직이는 형태를 말한다. 이 개념을 업무에 적용하면 팀을 중심으로 개발의 효율성을 높인다는 의미가 된다. 나아가 스크럼 프레임워크(Scrum Framwork)는 사람과 팀, 조직이 복잡한 문제에 적응할 수 있는 해법으로 가치를 창출하도록 돕는다. 1990년대 초반 켄슈와버와 제프서덜랜드(Ken Schwaber & Jeff Sutherland)가 개발한 이 개념은2010년부터 지속적으로 전 세계의 사람들이 스크럼을 이해하고 활용할 수 있도록 스크럼 가이드를 발전시켜왔다. 이를 활용하여 프로덕트의 생산성과 가치, 창조성, 결과에 대한 만족도를 높일 수 있다.





2. 스크럼 프레임워크의 원리


• 우리는 고객을 잘 모릅니다.

• 그렇기 때문에 빠르게, 그리고 자주 고객에게 릴리즈하고 새롭게 발견해야 합니다.

• 그렇게 여러 번의 가설 검증 단계를 거치고

• 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아냅니다.

• 그렇게 우리는 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있습니다.


스크럼은 경험과 관찰한 것을 기반으로 한 의사 결정에서 지식을 얻는 경험주의(Empiricism)와 낭비를 줄이고 본질에 초점을 맞추는 린 씽킹(Lean thinking)을 기초로 한다. 고객 예측 최적화와 리스크 통제를 위해 반복적이고 점진적이다. 전체적으로 업무를 수행하는데 필요한 모든 기술과 전문성을 갖출 수 있도록 사람들을 스크럼에 참여시키고, 필요에 따라 그러한 기술을 공유하고 습득하는 것이다.   





3. 스크럼 팀


스크럼 조직의 기본 단위인 스크럼 팀은 일반적으로 한 명의 프로덕트 오너, 한 명의 스크럼 마스터, 그리고 개발자들로 구성되며 10명 이내의 인원이다. 수직구조 없이 하나의 프로덕트 목표에 동시에 집중하는 전문가들이 모인다. 스크럼 팀은 약속(Commitment), 집중(Focus), 열린 마음(Openness), 존중(Respect), 용기(Courage) 5가지 가치를 잘 지켜서 성공적으로 목표를 달성하는 것과 서로 협력할 것을 약속한다. 각 역할을 간단히 살펴보되 프로덕트 오너에 초점을 맞췄다.



프로덕트 오너

크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 프로덕트 오너는 프로덕트를 효율적으로 만들기 위한 팀의 할일 목록인 백로그를 효과적으로 관리하기 위해 다음 항목에 책임을 진다.


프로덕트 목표를 세우고 명쾌하게 소통하는 것

프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것

프로덕트 백로그 아이템을 우선순위에 따라 정렬

프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것


프로덕트 백로그와 연관된 이해관계자들의 요구를 대표하는 프로덕트 오너가 성공적으로 일하기 위해서는 조직 전체가 그의 결정을 존중해야 한다. 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것과 스프린트 리뷰에서 점검 할 수 있는 증가분(Increment)을 통해 프로덕트 오너의 결정을 확인할 수 있다.



스크럼 마스터 

스크럼 가이드대로 스크럼을 확립하는 것에 책임이 있는 스크럼 마스터는 스크럼 팀과 조직의 모든 구성원이 스크럼 이론과 실천법을 이해하도록 돕는다. 스크럼 팀과 더 큰 조직을 위해 봉사하는 진정한 리더, 스크럼 마스터는 스크럼 팀을 효율적으로 만들 책임이 있다.



개발자들

스크럼 팀의 개발자들은 매 스프린트마다 증가분(결과물)의 모든 부분을 만드는 것에 전념하는 사람들이다. 개발자들이 갖추어야 하는 특정한 기술들은 범위가 넓고 업종에 따라 다양하다.





4. 스크럼 이벤트

스크럼에는 네 개의 공식 이벤트(스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고)가 하나의 이벤트인 스프린트 안에 포함된다. 스프린트는 스크럼 이벤트들을 담는 컨테이너라고 할 수 있다. 스크럼 산출물을 점검하고 조정하는 공식적인 활동인 스크럼 이벤트는 주기적이고 반복적이다.




스프린트

단거리 질주라는 의미의 스프린트(Sprint)는 스크럼의 핵심활동이다. 아이디어를 가치로 만들어 내는 한달 이내의 이벤트(프로그램)로 새로운 스프린트는 이전에 진행 된 스프린트가 끝나는 즉시 시작한다. 만약 스프린트 목표가 효과적이지 않다면 프로덕트 오너만이 스프린트를 취소할 수 있다. 스프린트 기간 동안에는 아래 항목을 지켜야한다.


• 스프린트 목표 달성에 방해되는 변경은 불가능하다.

• 품질을 떨어뜨릴 수 없다.

• 프로덕트 백로그는 필요한 수준까지 정제해야 한다.

• 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.



프로덕트 목표를 달성하기 위한 스프린트는 다음과 같은 항목으로 구성되어 있다.



스프린트 계획

스프린트 동안 수행할 업무를 스크럼 팀 전체가 참여하여 계획한다. 프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요한 아이템들과 그것이 프로덕트 목표와 어떻게 연결되는지 참여자들이 논의할 수 있도록 준비해야 한다. 스프린트 계획은 다음과 같은 주제를 다룬다.


1) 스크럼 팀 전체가 참여하여 계획을 한다.

프로덕트 오너는 스프린트에서 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지를 제안한다. 전체 스크럼 팀원들은 협력하여 이해관계자들에게 중요한 이유를 담아서 스프린트의 목표를 정의한다.


2) 이 스프린트의 완료(Done)는 무엇인가?

개발자들은 프로덕트 오너와 논의하면서 이번 스프린트에 포함할 프로덕트 백로그 아이템을 선정한다. 이 과정으로 프로덕트 백로그 아이템을 정제하고 더 정확히 해야할 일을 이해할 수 있다. 개발자들이 지난 성과와 다음에 수용 가능한 업무량, 완료의 정의(Definition of Done)를 명확하게 알수록 더 확실히 스프린트를 예측할 수 있다.


3) 선정한 일을 어떻게 완료할 것인가?

개발자들은 선정한 모든 프로덕트 백로그 아이템들로 완료(Done)할 수 있는 증가분을 만드는 데 필요한 업무들을 계획한다. 보통 하루 안에 완료할 수 있는 크기로 더 작게 세분화하는 것이다. 스프린트 목표, 프로덕트 백로그 아이템들, 그리고 완료할 계획을 모두 스프린트 백로그라고 한다. 스프린트 계획은 최대 시간이 정해진 이벤트로, 1개월의 스프린트인 경우 8시간이 넘지 않도록 한다.



데일리 스크럼

데일리 스크럼은 스프린트 목표 대비 진행정도를 점검하여 스프린트 백로그를 조정하는 것으로 스크럼 팀의 개발자들만 참여하는 15분짜리 이벤트이다. 같은 시각과 장소에서 스프린트 기간 동안 매일 진행한다. 만약 프로덕트 오너나 스크럼 마스터가 스프린트 백로그 아이템을 맡았다면 개발자들의 일원으로 데일리 스크럼에 참여할 수 있다. 이는 팀의 소통을 향상시키고 장애물을 인지하여 신속한 의사 결정을 촉진한다. 지속적으로 서로 조율할 수 있는 데일리 스크럼 과정을 거치면서 오류와 불확실성을 줄일 수 있다.



스프린트 리뷰

스프린트의 결과물을 점검하고 향후에 조정할 것들을 결정하는 것이 리뷰의 목적이다. 프로덕트 오너를 포함한 스크럼 팀은 주요 이해관계자들에게 일의 결과물과 함께 목표 대비 진행정도를 보여줘야한다. 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것을 검토하여 다음 액션을 협력하여 논의하거나 프로덕트 백로그를 수정한다.



스프린트 회고

"다음 스프린트를 더 잘하기 위해 우리가 무엇을 할 수 있는가?"를 주제로 품질과 효율을 높이기 위한 방법들을 계획하는 것이 스프린트 회고이다. 프로덕트 오너를 포함한 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 결과물의 진행 사항을 점검한다. 이 과정에서 가장 효율적으로 도움이 되는 변화를 찾고 가장 영향이 큰 개선책을 최우선으로 고려하여 다음 스프린트 백로그에 추가할 수 있다. 스프린트 회고를 마지막으로 스프린트가 종료된다.





5. 스크럼 산출물

업무 또는 가치를 의미하는 스크럼 산출물은 스크럼팀 모두가 점검하고 조정할 수 있도록 투명하게 핵심정보를 담는다. 산출물인 프로덕트 백로그, 스프린트 백로그, 그리고 증가분은 측정가능한 진행 정도의 파악에 집중하고 투명한 정보제공을 명확하게 하기 위해 아래 사항을 포함한다.

 

• 프로덕트 백로그에는 프로덕트 목표가 있다.

• 스프린트 백로그에는 스프린트 목표가 있다.

• 증가분에는 완료의 정의가 있다.


출처 = https://ryanseamons.com/product-backlog/


프로덕트 백로그 : 프로덕트 목표 포함

프로덕트를 개선하기 위해 발생한 업무를 우선 순위에 따라 정렬한 목록이며 스크럼 팀은 한 스프린트에서 백로그들을 완료하게 된다. 쉽게 말해 팀이 "해야 할 일의 목록"이다. 개발자들이 그 백로그의 항목을 결정하면 프로덕트 오너는 백로그를 지속적으로 검토하고 우선순위를 지정하며 유지하고 관리하는 역할을 한다.

프로덕트 목표는 스크럼 팀이 목표로 삼아 계획하는 프로덕트의 미래 상태를 말하고 장기적인 목표이다. 이는 프로덕트 백로그 안에 포함되어 있고 나머지 백로그들은 그 목표를 달성하기 위한 것들이다.



스프린트 백로그 : 스프린트 목표 포함

스프린트 백로그는 스프린트 목표(왜), 스프린트를 위해 선택된 프로덕트 백로그들의 모음(무엇을), 증가분을 전달하기 위한 실행할 수 있는 계획(어떻게)으로 구성되어 있다. 개발자들을 위한 계획으로 가시적이며, 그들이 스프린트 목표를 달성하기 위한 업무를 실시간으로 보여주는 그림이다. 스프린트 백로그는 데일리 스크럼 때 진행 정도를 확인할 만큼 세부 내용이 충분해야 한다.

스프린트 목표는 개발자들이 약속한 스프린트의 유일한 목표이다. 일관성을 유지하고 집중할 수 있게 하며, 스크럼 팀이 함께 일하도록 돕는다. 목표는 스프린트 계획때 정하고 스프린트 백로그에 추가된다. 만약 업무 방향을 잃을 경우, 프로덕트 오너는 스프린트 목표에 영향을 주지 않는 선에서 백로그의 범위를 개발자와 협의할 수 있다. 



증가분 : 완료의 정의 포함

증가분(Increment)은 스크럼 팀이 스프린트 동안 완료한 업무로 기존 프로덕트에 더해지는 새로운 부분이다. 그동안 누적해온 것에 더해지므로 모든 증가분들이 함께 작동하도록 검증된 것이어야 한다. 수행한 업무가 완료의 정의를 충족하지 않으면 증가분에 포함될 수 없다.

완료의 정의는 증가분이 프로덕트에 요구된 품질 기준을 충족하는 상태이다. 어떤 일을 완료된 증가분으로 간주할 수 있는지 모두와 투명하게 공유한다. 만약 완료의 정의를 충족하지 않으면, 그것을 배포하거나 스프린트 리뷰 때 보여줄 수 없다.



지금까지 설명한 스크럼 프로세스 개념을 정리해보자.



1) 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.

2) 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분(Increment of value)*으로 만들어 낸다.

(*)스크럼 팀이 스프린트 동안 완료한 업무로 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미

3) 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.

4) 반복한다.







결론


애자일, 워터폴 방식 중 어떤 방식으로 제품을 개발하는 것이 적정한지 선택할 때 고려해야 하는 요소는 3가지가 있다.


스코프 : 업무 범위가 얼마나 되는가 (무슨 기능을 만들어야 하는가)

스케쥴 : 투입 가능한 시간이 어떻게 되는가, 시간이 얼마나 있는가, 기한이 언제인가

리소스 : 투입할 수 있는 리소스(돈과 자원, 사람 등)이 얼마나 있는가


스케쥴과 투입 가능한 리소스의 경우 제한적이기 때문에 요구사항의 범위(스코프)에 따라 개발 방식이 결정될 가능성이 높다. 개발 범위가 유동적이고 개발 기간동안 고객의 요구사항이 유동적인 경우 애자일로 개발하는 것이 좋다. 애자일 개발 과정에서 프로덕트 오너의 가장 중요한 역할은 바로 스코프를 잘게 쪼개는 것이다. 핵심 기능 위주로 빠르게 개발할 수 있는 형태로 최대한 잘게 쪼개고 실제로 구축될 수 있도록 해야한다.



프로덕트 오너는 애자일 프로세스의 주요 이해관계자이다. 그는 만들고자 하는 것의 비전을 갖고 그것을 스크럼 팀에 전달하는 키맨이기 때문에 프로젝트를 성공적으로 시작하는 열쇠라고 할 수 있다. 스크럼팀의 실행 목록인 프로덕트 백로그를 통해 이 작업을 부분적으로 수행한다.

스크럼에서 프로덕트 오너는 의사 결정권자이기 때문에 올바른 결정을 내리기 위해 시장, 고객 및 비즈니스를 이해하고 있어야 한다. 그는 스프린트 계획 회의에서 제품 백로그의 우선 순위를 지정하고, 명확한 목표안에서 팀에 동기부여하는 역할을 한다. 팀원은 각 스프린트 동안 수행할 수 있는 작업의 양과 필요한 스프린트 수를 자율적으로 선택한다.

최고의 프로덕트 오너는 팀과 함께 적극적으로 호흡하는 사람이다. 그렇기 때문에 커뮤니케이션 역량이 가장 크게 작용한다. 조직 전체와 그 밖의 이해관계자와 긴밀하게 협력해야 하므로 주어진 시간 안에 프로젝트의 참여자들에게 다양한 메시지를 전달할 수 있어야 한다.



문제를 기막히게 해결하는 유익한 기획자.
코드스테이츠 PM 부트캠프로 획기적인 프로덕트 매니저가 되어 가다.
기막힌 생각과 획기적인 방법론자, PM이야기 #20.  끝.

참고자료


매거진의 이전글 워터폴&애자일 방법론과 카카오톡 멀티프로필의 문제해결
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari