백로그와 추정: 에픽·사용자 스토리·스토리 포인트

일의 계층

큰 목표는 그대로 일할 수 없다. 위에서 아래로 쪼개면서 각 단위가 왜 중요한지를 위 단위와 연결해 둔다.

flowchart TB
  goal["목표(연간 OKR 등)<br/>#quot;올해 고객 만족도를 높인다#quot;"] --> ini["이니셔티브(분기)<br/>#quot;1분기 리포트 경험 개선#quot;"]
  ini --> epic["에픽(여러 스프린트)<br/>#quot;공유할 수 있는 리포트 대시보드#quot;"]
  epic --> story["사용자 스토리<br/>#quot;관리자로서 리포트를 내려받아 이해관계자와 공유하고 싶다#quot;"]
  story --> task["태스크<br/>#quot;CSV 내보내기 API 추가#quot;, #quot;다운로드 버튼 UI#quot;"]

스크럼 가이드는 백로그 항목의 형식을 정하지 않는다. 에픽·스토리는 가장 흔한 관행일 뿐이다. 스크럼의 틀은 스크럼: 책임·이벤트·산출물에 있다.

사용자 스토리

[역할]로서, [이점]을 얻기 위해 [목표]를 원한다.
As a [role], I want [goal], so that [benefit].

역할은 누구를 위해 만드는지, 목표는 무엇을 하려는지, 이점은 왜 가치 있는지다. 이점이 빠지면 기능 명세가 된다. "왜"가 있어야 개발자가 더 나은 구현을 제안할 수 있다.

3C

INVEST: 좋은 스토리의 조건

스토리는 계층(DB → API → UI)이 아니라 사용자 흐름을 따라 세로로 자른다. 얇아도 끝에서 끝까지 동작하는 조각이어야 가치가 있고 테스트할 수 있다.

인수 기준

인수 기준(acceptance criteria)은 이 스토리 하나가 끝났는지 판단하는 조건이다. 팀 전체의 품질 기준인 완료의 정의(DoD)와 함께 충족해야 완료다. Given-When-Then으로 쓰면 그대로 테스트 케이스와 태스크가 된다. 그 방법은 BDD·SDD로 태스크 나누기에 있다.

백로그 다듬기

제품 백로그에는 새 기능(스토리)만이 아니라 버그, 기술 부채, 지식 습득(스파이크·프로토타입·개념 증명)이 함께 들어간다. 좋은 백로그는 흔히 DEEP으로 요약한다.

추정: 스토리 포인트와 플래닝 포커

스토리 포인트(story point)는 시간이 아니라 상대 크기다. 작업량·복잡도·불확실성을 합쳐 "기준 스토리보다 두 배쯤 크다"처럼 매긴다. 사람마다 속도가 달라도 상대 크기에는 합의하기 쉽다는 것이 시간 대신 쓰는 이유다.

플래닝 포커(planning poker)는 이 크기를 팀이 함께 정하는 방법이다. 랜드 연구소의 와이드밴드 델파이(Wideband Delphi) 기법을 바탕으로 2002년 제임스 그레닝(James Grenning)이 만들었고, 마이크 콘(Mike Cohn)의 『Agile Estimating and Planning』(2005)으로 널리 퍼졌다.

1. PO가 스토리를 읽고, 개발자가 질문해 범위를 맞춘다
2. 각자 카드를 고른다 (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?)
3. 동시에 뒤집는다. 먼저 말한 숫자에 끌려가는 앵커링을 막는다
4. 값이 갈리면 가장 높은 사람과 가장 낮은 사람이 이유를 설명한다
5. 다시 뒤집는다. 비슷해질 때까지 반복한다

• 숫자가 피보나치처럼 벌어지는 것은 클수록 불확실하다는 뜻이다. 13을 넘으면 정밀하게 맞추지 말고 쪼갠다.
• 가장 큰 가치는 숫자가 아니라 4번의 대화다. 높게 부른 사람은 남이 못 본 위험을, 낮게 부른 사람은 더 쉬운 방법을 알고 있는 경우가 많다.

시간으로 추정해야 할 때: 구현 시간에 곱하기

외주 견적이나 출시일처럼 시간 추정이 필요할 때는 사람이 그나마 추정할 수 있는 것이 구현 시간뿐이고, 그것도 낙관적이라는 점에서 출발한다.

구현이 전체의 3분의 1이므로 현실적인 태스크 추정 ≈ 구현 추정 × 3이다. 곱하는 수는 경험에 따라 다르다. 태스크 하나는 2주를 넘지 않게 쪼갠다.

프로젝트는 에픽 → 스토리 → 태스크로 나눠 태스크마다 낙관적으로 추정하고, 모르는 부분에는 시간 상자를 둔 조사(spike) 를 넣고, 위험을 더한다. 스토리 하나가 4주를 넘으면 추정하지 말고 먼저 조사한다. 경험칙으로 현실 일정 ≈ 낙관 경로 × 3.14 + 2주다. 더해야 할 위험은 버스 팩터(한 사람만 아는 지식), 병가, 휴가·공휴일, 실수, 설계 오류다.

속도와 진척 차트

속도(Velocity)

속도는 한 스프린트에 완료의 정의까지 끝낸 스토리 포인트의 합이다. 반쯤 한 항목은 0점이다. 보통 최근 3~4개 스프린트 평균으로 다음 스프린트에 얼마나 담을지 정한다.

속도는 설명 지표다. 올리라고 요구하는 순간 포인트가 부풀고(측정이 목표가 되면 측정이 망가진다는 굿하트의 법칙), 품질이 깎인다. 팀 구성, 스프린트 길이, 완료의 정의가 바뀌면 속도도 다시 재야 한다.

번다운과 번업

스프린트 안에서는 번다운이, 여러 스프린트에 걸친 릴리스나 에픽에는 범위 변화가 보이는 번업이 잘 맞는다. 실제선이 며칠씩 평평하다가 마지막 날 뚝 떨어지면, 항목이 너무 커서 끝까지 완료가 안 되는 것이다.

한계

• 추정은 틀린다. 추정의 목적은 정확한 날짜가 아니라 크기에 대한 공유된 이해와 대략의 계획이다. 일정을 미리 약속하기보다 만들어 보며 측정하자는 관점은 애자일과 스프린트에 있다.
• 포인트 추정 자체를 생략하고 항목을 비슷한 크기로 쪼갠 뒤 개수(처리량)로 예측하는 팀도 있다. 흐름 지표는 칸반과 린에서 다룬다.
• 스토리 포인트를 시간으로 환산하기 시작하면 상대 추정의 장점이 사라진다.

정리

• 목표 → 에픽 → 스토리 → 태스크로 쪼개되, 각 단위가 위의 "왜"에 연결되게 한다.
• 스토리는 3C로 대화하고, INVEST로 점검하고, 인수 기준으로 끝을 정한다. 계층이 아니라 사용자 흐름으로 세로로 자른다.
• 스토리 포인트는 상대 크기이고, 플래닝 포커의 가치는 숫자보다 의견이 갈릴 때의 대화다.
• 속도·번다운·번업은 계획을 돕는 설명 지표다. 성과 목표로 쓰면 망가진다.

관련 노트: 스크럼: 책임·이벤트·산출물, 애자일과 스프린트, BDD·SDD로 태스크 나누기, 칸반과 린: 흐름과 낭비, 기술 부채, Jira: 이슈 구성, JQL, 워크플로, GitHub 이슈·프로젝트로 진행 상황 관리하기, 소프트웨어 프로젝트 관리: 비용 산정·일정·위험