백로그
🤤 시니어 개발자 : 일단 백로그에 두죠.
🙂 주니어 개발자 : 와, 그러면 나중에 고칠 수 있는 거죠?
🤤 시니어 개발자 : …
🥲 주니어 개발자 : 고칠 수 있는 거죠? 맞죠?
백로그란
백로그 (backlog) 란 개발 및 업무 관리에서 완료되지 않은 작업들의 목록을 가리키는 말입니다. 아직 완료되지 않은 작업이나 고객의 요구사항 등이 백로그에 들어가게 되죠.
백로그는 back + log 라는 합성어로, 벽난로 뒤에 쌓아둔 통나무 무더기를 뜻하는 단어가 그 어원이라고 합니다. 필요하지만, 일단은 아무렇게나 쌓아둔 상태를 의미한다고 합니다.
백로그는 투두리스트와 비슷합니다. 아직 완료되지 읺은 작업, 이에 대한 설명과 우선순위 등을 포함합니다. 조금 다른 면이 있다면 투두리스트는 개인적이거나 작은 규모의 작업에 대한 내용이라면, 백로그는 주로 팀 단위면서 큰 규모의 작업에 대한 내용이라는 점입니다.
백로그의 구성 요소
백로그는 미완료 작업의 명칭, 작업에 대한 설명을 포함하여 이 작업에 대한 의사결정을 도울 항목들을 함께 작성해주는 게 좋습니다.
| 구성 요소 | 설명 |
|---|---|
| 작업 이름 | - 현재 완료되지 않은 작업의 이름입니다. - 명료하고 긍정적인 언어로 작성하면 좋습니다. |
| 작업 설명 | - 작업에 대한 상세한 설명이 필요합니다. - 의사결정자나 관련자가 쉽게 파악할 수 있게 명료하게 작성합니다. |
| 우선 순위 | - 작업의 필수 여부, 중요도나 긴급도에 따른 우선 순위를 정합니다. - 이러한 우선 순위를 정하는 것은 의사결정에 큰 도움이 됩니다. - 우선순위 선정에는 Moscow, RICE Score 등 방법론이 도움이 됩니다. |
| 상태 | - 현재 진행중인지, 완료했는지, 착수 전인지 상태를 업데이트 합니다. |
| 구현의 난이도 | - 작업을 구현하는 데 있어 난이도를 작성하면 의사결정에 도움이 됩니다. |
| 예상 소요 기간 | - 구현의 난이도와 함께 예상 소요 기간은 의사결정에 도움이 됩니다. |
| 작업 간 공생관계 | - 어떤 작업을 했을 때 어떤 작업이 영향을 받는지 - 또는 어떤 작업을 위해서는 필수적으로 수행되어야 할 작업이 있는지 등 - 작업 간의 공생관계를 적어주면 좋습니다. |
백로그 작성과 관리
작성 툴에 제한이 없다
백로그를 작성하는 방법이나 툴은 정해져있지 않습니다. 파일로 관리하거나 노션, 슬랙, 디스코드 등의 툴들을 이용할 수도 있습니다. 그저 좋은 프로그램을 만들 수 있게 하기 위해 가장 적절한 툴을 이용하는 게 좋습니다.
우선 순위의 설정
우선순위 설정에 있어 여러 방법론을 참고하면 도움을 받을 수 있습니다. 이번 포스팅에서는 대표적인 방법론으로 Moscow와 RICE Score에 대해 간략히 설명해보겠습니다.
(1) Moscow
작업 항목을 Must Have (필수적인), Should Have (해야 할 것), Could Have (가능하다면), Won’t Have(할 필요 없음) 네 가지로 분류하면서 작업의 중요도를 좀 더 명확하게 표현할 수 있습니다.
| 항목 | 설명 |
|---|---|
| Must Have | 필수적으로 해야 하는 작업 |
| Should Have | 중요하지만 필수는 아닌 작업 |
| Could Have | 가능하다면 해야 하는 작업 |
| Won’t Have | 하지 않아도 되는 작업 |
(2) RICE Score
우선순위를 선정하기 위한 가치 평가 방법으로, Reach(도달 범위), Impact(영향), Confidence(신뢰도), Effort(노력) 네 가지 항목으로 Rice 점수를 산정합니다. 쉽게 말해, 투입한 노력에 상응하여 얻을 수 있는 성과나 프로젝트에 대한 영향도를 산정하는 방법입니다.
| 항목 | 뜻 | 설명 |
|---|---|---|
| Reach | 도달 범위 | - 특정 기간 동안 해당 작업(기능)이 얼마나 많은 사용자에게 영향을 미칠지 - ex. 매달 몇 명의 사용자가 해당 기능을 사용할지 - 주로 수치로 평가됨 |
| Impact | 영향 | - 해당 작업(기능)이 사용자에게 영향을 미치는 영향도 - 보통 정성적 요소이나 - 정량적으로는 “큰 영향”(3점) “중간 영향”(2점) “작은 영향”(1점) 과 같이 평가도 가능 |
| Confidence | 신뢰도 | - 산정한 Reach와 Impact가 얼마나 신뢰할 수 있는 자료인지 - 예를 들어 시장조사 혹은 고객 인터뷰를 통해 한 평가일수록 Confidence가 높음 - 이것으로 불확실성이 높은 작업은 낮은 우선순위로 두는 데 도움 됨 |
| Efford | 노력 | - 해당 작업을 하는 데 필요한 시간과 리소스 - 프로젝트에 투입되는 시간이나 인력에 대한 정성 및 정량적 자료 |
백로그를 잘 관리하기
작업의 명칭은 명료하고 긍정적인 언어로
백로그는 당장 처리하기 어려운 작업들이 쌓인 만큼, 기피되거나 중요도가 낮은 업무로 인식되어 외면받을 수 있습니다. 때문에 작업의 이름을 붙이는 게 굉장히 중요한데요, 백로그를 “치워야 할 무언가”로 정의하기보다는 “프로그램을 더 좋게 만드는 의미 있는 일”로 받아들일 수 있도록 긍정적인 언어로 작성하는 게 좋습니다. 그렇다고 해서 미사여구를 붙이거나 본질을 흐리는 작업명은 판단을 어렵게 하므로, 명료하고 본질에 충실한 작업의 명칭을 붙이는 것도 중요합니다.
모두가 접근하고 편집할 수 있게
프로그램의 개발에 있어 다수의 아이디어와 의견 교환이라는 것은 더 좋은 프로그램을 만드는 시작이 될 수 있습니다. 때문에 모든 구성원이 접근하기 편한 위치에 두어야 하고, 편집 권한에 대해 자유도를 높임으로써 구성원들의 백로그에 대한 참여도를 높이는 게 좋습니다.
자주 볼 수 있는 곳에 두기
백로그는 자주 들여다보고 예뻐해줘야 합니다. 그렇지 않은 백로그는 그저 처리 곤란한 일이 생길 때 적어두는 휴지통이 되어버립니다. 접근하기 편하고 자주 볼 수 있게 백로그를 위치시켜, 더 좋은 의견의 교환이 일어나고, 더 좋은 프로그램을 만들 수 있는 자료로 삼아야 합니다.
Reference
Reddit - Backlogs
우아한 기술 블로그 - 백로그를 백로그로 두지 않는 법
보드믹스 - # 애자일 프로젝트에서 잘 파악해야 하는 백로그 관리
주니어 PM의 백로그 관리법