스크럼을 도입했는데 버그가 백로그에서 사라지는 이유

스프린트는 잘 도는데 버그만 안 줄어듭니다

스크럼을 도입한 팀에서 자주 보이는 풍경이 있습니다. 스프린트는 2주마다 정확히 돌고, 번다운 차트도 예쁘게 내려가고, 회고도 합니다. 그런데 버그 목록만 계속 길어집니다.

그리고 어느 날 반년 전에 등록된 버그가 백로그 아래쪽에서 발견됩니다. 아무도 안 고쳤고, 아무도 안 닫았고, 심지어 아직 재현되는지도 모릅니다.

이건 팀이 게을러서 생긴 일이 아닙니다. 스크럼의 구조와 버그의 성질이 잘 안 맞아서 생기는 일입니다. 어긋나는 지점이 어디인지 짚어보겠습니다.

어긋나는 지점 1 · 버그는 스프린트 경계를 안 지킵니다

스토리는 스프린트 계획 회의에서 들어옵니다. 2주 단위로 묶고, 포인트를 매기고, 시작할 때 범위를 정합니다.

버그는 그렇게 안 옵니다. 스프린트 6일차에 터지고, 데모 30분 전에 발견되고, 릴리즈 직후에 고객이 제보합니다. 계획 회의를 기다려주지 않습니다.

그래서 팀은 둘 중 하나를 합니다.

• 지금 고친다 → 스프린트 계획이 무너지고, 번다운은 이유 없이 튀어 오릅니다
• 다음 스프린트 백로그에 넣는다 → 다음 계획 회의에서 새 스토리와 우선순위 경쟁을 합니다

두 번째가 문제의 시작입니다. 우선순위 경쟁에서 버그는 거의 항상 집니다.

어긋나는 지점 2 · 버그는 우선순위 경쟁에서 이길 수 없습니다

계획 회의 테이블에 두 항목이 올라옵니다.

• A: "결제 수단 추가" · PO가 원하고, 매출과 연결되고, 데모에서 보여줄 수 있습니다
• B: "주문 목록 정렬이 가끔 뒤집힘" · 사용자 일부만 겪고, 우회 방법이 있고, 데모에서 안 보입니다

건강한 팀이라도 A를 고릅니다. 한 번은 옳은 판단입니다. 문제는 이 판단이 매 스프린트마다 같은 방향으로 반복된다는 점입니다. B는 매번 밀리고, 밀릴 때마다 백로그에서 조금씩 아래로 내려가고, 스무 개쯤 쌓이면 아무도 그 아래를 안 봅니다.

버그와 스토리를 같은 목록에 넣고 같은 기준으로 정렬하는 한, 이 결과는 구조적으로 정해져 있습니다.

어긋나는 지점 3 · "완료"의 정의가 검수를 안 담습니다

스크럼에는 완료 정의(DoD)가 있습니다. 그런데 많은 팀의 DoD가 개발 관점에서 끝납니다. 코드 리뷰 통과, 머지, 배포.

버그 수정에는 그 뒤가 하나 더 있습니다. 처음 제보한 사람이 다시 보고 "맞다, 고쳐졌다"고 확인하는 단계입니다. 이게 DoD에 없으면 이런 일이 생깁니다.

• 개발자는 고쳤다고 생각하고 카드를 닫습니다
• QA는 다른 조건에서 여전히 재현되는 걸 나중에 발견합니다
• 같은 버그가 새 이슈로 다시 등록됩니다. 이력이 끊긴 채로

세 달 뒤 "이 버그 예전에도 있지 않았나?"라는 질문에 아무도 답할 수 없게 되는 이유가 이겁니다.

buggle이 상태를 두 겹으로 두는 게 이 지점입니다. 파트별 작업이 배포/반영까지 가도 이슈는 아직 안 끝납니다. 검수요청으로 올라가서 확인완료 또는 재수정요청으로 갈려야 종결됩니다. 반려되면 새 이슈가 아니라 같은 이슈가 되돌아오므로 왕복 이력이 한자리에 남습니다.

그래서 어떻게 바꾸나

세 가지를 권합니다. 스크럼을 버리자는 얘기가 아니라, 버그를 스토리와 다른 트랙으로 빼자는 얘기입니다.

1. 버그는 백로그가 아니라 별도 흐름에 둡니다

스토리 백로그는 "무엇을 만들 것인가"의 목록입니다. 버그는 "이미 만든 것 중 무엇이 잘못됐나"의 목록이라 성격이 다릅니다. 같은 줄에 세워 정렬하면 앞서 본 대로 항상 집니다.

목록을 나누면 버그 우선순위는 버그끼리 비교하게 됩니다. "결제 오류 대 정렬 오류" 비교는 실제로 답이 나오는 질문입니다.

2. 스프린트 용량의 일부를 미리 버그에 떼어둡니다

비율은 팀마다 다릅니다. 중요한 건 숫자가 아니라 계획 회의 전에 정해둔다는 점입니다. 미리 떼어두지 않으면 매번 새 기능과 겨루게 되고, 결과는 늘 같습니다.

이 예산을 정할 때 근거가 필요한데, 이 부분에서 데이터가 쓸모 있습니다. buggle의 처리추이 보고서는 기간별로 등록·수정·확인 건수가 어떻게 움직였는지 보여주고, 노후지연 보고서는 오래 머문 이슈를 따로 뽑아줍니다. "지난 분기에 등록 대비 확인이 계속 모자랐다"는 건 감이 아니라 숫자로 말할 수 있는 얘기입니다.

3. 회귀는 화면 단위로 봅니다

스프린트마다 전체를 다시 볼 수는 없습니다. 그래서 어디를 다시 볼지 골라야 하는데, 이 선택의 근거가 보통 "느낌"입니다.

이슈를 화면에 연결해 두면 근거가 생깁니다. 화면별 수정이력을 보면 이번 분기에 어느 화면이 자주 흔들렸는지가 나오고, 그 화면이 다음 회차 회귀 검수 대상이 됩니다. 재확인반려 보고서에서 한 번에 안 끝난 이슈가 몰린 화면도 같은 신호입니다.

정리

스크럼이 버그에 약한 건 스크럼이 나빠서가 아니라, 계획된 작업을 다루도록 만들어진 틀에 계획되지 않은 작업을 밀어 넣어서입니다. 목록을 나누고, 용량을 미리 떼고, 완료 정의에 검수를 넣으면 대부분 해결됩니다.

이걸 도구 없이 규칙만으로 해도 됩니다. 다만 규칙은 바쁠 때 제일 먼저 무너지기 때문에, 도구가 기본값으로 그렇게 굴러가면 유지가 쉽습니다. buggle은 이 흐름이 기본이고 무료로 시작할 수 있습니다. 보드를 검수까지 굴리는 구체적인 구조는 칸반 보드로 QA 검수까지 굴릴 때의 구조에 이어서 적었고, 보드 도구 자체의 한계는 트렐로로 버그를 관리하다 막히는 네 지점에 따로 적었습니다.