애자일 품질 지표 — 번다운·리드타임·결함 유출률을 팀 회고에 연결하기

개념

이 레슨의 자리 — 리드의 계기판이 아니라 팀의 대화 재료

모듈 43 레슨 5(s2-m43-l05)는 리드가 매일 아침 혼자 보는 계기판 이었다 — 번업, 결함 유입·해결 곡선, 재오픈율, 위험 목록. 이 레슨은 같은 숫자를 팀이 2주에 한 번 함께 읽는 자리 로 옮긴다. 리드의 지표는 경보, 팀의 지표는 가설 이다. 성공 조건은 "지표를 잘 그렸다"가 아니라 회고 끝에 다음 스프린트에 시도할 변경 한 줄이 남았는가 다.

지표 1 — 번다운과 번업

번다운(burn-down) 은 남은 일을, 번업(burn-up) 은 완료한 일과 전체 범위를 두 줄로 그린다. 계산은 잔여(D일) = 총 포인트 − D일까지 완료 뺄셈 하나다. 스프린트 24(2주, 10일, 5명)의 값이다.

D5에 긴급 정책 변경으로 범위가 5포인트 늘었고, D10에 스토리 1건이 이월됐다.

첫째, D5의 잔여가 28에서 33으로 올라갔다. 번다운만 보면 팀이 뒤로 간 것처럼 보이지만 원인은 속도가 아니라 범위다. 번업에서는 범위 선이 34에서 39로 오른 것이 그대로 보인다. 번다운 단독으로는 "느린 것"과 "늘어난 것"이 구분되지 않는다.

둘째, 완료 31점 중 22점(71%)이 D8~D10 사흘에 몰렸다. 전형적인 하키스틱이다. 앞 절반 동안 개발은 돌았지만 완료의 정의를 충족한 것이 없었다 는 뜻이고, 테스트가 끝에 압축됐다는 신호다. 번다운의 모양은 진척이 아니라 흐름의 구조 를 보여 준다.

셋째, 완료 31점 대 계획 34점은 실패가 아니다. 직전 세 스프린트가 29, 32, 31이면 31은 그 범위 안이다. 속도는 예측용 관측치이지 달성 목표가 아니다 — 이 구분이 지표 오염의 출발점이다.

지표 2 — 리드타임과 사이클타임

둘은 자주 혼용되지만 재는 구간이 다르고, 구간이 다르면 개선 주체도 달라진다.

리드타임   = 완료 − 요청(백로그 등록)   ← 고객이 체감하는 시간
사이클타임 = 완료 − 착수(In Progress)   ← 팀이 통제하는 시간
리드타임 = 백로그 대기 + 사이클타임

스프린트 24에 완료된 스토리 7건이다(단위: 영업일).

계산해 보면 이렇다.

사이클타임  평균 36.0/7 = 5.14일,  중앙값 5.0일
리드타임    평균 151.0/7 = 21.6일, 중앙값 18.0일, 85퍼센타일 ≈ 43일(S-104)
흐름 효율   (36.0 − 12.5) / 36.0 = 65.3%
테스트 대기 12.5 / 36.0 = 34.7%

평균과 중앙값이 벌어지면 평균을 버린다. S-104 하나가 43일이라 평균이 21.6일로 끌려 올라갔고 대부분은 18일 안팎에 끝났다. 리드타임 분포는 거의 언제나 오른쪽으로 긴 꼬리를 갖기 때문에 중앙값과 85퍼센타일을 함께 본다.

가장 눈에 띄는 숫자는 테스트 대기 12.5일, 사이클타임의 34.7% 다. 아무도 그 스토리를 만지지 않은 시간 — 개발이 끝났는데 테스트가 시작되지 않은 시간이다. 개발을 빨리 하는 것보다 대기를 줄이는 쪽이 훨씬 크다.

둘을 나눠 쓰는 두 번째 이유는 책임 소재 다. S-104의 리드타임 43일 중 36일은 백로그 대기였고, 이건 팀이 아니라 우선순위 결정의 문제다. 회고에서 팀이 바꿀 수 있는 것은 사이클타임이고 리드타임은 PO와 함께 보는 숫자다.

배포 빈도·변경 실패율 등의 DORA 지표는 레슨 s6-m38-l06 에서 다룬다. 그쪽은 배포 파이프라인을, 이 레슨은 스토리 한 건이 팀 안에서 흐르는 시간을 본다.

