어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 2

Part 1에서는 제가 스크럼을 탄탄하게 운영하기 위해 이론부터 공부하기 시작한 과정과 스크럼의 정의, 스크럼 팀이 어떻게 구성되는지 그리고 각 구성원들의 역할에 대해서 다루었습니다.

 

어깨너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1 보러 가기

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

 

Part 2에서는 스크럼을 실질적으로 운영하는 방식과 스크럼의 산출물(=개선된 제품)에 대해 적어보겠습니다.

 

스크럼 이벤트

스크럼을 잘 굴리기 위해 해야 하는 일들을 스크럼 이벤트라고 하며 이 이벤트들은 스프린트라는 컨테이너에 담겨 운영됩니다. 적절하게 열린 스크럼 이벤트들의 총합은 개선된 제품이라는 산출물로 나와야 합니다. 대표적인 스크럼 이벤트로는 스프린트 플래닝, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고 등이 있습니다.

 

스크럼 이벤트들은 최선의 산출물을 만들어내기 위해 구조화되어 설계되었기 때문에 각 이벤트들을 빠짐없이 진행하는 것을 지향해야 합니다만, 현업에서의 기억을 돌이켜보면 시시때때로 터지는 이슈들과 다양한 이해관계자로부터 들어오는 요구사항들 덕분에 유동적인 대응은 필수적이라고 생각합니다.

 

스크럼 이벤트는 주기적이고 반복적인 활동이기 때문에 각 이벤트들이 누락 없이 진행된다면 별도의 미팅을 최소화할 수 있습니다. 이는 소중한 우리 스크럼 팀의 시간을 효율적으로 사용하는 데 중요한 부분입니다.

출처 : https://brainhub.eu/blog/differences-lean-agile-scrum/

 

 

그럼 스크럼 이벤트들을 담는 컨테이너인 스프린트와 그 안에 담긴 스크럼 이벤트들을 설명해 보겠습니다.

 

스프린트

스크럼이 자동차라면 스프린트는 엔진이라고 비유할 수 있을 것 같습니다. (더 좋은 비유가 생각나신다면 댓글 환영합니다!)

스프린트는 2주~4주 정도의 기간으로 고정된 길이의 이벤트로, 스프린트 기간 동안 앞서 언급한 스프린트 플래닝, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 제품의 목표를 달성하기 위한 모든 작업을 수행하게 됩니다.

 

스프린트의 기간을 고정하는 이유는 한 스프린트의 기간을 너무 길게 잡게 된다면 그 시간 동안 목표나 상황이 바뀔 수 있기 때문입니다. 예를 들어, 지금 시점에 큰 개발 리소스가 필요하지만 강력한 고객 가치를 만들 수 있는 기능을 계획해서 3달짜리 스프린트를 진행한다고 가정해 보겠습니다.

 

컨텐츠 서비스인 경우, 부푼 마음을 안고 2달간 열심히 해당 기능을 개발하는 중에 트렌드가 완전히 바뀌어 해당 기능에 대한 수요가 완전히 없어질 수 있습니다. 또 금융 서비스인 경우 정부 정책의 변경으로 해당 기능 제공 자체가 불법이 될 수도 있고, 특정 산업과 관련 없이 비즈니스 전략 관점에서 해당 기능이 필요치 않게 될 수도 있습니다.

 

이렇게 되면 우리 팀은 2달간의 시간, 비용, 에너지 등 많은 자원들을 매몰비용으로 감수하게 됩니다. 저 역시 이런 경우를 경험해 보았고 팀의 멘탈에 대미지가 많이 들어왔고 팀의 속도가 저하되는 경험을 해보았기 때문에 이후에는 잠재력이 높은 기능일지라도 유연한 대응을 위해 백로그를 잘게 쪼게는 것을 지향하고 있습니다.

 

* 제품 백로그 : 제품을 개발하기 위해 수행할 작업의 목록과 우선순위를 말합니다. 제품 백로그 중 이번 스프린트에 포함된 백로그는 스프린트 백로그라고 부릅니다.

 

스프린트 플래닝

스프린트 동안 수행할 작업을 선정하는 이벤트로 스크럼 팀 전체가 참여하여 플래닝합니다. 이때, 프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요하면서 우선순위가 높은 아이템들을 나열하고 해당 아이템들이 프로덕트 목표에 어떻게 연결되는 지를 논의할 수 있도록 준비해야 합니다.

 

스프린트 플래닝에서는 다음의 3가지 주제를 중점적으로 다뤄야 합니다.

• 이 스프린트가 왜 가치가 있는가? Why
  • 프로덕트 오너는 이번 스프린트가 프로덕트에 어떤 가치를 더해줄지를 제안하고 팀원들과 함께 스프린트의 목표를 정의합니다.
