[코드스테이츠 PMB 15] W8D2 스크럼 가이드 학습하기

알림: '스크럼 완벽 가이드: 게임의 규칙'(링크)를 읽고 해당 부분의 일부 내용을 중심으로 글을 작성하였음을 미리 알립니다.

 

0. 들어가기 전에: 스크럼 정의

스크럼: 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법(Adaptive solutions)을 활용하여 가치를 창출하도록 도와주는 경량(Lightweight) 프레임워크다. (참고자료 1)

 

적응할 수 있는 해법? 경량 프레임워크..? 이런식으로 정의만 한 줄 써놓으면 읽는 사람도, 나중에 내가 다시 읽어볼 때도 이해가 안 갈 게 뻔해 보여서 조금 더 구체적으로 정리해보았다.

 

쉽게 말하면 프로덕트 오너(또는 프로덕트 매니저)가 일을 할 때 복잡한 문제에 부딪히는 상황에 문제를 해결하기 위한 방법론(프레임워크)라고 할 수 있다. 구체적으로 스크럼은 아래와 같은 방식으로 진행된다.

 

1. 프로덕트 오너는 복잡한 문제를 해결하기 위해 일의 우선순위에 따라 프로덕트 백로그(=할 일 목록)에 정렬한다.
2. 스크럼 팀은 선택한 업무를 스프린트(업무를 짧은 기간 안에 해내는 방법) 동안 프로덕트에 새로운 가치를 창출해낸다.
3. 스크럼 팀과 이해관계자들은 결과물을 점검하고(결과물에 대한 리뷰, 일하는 방식에 대한 리뷰 모두 진행) 보완점과 개선점을 정리하여 다음 스프린트에 적용할 요소를 정리해놓는다.
4. 반복한다. (계속계속)

---

1. 프로덕트 매니저로서 스크럼 관리 과정에 필요한 업무 요소 정리

(1) 백로그(Backlog) 관리

프로덕트 매니저는 백로그를 효율적으로 관리하는 책임이 있다. 여기서 '효율적으로 관리'라는 뜻은,

• 프로덕트 목표를 세우고 명확하게 소통하는 것: 스크럼 팀이 추구하는 목표를 일치시켜야 한다.
• 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
• 프로덕트 백로그 아이템을 우선순위에 따라 정렬

스크럼 팀 내에서 프로덕트 백로그에 대하여 공통된 이해를 할 수 있도록 합치시키는 것이 프로덕트 매니저가 해야 하는 중요한 일이다. 이는 스크럼 과정에서 의사소통에 문제가 생겨 추가적인 커뮤니케이션 또는 팀 내의 목표 불일치로 인한 손실을 방지하기 위하여 팀원들에게 명확하고 간결한 언어로 전달(구두로든 문서로든)해야 하는 책임이 프로덕트 매니저에게 있다는 것을 의미한다.

 

프로덕트 매니저가 백로그를 관리하는 권한과 최종 책임이 있으므로, 스크럼 팀원들은 프로덕트 매니저의 의견을 존중하여야 한다. 물론 프로덕트 매니저가 팀을 이끌기 위해서 상호 간의 존중은 필수적이다. 만약 팀원 중에 백로그를 변경하고 싶은 사람이 있다면, 그 사람이 구체적인 근거를 바탕으로 프로덕트 매니저를 설득할 수 있다. 프로덕트 매니저는 해당 의견을 검토한 뒤에 변경할 것인지, 유지할 것인지 자신의 의견을 명확하게 전달할 수 있도록 백로그에 대한 이해와 커뮤니케이션 능력이 필요하다.

 

---

2. 스프린트(Sprint) 진행 과정에서 중요한 점

스프린트: 한달 또는 그보다 짧은 기간으로 목표를 달성하는 이벤트

(1) 스프린트의 업무 사이클

1. 스프린트 계획: 제품 백로그를 유저 스토리(User stroy) 형식(Who, Why, What 정보가 포함된 글)으로 만든다.
2. 데일리 스크럼: 매일 정해진 시간에 짧은 시간(10~20분) 동안 스크럼 진행 과정을 파악하고 문제가 있다면 해결책을 찾는 과정
3. 스프린트 리뷰: 스프린트로 개발한 결과물을 고객과 이해관계자들에게 보여주고 의견을 백로그로 정리하는 단계
4. 스프린트 회고: 스프린트 기간 중의 좋았던 점, 개선이 필요한 점을 정리하고 다음 스프린트 진행 시 반영할 것을 정리하는 단계

(2) 스프린트 업무 원칙

