스크럼을 운영하다 보면 반드시 부딪히는 질문들이 있다.
- 설계 작업도 Story로 만들어야 할까?
- 리팩토링은 기능이 아닌데 Task로 둬야 하나?
- Story Point에 기술 작업이 섞이면 PO는 요구사항 진척률을 어떻게 파악하지?
이 글은 그런 고민을 팀 운영 관점에서 정리한 결과다.
이 혼란은 지표를 하나로 보려는 데서 시작된다.
1. Velocity와 요구사항 진척률은 다르다
먼저 혼란의 원인부터.
Velocity는 요구사항 진척률 지표가 아니다. 팀이 얼마나 안정적으로 일을 처리하는지, 다음 스프린트를 얼마나 예측 가능하게 계획할 수 있는지를 보기 위한 지표다.
근데 PO가 알고 싶은 건 그게 아니다.
“전체 요구사항 대비 지금 몇 % 왔나요?”
이 두 질문을 Story Point 하나로 해결하려는 순간 문제가 시작된다.
2. 기능만 Story로 만들면 생기는 문제
많은 팀이 처음에는 이렇게 접근한다.
- 사용자 기능 → Story
- 설계나 리팩토링 → Task
깔끔해 보인다. 근데 몇 스프린트만 지나면 문제가 드러난다.
- 설계와 기반 작업이 항상 뒤로 밀린다
- 팀은 분명 바쁜데 Velocity는 낮아 보인다
- “설계는 공짜인가?”라는 인식이 퍼지기 시작한다
관제나 플랫폼, 엔터프라이즈 성격의 제품이라면 이 구조가 기술부채를 빠르게 키운다.
3. 그럼 전부 Story로 만들면?
반대로 생각해볼 수 있다. 가능한 건 다 Story로 만들면 되지 않을까?
절반만 맞는 말이다.
모든 작업을 Story로 만들면 Story의 의미가 흐려진다. 기능 진척률도 읽을 수 없게 된다.
필요한 건 Story의 포기가 아니라 Story의 분리다.
4. Story를 두 가지로 나눈다
여기서 도달한 결론. Story는 하나의 타입이지만 의미는 두 가지로 나뉜다.
4.1 Functional Story
사용자가 직접 인지하고 사용하는 기능을 제공하는 Story. 기능 요구사항을 충족하거나 변경하거나 확장하는 작업이 여기 해당한다.
특징:
- 사용자 관점의 동작 변화가 있음
- 데모 가능
- “된다 / 안 된다”로 검증 가능
- 요구사항 진척률 산정 대상
예시:
- 내부 조종자가 임무를 생성할 수 있다
- 사용자 요청에 따라 임무 생성 절차가 변경된다
4.2 Enablement Story
기능 Story가 구현되고 안정적으로 동작하고 확장될 수 있도록 만드는 Story. 설계나 구조 개선, 품질이나 성능, 운영 기반을 마련하는 작업들이다.
특징:
- 사용자가 직접 인지하지 않음
- 기능을 가능하게 하거나 리스크를 줄이는 역할
- Velocity에는 포함되지만 요구사항 진척률에는 미포함
예시:
- 임무 생성 기능을 가능하게 하기 위한 상태 전이 구조 정비
- 임무 편집 안정성을 확보하기 위한 기본값 설정
- 대규모 임무 확장을 위한 모듈 리팩토링
5. Summary 작성 규칙
Story를 나눴으면 요약 형식도 달라야 한다.
- Functional Story →
[사용자]가 [행위]를 할 수 있다 - Enablement Story →
[기능]을 가능하게 하기 위한 [기반/개선/정비]
이것만 지켜도 백로그 훑을 때 어떤 성격인지 바로 보인다.
6. 왜 Task가 아니라 Story인가
이렇게 나누면 꼭 나오는 질문이 있다.
“Enablement를 그냥 Task로 두면 안 돼요?”
된다. 근데 대부분의 팀에서 비슷한 문제가 생긴다.
- Task는 우선순위 회의에서 밀린다
- Story Point 붙은 Task는 해석이 혼란스럽다
- 설계와 기술 투자가 잡무 취급받기 쉽다
Enablement는 Story로 격상시키되 지표 해석만 분리하는 게 낫다.
7. 버그와 기본값 설정은?
실제로 분류하다 보면 애매한 것들이 나온다.
버그:
- 요구사항을 깨는 버그 → Functional Story
- 구조나 안정성, 품질 문제 → Enablement Story
- 사소한 UI나 운영성 버그 → Task 또는 Bug
기본값 설정:
- 사용자에게 기능으로 인식되면 → Functional
- 내부 안정화 목적이면 → Enablement
기준은 하나. “이게 사용자에게 새로운 약속인가?“
8. 진척률은 어떻게 보여줄까
분류 체계가 잡히면 지표 해석도 명확해진다.
- Velocity → 모든 Story (Functional + Enablement)
- 요구사항 진척률 → Functional Story만
팀의 실제 노력은 Velocity에, PO가 보고 싶은 기능 진척률은 Functional Story에. 각자 볼 것만 보면 된다.
지표를 하나로 합치려 하지 말고 관점을 분리하자.
9. 기존 Story 정리법
기존 백로그 정리할 때는 재설계하지 말고 의미만 복원하면 된다.
- Story만 필터링
- “기능이 된다 / 기능이 되게 한다”로 분류
- 요약만 규칙에 맞게 수정
Story Point나 완료 여부는 건드리지 않는다. 한 번만 해두면 이후 운영이 훨씬 편해진다.
10. 정리
이 구조의 핵심은 Story를 늘리거나 줄이는 게 아니다. Task를 없애자는 것도 아니다.
일의 의미와 지표의 해석을 분리하는 것.
- 기능 → Functional Story
- 기반과 투자 → Enablement Story
이렇게 나누면 Velocity 논쟁이 줄고 설계가 보호받는다. PO와의 대화도 생산적으로 바뀐다.
물론 이게 정답은 아니다. 팀마다 상황이 다르고 제품 성격에 따라 맞는 방식도 다르다. 중요한 건 “왜 이렇게 나누는가”를 팀이 함께 이해하고 합의하는 것.
우리 팀도 아직 매 스프린트마다 고민하면서 다듬어가는 중이다.
스크럼은 형식이 아니라 의사결정을 돕는 도구다.