팀에 맞게 Jira로 스크럼 관리하기

들어가면서

저희 개발팀에서는 이전부터 스크럼을 운영하고 있었습니다. 관련 툴로는 Trello, Asana, Notion 등을 사용해보았습니다. 결국 어떤 툴들도 뭔가 하나씩 부족하다는 느낌을 받았고, Jira로 옮겨서 사용하고 있었습니다. Jira로 옮겨가면서 한번 규칙을 다같이 정했지만 시간이 꽤 흐르고 업무 방식들도 조금씩 바뀌면서 조금씩 흐지부지되었습니다. 그래서 다시 재정비를 해야겠다고 생각했고, 이번에 여러 글들을 읽으면서 재정비를 하고 팀에 적용한 과정을 공유합니다.

이슈

이슈 타입은 지라(JIRA) 기반으로 소개합니다.

에픽 (Epic) : 에픽은 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 업무의 큰 틀. 하나의 Sprint에 걸쳐서 끝나지 않고, 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합. 주로 Major Feature들을 중심으로 정의합니다. 서비스의 마일스톤에 해당합니다.
스토리 (Story) : 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것입니다. 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋습니다. 예) [(역할을 가진) 사용자]는 [행위 / 목표]를 수행하여 [이유]를 한다. 스토리는 대부분의 경우 서브 태스크가 있습니다.
디벨롭 (Dev): 사용자와는 직접적으로 관계되지 않는 개발과 관련한 업무
버그 (Bug): 서비스에서 발생하는 문제점 또는 리포팅된 버그
문서 (Doc): 개발과 구현에는 직접적으로 관련이 없는 문서작성 등의 문서 업무
서브 태스크 (Sub-task): 스토리의 하위 작업, 또는 Dev의 하위 작업. 스토리 또는 Dev를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업
이슈들의 가능한 상관 관계

Epic
 ├── Story
 |     └── Subtask
 ├── Dev
 |     └── Subtask(option)
 ├── Bug
 └── Doc

[Epic 없음]
     Story
      └── Subtask
     Dev
      └── Subtask(option)
     Bug
     Doc

Example

에픽과 스토리는 주로 PO가 작성합니다.

로드맵에는 에픽을 기록한다. 이 때, '...으로서'를 반드시 기재하도록 한다. 해당 에픽의 출처와 목적을 확인하기 위함이다.
- ex-1 : 사용자로서, 블록 코딩 프로젝트를 공유하는 웹사이트가 필요합니다.
- ex-2 : 개발자로서, 백엔드 개편에 따른 어드민 페이지 수정이 필요합니다.
- ex-3 : 세일즈팀으로서, 라이선스를 발급하는 시스템이 필요합니다.
에픽의 하위 스토리 또는 에픽 없는 스토리를 백로그에 작성할 때는 [(역할을 가진) 사용자]는 [행위 / 목표]를 수행하여 [이유]를 한다. 처럼 비즈니스 언어로 작성합니다.
- ex-1 : 어드민 사용자는 라이선스의 정보를 입력하고 라이선스 키를 발급한다.
- ex-2 : 대시보드 사용자는 라이선스 키를 입력해서 사용 가능한 라이선스를 얻는다.
- ex-3 : 사용자는 회원가입하고 로그인할 수 있다.
Dev와 Sub-task을 작성할 때에는 개발자가 작성하는대로 작성하면 된다.
- ex-1 : 어드민에서 발급한 라이선스 목록 페이지 개발
- ex-2 : 라이선스 키 발급 API 개발
- ex-3 : 도메인 구매

이슈 내용 작성

이슈에 작성해야하는 내용을 설명합니다.

업무 배경과 TO BE를 간략하게 1줄로 작성합니다. 경우에 따라 생략할 수 있습니다.
Assignee에 해당 업무를 진행할 담당자를 할당합니다. 스토리포인트 미팅에서 주로 결정합니다.
Reporter에는 해당 업무의 경과를 보고받을 보고자를 할당합니다.
Labels에 업무와 적절한 레이블을 작성합니다.
Priority는 업무의 우선순위를 결정합니다. 스토리포인트 미팅에서 주로 결정합니다.
Story point estimate는 업무의 예상되는 개발 기간인 스토리 포인트입니다. 스토리포인트 미팅에서 주로 결정합니다.
Due date는 업무의 마감 기간입니다. 본인이 예상하는 업무의 데드라인을 반드시 설정합니다.
Start date는 업무를 시작한 날입니다. JIRA에서는 업무를 칸반보드의 'IN PROGRESS'로 옮기면 자동으로 할당됩니다.

