‘Good’ 엔지니어는 일주일에 몇 개의 Jira 티켓을 닫나요?

Source: Dev.to

Overview

티켓 속도에 집착하는 것은 핵심을 놓치는 것이지만, 벤치마크는 여전히 유용할 수 있습니다. 티켓 수 자체만 보면 오해의 소지가 있는데, 티켓마다 요구되는 노력이 크게 다르기 때문입니다.

Benchmarks

• Baseline: 엔지니어 1인당 2주 스프린트에 5–10 스토리 포인트.
• Sustainable pace: 하루에 약 1개 티켓(주당 ≈5개 티켓).
• Spikes: 버그 트라이지 주에 10개 이상 티켓은 정상적이지만 지속 가능하지 않음.
• High‑velocity teams: 작업을 1일 단위 작업으로 쪼개면 팀당 주당 25개 티켓까지 달성 가능.

Factors Affecting Velocity

• Ticket complexity: 20개의 사소한 버그 ≠ 3개의 복잡한 작업.
• Work‑in‑Progress (WIP) limit: “In Progress” 상태를 1 주 이하로 제한.
• Breakdown: 작업을 Epic → Stories → Tasks 로 나누기.

Velocity Ranges

• Low (< 3 tickets/week) – 추정이 부정확하고, 짧은 (≈3 일) 사이클.
• Healthy (5–8) – 품질 좋은 티켓, 주 1회 이상 배포, 재작업 비율 낮음.
• High but fragile (> 12) – 주로 버그 작업만 진행, 기술 부채 누적, 테스트·리뷰 생략, 번아웃 위험.

Metrics to Track

• Velocity Chart – 주당 평균 완료 스토리 포인트.
• Control Chart – 사이클 타임 추세.
• Burndown Chart – 스프린트 커밋 추적.

Recommendations

• Impactful velocity(주당 배포된 가치)에 초점을 맞추고, 단순 티켓 수에 집착하지 말 것.
• 다음 질문을 스스로에게 해보세요:
  • 기능을 배포하고 있는가, 아니면 티켓만 닫고 있는가?
  • 사이클 타임이 개선되고 있는가?
  • 차단 요인이 분기별로 감소하고 있는가?
• 품질을 유지하면서 지속 가능한 처리량을 목표로 하며, 허세 메트릭은 피하십시오.

References

• Scrum.org – Scrum Kanban
• Scrum.org Forum – Story points: complexity vs. effort