경력 입사자의 스크럼 스프린트 적응기 (with Jira software)

⚠️ 본 글은 스크럼 표준 이론을 설명하는 것이 아닙니다.

 

안녕하세요. Dev platform 팀 임진욱입니다.

지마켓의 Jira, Wiki, GIthub, CI/CD 시스템을 담당하고 있습니다.

 

지마켓으로 이직 후, 1년간 업무를 진행하며 스크럼을 사용하는 경험기를 다룹니다.
(👉 스크럼에 대해서 더 알고 싶은 사람은 스크럼 설명 - Jira software 문서를 참고하면 도움이 됩니다.)

스크럼이란?
스크럼은 팀이 일련의 가치, 원칙 및 관행을 바탕으로 작업을 구조화하고 관리할 수 있도록 지원하는 애자일 프로젝트 관리 프레임워크입니다.
스크럼은 팀이 경험을 통해 배우고, 문제를 해결하면서 스스로 구성하며, 얻은 것과 잃은 것을 되돌아보며 지속적으로 개선하도록 유도합니다.

 

 

 시스템 관리 엔지니어로서 연속적으로 이어지는 운영 업무들을 짧은 단위로 목표를 정해서 스크럼을 하는 것이 좋아하지 않았습니다. 억지스레 '완료' 처리를 하게 되는 경우가 생기거나, 연속적인 업무의 경우, 계획한 스프린트에서 끝내지 못하고 다음 스프린트로 연기하는 경우도 있었습니다.

이직 후, 데일리 스크럼을 하는 것을 보고 "여기도 스크럼을 하는구나!" 하고 좋아하지 않았습니다. 하지만 팀에서 프로젝트를 이끌어 가는 것을 보고, 업무를 진행하는데 도움이 될 수 있겠다!라는 생각이 들었습니다. 이러한 생각이 들었던 이유는 아래와 같습니다. 👇

• ⭐️ 팀장님이 회고때 관여를 하지 않습니다. (회고 운영 X, 팀원과 같은 위치에서 참여)
• 플래닝 때 백로그 목표와 내용을 명확히 한다.
• 데일리 미팅 시 짧게 진행되도록 노력한다. (스탠딩 미팅)

그럼 실제로 어떻게 일하고 있는지 보여드리도록 하겠습니다.

 

이렇게 일하고 있어요 🧑‍💻

스크럼의 단계는 아래와 같이 진행하고 있으며, 각 단계별로 어떻게 진행하고 있는지에 대해 경험을 공유드리겠습니다.

스크럼 단계

Sprint planning -> Daily scrum -> Sprint review -> Sprint retrospective

스프린트 플래닝

이번 스프린트에서 어떤 작업을 할 수 있으며, 선택한 작업은 어떻게 완료하는가?

 

 위 목적을 달성하기 위하여 팀원들과 시간을 들여 논의를 합니다. 저희 팀은 스프린트를 진행할 때, 스크럼 단계에 따라 작업을 할 수 있도록 Jira board를 활용합니다.

 

 스프린트가 달성해야 하는 목표 항목을 백로그 로 생성합니다. 계획을 잘하기 위해서는 백로그를 긴 시간을 할애하여 생성하여야 합니다. 백로그 생성 시 알 수 없는 부분이 많거나 위험도가 높은 작업을 백로그로 등록하는 것은 지양해야 합니다. 작업 범위가 크거나 불확실성이 높은 작업은 세분화하고, 다음 스프린트를 위해 작업의 일부를 남겨 두어도 좋습니다.

 

 프로젝트 관리자는 달성해야 하는 목표에 따라 스프린트를 생성합니다. 이때, 목표와 스프린트 기간과 시작일을 설정합니다. 스크럼을 통해 업무를 다년간 하며, 팀 스타일에 맞춰가고 있습니다. 스프린트 기간의 경우도 초기에는 대중적으로 사용하는 2주로 설정하였습니다. 저희 팀의 경우, 2주의 스프린트 기간이 너무 짧다는 의견이 스프린트 회고 때 있었고, 현재는 4주 기준으로 스프린트를 진행하고 있습니다. 즉, 시작일은 월초, 끝나는 시간은 월 말으로 설정되어 있습니다.

 

