본문 바로가기

Project Management/Agile Scrum with JIRA

[Chapter 6] JIRA 스프린트(Sprint) 관리 - (1) 스프린트 사전 계획

jira board image

 

스프린트를 준비해 봅시다

이번 챕터에서는, 본격적으로 스프린트(Sprint)를 준비하고 수행하는 전반적인 프로세스를 다루어 볼 예정입니다. 사실 스프린트는 어렴풋이 일감을 쪼개 단위를 만들고, (상대적으로) 짧은 기간 수행하여 완료하는 과정을 거친다는 것을 알고 계실 것입니다. 

 

하지만 애자일 스크럼 프레임워크의 주요 업무 수행 단위 개념인 만큼, 알아두어야 할 내용도 많고 본인이 PO이거나 스크럼 마스터 포지션의 역할을 수행하고 있다면 디테일한 체계를 익혀둘 필요가 있습니다. 여기 오신 여러분들이 JIRA 안에서 [스프린트 생성] / [스프린트 완료] 버튼 클릭하는 법을 몰라서 오신 것이 아니기 때문이죠(^^;)

 

이번 챕터의 아티클들을 통해서 '프로젝트, 그리고 프로덕트를 관리하는 사람'으로서 가져야 할 일종의 기본소양들을 살펴가며 JIRA에서의 스프린트 관리 방법을 살펴보겠습니다.

 

 


 

초기 계획(Baseline)을 세운다는 것의 의미

앞서 우리는 만들어야 할 프로덕트(product)에 대한  로드맵을 짜고 백로그 아이템들을 수립해 두었습니다. 여기까지는 "우리는 무엇을 해야 하는가?"에 대한 계획을 세운 상태입니다. 이제부터는 "어떻게 실행할 것인가?"를 계획하는 단계입니다.

 

여기서 인지해둘 원칙은 [초기 계획은 바뀌는 게 당연하다] 입니다. 초기에 완벽한 계획을 세우려는 목표를 가져서는 안 됩니다. 최대한 꼼꼼하게 초기 계획을 짜되, 실제로 수행을 해나가면서 상황과 여건에 따라 바뀌는 계획을 관리하고 이를 초기 계획과 비교하며 일정과 자원을 관리해야 한다는 원칙을 가져야 합니다. 

 

그러므로 스프린트 계획을 수립하고 관리할 때는 초기 계획을 설정하는 단계 / 프로젝트의 진척 사항을 관리하는 단계를 구분하고, 단계에 맞는 역할을 수행해야 할 것입니다. 

 

 

언제나 예상치 못한 상황은 벌어지기 마련입니다

 

 


 

 

스프린트 계획 회의를 준비해 봅시다

현재 우리는 일감들도 찾아 두었고, 업무를 담당할 팀원도 구성이 되어 있는 상태입니다(그렇게 가정해 봅시다). 그럼 스프린트 계획 회의는 왜 하는 것일까요? 중요한 내용이므로 강조하기 위해서 당연한 이야기를 아래와 같이 정리했습니다.

 

스프린트 계획 회의는 해당 스프린트에서 다음을 결정하기 위해 하는 것이 목적으로 합니다.

 - 목표는 무엇이며 
 - 무엇을 만들 것인지
 - 어떻게 진행해 나갈 것인지

 

그럼 이 스프린트 계획 회의에는 누가 참석해야 할까요? 

스프린트 계획 회의 참석자는 다음과 같습니다. 

  - 프로덕트 오너(Product Owner)
  - 스크럼 마스터(Scrum Master)
  - 스크럼 팀원
  - 관련 분야의 전문가

 

스프린트 계획 회의의 준비물도 살펴봅시다.

스프린트 계획 회의 준비물

  - Product Backlog
  - 팀 속도 / 역량 측정 데이터
  - 프로젝트의 제약사항, 특이사항
  - 프로젝트에서 가정해야 할 요건들

 

 


 

스프린트 계획 회의의 산출물

스프린트 계획 회의를 통해서 어떤 것들을 결정하고 완결된 상태로 산출해야 할까요? 하나씩 짚어봅시다. 

 

우선 스프린트의 목표를 확정해야 합니다. 이 스프린트는 왜 진행하는가? 그리고 이를 통해서 어떤 비즈니스 가치를 만들어 낼 수 있는지를 설명할 수 있어야 합니다. 또한 이를 통해서 스크럼 팀원들에게 동기를 부여하고 동시에 어떤 결과를 냈을 때 이 스프린트를 완료했다고 할 수 있는지 정의해야 합니다. 이를테면, 어떤 버전을 앱스토어에 출시한다! 와 같은 구체적인 목표 말이죠.

 

그리고 해당 스프린트의 백로그를 산출해야 합니다. 우리는 앞선 아티클에서 백로그의 정의에서 Product Backlog와 Sprint Backlog가 구분된다는 이야기를 얼핏 했었습니다. 여기서 산출되는 것이 바로 Sprint Backlog(스프린트 백로그)인 것입니다! 즉 프로덕트 백로그로서 정의된 일감들 + User Story + Task들에 대해서 세분화시켜 Subtask를 정의하고 해당 스프린트에서 수행할 일감들을 정의해야 합니다. 

 

마지막으로, 스프린트의 마일스톤을 산출해야 합니다. 즉 이번 스프린트는 얼마나 걸릴 것인지 기간을 결정하고, 그다음 진행사항 체크를 위한 데일리 스크럼의 시간과 장소 마지막으로 스크럼 리뷰와 회고를 진행할 시간과 장소를 결정합니다. 

 

 


 

그럼 지금부터는 스프린트 계획 회의를 통해서 수립된 세분화된 백로그(subtask) 등록과 우선순위 설정, 작업시간 추정치 설정과 담당자 배정을 JIRA에서 진행해 보겠습니다. 

 

하위 작업(subtask) 등록

우선 스프린트 계획 미팅에서 각각의 백로그에 대한 논의가 이루어졌다면, 각 이슈에 대한 하위 작업들을 추가로 정의하고 등록합니다. 

 

register a subtask
개별 백로그 별 하위 작업(subtask) 등록

 

위와 같이 백로그 메뉴에서 개별 개별 이슈를 선택하고, [하위 작업 생성]을 클릭하면 아래에 [하위 작업] 메뉴가 출력됩니다. 여기에 작업 이슈 사항을 기입하고 만들기를 선택하면, 해당 이슈의 하위 작업이 생성됩니다. 이 하위 작업은 개별 백로그 아이템과 거의 비슷하게 다룰 수 있습니다. 다만, 특정 백로그 아이템에 귀속된다는 차이점이 있죠.  

 

 

우선 순위, 예상 시간 작성

 

시험 삼아 [회원 가입이 가능하다]라는 이슈 아래에 [로그인 프론트 페이지 개발]이라는 하위 작업을 생성해 두었습니다. 이 이슈를 클릭하면, 기존 백로그 아이템과 마찬가지로 세부 정보를 선택할 수 있죠. 여기에서도 마찬가지로 작업의 우선순위 / 그리고 예상 시간을 작성합니다. 

 

 

그러고 나서 해당 하위 작업에도 [담당자]를 클릭해 할당해주면 기본적인 스프린트 전 백로그 관리 작업은 마무리된다고 생각해주시면 됩니다. 남은 백로그 아이템도 검토하여 위와 같은 절차를 반복해주면 됩니다. 물론! 상황에 따라 이 프로세스 자체는 유연하게 운영하셔도 좋습니다. 다만, 이러한 구성 요소가 있다는 점을 먼저 숙지하고 대응하셔야 한다는 점을 잊지 마세요.