JIRA 입문, JQL 심화와 자동화에서 이어지는 글이다.
이 글은 도구 사용법이 아니라 팀을 어떻게 굴리느냐에 대한 글이다.
들어가며,
JIRA를 잘 쓰는 팀과 못 쓰는 팀의 차이는 기능을 얼마나 아느냐가 아니다. JIRA에 적힌 내용이 실제 상황과 일치하느냐의 차이다.
못 쓰는 팀에서 흔히 보이는 증상
- 보드는
진행 중인데 실제로는 2주째 손도 안 댄 이슈 - 스프린트가 끝날 때마다 절반이 미완료로 남아 다음으로 넘어감
- 번다운 차트가 마지막 날 절벽처럼 떨어짐
- 회고 때 “이번엔 좀 바빴다”는 말만 반복
이건 JIRA 기능의 문제가 아니라 운영 방식의 문제다. 이 글은 그 운영 방식을 다룬다.
백로그 관리,
백로그(Backlog)는 아직 일정이 안 잡힌 이슈 대기열이다. 여기가 엉망이면 스프린트 계획도 엉망이 된다.
그루밍(Grooming)
백로그 정리 작업을 그루밍 또는 백로그 리파인먼트(Refinement) 라고 부른다. 보통 스프린트 중간에 1시간 정도 잡는다.
그루밍에서 하는 일
- 우선순위 재정렬 — 위에 있을수록 먼저 할 일
- 큰 이슈 쪼개기 — 한 스프린트에 안 끝날 것 같으면 나눈다
- 불명확한 이슈 구체화 — 설명, 완료 조건 채우기
- 죽은 이슈 정리 — 6개월째 아무도 안 건드린 이슈는 닫는다
- 스토리 포인트 추정 — 아직 안 매겼으면 매긴다
죽은 이슈 찾는 JQL
project = SHOP AND sprint IS EMPTY AND updated <= -90d
ORDER BY created ASC
3개월 넘게 업데이트가 없는 백로그 이슈다. 대부분 지워도 아무 일 안 일어난다. 백로그가 500개면 아무도 안 본다.
좋은 이슈의 조건 (INVEST)
스토리를 쓸 때 쓰는 체크리스트다.
| 항목 | 의미 |
|---|---|
| Independent | 다른 이슈와 독립적으로 진행 가능한가 |
| Negotiable | 구현 방법이 못 박혀 있지 않은가 |
| Valuable | 사용자에게 가치가 있는가 |
| Estimable | 크기를 추정할 수 있는가 |
| Small | 한 스프린트 안에 끝나는가 |
| Testable | 완료를 검증할 수 있는가 |
특히 E(추정 가능) 가 안 되면 신호다. 크기를 못 매기겠다는 건 요구사항을 아직 이해 못 했다는 뜻이므로, 조사용 이슈(Spike)를 먼저 만든다.
완료 조건(Acceptance Criteria)
이슈 설명에 무엇이 되면 끝인지를 적는다. 이게 없으면 “다 됐나요?”를 매번 말로 확인해야 한다.
[완료 조건]
- [ ] 저장된 카드로 결제가 성공한다
- [ ] 잔액 부족 시 에러 메시지가 노출된다
- [ ] 결제 성공 시 주문 상태가 '결제완료'로 바뀐다
- [ ] 결제 이력이 DB에 기록된다
체크박스로 쓰면 리뷰할 때 하나씩 확인하기 좋다.
스토리 포인트와 추정,
가장 오해가 많은 부분이다.
시간이 아니라 크기다
스토리 포인트는 상대적인 크기다. “3포인트 = 3일”이 아니다.
왜 시간으로 안 하는가
- 사람마다 걸리는 시간이 다르다 (신입 3일, 시니어 1일)
- 시간으로 추정하면 틀렸을 때 압박이 된다
- 크기는 사람이 달라도 대체로 합의된다 (“A가 B보다 두 배 크다”)
기준은 이렇게 잡는다.
- 팀이 잘 아는 이슈 하나를 골라 기준점(예: 3포인트) 으로 삼는다
- 새 이슈가 나오면 “이게 그것보다 큰가 작은가”로 비교한다
피보나치 수열을 쓰는 이유
보통 1, 2, 3, 5, 8, 13, 21을 쓴다. 숫자가 커질수록 간격이 벌어지는데, 이게 의도된 것이다.
크기가 클수록 추정이 부정확해지기 때문이다. 1과 2는 구분되지만, 20과 21은 구분할 수 없다. 그래서 큰 쪽은 아예 선택지를 띄엄띄엄 둔다.
| 포인트 | 대략적인 느낌 |
|---|---|
| 1 | 아주 작음. 설정 값 하나 바꾸기 |
| 2~3 | 하루 안에 끝나는 명확한 작업 |
| 5 | 2~3일. 일반적인 기능 하나 |
| 8 | 크다. 쪼갤 수 있는지 다시 본다 |
| 13 이상 | 무조건 쪼갠다. 이해를 못 한 것이다 |
13 이상은 이슈가 아니라 에픽이라고 생각하면 된다.
플래닝 포커(Planning Poker)
여러 명이 동시에 추정치를 공개하는 방식이다.
- 이슈 설명을 읽는다
- 각자 속으로 포인트를 정한다
- 동시에 공개한다
- 숫자가 크게 다르면(예: 2 vs 13) 그 사람들이 이유를 설명한다
- 다시 추정한다
핵심은 3번의 동시 공개다. 순서대로 말하면 먼저 말한 사람 숫자에 끌려간다.
4번이 진짜 목적이다. 숫자가 갈린다는 건 같은 이슈를 서로 다르게 이해하고 있다는 뜻이고, 그걸 발견하는 게 추정의 실제 가치다.
스프린트 운영,
스프린트 계획(Planning)
스프린트 시작할 때 하는 회의다. 여기서 정하는 것
- 스프린트 목표 — 이번에 무엇을 달성하는가 (한 문장으로)
- 가져올 이슈 — 백로그 위에서부터 순서대로
- 얼마나 가져올지 — 지난 스프린트들의 속도(Velocity)를 근거로
얼마나 가져올지가 관건인데, 지난 3개 스프린트의 평균 완료 포인트를 쓰면 대체로 맞는다.
지난 3스프린트 완료: 24, 28, 26 포인트
→ 평균 26 → 이번 스프린트도 26 내외로 가져온다
처음 몇 스프린트는 데이터가 없으니 감으로 하되, 적게 가져오는 쪽으로 시작한다. 일찍 끝나면 백로그에서 더 가져오면 되지만, 못 끝내면 회고가 무거워진다.
스프린트 목표를 한 문장으로
이슈 목록이 곧 목표는 아니다. 목표는 따로 있다.
X "SHOP-101, SHOP-102, SHOP-105를 완료한다"
O "사용자가 저장된 카드로 결제를 완료할 수 있다"
목표가 한 문장이면, 스프린트 중간에 우선순위 판단이 쉬워진다. “이게 목표에 기여하나?”로 물으면 되기 때문이다.
데일리 스탠드업
매일 짧게(10~15분) 하는 회의다. 보드를 띄워놓고 한다.
각자 말하는 것
- 어제 한 일
- 오늘 할 일
- 막힌 것
3번이 가장 중요한데 보통 생략된다. 스탠드업의 목적은 진행 보고가 아니라 막힌 것을 빨리 드러내는 것이다.
안티패턴
- 팀장에게 보고하는 자리가 된다 (팀원끼리 공유하는 자리다)
- 문제 해결을 그 자리에서 시작한다 (관련자만 남아서 따로 한다)
- 15분을 넘긴다
스프린트 중간에 일이 들어올 때
현실에서 반드시 생긴다. 원칙은 이렇다.
- 긴급 장애: 바로 넣는다. 대신 같은 크기의 이슈를 뺀다
- 그 외: 백로그로 보내고 다음 스프린트에 검토한다
중요한 건 뭔가 들어오면 뭔가 나가야 한다는 것이다. 계속 추가만 하면 스프린트 계획이 의미가 없어진다.
들어온 일의 양을 추적하려면
sprint IN openSprints() AND created >= startOfWeek()
이 숫자가 매 스프린트 크면, 계획 방식이나 팀 구조에 문제가 있는 것이다.
스프린트 회고(Retrospective)
스프린트가 끝나고 하는 회의다. 형식은 여러 가지가 있는데 가장 단순한 것은 KPT다.
| 항목 | 의미 |
|---|---|
| Keep | 잘 됐으니 계속할 것 |
| Problem | 문제였던 것 |
| Try | 다음에 시도해볼 것 |
회고가 형식적으로 흐르지 않으려면
- Try는 1~2개만 정한다. 많으면 아무것도 안 바뀐다
- Try를 이슈로 만든다. 다음 스프린트 백로그에 넣어야 실제로 한다
- 지난 회고의 Try가 어떻게 됐는지 먼저 확인하고 시작한다
차트 읽는 법,
JIRA가 그려주는 차트는 팀 상태를 보여주는 계기판이다. 읽을 줄 알아야 쓸모가 있다.
번다운 차트(Burndown Chart)
스프린트 동안 남은 작업량이 줄어드는 추이를 보여준다.
- 가로축: 스프린트 기간 (날짜)
- 세로축: 남은 스토리 포인트
- 회색 직선: 이상적인 속도 (매일 균등하게 줄어드는 가상선)
- 실선: 실제 남은 양
정상 모양은 실선이 이상선 근처에서 완만하게 내려간다. 나머지 셋은 각각 다른 문제를 가리킨다.
절벽형 — 마지막 날 한꺼번에 떨어진다. 원인은 대개 둘 중 하나다.
- 이슈 상태를 실시간으로 안 옮기고 마지막에 몰아서 옮김
- 이슈가 너무 커서 중간 진척이 안 보임
둘 다 이슈를 잘게 쪼개면 개선된다.
평평한 구간 — 중간에 며칠간 아무것도 완료되지 않았다. 막힌 이슈가 있거나, 다들 큰 이슈 하나를 붙들고 있는 상황이다.
중간에 증가 — 스프린트 도중에 일이 추가됐다. 한두 번은 괜찮지만 매번 그러면 계획 자체를 다시 봐야 한다.
속도 차트(Velocity Chart)
스프린트마다 계획한 포인트 vs 완료한 포인트를 막대로 보여준다.
포인트
30 | ▓░ ▓░ ▓░ ▓░
20 | ▓░ ▓░ ▓░ ▓░ ▓ 계획
10 | ▓░ ▓░ ▓░ ▓░ ░ 완료
0 |__S1____S2____S3____S4___
24/22 28/26 26/25 30/18
읽는 법
- 계획과 완료가 비슷하다 → 추정이 정확하다. 좋은 상태
- 완료가 계속 적다 → 매번 과하게 가져온다. 계획량을 줄인다
- 들쭉날쭉하다 → 추정이 불안정하거나, 스프린트마다 외부 요인이 많다
S4에서 30 계획 / 18 완료로 크게 벌어졌다면, 회고에서 그 이유를 찾는 게 핵심이다.
주의: 속도는 팀 간 비교에 쓰면 안 된다. 포인트 기준이 팀마다 다르기 때문이다. A팀 30포인트와 B팀 30포인트는 아무 관계가 없다. 같은 팀의 시간에 따른 변화만 의미가 있다.
누적 흐름도(CFD, Cumulative Flow Diagram)
상태별 이슈 개수를 시간에 따라 쌓아서 보여준다. 병목을 찾는 데 쓴다.
읽는 법
- 어떤 색 띠가 계속 두꺼워지면 그게 병목이다
- 위 그림은
리뷰 중띠가 두꺼워지고 있다 → 리뷰가 밀리고 있다는 뜻 - 대응: 리뷰 우선순위를 올리거나, 리뷰어를 늘리거나, WIP 제한을 건다
완료 띠의 기울기가 팀의 실제 처리 속도(처리량)다.
제어 차트(Control Chart)
이슈 하나가 시작해서 끝날 때까지 걸린 시간(사이클 타임)의 분포를 보여준다.
- 점 하나가 이슈 하나
- 세로축이 걸린 시간
- 점들이 흩어져 있으면 예측이 어렵다는 뜻
사이클 타임이 짧고 일정하면 “이 일은 대략 3일 걸립니다”라고 말할 수 있게 된다. 이게 예측 가능한 팀의 정의다.
어떤 차트를 언제 보나
| 시점 | 볼 차트 | 확인할 것 |
|---|---|---|
| 매일 스탠드업 | 번다운 | 예정대로 줄고 있나 |
| 스프린트 계획 | 속도 | 이번엔 얼마나 가져올까 |
| 회고 | 속도 + 번다운 | 왜 계획과 달랐나 |
| 프로세스 개선 | 누적 흐름도 | 어디가 막히나 |
WIP 제한,
칸반을 쓴다면 반드시 알아야 하는 개념이다.
WIP(Work In Progress) 제한은 한 열(상태)에 동시에 놓을 수 있는 이슈 개수의 상한이다.
| 할 일 | 진행 중 (최대 3) | 리뷰 중 (최대 2) | 완료 |
|--------|------------------|------------------|------|
| SHOP-12| SHOP-10 | SHOP-8 |SHOP-5|
| SHOP-13| SHOP-11 | SHOP-9 |SHOP-6|
| SHOP-14| SHOP-15 | | |
진행 중이 3개로 차 있으면, 새 이슈를 시작할 수 없다. 먼저 있던 것을 끝내야 한다.
왜 제한하나
동시에 여러 개를 붙들면 전부 느려지기 때문이다.
- 컨텍스트 전환 비용이 든다
- 전부 “진행 중”인데 완료되는 건 없는 상태가 된다
- 어디가 막혔는지 안 보인다
WIP 제한이 있으면 막힌 곳이 강제로 드러난다. 리뷰 열이 꽉 차서 아무도 새 작업을 못 시작하면, 그 순간 팀이 리뷰부터 처리하게 된다.
보드 설정에서 열마다 최대 개수를 지정하면, 초과 시 열이 빨갛게 표시된다.
권장 시작값은 팀 인원 수 정도다. 5명이면 진행 중 제한을 5로 두고, 익숙해지면 줄인다.
팀 규칙 정하기,
JIRA 설정보다 중요한 것이 팀 합의다. 아래는 정해두면 좋은 항목들이다.
Definition of Done (완료의 정의)
“완료”가 무엇인지 팀 전체가 같은 뜻으로 써야 한다.
[Definition of Done]
- 코드가 main에 머지됨
- 코드 리뷰 승인 1건 이상
- 단위 테스트 작성 및 통과
- QA 환경에서 동작 확인
- 문서(API 명세) 갱신
이게 없으면 누군가는 “코드 짰으니 완료”, 누군가는 “배포까지 해야 완료”로 생각한다.
상태 전환 규칙
| 상태 | 언제 옮기나 | 누가 |
|---|---|---|
| 할 일 → 진행 중 | 실제로 작업을 시작할 때 | 담당자 |
| 진행 중 → 리뷰 중 | PR을 올렸을 때 | 담당자 |
| 리뷰 중 → 완료 | PR이 머지됐을 때 | 리뷰어 또는 자동화 |
“실제로 작업을 시작할 때”가 핵심이다. 미리 옮겨두거나 나중에 몰아서 옮기면 보드가 거짓말을 하게 된다.
이슈 작성 규칙
- 제목은 무슨 일인지 알 수 있게 (1편의 “좋은 요약” 참고)
- 버그는 재현 방법 필수
- 스토리는 완료 조건 필수
- 스프린트에 들어가기 전까지 포인트 추정 완료
정리,
도구는 거들 뿐이고, 결국 아래 세 가지가 지켜지면 대부분 잘 돌아간다.
- 보드가 현실과 일치한다 — 상태를 그때그때 옮긴다
- 이슈가 충분히 작다 — 한 스프린트에 안 끝나면 쪼갠다
- 회고에서 정한 것을 실제로 한다 — Try를 이슈로 만든다
차트는 이 세 가지가 지켜질 때만 의미가 있다. 보드가 현실과 다르면 번다운 차트도 거짓말을 하기 때문이다.
시작한다면 순서는 이렇다.
- Definition of Done을 팀과 합의해 문서로 남긴다
- 상태를 그때그때 옮기는 습관을 2주간 지킨다
- 그다음에 번다운 차트를 본다 — 이제야 데이터가 믿을 만해진다