Jira board에서 스프린트가 생성되면 해당 스프린트에서 달성해야 하는 목표에 맞는 백로그를 스프린트에 등록하면 '스프린트 플래닝'을 위한 준비가 됩니다.

 스프린트 플래닝 회의는 프로젝트에 관여된 모든 사람이 함께 모여 진행합니다. 스프린트 플래닝 회의는 아침부터 오후까지 길게 잡고, 스프린트 목표를 이루기 위하여 백로그를 공유합니다. 형식적인 브리핑이 아닌 함께 하는 팀원들이 업무 내용을 이해할 수 있도록 상세하게 설명을 해야 합니다.

 

 각 이슈마다 업무 설명이 끝난 후, '스토리 포인트'를 설정하게 되는데, '스토리 포인트'는 누가 해당 업무를 처리하는지 관계없이 해당 업무를 처리하는데 얼마큼 시간이 필요할지 생각하여 투표하고, 의견을 종합하여 최종 스토리 포인트를 결정합니다. 저희 팀은 'Planning Poker'를 이용하여 스토리 포인트를 측정합니다.

 이슈마다 '스토리 포인트' 할당이 끝나면, 이슈 담당자를 정합니다. 너무 많은 스토리를 가져오거나, 속도를 과대 평가하거나, 스프린트에서 완료할 수 없는 작업을 가져오지 말아야 합니다. 품질 또는 기술적 부채를 잊지 말아야 할 점입니다.

"자신 또는 팀이 실패할 수밖에 없는 계획을 세우지 말아야 합니다."

 이슈 담당자까지 지정이 완료되고 나면 프로젝트 관리자는 달성가능한 '스토리 포인트'가 할당된 지 확인하고 스프린트를 시작합니다.

데일리 스크럼

데일리 스크럽은 핵심 팀(제품 소유자, 개발자 및 스크럼 마스터)이 매일 아침 참여하는 회의입니다. 진행률을 논의하고 업무 진행을 방해하는 요소를 파악하기 위한 짧은 회의입니다. 참석자들이 회의에 서서 참여하면 회의가 짧게 진행되기 때문에 '스탠드업 미팅'이라고도 불려집니다. 데일리 스크럼에서 중요한 점은 보고 형식이 되면 안 됩니다. 모두가 팀의 상태와 진행률을 알 수 있도록, "우리"라는 개념을 강조합니다.

 

저희 팀은 오전 10시에 회의를 진행하며 아래의 두 가지를 위주로 이야기하고 있습니다.

• 어제 어떤 작업을 했습니다.
• 오늘 무슨 일을 하고 있습니다.
• 어떤 이슈가 나를 방해합니다. (위 두 개의 답변을 하며 함께 공유합니다)

 보고 형식으로 팀장님께 이야기하는 것이 아닌, 참여자들끼리 상황 공유를 하고 도움을 줄 수 있는 경우 의견을 냅니다. 또한 회의가 끝난 후 함께 문제를 해결하는 시간을 가지기도 합니다.

 

스프린트 리뷰

저희 팀은 스프린트를 4주 단위로 하고 있으며, 스프린트 리뷰와 회고는 월 마지막주 화요일에 하고 있습니다. 스프린트 리뷰 포맷은 아래와 같습니다.

 

sprint review

스프린트 리뷰는 스프린트 동안 달성하고자 했던 목표와 "결과물"에 중점을 두고 리뷰를 합니다. 발표자는 스프린트 기간 동안 작업한 내용을 시각적으로 보여주고, 팀원은 피드백과 KPT (Keep, Problem, Try)를 작성해 줍니다.

저희가 하는 것 중, 특이점은 "Story Point Check" 항목이 있는데, 스프린트 회고 때 나온 의견의 결과물로 스토리 포인트를 잘 설정하기 위하여 스프린트 리뷰 때, 설정한 스토리 포인트와 실제 본인이 작업하며 느낀 스토리 포인트에 대한 확인을 하고 있습니다. (선택적으로 하고 싶은 사람만 하고 있습니다)

 

스프린트 회고 ⭐️⭐️⭐️

스프린트 회고는 업무 관련된 회고가 아닌, 스프린트를 진행하면서 작업방법, 프로세스, 환경 등 교훈을 정리하고 팀 프로세스 개선을 위한 활동입니다.

 

스프린트가 성숙해지기 위해서는 회고가 가장 중요하다고 생각합니다. 개인적으로 팀이 스크럼에 잘 적응할 수 있었던 이유는 스프린트 회고 문화를 잘 정착시켰기 때문이라 생각됩니다.

 

• 직책자(팀장/PM)의 주도로 회고를 하지 않는다.
• 회고 진행자는 팀원이 돌아가며 진행한다.
• 팀원들의 적극적인 참여가 필요합니다.

 

