Jira 에픽 쪼개기, 스토리 나누는 기준

📌 목차

1. 회원가입 스토리 하나가 계속 늘어났던 순간
2. 크기가 아니라 완결성으로 나눈다
3. 실제 사례로 보는 회원가입 에픽 쪼개기
4. 우리 팀 에픽에 적용하는 3단계
5. 실무 팁 3가지
6. 마무리
7. FAQ

1. 회원가입 스토리 하나가 계속 늘어났던 순간

회원가입 기획서를 쓸 때 화면 하나, 스토리 하나면 충분하다고 생각했습니다. 그런데 개발 단계에 들어가니 인증 방식, 오류 처리, 약관 동의 같은 조건들이 하나씩 튀어나오면서 스토리가 계속 늘어났습니다. 처음 잡은 스토리 하나로는 감당이 안 됐고, 그제야 에픽을 어떻게 쪼개야 하는지 제대로 고민하게 됐습니다.

돌아보면 문제는 쪼개는 타이밍이 아니라 쪼개는 기준이 없었다는 것이었습니다. 이번 글에서는 에픽을 스토리로 나눌 때 크기가 아니라 어떤 기준으로 잘라야 하는지, 그 기준을 실제 사례에 적용하는 과정까지 정리해보겠습니다.

2. 크기가 아니라 완결성으로 나눈다

에픽을 스토리로 쪼개라는 말을 들으면 흔히 "더 작게 나누면 된다"고 생각합니다. 하지만 작게 나누는 것과 제대로 나누는 것은 다른 문제입니다. 작게만 나누면 서로 의존하는 조각들이 생기고, 하나가 늦어지면 나머지도 같이 멈춥니다.

레고에 비유하면 이해가 쉽습니다. 에픽은 완성된 세트 전체이고, 스토리는 그 세트 안에서 조립을 멈춰도 그 자체로 서 있는 하나의 구조물입니다. 바퀴 하나, 창문 하나 같은 낱개 블록은 태스크에 가깝습니다. 스토리를 나눌 때 기준으로 삼아야 할 것은 크기가 아니라 "혼자서도 서 있을 수 있는가"입니다.

2일차 용어 정리 글에서 "회원가입 개선"을 에픽의 예시로 든 적이 있습니다. 그 글이 에픽과 스토리가 무엇인지 정의하는 글이었다면, 이번 글은 그 에픽을 실제로 어떻게 쪼갤지에 대한 글입니다.

쪼개는 기준은 아래 세 가지로 정리할 수 있습니다.

기준	확인할 질문
사용자 가치	이 조각만으로도 사용자에게 의미가 있는가
검증 가능	완료 여부를 테스트로 확인할 수 있는가
독립 배포	다른 조각 없이 이것만 배포할 수 있는가

3. 실제 사례로 보는 회원가입 에픽 쪼개기

다시 회원가입 이야기로 돌아가 보겠습니다. 처음 스토리 하나로 잡았던 범위 안에는 사실 성격이 다른 네 가지 조각이 섞여 있었습니다. 개발 중에 튀어나왔던 조건들을 위 세 기준으로 미리 확인했다면 아래처럼 나눌 수 있었습니다.

후보 스토리	사용자 가치	검증 가능	독립 배포
이메일과 비밀번호로 계정을 생성할 수 있다	○	○	○
약관에 동의해야 다음 단계로 진행된다	○	○	○
잘못된 형식을 입력하면 오류 메시지를 확인할 수 있다	○	○	○
가입 후 인증 메일을 받고 인증을 완료할 수 있다	○	○	○

네 조각 모두 세 기준을 통과했기 때문에 각각 독립된 스토리가 됩니다. 반대로 "회원가입 화면을 예쁘게 다듬는다"처럼 사용자 가치는 있어도 검증 문장으로 쓰기 어려운 조각은 스토리보다 다른 스토리의 세부 작업으로 넣는 편이 낫습니다.

처음부터 이렇게 네 조각으로 나눠 놓았다면, 개발 중 조건이 "튀어나온다"는 느낌 대신 "이미 나눠둔 상자 중 하나에 담긴다"는 느낌으로 바뀌었을 것입니다.

4. 우리 팀 에픽에 적용하는 3단계