지표 3 — 결함 유출률(Defect Escape Rate)

결함 유출률 은 "못 잡고 내보낸 비율"이고, 반대로 읽은 것이 결함 제거 효율(DDE) 이다. 기간 정의가 빠지면 숫자가 의미를 잃으므로 "릴리스 후 30일 이내 운영 발견" 처럼 창을 고정한다.

결함 유출률 = 운영 발견 / (내부 발견 + 운영 발견) × 100
DDE        = 내부 발견 / 전체 발견 × 100 = 100 − 결함 유출률
 
스프린트 24: 내부 발견 23건, 릴리스 후 30일 내 운영 발견 4건
  결함 유출률 = 4 / (23 + 4) = 14.8%
  DDE        = 23 / 27      = 85.2%

총량으로는 어디를 고칠지 알 수 없으므로 결함이 어느 단계에서 잡혔는지 세어 단계별로 쪼갠다.

이 표가 총량보다 유용한 이유는 "더 왼쪽으로 옮길 수 있는가"를 물을 수 있기 때문 이다. 팀 테스트에서 잡힌 8건 중 몇 건이 리파인먼트 질문이나 단위 테스트로 잡힐 수 있었는지를 묻는다. 유출 4건은 지나간 일이지만 8건의 왼쪽 이동은 다음 스프린트에 걸 수 있는 변경 이다.

유출 4건은 반드시 원인별로 한 줄씩 남긴다. 숫자 4는 아무 정보도 주지 않는다.

4건 중 3건이 S-104 한 스토리 에서 나왔다. 백로그에 36일 묵었고, 사이클타임이 가장 길었고, 유출도 가장 많았다. 세 지표가 한 스토리를 가리킬 때가 회고의 가장 좋은 재료다.

스프린트 24 회고 — 숫자에서 실험으로

여기까지가 측정이고 여기부터가 중심이다. 숫자 → 읽어낸 것 → 바꿀 것 을 채우지 못하면 그 지표는 수집하지 않는 편이 낫다.

네 줄을 전부 실행하면 아무것도 안 된다. 회고에서는 하나만 고른다. 스프린트 24 팀은 첫 줄(WIP 상한 3)을 골랐다 — 영향이 가장 크고 다음 회고에서 참·거짓이 판정되기 때문이다. 나머지는 "대기 중인 가설"로 남긴다. 실험 형식은 고정해 둔다.

[관측]   테스트 대기가 사이클타임의 34.7%를 차지한다
[가설]   개발자가 다음 스토리를 먼저 착수해서 테스트가 밀린다
[실험]   다음 스프린트 동안 진행 중 스토리 상한을 3으로 둔다
[측정]   테스트 대기 비중 (지금 34.7%)
[판정]   스프린트 25 회고에서 25% 이하면 유지, 아니면 가설을 버린다
[기한]   1스프린트

판정 줄과 기한 줄이 없으면 실험이 아니라 다짐이다. "대기를 줄이자"는 참·거짓을 가릴 수 없어 세 번째 회고까지 같은 문장으로 살아남는다.

지표는 어떻게 오염되는가 — 굿하트의 법칙

