[Chapter 4] JIRA에서 백로그 작성하기 - 백로그(Backlog)가 뭐야?(상)

 

대체 그놈의 백로그(Backlog)가 뭔데?

우연히 어떤 분에게 백로그가 무엇인지, 설명할 기회가 있었습니다. 나름대로 그 개념을 간단하고 이해하기 쉽게 설명을 드렸는데, 돌아오는 질문이 "그래서 요구사항이란거죠?" 였습니다. 

 

반은 맞고, 반은 틀린 대답이라고 볼 수 있습니다. 애초에 이 분은 애자일 프로세스 전반에 대한 이해도가 전혀 없는 상황이었기 때문에, '뭐 이리 간단한 개념을 어렵게 설명하지?'라는 의문이 들 수밖에 없었을 겁니다. 

혹시 이 글을 읽는 분들 중에서도 JIRA도 처음 써보고, 구글에 [백로그 뜻]만 단편적으로 검색해서 보시는 분들도 있을 것입니다. 만일 그렇다면 백로그 개념이 이해가 안 가는 것도 당연하다는 말씀을 드리고 싶습니다. 

 

단어의 정의를 한 번에 풀이해서 이해하시기 보다는, 반복해서 말씀드리지만 프로세스 전반에 대한 이해 속에서 이해해야 하는 개념이니 이전의 글들을 가볍게 읽어보시면서 숙지하셨으면 합니다. 

 

 

---

 

Product Backlog

우리가 JIRA, 애자일 프레임워크에서 사용하는 주요 백로그는 Product Backlog 개념입니다. Product Backlog는 제품기능 / 수정 / 변경 / 기술 개선과 관련된 세부적인 요구사항을 의미합니다(네, 요구사항 맞습니다). 이 요구사항들을 통해 스크럼 팀 멤버들에게 실질적인 일감을 생성하고 할당하게 되기에 매우 중요한 개념으로서 항상 언급되는 것입니다. 

 

Product Backlog로 정리된 요구사항들은 스크럼 멤버들의 작업을 점차 구체화하고, 개발 사항을 점점 고도화 시키는 개념이면서 스프린트 / 릴리즈 과정에서의 우선순위 산정과 작업량 측정의 기준점이 되죠. 본인이 PO라면, 이 백로그 아이템(이슈)를 정리해 일감으로서 완결된 형태로 정리하고 이와 관련된 의사결정을 할 수 있는 환경을 구축하는 것이 가장 중요한 업무입니다. 

 

아마 프로젝트가 막 킥오프를 마친 상태이거나, 제품 방향성이 잡혀있지 않은 상태라면 이 백로그는 매우 추상적인 상태일 것입니다("딱! 클릭하면 원하는 제품이 추천되는 기능!" / "목소리만 녹음하면 자동으로 원하는 영상을 만들어주는 앱 어때?") 이를 정제하여 작업으로서 가치 추정이 가능한 백로그를 만들고 정리하는 작업을 Product Backlog Grooming이라고 합니다. 

 

 

---

 

빌 웨이크의 INVEST

개념적으로 백로그를 정의하다보면, 이 백로그 아이템들에 대해서 User Story 형식으로 정리한다는 개념을 접하게 되는 경우가 있는데요, 이 부분은 백로그로서 가져야 하는 개별 아이템들의 조건을 참고하는 정도로 이해하시고 넘어가셔도 좋습니다. 지나치게 지엽적인 개념에 얽매이실 필요는 없습니다. 

 

좋은 User Story는 

- Independent : 독립적이고
- Negotiable : 협상이 가능하며
- Valuable : 가치 있고
- Estimable : 추정 가능하며
- Small : 적절한 규모이며
- Testable : 확인이 가능한 것이어야 한다.

 

참고로 이쯤되면 "Product Backlog가 있으면, 다른 Backlog도 있나?"라는 생각이 들 것입니다. 네, Sprint Backlog가 있습니다. Product Backlog는 - 우리가 무슨 일을 할 것인가 - 에 초점을 맞춘 백로그라면 Sprint Backlog는 - 그 일들을 어떤 방식으로 처리할 것인가 - 에 집중한 것입니다. PO 레벨에서 일감을 정리하는 관점에서 대부분 백로그라 함은 Product Backlog를 의미한다고 생각해주시면 됩니다. 

 

 

---

 

백로그 작성 프로세스

다음 아티클에서는 Chapter 0에서 살펴본 백로그 생성 및 등록 절차를 상세히 다뤄볼 예정입니다. 우선은, 백로그 등록 프로세스를 먼저 숙지해 둡시다. JIRA에서 툴을 클릭해 무언가를 등록하는 작업 자체는 크게 어렵지 않습니다. 이러한 기능적인 사용 방법은, 업무 프로세스가 이해된 상태에서 의미를 갖는다는 점을 다시 강조하도록 하겠습니다. 

 

1. 초기 Proudct Backlog를 수집한다. 다양한 이해관계자들의 의견을 취합한다.
2. 취합된 Backlog를 Grooming하여 정리한다.
3. 이를 User Story, Task, 버그와 같은 이슈 형태로 분류한다.
4. 이슈를 Product Backlog에 개별적으로 등록해 일감으로 만든다.
5. 각각의 Backlog를 Epic에 할당한다.
6. 우선순위를 부여한다.
7. Story Point를 부여한다.

 

이제 다음 아티클에서는 실제 JIRA에서 백로그 등록 과정을 따라해 보도록 하겠습니다.