• 목표 일관성 유지: 스프린트 목표 달성을 저해하는 목표 변경을 해서는 안 된다.
• 품질 수준 관리: 일정 수준 이상의 품질을 유지하면서 스프린트를 진행해야 한다.
• 백로그 정제: 필요한 수준까지 프로덕트 백로그의 우선 순위를 정하고 관리해야 한다.
• 범위 조정: 스프린트를 통해 달성하고자 하는 목표의 범위를 명확하게 정하고 필요한 경우 프로덕트 매니저와 협상할 수 있다.

(3) 스프린트 진척을 확인시켜 주는 시각화 수단

1) 번 다운 차트(Burn-down chart)

번 다운 차트(출처=Visual Paradigm)

진행해야 할 업무가 정해져있고, 해당 일정에 따라 진척도를 나누어 파악하는 데 용이하다.

 

2) 번 업 차트(Burns-up chart)

번 업 차트(출처=Clarios Technology)

위의 번 다운 차트와 유사하지만, 위 이미지처럼 스프린트 중간에 달성해야 할 일이 추가되는 것을 표시하기 용이하다. 그리고 스프린트 기간이 끝나는 날에 맞춰 달성이 불가능한 목표는 우선순위에 따라 제거한다.

 

3) 누적 흐름도(Cumulative flows)

누적 흐름도

위와 같이 스프린트 기간과 진척률을 다양한 시각화 수단을 활용하여 확인할 수 있다. 만약 예상 진척도보다 실제 업무가 늦는 상황이라면 프로덕트 매니저는 문제를 파악하고 적절한 해결책을 세워서 대처해야 한다.

 

시각화 수단은 여태까지 배운 것처럼 의사결정을 도와주는 하나의 수단일 뿐이다. 위에서는 다양한 것들을 정리했지만 실제로 일할 때 발생하는 문제들을 경험하면서 이슈를 확인하고 중간에 발생하는 이벤트에 따라 끊임없이 결정을 내려야 한다는 것만 알았다. (이 부분은 실제로 경험하면서 체득하는 영역인 듯하다)

 

---

3. 스크럼 산출물

프로덕트 매니저로서 밀도 높은 일정을 소화하면서 스스로를 갈아넣은(?) 결과물이 명징해야 스스로의 성과를 입증할 수 있고, 스크럼을 지속할 수 있다. 그래서 스크럼 결과물은 어떻게 판단하는 걸까?

 

각 산출물은 측정 가능한 진척에 집중한다. 측정 지표는 스프린트 계획 단계에서 정의를 내려야 한다. 물론 한 스프린트 내에 얼마나 완료할지 정하는 일은 쉬운 일은 아니다. 그럼에도 불구하고 스크럼을 반복적으로 이끌어 가면서 보완과 개선을 통해서만 스프린트 예측의 정확도를 높일 수 있다. 즉, 측정 가능한 지표를 달성 가능한 수준(이 부분도 스크럼에 대한 경험이 있어야 설정할 수 있을 것 같다)으로 설정하되 시행착오의 과정은 필연적이라고 할 수 있다. (쫄지 말자)

 

스크럼 산출물을 판단하기 위한 기준은 프로덕트 백로그, 스프린트 백로그 두 가지가 있다.

(1) 프로덕트 백로그

프로덕트를 성장시키기 위한 것으로 업무를 우선순위에 따라 정렬한 목록을 의미한다. 프로덕트 백로그는 스프린트 계획 단계에 설정하는 것으로서 한 스프린트 안에 완료할 수 있는 수준으로 설정한다.

 

프로덕트 백로그를 정제할 때 백로그를 보다 구체적으로 정의하여 명확하게 작은 단위로 일을 나눈다(설명(description), 우선 순위에 따른 정렬(ranking), 크기(Volume)와 같은 세부 사항을 지속적으로 추가하는 활동을 의미한다). 여기서 프로덕트 백로그의 크기는 개발자들이 결정하는 책임을 지고, 프로덕트 매니저는 개발자들이 절충안을 이해하고 선택할 수 있도록 도움을 줄 수 있다.

 

(2) 스프린트 백로그

스프린트 백로그는 스프린트 목표(Why), 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음(What), 증가분(Increment)을 전달하기 위한 실행할 수 있는 계획(How)으로 구성되어 있다.

 

스프린트 백로그 예시(출처=Scrum.org)

스프린트 백로그는 개발자들에 의한, 개발자들을 위한 계획이다. 위 예시 이미지와 같이 매우 가시적이며, 개발자들이 스프린트 목표를 달성하기 위해 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는 그림이다. 따라서 스프린트 백로그는 스프린트 기간 동안 더 알게 된 것만큼 업데이트 된다. 스프린트 백로그는 데일리 스크럼 때 진척을 확인할 수 있을 만큼 세부 내용이 충분해야 한다.

 

---

4. 참고 자료

1. 스크럼 완벽 가이드: 게임의 규칙, 2020.11., https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Korean.pdf