칸반 보드 관리

칸반 보드에서 GROUP BY를 Sub-task 로 보면 서브 태스크를 쉽게 드래그앤 드랍으로 관리할 수 있습니다.

깃헙과 연동하기

브랜치를 생성할 때, '이슈 번호'로 브랜치를 생성합니다.
- ex) MWEB-172
커밋을 생성할 때, '이슈 번호'를 앞에 붙이고 커밋 메세지를 작성합니다.
- ex) (MWEB-172) 라이선스 키 발급 버튼 추가
PR을 생성할 때, '이슈 번호'를 앞에 붙이고 PR 메세지를 작성합니다.
- ex) (MWEB-172) 라이선스 키 발급 페이지 개발

스프린트 운영

그루밍 (스프린트 도중의 월요일)

다음 스프린트에 들어가기 전에 PO가 다음 스프린트에 개발할 기능에 대해서 대략적으로 리뷰하는 행위 (스프린트 진행 중에 일어남) - Epic or Story

[WHY]

다음 스프린트에 대한 가시성 확보 (미리 생각할 시간을 줍니다.)
개발 개시 전 리뷰를 통해서 개발 가능성, 기획상 구멍을 찾아서 수정할 시간을 갖음

[HOW]

1시간 정도로 사용자 스토리나 UX 프로토타입을 리뷰
가급적 실제로 돌아가는 UX 목업이 좋음 (애니메이션 복잡도 등을 미리 예측 가능)

스프린트 계획 (스프린트 시작날의 월요일)

이번 스프린트에 진행할 Epic과 Stroy의 Sub-task 또는 Dev, Bug, Doc 업무를 개발자들과 함께 리스트업 합니다.
업무의 우선순위를 결정하고(대부분 보통), 스토리 포인트를 플래닝 포커를 통해 계획합니다.
업무의 담당자를 할당합니다.

플래닝 포커 : 팀원들은 각자 숫자가 쓰여진 카드를 골라 다른 팀원들에게 보여줌으로써, '스토리 점수'를 매길 수 있습니다. 만약, 팀원들간의 '스토리 점수'가 현저하게 차이가 난다면, 해당 개발이 왜 그렇게 시간이 오래 걸리는지에 대해 의논해야 합니다. 팀원 마다 알고있는 지식이 다르기 때문이거나, 다른 시각으로 업무를 해석하고 있기 때문입니다.
최대 3일 이내의 작업으로 업무가 분리되어야 합니다.
고려해야할 사항
- Task 설정시 구체적인 종결 행위를 기반으로 Task 설정 하는것이 좋습니다.
- Task 설정시 분석,설계 / 구현 / 테스트 → 1:1:1 의 리소스 분배가 좋습니다.
- 주요 Task에 대해서는 어떤 형식으로든지 리뷰를 하는것이 좋습니다.
- Task 기간 설정시 20%의 버퍼를 두는것이 좋습니다.

데일리 스크럼

데일리 스크럼 회의는 매일 오전 11시 15분에 10분 가량 진행합니다.
데일리 스크럼 회의에서 다음과 같은 내용을 공유하면 된다.
- JIRA를 기준으로 어제 처리한 업무
- JIRA를 기준으로 현재 처리하고 있는 업무
- JIRA를 기준으로 현재 업무 다음에 처리할 업무
- 업무를 처리하는데 있어 발생한 이슈, 원인, 이유, 해결 방안
- 발생한 긴급 이슈에 대한 내용 공유

스프린트 리뷰 및 회고

업무는 본인이 수행한 업무의 구현이 테스트까지 완료되었을 때 업무가 종료되어야 합니다.
팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다
스크럼 팀이 상의하여 스프린트 성공 기준을 정의합니다.
- 받아들일 수 있는 기준
- 내부 사용 테스트 통과
- 스프린트의 성공을 기준으로 스프린트 목적에 대한 점수를 매겨봅니다.
- 서로 축하하고 공유합니다.
스프린트 회고
- Stop doing
- Keep doing
- Start doing