제가 생각하는 저희 팀이 회고를 잘 적응할 수 있었던 이유입니다. 한국의 문화적 특성상 직책자가 주도하는 회의에서는 자유로운 토론이 되지 않는 경우가 있습니다. 보통 스크럼 마스터가 회고를 진행하는데, 한 명의 고정된 진행자가 있을 경우, 팀원의 참여도가 점점 떨어질 수 있습니다. 팀원이 돌아가며 회고 진행을 할 경우, 진행자는 회고를 준비하고 이끌어 가기 위해 학습합니다. 이런 경험이 쌓이며 성숙된 문화가 정착되고 있습니다.

회고 툴은 회고 진행자가 전적으로 준비해오고 있습니다. 고정된 툴을 사용해야 하는 것도 아닙니다. 회고 툴을 사용한 것 중, 제일 좋았던 툴은 retrotool 입니다.

스프린트 회고

회고 진행자는 retrotool 에서 아래 칼럼을 생성하여 회고를 준비합니다.

• [잘한 점/성공의 원인] : 칭찬하거나, 스프린트 진행 중 긍정적이었던 부분
• [부족한 점/장애물] : 부족하거나, 스프린트 진행 중 방해 요소
• [개선 방법]
• [개선방법(누적)] : 누적된 개선 방법 (문화로 정착할 경우 졸업)

진행 방법은 아래와 같습니다.

절차	내용	시간
아이스브레이킹	팀원과의 대화	5 ~ 10분
개선방법 (누적) 공유
잘한점	잘한점 작성	5분
공유	작성 내용 확인 및 공유
부족한점	부족한점 작성	5분
공유	작성 내용 확인 및 공유
개선점	개선점 작성	5분
공유	개선점 공유 및 평가

 

 회고에 자유로운 대화를 하기 위하여 회고에 앞서 아이스브레이킹을 진행합니다. 밸런스 게임이나 이상형 월드컵 등으로 자유로운 분위기로 대화를 할 수 있는 환경을 준비합니다.

 

 

 지금까지 누적된 개선방법(누적)을 공유하고, 이번 스프린트에 잘한 점을 '5분'동안 각자 작성합니다. retrotool 툴은 포스트잇 형태로 익명으로 작성 가능합니다. 업무 내용 외 스프린트를 진행하며, 칭찬하고 싶은 사람이나 좋았던 것에 대한 작성을 합니다. 팀원들이 작성한 내용을 보고, 공감이 될 경우 포스트잇을 클릭(LIKE)합니다. 회고 진행자는 공감이 많이 된 순으로 작성된 내용에 대해서 팀원들의 의견을 듣는 시간을 가집니다. 이때, 꼭 작성자가 본인이 쓴 내용을 이야기하지 않아도 됩니다. 부족한 점도 좋은 점과 동일하게 작성하고 공유합니다.

 잘한 점과 부족한 점에 대한 공유가 끝나면, 팀원들이 '5분'간 각자 개선점을 작성합니다. 개선점 작성이 끝나면 진행자는 개선점을 공유합니다. 누적된 개선 사항 중, 이미 문화로 정착되었거나 불필요하다고 느낄 경우 '졸업'을 시키고, 새로운 개선 사항을 추가해 줍니다. 회고에서 나온 개선사항은 언제든 팀원들이 볼 수 있는 공간에 정리해 둡니다. (저희의 경우 주간회의록 제일 상단에 정리해 둡니다.)

 

모든 회고가 완료되면, 회고 진행자는 회고록을 작성합니다. 📃

 

 

스프린트 종료

프로젝트 관리자는 지정된 날짜에 스프린트를 종료를 팀원에 알리고 종료를 합니다.
그 후, 새로운 스프린트를 작성하고, 플래닝을 준비합니다.

 

맺음말

스크럼 이론이 존재하고, 이를 지원하는 Tool로 지원을 받을 수 있습니다. 중요한 점은 협업하는 팀이 목표를 달성하기 위하여 사용하는 방법론이므로 정답이 존재하지 않는다는 것입니다. 회사마다 팀마다 맞는 문화를 만들어 협업 및 업무에 도움이 되는 방법을 찾아가는 것이 좋습니다.

 

참고 자료

용어 설명

백로그(Backlog) : 프로젝트 관리, 소프트웨어 개발, 업무 관리 등 다양한 분야에서 사용되는 용어로, 완료되지 않은 작업 항목들의 리스트나 목록을 가리킵니다.
스크럼 마스터 : 스크럼의 전문가로 스크럼 프레임워크를 따르도록 보장합니다

 

참고 문서

• 스크럼과 스프린트
• 스크럼 설명 - Jira software
• 스프린트 계획
• 데일리 스크럼
• 스크럼 마스터
• 회고