1. 1단계. 에픽의 최종 목표를 한 문장으로 쓴다 "회원가입 기능을 추가한다"처럼 이 에픽이 끝났을 때 무엇이 가능해지는지 한 문장으로 정리합니다.
2. 2단계. 그 목표에 필요한 사용자 행동을 나열한다 계정 생성, 약관 동의, 오류 확인, 이메일 인증처럼 사용자가 실제로 거치는 행동을 빠짐없이 적습니다.
3. 3단계. 세 기준으로 각 행동이 독립된 스토리가 되는지 검증한다 사용자 가치, 검증 가능, 독립 배포 세 질문에 모두 "예"로 답할 수 있으면 스토리로 확정합니다. 하나라도 "아니오"면 다른 스토리에 포함시키거나 기준을 더 좁혀 다시 씁니다.

5. 실무 팁 3가지

팁1. 사용자가 얻는 결과 단위로 자른다

스토리 제목은 화면이나 기능이 아니라 사용자가 무엇을 할 수 있게 되는지로 씁니다. "회원가입 화면 만들기"보다 "이메일과 비밀번호로 계정을 생성할 수 있다"처럼 쓰면, 이 스토리가 끝났을 때 무엇이 완성되는지 팀 전체가 같은 그림을 그릴 수 있습니다.

팁2. 한 스프린트 안에 끝나는 크기로 자른다

세 기준을 통과했더라도 작업량이 스프린트를 넘어선다면 다시 쪼갤 신호입니다. 예를 들어 "이메일 인증"이 발송, 인증번호 확인, 재발송까지 포함해 너무 커진다면, 발송과 확인만 우선 스토리로 잡고 재발송은 다음 스토리로 미룰 수 있습니다.

팁3. 완료를 확인할 수 있는 단위로 자른다

"이 스토리가 끝났다"를 테스트 한두 줄로 설명할 수 없다면 아직 덜 쪼개진 것입니다. QA가 무엇을 확인하면 되는지 스토리 작성 시점에 함께 적어두면, 나중에 "이거 끝난 거 맞나요"라는 질문 자체가 줄어듭니다.

다만 이 기준을 지나치게 엄격하게 적용하면 스토리 수가 필요 이상으로 늘어나 보드가 오히려 복잡해질 수 있습니다. 기준은 참고 틀이지, 모든 에픽에 기계적으로 적용할 규칙은 아닙니다. 팀의 스프린트 주기와 인원에 맞춰 조각의 크기를 조절하시기 바랍니다.

6. 마무리

오늘 내용 3줄 요약

• 에픽을 스토리로 나눌 때 기준은 크기가 아니라 완결성입니다.
• 사용자 가치, 검증 가능, 독립 배포 세 가지 질문으로 스토리 여부를 판단할 수 있습니다.
• 목표를 한 문장으로 쓰고, 사용자 행동을 나열한 뒤, 세 기준으로 검증하는 3단계로 적용합니다.

지금 진행 중인 에픽이 있다면 이 세 가지 기준으로 한 번 쪼개보세요.

Jira를 다시 익히는 중이시라면 Jira 기획자 가이드 허브 글에서 지금 상황에 맞는 글을 먼저 찾아보셔도 좋습니다.

7. FAQ

Q. 스토리가 너무 작아지면 오히려 관리가 번거롭지 않나요?

맞습니다. 스토리 수가 지나치게 늘어나면 보드 관리가 오히려 복잡해질 수 있습니다. 세 기준을 통과했어도 작업량이 아주 작다면, 관련된 스토리 안에 하위 작업으로 묶는 편이 나을 때도 있습니다.

Q. 에픽 하나를 여러 담당자가 나눠 맡을 때도 이 기준이 통하나요?

오히려 담당자가 여러 명일 때 더 필요합니다. 스토리가 독립 배포 기준을 통과하면 담당자마다 서로의 작업을 기다리지 않고 각자의 스토리를 진행할 수 있습니다.

Q. 에픽을 쪼개는 시점은 언제가 적절한가요?

스프린트에 넣기 직전이 아니라 에픽을 처음 등록하는 시점에 한 번 쪼개보시길 권합니다. 이 글의 사례처럼 개발 중에 조건이 하나씩 튀어나오는 상황을 미리 줄일 수 있습니다.