• 이 스프린트의 완료는 무엇인가? What
  • 개발자들은 이번 스프린트에 포함할 백로그 아이템을 선정하고 팀은 이 과정에서 백로그 아이템을 정제합니다.
  • 한 스프린트 내에 얼마나 완료할 수 있을지를 예상하는 것이 쉬운 일은 아니지만 스프린트를 반복적으로 수행하면서 지난 스프린트들의 결과를 토대로 팀의 속도를 측정해서 오차범위를 줄여나가야 합니다.
  • 지난 스프린트의 결과로 팀의 속도를 예측하는 템플릿
• 선정한 일을 어떻게 완료할 것인가? How
  • 개발자들은 선정한 프로덕트 백로그 아이템들을 가지고, 완료의 정의를 충족시키는 업무들을 계획하고 배분합니다.
  • 업무의 계획은 대체로 프로덕트 백로그 아이템을 하루 단위로 완료할 수 있는 크기로 더 작게 쪼개는 것으로 이루어집니다.

출처 : https://brunch.co.kr/@workingus/43

 

스크럼 가이드에서는 스프린트 플래닝은 최대 시간을 고정해서 이루어져야 하며, 4주 간의 스프린트인 경우 최대 8시간이 넘지 않도록 하는 것을 권장하고 있습니다. 참고로 저는 평균 2주 간의 스프린트를 운영하며 스프린트 플래닝 최대 시간을 2시간 이내로 맞추려고 하고 있습니다.

 

데일리 스크럼

데일리 스크럼은 스프린트 목표의 진척 상황을 점검하고, 필요한 경우 업무 진행 계획과 스프린트 백로그를 변경 및 조정하는 이벤트입니다. 데일리 스크럼은 매일 특정 시간에 스크럼 팀이 모여 15분 정도의 길이로 진행하게 되며, 주로 개발자들 간의 소통이 주요 목적이지만 경험 상 프로덕트 오너도 가능하면 참여해서 스프린트 목표에 맞게 조정이 이루어지고 있는지 함께 챙기는 편이 생산적이었습니다.

 

데일리 스크럼은 팀의 소통을 원활하게 하고 혹시 모를 장애물을 빠르게 인식하고 해결 방안을 모색할 수 있도록 하기 때문에 꼭 진행해야 하는 이벤트이지만 제품의 상황과 조건에 따라 데일리가 아니라 일주일 중 월/수/금 혹은 화/목에만 진행하는 식으로의 조정도 가능하다고 생각합니다.

 

데일리 스크럼을 효율적(?)으로 하기 위해서 이렇게도 합니다.

 

스프린트 리뷰

스프린트 리뷰는 스프린트의 끝에서 두 번째로 진행하는 이벤트로 스프린트 리뷰의 가장 큰 목적은 이번 스프린트의 결과물(=산출물)을 점검하고 향후에 적응할 것들을 결정하는 것입니다. 결과물의 점검은 이번 스프린트의 목표 및 백로그가 특정 기능을 개발해서 적용하는 것이었다면, 해당 기능이 실제 동작하는 것을 스프린트 리뷰 시간에 직접 데모하고 기능 개발의 완료를 모든 팀 구성원이 합의하는 것을 뜻합니다. 이때, 필요하다면 스크럼 팀원뿐만 아니라 주요 이해관계자들도 함께 미팅에 초대하여 스프린트의 결과물과 프로덕트 목표 대비 진척상황을 공유하는 자리를 만들기도 합니다.

 

스프린트 리뷰에서는 이번 스프린트에서 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토해야 합니다. 만약 환경에 변화가 있었다면 해당 정보를 기반으로 스크럼 팀은 다음 스텝으로 무엇을 할 것인지 논이해야 합니다. 이 과정에서 프로덕트 백로그의 세부 명세나 우선순위를 변경할 수도 있습니다.

출처 : https://ancaonuta.medium.com/12-things-you-must-know-about-the-sprint-review-e57cfea4da3d

 

스프린트 회고

스프린트 회고는 스프린트의 마지막에 진행하는 이벤트로 스프린트 회고의 목적은 스크럼 팀이 만들어내는 결과물의 품질과 효율을 높이기 위한 방법들을 계획하는 것입니다. 스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 스프린트&스크럼 프로세스, 툴, 완료의 정의에 대해 이번 스프린트가 어떻게 진행되었는 지를 스스로 점검합니다.

 

저는 스프린트를 점검하는 회고 방법으로 KPT 프레임워크를 주로 사용했습니다.

