백로그 제대로 관리하기
네? 저희 스크럼팀 백로그가 100개라고요?
지금의 스쿼드에 몸 담은지 5개월 반. 백로그*가 100개에 가까워졌다.
이게 전체 백로그의 절반도 안 된다니... | 비밀유지를 위해 텍스트는 모자이크 처리했습니다. 백로그는 스크럼팀에서 일의 시작을 담당한다.
스크럼팀은 제품 백로그를 검토하여 스프린트 백로그로 넣을 작업을 고르고 이를 완료하여 배포한다. 이 과정을 매번 반복하면서 백로그는 완료되어 목록에서 사라지고, 새로운 아이디어와 요구사항이 나올 때마다 추가되며 바뀐다.
그러니 백로그의 개수가 줄어들거나 늘어나는 것은 무척 자연스러운 현상이다. 여름 쯤에는 제품 백로그가 30여개 정도였는데, 겨울이 깊어가니 100여개가 됐다는 것도! 자연히 일어날 수 있는 일이다.
하지만, 아무리 그래도 100개라니?
100이라는 숫자만 들어도 너무 많다고 느껴진다. 사실 숫자 자체에는 아무런 의미가 없다는 걸 안다. 30개나 100개나 어떤 스크럼팀의 백로그인지에 따라 좋을 수도 나쁠 수도, 관리가 잘 된 걸 수도 아닐 수도 있다. 백로그 관리의 규칙에 따라 한계 개수의 수가 스크럼 팀에 따라 다른 게 당연하다.
그래도 100개라니?! 자꾸 100이라는 숫자가 압박처럼 느껴진다.
그래서 정말 문제인지를 확인해보기로 했다.
진짜 문제일까? 네, 진짜 문제였군요
약 한 달 전부터 백로그를 확인하고 관리하는 일이 불편하다고 생각했다. 날이 갈수록 우선순위를 확인하고 관리하는 것이 이전보다 조금 더 시간이 걸리고, 이미 백로그에 있는 스토리를 또 백로그로 작성하는 일도 점차 많아졌다. 백로그 관리의 책임이 있는 내가 이런 어려움을 겪고 있다는 건, 백로그를 제대로 관리해야 할 타이밍이 도래했다는 뜻이다. 특별히 우리 스크럼팀에서 백로그 관리의 규칙이 없었기에, 현재 상황을 정리해보고 규칙을 정해 관리해봐야겠다는 생각이 들었다.
내가 지금 백로그를 사용하면서 겪는 어려움은 크게 2가지다.
가독성이 낮다
모든 아이템은 텍스트로, 문장 중심의 유저 스토리로 작성하고 있다. 따라서, 텍스트를 중심으로 보여져 구분이 어렵다. 백로그가 많으면 많을 수록 읽어야 할 텍스트가 많아진다. 우선순위를 부여해놔도 이게 무슨 아이템인지 알기 위해서는 모든 문장을 읽어야만 한다. 아무리 유저 스토리를 읽기 쉽게 작성하려고 노력해도, 어드민에 기능을 설명하려면 비슷한 메뉴 이름이나 동작이 반복되어 비슷한 단어가 나오는 스토리를 헷갈리곤 한다.
우선순위 변경이 어렵다
우선순위는 비즈니스 상황에 따라 변하고, 지난 주에 배포한 기능에 대한 고객의 피드백에 의해 빠르게 수정해야 하는 경우도 생긴다. 우선순위를 정하는 기준이 있다고 하더라도 변경되는 일은 잦다. 지난 주에 가장 중요했던 백로그가 이번 주에는 중요도가 낮아질 수도 있다. 중간 정도 우선순위를 가지고 있던 백로그가 아주 낮은 우선순위로 변경될 수도 있다.
우리는 현재 우선순위를 정렬로 보고 있다.
팀이 사용 중이 프로젝트 관리 툴인 Monday는 아이템이 하나의 그룹에서 목록으로 쌓이는 구조를 가지고 있어, 상단에 올라와 있을 수록 높은 우선순위를 가진 아이템으로 보고 있다. 그래서 우선순위를 변경할 때에는 해당 아이템을 마우스 좌클릭으로 선택 후 원하는 위치로 드래그한다. 백로그의 숫자가 증가하니, 우선순위를 크게 변동해야 할 때에는 드래그를 힘겹게 해야 한다. 또 실수하는 일도 종종 있어서 소소하게 여러 차례 클립과 드래그를 반복하게 된다. 그래봐야 몇 초 더 쓰는 것이지만, 약간씩 아주 약간씩 우선순위 변경에 추가적으로 시간이 들어가고 있다.
게다가 우리는 웹, iOS 앱, 안드로이드 앱 3개의 프로덕트의 백로그를 한 그룹에서 관리하고 있다. 프로덕트별 구분을 하지 않고 아이템별 우선순위만 두고 구분을 하려니 실제 작업자들이 보기에는 불편함이 있어 백로그의 상위에는 앱, 하위에는 앱 아이템을 배치하고 각 프로덕트 내에서의 우선순위를 관리 중이다.
아이템을 새롭게 추가하면 가장 상단 또는 하단에 생성되는데, 프로덕트에 맞게 이동을 시키려면 또 심혈을 기울여야 한다. 약간의 귀찮음과 실수가 계속 증가하고 있는 모양새다.
왜 이렇게 됐을까?
한편으로는 의아하기도 하고, 아쉽기도 하다. 지금까지 백로그 정제**를 (나름대로) 소홀히하지는 않았다. 특정한 주기를 정해서 관리한 것은 아니지만, 매 스프린트마다 시간이 날 때마다 중복 아이템의 정리, 우선순위 설정, 스토리 쪼개기 등의 활동을 계속해왔다. PO의 책임 중 하나로 아주 중요하게 서술되곤 하는 부분이 Product Backlog Item(PBI)의 관리라, 잊지 않고 진행해왔다고 생각한다. 그런데도 (우리 기준에) 비대한 백로그가 된 이유가 무엇일까?
백로그가 세분화되면서 증식한다
백로그 정제 당시에 1~2 스프린트 뒤에 스프린트 백로그로 분류될 것을 기대하고 사이즈를 작게 쪼개둔 스토리들이 백로그에 쌓인다. 우선순위가 변경되는 바람에 이미 실행 가능한 크기로 쪼개둔 백로그가 당면한 문제 또는 고객의 니즈와의 관련성이 낮아지는 경우가 몇 번 있었다. MVP 상태에서 유료 고객이 발생하다 보니, 유료 고객의 목소리에 귀 기울이지 않을 도리가 없다.
한 마디로, 1개의 백로그가 세분화를 거치며 3~4개로 분화되었는데 우선순위에서 밀려 해결되지 못하고 쌓이는 일이 반복되고 있어, 백로그의 숫자가 증식하고 있는 것이다.
3개 프로덕트를 관리하니 최소 백로그의 수 자체가 많다
웹, iOS 앱, 안드로이드 앱 백로그를 모두 한 그룹에서 관리하고 있어 절대적으로 수가 많을 수 밖에 없다.
우리 스쿼드는 웹, iOS 앱, Android 앱을 모두 다루고 있다. 웹 10개, iOS 앱 10개, Android 앱 10개씩이면 총 30개의 백로그가 만들어진다. 각각의 백로그를 모두 하나의 보드에서 관리하면 백로그는 금방 숫자가 많아진다.
원인을 잘 들여다 보면 모두 ‘많은 백로그의 수’의 문제였다.
자, 그럼 수를 줄여봅시다
적절한 백로그의 수(백로그의 사이즈)로 만들기
많은 백로그의 수가 문제임을 알았으니, 적절한 사이즈는 몇 개인지 찾아보고 실제로 적절한 사이즈로 줄이는 작업을 해보자.
우선, 관리가 용이하며 실제 스크럼을 잘 운영할 수 있도록 해주는 적절한 백로그의 수가 얼만큼인지 알아봐야 한다. '적절한 백로그의 사이즈'란, 백로그의 존재 이유를 훼손하지 않고 활용 가치를 떨어뜨리지 않아야 한다. 너무 작아서 스프린트의 진행에 방해가 되면 안 되고, 너무 많아서 우선순위를 알아보기 어려우면 안 된다. 나는 다음과 같이 적절한 백로그 사이즈의 조건을 정의했다.
백로그의 적절한 사이즈의 조건
✔ 2 스프린트 분량 만큼은 백로그가 세분화되어 있어야 한다
✔ 한 번의 화면에서 볼 수 있을 정도의 숫자로 제한한다 (가독성, 우선순위 변경 문제 해결)
✔ 현재 시점에서 낮은 우선순위를 갖거나, 긴급도가 낮은 백로그는 세분화하지 않는다 (가독성 문제 해결)
백로그의 수를 관리 가능한 수로 만들기 위해 다음과 같은 구체적인 방법을 진행하기로 했다.
적절한 사이즈를 찾고, 적절한 사이즈로 줄이는 방법
1. 우리 스크럼팀의 적절한 백로그 한계 수 찾기
2. 중복 백로그 삭제 및 아카이빙
3. 2 스프린트 내로 진행할 우선순위가 높은 아이템의 상단 배치
4. 그 외의 백로그 중 기능/성격별 백로그 그룹화
자, 이제 실행해보자!
1. 적절한 백로그 한계 수 찾기
우리 스크럼 팀의 평균 증분(배포를 완료하는 스프린트 백로그의 수) 찾기
제일 먼저, 우리가 2개 스프린트에서 진행 가능한 스토리가 평균적으로 몇 개인지, 즉 증분이 몇 개인지 확인해봤다.
올 하반기에 진행한 8개의 스프린트를 살펴보니 평균 14개의 스토리를 완료했다. 이는 웹과 2가지 앱을 모두 합한 수로, 앱은 평균적으로 각 3개로 총 6개, 웹은 8개 정도를 완료했다. 2개 스프린트를 위한 스토리의 수는 앱은 12개, 웹은 16개의 백로그를 가지는 것이 일반적이다.
우리 스크럼팀의 2 Sprint 평균 증분앱은 10개 안팎, 웹은 15개 안팎으로 보기로 했다.
스프린트 두 개 분량의 웹과 앱의 백로그는 총 25~30개가 적절하다고 볼 수 있다.
관리를 위해 한 화면 안에서 볼 수 있는 스토리의 수를 고려
한 화면에서 볼 수 있는 스토리의 수는 약 20개 정도다.
그런데 이미 웹이 16개를 가지고 있다고 하면 추가할 수 있는 백로그는 4개가 된다. 하지만 현실적으로 보자. 에픽 사이즈라고 해도 단 4개만을 허용하는 것이 가능한가?
되돌려 생각해봐도 실질적으로 가지고 있던 백로그가 최소 10개는 되었다. 현재 논의되고 있는 에픽만 해도 6개인데, 이 에픽은 정말로 커~어~다~란~ 크기로 세부사항이 하나도 없다. 없는 정도가 아니라 거대한 덩어리다. 아무리 세부사항이 필요없다고 하더라도, 거대한 사이즈로는 백로그에 들어있는 관리 대상이라고 보기 어렵다.
그러니 딱 20개로 한정하지 말고, 스크롤을 한 번 정도 돌려서 어렵지 않게 확인할 수 있는 정도의 개수를 정하는 것이 현실적인 것 같다.
결과적으로 웹은 25개, 앱은 20개 정도가 적절하다고 보고 각각 30개와 25개가 최대 숫자라고 정리했다.
이 기준은 실제로 정리를 해보고 어느 정도가 적절할 지 다시 한 번 확인을 해보고자 한다.
2. 백로그 삭제와 아카이빙
중복 백로그 삭제
전체 백로그를 살펴보고 다른 문장이나 용어로 작성되어 있지만 실질적으로 내용이 같은 항목들을 제거했다.
⇒ 4개 백로그 삭제
낮은 Relevant 백로그 아카이빙
relevant (관련성 + 시의성)를 기준으로 우선순위를 부여했다.
우선순위를 나타내는 방법은 기존에 팀이 사용하고 있는 방법인 상단 배치-순서이다. 가까운 시일 내에 실행할 아이템을 위로, 그렇지 않은 아이템을 아래로 위치 시키고 낮은 relevant를 가지는 아이템은 삭제하거나 아카이빙했다.
relevant 판단 기준은 다음과 같이 세웠다.
언젠간 반드시 포함될 기능이지만, 지난 6개월 동안 한 번도 우선순위가 높아진 적이 없는 아이템
6개월 이내에 우선순위가 높아질 가능성이 무척 낮은 아이템
⇒ 11개 백로그 아카이빙
판단이 불가능한 백로그 삭제
내가 작성한 기억이 없는 백로그가 있어서 살펴봤더니, 프로덕트 디자이너 분이 작성한 것이었다. 당시 PO 부재 중인 상태에서 대행했던 과정에서 작성한 1개, 최근에 공유한 아이디어가 백로그로 들어와 있는 것이 1개. 나와 백로그에 추가하기로 정확히 논의한 내용이 아니었고, 백로그가 상당 부분 세분사항이 포함되어 있어 유효성을 따지기 어려운 상황이었다. 디자이너 분과 논의하여 두 개 모두 삭제하기로 결정했다.
⇒ 2개 백로그 삭제
백로그 정리 작업과는 별개로, 위와 같은 이유로 삭제한 2개의 백로그가 한 개는 3월에, 한 개는 11월에 작성된 것이었는데 이걸 여태까지 정확하게 모르고 있었다는 것이 상당히 충격이었다.
나름대로 관리해온다고 관리한 것인데, 어떻게 이렇게까지 부실한 부분이 있을 수 있는지. 내 스스로에게 조금 부끄러웠다.
백로그 관리의 책임이 나한테 있다고 꾸준하게 생각해오고 있었음에도 불구하고, 많이 부족했음을 깨달았다.
백로그 작성과 삭제 등 관리의 책임은 모두 PO에게 있음을 명확하게 하고, 앞으로의 백로그 추가는 PO와 논의하고 PO가 직접 작성하는 것으로 규칙을 정했다.
여기까지 마치니, 앱은 총 18개의 백로그만 남아 한 화면에서 보기 적절한 개수로 조정되었다!
스크롤 하지 않아도 한 화면에서 충분히 잘 보이는 앱 백로그웹의 백로그 정리를 위해서 계속해보자.
3. 2개 스프린트 내로 진행할 우선순위가 높은 아이템 결정
우선순위에 따라 (세분화된) 백로그를 상단 배치하는 작업이다.
최근 스크럼팀과 6개의 에픽을 놓고 ICE Score를 부여하는 워크샵을 진행했다. 여기서 높은 점수를 받았던 에픽과 관련한 백로그 3개를 최상단에 위치시켰다. 지난 스프린트 때에 최초 계획에 포함시켰으나 완료하지 못해 취소한 스토리들과 리뷰를 통해 개선되어야 한다고 합의한 스토리를 차례로 배치했다.
이렇게 배치하고 나니, 웹에서는 총 14개의 스토리가 실행 가능한 사이즈로 정의되었다.
적절한 백로그의 수는 25~30개이기 때문에 이제 리스트에 남겨둘 수 있는 백로그는 이제 11~16개이다.
4. 백로그의 그룹화
실행 가능한 단위로 쪼개져 작성된 스토리는 가독성을 낮추는 주요 요인 중 하나였다. 정리하는 시점에서 2개 스프린트 이내에 실행하지 않을 것이 분명한 백로그들 중 같은 목표를 가진 백로그들을 해당 목표나 기능을 이름으로 하여 하위 아이템으로 만들었다.
Monday의 아이템의 변환 기능을 이용했다.
목표나 기능을 이름으로 하여 상위아이템을 생성하고, 기존에 상위 아이템을 ‘변환’ 기능을 통해 하위 아이템으로 묶었다. 예를 들면 ‘수료증’ 기능 아래 ‘관리자는 특정 클래스의 수료 기준을 설정할 수 있다.’, ‘관리자는 유저가 수료증을 신청하면 수료증을 발급할 수 있다.’, ‘유저는 수료증 발급을 신청할 수 있다.’와 같은 백로그를 하위 아이템으로 묶는 것이다.
상위 태스크 아래 하위 아이템을 묶었다백로그가 묶여 있음을 명확하게 하고 가독성을 높이기 위해 이런 묶음의 상위 백로그는 명사형으로 작성했다. 총 35개의 백로그를 9개의 백로그로 묶었다. 묶인 하위 아이템은 최소 2개에서 많게는 6개까지였다.
⇒ 35개의 백로그를 9개의 백로그로
짜잔.
약 100개의 백로그를 48개(웹29개 , 앱 18개)로 만들었다.
웹과 앱의 목록을 분리하여 관리하는 것도 고려했으나, 일단 현재까지 작업한 형태로 사용해보고 그래도 낮은 가독성과 관리의 어려움에 시달리면 추후에 시도해보기로 했다.
간단히 지속적인 관리를 위한 백로그 규칙을 정리하면 다음과 같다.
백로그 관리 규칙
백로그 정제와 정리는 전적으로 PO의 책임과 의무다.
백로그는 매 스프린트마다 PO가 반드시 1회 이상 정제한다.
백로그는 웹과 앱을 합쳐 최대 55개를 넘지 않는다. (웹은 25~30개, 앱은 20~25개를 유지한다)
백로그 정리를 위해 리서치를 실시했는데, 내가 진행한 방법 외에도 우선순위 부여나 분류 시 라벨을 활용하는 방법을 많이 추천했다. 백로그의 생성일을 기록하거나, 우선순위를 정해둔 라벨을 활용해 라벨을 붙이거나, 스토리의 크기를 라벨링하여 관리의 용이성을 높이는 방법을 이번에 적용해볼까 고려했으나 일단 정리를 완료했으니 지금의 규칙과 기준이 얼마나 유용한지 사용해보고 측정해보고자 한다.
IT 업계에 몸 담그고 있는 동안, 한시도 ‘그 땐 맞고 지금은 틀리다’라는 말이 옳지 않았던 적이 없다. 상황은 시시각각으로 변하고, 고객이 추구하는 것은 조금씩 변한다. 처음 정의하고 이해한 내용대로 긴 호흡으로 제품을 만들어 가다 보면 막상 배포하거나 출시할 때에 틀렸다는 것을 알게 된다. 애자일 방법론 안에서 백로그를 관리하는 일은 지금, 오늘 옳은 일에 스크럼팀이 전력을 다해 몰입하기 위한 밑작업인 것 같다.
*백로그(backlog): 우선순위가 부여된 작업 목록
프로젝트 관리 전략의 범위 내에서 팀이 작업해야 하는 작업의 우선순위가 지정된 목록 project-management-knowledge
로그맵과 요구사항에서 도출된 개발팀의 우선순위가 지정된 작업 목록 Atlassian
고객의 요구에 따라 변경되는 요구 사항의 목록. 제품에 대한 원하는 모든 기능의 위시리스트. 스크럼 팀은 백로그를 사용하여 기능의 우선순위를 정하고 기능 구현의 순서를 파악한다. agile-academy
스크럼팀이 전달해야 하는 요구사항, 진행 중인 요구사항, 피처, 기능, 스토리, 개선사항 및 수정사항의 묶음이다. <애자일조직은 이렇게 일합니다>
**백로그 정제(backlog reinforcemece)
스프린트 백로그(스프린트에서 진행할 아이템)는 PBI 목록에서 선정하게 되므로, 스프린트에 포함될 만큼 중요한 아이템에 우선순위를 부여하고 실행 가능한 정도의 크기로 쪼개고 세분화해야 한다.
스토리에 살을 붙여 스토리를 충분히 상세하게 만들고, 한 스프린트에서 진행하기에 너무 큰 스토리를 잘게 쪼개고, 새로운 스토리르 추가하고, 다른 백로그 항목의 상대적 우선순위를 업데이트하고, 스토리를 추정하거나 재추정하는 일 등을 포함한다. 일반적으로 백로그 정제는 스크럼팀이 다음 스프린트에서 진행할 만한 가치가 있는 백로그 항목의 세부사항을 채우는 것으로 구성된다.
2개 스프린트만큼의 완전히 정교화된 PBI가 준비되어 있는 게 좋다.
백로그 정제는 다양한 제품 개발 태스크를 가장 중요한(critical) 것부터 우선순위를 부여하는 과정 Backlog Refinement: The Ultimate Guide