사람은 자기가 측정된다는 것을 알면 행동을 바꾼다. 이것이 굿하트의 법칙(Goodhart's Law) 이고, 널리 인용되는 문장은 인류학자 Marilyn Strathern이 1997년에 정리한 형태다.

"측정이 목표가 되면, 그것은 좋은 측정이 아니게 된다(When a measure becomes a target, it ceases to be a good measure)."

원 명제는 경제학자 Charles Goodhart가 1975년 통화정책 논문에서 낸 것으로, 통계적 규칙성은 통제 목적으로 쓰는 순간 무너진다는 내용이었다. 애자일 지표에서는 매 스프린트 재현된다.

공통 구조가 보인다. 숫자를 움직이는 가장 값싼 방법은 일을 잘하는 것이 아니라 계수 규칙을 바꾸는 것이고, 그 규칙을 쥔 쪽이 팀이다. 악의도 필요 없다 — 압력이 반복되면 규칙은 저절로 느슨해진다. 방어 장치는 다섯이다.

1. 쌍으로 본다. 하나만 보면 조작되지만 짝을 이루면 조작 비용이 급격히 올라간다 — 속도↔유출률, 사이클타임↔재오픈율, 완료 스토리 수↔스토리당 평균 포인트, 결함 수↔단계별 DDE.
2. 목표가 아니라 질문으로 쓴다. "속도 35 달성"이 아니라 "속도가 두 스프린트째 떨어졌는데 무슨 일이 있었나"다.
3. 소유권을 팀에 둔다. 직접 수집·해석하면 조작할 이유가 줄고, 외부에서 내려와 평가에 쓰이는 순간 조작이 합리적 선택이 된다.
4. 정의를 문서화하고, 바꿀 때는 회고에서 공개적으로 바꾼다. "유출 판정 창은 며칠인가"가 조용히 바뀌면 추세선 전체가 거짓말이 된다.
5. 사람 단위로 쪼개지 않는다. 개인별 발견 수나 완료 포인트를 집계하는 순간 팀 지표는 평가 도구가 되고, 위 표의 모든 행이 한꺼번에 일어난다.

팀이 보는 지표와 팀 밖으로 내보내는 지표

같은 숫자라도 누가 보느냐 에 따라 안전한 것과 위험한 것이 갈린다. 기준은 하나다 — 팀 간 비교에 쓰일 수 있는 지표는 밖으로 내보내지 않는다.

포인트는 팀마다 다른 단위라 비교 가능한 척도가 아니다. A팀 40점과 B팀 25점은 비교할 수 없는데도 표에 나란히 놓이면 비교가 시작되고, 다음 스프린트에 B팀의 추정이 부푼다. 밖으로 내보낼 것은 과정 지표가 아니라 결과 지표 다 — 리드타임 중앙값, 유출률 추세, 운영 영향. 이 셋은 조작하려면 실제로 결과를 바꿔야 한다. 경영진 보고의 형식과 언어는 모듈 26에서 따로 다룬다.

실무에서 왜 필요한가

회고가 시들해지는 이유는 대개 재료 부족이다. "이번 스프린트 어땠나요"로 시작하면 기억에 남은 사건 두세 개와 감정만 오가고, 목소리 큰 사람의 인상이 팀의 결론이 된다. 숫자는 그 자리에 공통의 사실을 놓는다 — 테스트 대기가 사이클타임의 3분의 1이라는 문장은 반박하려면 데이터가 필요하고, 대화가 구조로 옮겨간다.

두 번째 이유는 QA를 테스트 실행자가 아니라 흐름 개선자로 만드는 것 이다. 유출률 14.8%를 보고할 수 있는 QA는 많지만, 4건 중 3건이 백로그에 36일 묵은 스토리에서 나왔다는 것을 연결하고 "20일 넘은 스토리는 착수 전에 쪼개자"까지 가져오는 QA는 드물다. 앞은 결과 보고이고 뒤는 프로세스 설계다. 여기에 방어의 몫이 붙는다 — "다음 분기 유출률 5% 이하"가 내려올 때 그것이 왜 유출 정보를 파괴하는지 설명할 수 있어야 한다.

실습 과제

과제 1 — 우리 팀 스프린트 지표 계산하기 (25분)

최근 완료한 스프린트 하나를 골라 실제 숫자로 채운다. 도구가 없으면 티켓 이력을 손으로 세도 된다 — 처음 한 번은 그 편이 정의를 확정하는 데 낫다.

1. 흐름 표 — 완료 스토리 전부에 백로그 대기 / 개발+테스트 / 테스트 대기 / 사이클타임 / 리드타임 을 채운다.
2. 통계 — 사이클타임 평균·중앙값, 리드타임 중앙값·85퍼센타일, 흐름 효율, 대기 비중.
3. 결함 — 내부 발견 수와 릴리스 후 30일 내 운영 발견 수로 유출률·DDE를 계산하고 단계별 누적 DDE 표를 만든다.
4. 한 줄로 답한다. "평균과 중앙값이 얼마나 벌어졌고, 그 차이를 만든 스토리는 무엇인가."

정의가 애매해 막히는 지점(착수 시각은 언제로 잡나 등)을 메모한다. 그 메모가 과제 3의 재료다.

과제 2 — 숫자에서 실험 한 줄까지 (20분)

과제 1의 숫자에서 관측 세 개를 뽑아 각각 본문의 6줄 형식(관측 / 가설 / 실험 / 측정 / 판정 / 기한)을 채우고, 셋 중 하나만 골라 다음 스프린트에 건다.

• 판정 줄은 반드시 숫자여야 한다. "개선되면"은 판정이 아니다. 기한은 1~2 스프린트를 넘기지 않는다
• 고른 이유와 고르지 않은 이유를 각각 한 줄로 적는다 — 회고에서 실제로 필요한 말이다

과제 3 — 지표 정의서 (15분)

팀이 쓸 지표 4~5개를 한 장에 정의한다. 지표당 정의 / 제외 / 짝 / 조작 경로 / 공개 범위 다섯 줄. 결함 유출률이면 제외는 "문서 오탈자·재현 불가 종료", 짝은 속도, 조작 경로는 "'개선 요청'으로 재분류하면 0%가 된다 → 분류 변경은 QA·PO 합의 시에만".

조작 경로를 먼저 적어 둔 지표는 조작되기 어렵다.

자가 체크리스트

• 번다운과 번업의 차이를 설명하고, 잔여 선이 올라간 사례에서 원인이 속도인지 범위인지 구분할 수 있다
• 리드타임과 사이클타임의 구간 차이와, 어느 쪽이 팀이 통제 가능한 지표인지 말할 수 있다
• 흐름 효율·대기 비중을 계산하고, 리드타임에 평균 대신 중앙값·85퍼센타일을 쓰는 이유를 말할 수 있다
• 결함 유출률과 DDE를 계산식·기간 정의까지 포함해 쓰고, 단계별 DDE 표에서 "결함을 왼쪽으로 옮기는" 변경을 제안할 수 있다
• 스프린트 지표 하나를 관측·가설·실험·측정·판정·기한 여섯 줄의 회고 실험으로 옮길 수 있다
• 굿하트의 법칙을 이름과 함께 설명하고, 속도·결함 수·커버리지가 어떻게 오염되는지 사례로 말할 수 있다
• 팀 내부에만 두는 지표와 밖으로 내보내는 지표를 구분하고, 속도를 내보내면 안 되는 이유를 설명할 수 있다

흔한 실수

• 번다운만 그리고, 리드타임을 평균으로 보고한다. 범위 선이 없으면 느린 것과 늘어난 것이 구분되지 않고, 분포가 꼬리를 끌어 평균은 어느 스토리도 설명하지 못한다. 범위 선을 함께 그리고 중앙값·85퍼센타일을 쓴다.
• 유출률을 총량으로만 본다. 14.8%로는 아무것도 고칠 수 없다. 결함마다 "왜 못 잡았나"와 "어느 단계로 옮기나"를 붙여야 행동이 나온다.
• 속도를 목표로 걸거나 팀 밖으로 내보낸다. 목표가 되면 추정이 부풀어 예측 기능이 죽고, 밖으로 나가면 단위가 다른 팀끼리 비교가 시작된다. 밖으로 보낼 것은 리드타임 중앙값·유출률·운영 영향뿐이다.
• 결함 수 감소를 목표로 삼거나 지표를 사람 단위로 쪼갠다. 전자는 티켓을 안 쓰는 것이 가장 값싼 달성법이고, 후자는 팀 지표를 평가 도구로 바꾼다.
• 판정 기준 없는 실험을 여러 개 한꺼번에 건다. "대기를 줄이자"는 참·거짓을 가릴 수 없어 세 번째 회고까지 살아남고, 전부 시도하면 무엇이 효과가 있었는지 알 수 없다. 숫자와 기한을 붙여 한 번에 하나만 건다.

참고 자료

• Marilyn Strathern, "'Improving ratings': audit in the British University system", European Review 5(3), 1997 — 굿하트의 법칙 인용문의 출처. 원 명제는 Charles Goodhart(1975), 표현은 Strathern의 것이다. 인용 시 원문 확인
• Kanban Guide (kanbanguides.org) — 흐름 지표 정의
• Scrum Guide 2020 (scrumguides.org) — 스프린트·완료의 정의·회고의 공식 정의. 번다운 차트가 2020판에서 빠진 점은 원문 확인
• 레슨 s2-m43-l05 — 같은 지표를 리드가 매일 읽는 법 (이 레슨은 그것을 팀 회고로 옮긴 것)
• 레슨 s6-m38-l06 — DORA 지표를 포함한 품질 대시보드
• 레슨 s2-m48-l03 — 리파인먼트 질문과 스토리 슬라이싱 (결함을 왼쪽으로 옮기는 수단)