• Keep 현재 만족하고 있는 부분이자, 앞으로도 유지하면 좋을 부분
• Problem 불편하고 아쉬운 부분, 문제라고 생각되는 부분
• Try Problem을 해결할 수 있도록 당장 실천해보았으면 하는 부분

KPT 회고를 진행할 때 즉석에서 자유로운 의견을 표출하는 것도 좋지만, 그때그때 하고 싶은 말이 잘 떠오르지 않아 타이밍을 놓치는 경우도 많이 보았습니다. 그래서 미리 KPT에 하고 싶은 말을 간단히 메모해서 올 수 있도록 가이드하는 방법을 사용했을 때, 회고 미팅이 좀 더 효율적으로 돌아갔던 경험이 있습니다.

출처 : https://sdg.neuromagic.com/en/retrospective-framework/

 

스프린트 예시

이제 스크럼 이벤트들을 포함한 2주짜리 스프린트 스케줄 예시를 들어보겠습니다.

1. 스프린트 플래닝을 통해 이번 스프린트에 진행할 백로그를 선정하고, 백로그를 완료하기 위한 작업 목록을 쪼개어 배분합니다.
2. 백로그가 바로 기능 개발이 가능할 정도로 구체화되었다면 백엔드부터 설계 및 개발을 시작합니다. 프론트엔드는 디자인 작업물이 나온 뒤 작업이 가능하기 때문에 상대적으로 작업 시작 시점이 늦을 수 있습니다.
3. 스프린트 기간 동안 데일리 스크럼을 통해 지속적인 커뮤니케이션으로 목표 달성을 위한 최적화 작업을 진행합니다.
4. 백엔드와 프론트엔드 모두 개발이 완료되면 QA를 진행합니다.
5. 스프린트 리뷰를 통해 스크럼 팀원과 이해관계자가 실제 동작하는 백로그를 확인하고 다음 스프린트에 대해 논의합니다.
6. 스프린트 회고를 통해 이번 스프린트에서의 KPT를 논의하고 스프린트를 종료합니다.

 

위의 프로세스를 보면서 느끼셨겠지만 스프린트 기간을 온전히 기능 개발로 활용하기 위해서는 당장 개발을 시작할 수 있을 정도로 구체적이고 완성에 가까운 백로그와 프론트엔드 디자인 작업물이 필요합니다. 따라서 저는 다음 스프린트를 위한 백로그 작업과 프론트엔드 디자인 작업을 이번 스프린트 기간 중에 완성하는 것을 지향하고 있습니다.

 

스크럼 산출물

스크럼의 산출물은 여러 의미로 해석되고 있지만 저는 고객에게 유의미하게 전달하는 제품의 가치의 의미로 사용하고 있습니다. 그리고 이 제품의 가치는 주로 제품 그 자체 혹은 제품의 특정 기능으로 제공됩니다. 결론적으로 우리는 고객에게 유의미한 효용을 제공하는 제품 혹은 기능을 스크럼 산출물이라 하고 이를 스프린트라는 방식을 통해 만들어낸다고 할 수 있습니다.

 

스크럼 산출물의 측정 가능함과 이를 통한 정보의 투명성을 팀과 조직에게 제공하는 것은 매우 중요합니다. 경영학의 아버지 피터 드러커 옹께서 하신 "측정할 수 없는 것은 관리할 수 없다."라는 말처럼요. 그래서 스크럼 가이드에서는 각 산출물이 다음의 약속을 담고 있다고 말합니다.

• 프로덕트 백로그에는 프로덕트 목표가 있다.
• 스프린트 백로그에는 스프린트 목표가 있다.
• 가치의 증가분(산출물)에는 완료의 정의가 있다.

 

프로덕트 백로그

프로덕트 백로그는 프로덕트의 가치를 증가시키기 위한 아이디어를 우선순위에 따라 정렬한 목록입니다. 프로덕트 백로그는 스크럼 팀이 실행하는 업무를 제공하는 유일한 출처로 기능합니다. 프로덕트 백로그는 프로덕트 가치의 증가에 도움이 되는 아이디어라는 판단이 들면 언제든지 추가할 수 있어야 합니다. 

 

추가된 프로덕트 백로그는 정제라는 단계를 거치는데, 이는 프로덕트 백로그 아이템을 구체적으로 정의하여 보다 명확하게 일을 할 수 있는 작은 단위로 쪼개는 것으로 구체적인 설명, 우선순위에 따른 순서 정렬, 일의 크기와 같은 세부 사항들을 더해가는 활동입니다. 개발자들은 프로덕트 백로그 아이템의 크기를 결정하는 데 책임을 가지고 임해야 하고, 프로덕트 오너는 프로덕트 백로그가 어떻게 가치를 증가시키는지에 대한 명확한 설명을 통해 스크럼 팀의 이해를 도와야 합니다.

