지라 이슈 타입 (story 냐 task 냐..)

오늘은 이슈 생성 방식부터 이슈 간 연결, 그리고 완료까지 걸린 시간을 측정하는 방법까지 심층적으로 살펴보았다.

1. 에픽(Epic), 스토리(Story), 태스크(Task), 버그(Bug), 서브태스크(Subtask)의 구조와 적당한 크기

• Epic (에픽)
  • 큰 작업 패키지, 3~10개의 스토리/태스크 묶음
  • 이상적으로 3개월 이내 완료 가능
• Story (스토리)
  • 고객에게 직접 가치 제공, 한 스프린트(1~4주) 안에 완료 가능
  • 권장 기간: 3~5일로 1주일 이내에 완료될 수 있는 크기로 계획
    • 보통 1주일 정도 소요되는 스토리는 마이크로매니지먼트를 피하면서도 진행 상황을 추적하기에 적당한 균형점을 제공한다
• Task (태스크)
  • 비기능적 작업(예: 문서화, 마케팅 등)
  • 스토리와 동일 계층
• Bug (버그)
  • 오류 수정, 중요도와 긴급성이 핵심
  • 서브태스크로 세부 조치 사항 기록 가능
• Subtask (서브태스크)
  • 스토리/태스크/버그의 세부 단계, 1일 이내 소요가 이상적

지라 이슈 타입

앞서 지라에서는 story 와 task 를 동일한 레벨에서 사용하고 story point 를 주고 싶을떄 story 를 사용한다고 했지만 조금 더 자세하게 story 와 task 를 정의해보자면 story는 끝났을때 사용자가 뭔가를 할수있다 라고 말할 수 있는것이다. 예를들면 "사용자가 비밀번호 재설정 할 수 있다" 거나 "모바일 앱에서 상품을 결제할 수 있다" 이런류의 작업이고 이 스토리가 완료된다고 하면 사용자가 어떤 이익을 얻을 수 있다.

반면 task 는 내부적 기술작업 같은 일로 고객에게 직접적으로 노출 되는 일은 아니다. 고객에게 바로 전해줄 가치는 없지만 반드시 해야하는 작업이다. 예를를면 코드 리팩토링, 서버 설정, 데이터베이스 마이그레이션 작업등이 태스크에 해당한다. 이 태스크가 완료되더라고 고객에게 전달하는 가치는 꼭 있는게 아니다(있을수도 있다) 

질문	답이 YES → Story	답이 NO → Task
이 작업이 끝나면 고객이 직접 이득을 보나요?	✅	❌
고객/사용자가 요구한 기능인가요?	✅	❌
결과물이 UI나 사용자 플로우에 보이나요?	✅	❌
내부 기술적 개선/유지보수 작업인가요?	❌	✅

그래서 어떤팀은 story 만 사용하고 task 는 아예 안쓰는 경우도 있고 어떤 팀은 story 는 기능! task 는 기술작업으로 명확하게 구분하는 경우도 있다고 한다. 유연하게 팀에 맞게 규칙을 세우는게 중요하다.

 

2. Linked Issues의 의미와 사용

• blocks / is blocked by: 순차적 의존 관계 표시 (A가 끝나야 B 진행)
• clones / is cloned by: 동일한 원본에서 파생, 각자 독립적으로 진행
  • Clone: 복사해서 다른 방향으로 발전할 경우 clone 을 떠서 진행
• duplicates / is duplicated by: 동일한 문제의 중복 티켓
  • Duplicate는 이슈를 삭제하는 대신 원본과 연결하고 해결 시 함께 완료 처리하는게 기록상 좋다
  • 해결될때는 원본 이슈 하나만 처리완료하면 된다
• relates to: 연관성만 있는 경우

3. 에픽 관리 방법

• Kanban
  • 에픽을 보드에서 드래그 앤 드롭으로 우선순위 조정
  • 다른 상태로 이동 가능
• Scrum
  • 에픽 패널 활성화 필요! (잘 안보임)
    • 방법: 백로그 상단 Epics 클릭 → 토글 스위치 ON
  • 패널에서 진행률, 하위 이슈, 스토리 포인트 확인
  • 에픽에 바로 이슈 추가 가능

4. Story Points vs Original Estimate

이슈(epic, story, task) 등록시 세부사항 영역에 stroy points 와 original estimate 는 해당 이슈가 얼마나 걸릴까를 나타내는 지표이지만 쓰임새와 철학은 완전히 다르다.

Original Estimate 는 이 일을 완료하는데 "실제 몇 시간" 이 걸릴지? 를 나타내지만 Story Points 는 이 일이 얼마나 복잡한지 "상대적으로 평가" 하는 방식이다.

구분	Original Estimate	Story Points
개념	작업 시간(시간/일) 단위로 추정	상대적 난이도 및 복잡도로 추정
단위	시간 단위 (예: 3h, 2d)	숫자(1, 3, 5, 8 등, 피보나치 사용 多)
사용 맥락	워터폴(전통적 PM)에 가깝다	애자일(Scrum, Kanban)에서 사용
포커스	얼마나 “걸릴지” (속도 = 시간)	얼마나 “어려운지” (속도 = 팀 벨로시티)
예측 방식	실제 소요시간 예측	상대적 규모로 팀의 처리 속도 기반 예측
활용	일정 관리, 리소스 배분	스프린트 계획, 버전 관리, 팀 역량 측정

Original Estimat 에서는 "이게 몇시간 걸리는 작업이지" 를 물어본다면 Story Points 는 "이거 지난번 그 이슈보다 얼마나 더 어렵나?" 처럼 난이도, 복잡성, 위험도까지 고려해서 상대적인 크기를 추정한다. 

Story Points 를 추정하는 방식은 여러가지가 있지만 보통 피보나치 수열(1, 2, 3, 5, 8, 13, 21…)을 자주 사용한다고 한다. 피보나치 수열로 정한 Story Points 에서는 그 크기가 커질수록 불확실성이 크다.

우리 팀은 지난 스프린트에서 평균 30 stroy pints 를 처리했다라고 하면 우리 팀의 속도(Velocity)는 30이라고 본다. 이렇게 정해두면 다음 스프린트를 계획할때 우리 팀의 속도가 평균 30이니까 이번에도 30 Story Points 정도를 잡고 시작할 수 있다. 그리고 대략 3개의 스프린트를 소화해야한다면 역으로 90 story points 가치의 프로젝트를 끝낼 수 있다 생각할 수 있어서 한눈에 팀의 생산성도 확인 가능하다. 

즉 Story Points 는 개별 작업의 상대적 크기이고 Velocity(속도)는 팀의 한 스프리느 처리량을 말한다. 속도는 팀마다 다르고 심지어 프로젝트마다 다르다. 

복잡한 프로젝트에서는 두개의 측정 방식을 같이 쓰는 경우도 있다고 한다. Story Points 로 팀의 속도를 추정하고 Original Estimate 는 실제 일정을 관리하는 용도를 사용하는 예를 들 수 있다.

 

다음에는 지라에서 기본으로 제공하는 이슈유형 말고도 custom 이슈 유형을 만드는 방법에 대해서 정리해 보려고 한다.

지라의 새로운 이슈 타입? (feat. 위험 관리 플랜)