프로덕트 목표

프로덕트 목표는 스크럼 팀이 목표로 삼아 계획하는 프로덕트의 미래 상태를 말합니다. 프로덕트 목표는 프로덕트 백로그의 구성요소 중 하나이며 프로덕트 백로그의 나머지는 "무엇"이 프로덕트 목표를 충족시킬 것인지에 대한 정의로 구성됩니다.

 

프로덕트 목표는 스크럼 팀의 장기적인 목표입니다. 따라서 스크럼 팀은 새로운 목표를 맡기 전에 현재의 목표를 반드시 달성하거나 포기해야 합니다.

 

스프린트 백로그

스프린트 백로그는 프로덕트 백로그 중 해당 스프린트에 구현하고자 하는 가치의 증가분으로 선택한 아이템을 의미합니다. 스프린트 백로그는 개발자들에 의한, 개발자들을 위한 계획으로 개발자들이 스프린트 목표를 달성하기 위해 스프린트 기간 동안 완수하기로 계획한 매우 세부적으로 쪼개어지고 가시화된 업무를 나타내는 청사진입니다.

스프린트 목표

스프린트 목표는 해당 스프린트에서 달성하고자 합의한 유일한 목표입니다. 스프린트 목표는 스프린트 플래닝 이벤트에서 결정되어 스프린트 백로그에 추가되어야 합니다. 스프린트 기간 동안 스크럼 팀은 스프린트 목표를 지속적으로 유념하면서 일을 해야 합니다. 만약 급한 이슈나 hotfix 버그가 발생하여 스프린트 도중 기대와는 다른 업무가 수행되고 있다면 스크럼 팀은 스프린트 목표에 영향을 주지 않는 선에서 해당 스프린트의 스프린트 백로그 범위를 조율해야 합니다.

 

가치의 증가분(산출물)

가치의 증가분은 최종적인 프로덕트 목표를 달성하기 위한 디딤돌입니다. 매 스프린트마다 스크럼 팀이 만들어낸 가치의 증가분은 누적되어 증가하여 전체 가치의 총량을 크게 만듭니다. 스크럼 팀은 모든 가치의 증가분들을 더해가는 것뿐만 아니라 모든 증가분들이 합쳐졌을 때, 정상적으로 작동하는 것을 보장할 수 있을 만큼 철저하게 검증해야 합니다. 

 

스프린트에서 목표는 하나지만 가치의 증가분은 여러 개가 될 수 있습니다. 가치의 증가분은 스프린트 리뷰 이벤트에 스크럼 팀과 이해관계자들에게 소개됩니다. 단, 스프린트 중 수행한 업무가 완료의 정의를 충족하지 않으면 엄격하게 가치의 증가분에 포함시키지 말아야 합니다.

완료의 정의

완료는 스크럼 팀의 스프린트 동안의 작업이 가치의 증가분(산출물)으로써 인정받은 상태를 표현하는 말입니다. 하나의 프로덕트 아이템이 완료의 정의를 충족하는 순간에 하나의 증가분이 탄생합니다. 이미 팀 혹은 조직에서 사용하고 있는 완료의 정의가 있고 납득할 수 있다면 해당 정의를 함께 조직이 공통으로 사용하는 것이 효율적이겠지만 필요하다면 스크럼 팀은 반드시 프로덕트에 적절한 완료의 정의를 만들 수 있어야 합니다. 저는 기존에 백로그와 테스트 시나리오를 직접 작성하면서 이를 완료의 정의로 활용했는데 현재는 인수 기준 Acceptance Criteria라는 방법론을 공부하고 적용해보고 있습니다.

 

* 인수기준 Acceptance Criteria에 대한 글은 별도로 작성할 예정입니다.

 

마치며

글의 초입에 고백한 것처럼 저는 주니어 시절에 이론적인 토대가 약한 채로 PM 업무를 수행하고 있었는데요, 이론이라는 단단한 토대를 쌓고 업무를 시작한 뒤로 더 가파른 성장을 할 수 있었다고 생각합니다. 스스로에 대한 믿음과 자신감도 높아졌고요.

어깨너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1 & 2를 작성하면서 스크럼을 통해 우리가 얻을 수 있는(얻어야 하는) 효과에 대해 다시 한번 되새길 수 있어 개인적으로도 뜻깊은 시간이었습니다. 

 

 

어깨너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1 보러 가기

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

 

 

북극성 지표(North Star Metric)에 대해 궁금하다면

우리 제품이 성공 중이라는 것을 알 수 있는 방법