어떻게 하면 Jira Ticket을 잘 만들 수 있을까(1)

배경

최근 이직한 회사에서의 티켓 발급의 어려움으로 Jira Ticket TF를 만들어서 짧게 스터디하고 사내 다른 팀은 어떻게 했는지 레퍼런스도 모아 제시했습니다. 공개가 가능한 선에서 요약해서 내용을 블로그에 기록합니다. 

문제인식

1. 티켓 작성 시 과도한 고민 소요

• 문제점: Jira 티켓을 만들 때 제목과 내용을 어떻게 작성해야 할지 매번 고민하는 시간이 발생함.
• 영향: 작업 시작 전 반복적인 의사결정 비용이 들고, 일관성 없는 티켓 작성으로 인해 협업 시 맥락 파악이 어려움.

2. 에픽, 스토리, 태스크의 구분 기준 불명확

• 문제점: 작업을 어떤 수준의 티켓(에픽 / 스토리 / 태스크 / 하위 태스크)으로 나누어야 할지 판단이 어려움.
• 영향: 구성원 간 티켓 분류 방식이 달라져 작업 단위 설정에 혼선이 생기며, 티켓을 생성하거나 분해할 때 불필요한 논의나 시간이 소요됨.

3. 코드의 배경 추적 불가

• 문제점: 특정 코드가 어떤 이슈나 요구사항으로 인해 작성되거나 변경되었는지를 명확히 파악하기 어려움.
• 영향: 유지보수나 리팩터링 시 관련된 의도와 맥락을 파악하는 데 시간이 소요되며, 신규 인원이 시스템을 이해하고 적응하는 데 어려움을 겪을 수 있음. 또한, 동일한 논의가 반복되는 비효율이 발생할 가능성도 있음.

4. 일정 산정의 어려움

• 문제점: 에픽의 전체 기간, 각 스토리 및 태스크 단위의 작업 기간을 구체적으로 추정하기 어려움.
• 영향: 일정이 부정확하게 계획되며, 프로젝트 관리 및 리소스 배분에 영향을 끼침.

 

티켓 잘만드는 것은 어떤 효과를 가져다 줄 수 있을까?

https://www.atlassian.com/agile/project-management/user-stories

User Stories | Examples and Template | Atlassian

• 생산성 향상을 가져오기는 하지만 구체적으로 어떤 기준으로 얼만큼 상승한다라는 자료는 찾기가 어렵습니다.
  • 그러나 아래의 효과가 있을 것으로 기대됩니다.
    • Ticket에 대한 배경및 내용을 스토리카드안에서 대부분 확인할 수 있다. → 매니저님은 대부분의 티켓이 생성된 이유, 목적, 종료일자 등에 대해서 전반적으로 파악할 수 있다.
    • 작업자는 구체화된 작업의 범위와 목적에 따라 최소단위로 작업하여 배포주기를 짧게 가져갈 수 있다.
    • 작업자가 교체되거나 새로운 사람이 들어올 때 온보딩의 시간을 줄일 수 있다. → 일관된 스토리카드 포멧 유지가 되기 때문에 → 티켓의 이유와 효과 또는 결과에 대한 내용이 카드에 써져 있기 때문에

해결방안

1. 무엇을 티켓으로 만들까?

(토스의 PO Session 영상 플레이리스트를 기반)

티켓을 어떻게 만들지 고민하기에 앞서, 무엇을 티켓으로 만들 것인가에 대한 명확한 기준이 필요합니다. 이는 단순히 작업 단위를 나누는 문제를 넘어서, 우리가 지향하는 가치와 업무의 우선순위를 정의하는 문제입니다.

1-1. 영향력 기반의 티켓 구성

• 티켓은 단순한 작업이 아니라 영향력이 있는 단위를 중심으로 작성되어야 합니다.
• 여기서 말하는 영향력이란 다음 두 가지 중 하나에 해당합니다:
  • 비즈니스 가치 향상 (예: 유저 성장, 수익 증가) - 고객이 원하는 것을 만들기
  • 기술적 고도화 (예: 성능 개선, 아키텍처 개선)
• 명확한 작업 (https://youtu.be/Tmj1HEFnKpE?si=-ReVFrPh5m4MnqZA&t=1426)

1-2. 우리 조직의 현재 상태 이해하기

• 우리는 스타트업이다.
  • ‘스타트업’이라는 정체성은 곧 불확실성 속에서 가설을 세우고 실험하는 과정을 의미한다.
  • 특히 제품, 고객, 시장에 대한 불확실성이 크며, 이는 린 스타트업 철학과 맞닿아 있다.

1-3. 액티브 유저와 제품 정의의 필요성

• 제품이 무엇이고, 어떤 유저가 우리의 핵심 유저인지 정의되어야 한다.
• 이를 위해 다음과 같은 개념을 참고할 수 있다:
  • Retention Plateau시간이 지나도 유지되는, 충성도 높은 재방문 유저 수를 의미한다.
  • → 실제 고객이 남아있는 지표로 활용 가능
  • retention = 재방문율이라고 의미를 사용함 명사로 보유, 유지 plateau = 고원

• Carrying Capacity(Inflow – 신규 유입, Churn – 이탈 유저를 기반으로 계산)
  → 주로 B2C에 적용되지만, B2B 환경에서도 사용 시간을 통한 대체 지표로 응용 가능
  마케팅 등의 외부 투입 없이도 유지 가능한 유저 수를 예측하는 공식.
  
  

• 전략적으로 볼 때 다음 두 방향으로 나뉜다:
  • 이탈을 줄이는 전략: 사용성 개선, 버그 수정 등 → 보완 중심
  • 유입을 늘리는 전략: 신규 기능 개발, 확장 등 → 성장 중심
• 선택한 전략에 따라 우선 진행해야 할 에픽과 스토리가 결정될 수 있다.

1-4. 의사결정과 관리를 위한 PO 역할의 중요성

• 이처럼 전략의 선택과 우선순위 결정은 누군가가 전체 그림을 보고 방향을 설정해야 가능한 일이다.
• 이를 위해 Product Owner(PO) 역할이 반드시 필요하다.

구분	Product Manager (PM)	Project Manager (PjM)	Product Owner (PO)
초점	제품의 시장 성공	프로젝트의 일정/완수	기능의 우선순위와 전달
책임	무엇을 만들까? 왜?	어떻게 잘 끝낼까?	무엇을 먼저 만들까?
위치	비즈니스 측	운영/관리 측	스크럼 개발팀 내부
관점	전략/비전 중심	실행/관리 중심	기능/개발 중심

2. 어떻게 티켓을 만들까?

• 현재 재직중 회사는 Jira를 도입하고 있기 때문에 Jira의 컨셉에 대해 알아야함
• 지라는 이슈 중심의 프로젝트 및 워크플로우 관리 도구.

Epic
 └── Story (User Story)
      ├── Sub-task
 └── Task
      ├── Sub-task
 └── Bug
      ├── Sub-task

Jira는 애자일 개발 방식, 특히 스크럼(Scrum)을 기반으로 설계되어 Epic, Story, Sprint 등의 용어와 구조를 사용하는 것이다.

참고로 애자일(반복적이고 점진적인 개발 방법) 방식에는

애자일 방법론과 종류 참고

1. 스크럼 (Scrum)

가장 널리 쓰이는 애자일 방법론

• 특징:
  • 고정된 기간의 스프린트 (보통 1~4주)
  • 매일 하는 데일리 스크럼(스탠드업)
  • 정기적인 회고 및 리뷰
  • Product Owner, Scrum Master, 개발 팀의 명확한 역할 분리

---

2. 칸반 (Kanban)

작업의 흐름(Flow)을 시각화하고 지속적으로 개선하는 방식

• 특징:
  • WIP(Work In Progress, 진행 중 작업 수) 제한
  • 스프린트 없음, 연속적인 작업
  • 보드(컬럼: Todo / In Progress / Done) 중심

---

3. XP (Extreme Programming)

소프트웨어 품질 향상과 빠른 릴리스를 목표로 하는 개발 중심 방식

• 특징:
  • 짝 프로그래밍 (Pair Programming)
  • 테스트 주도 개발 (TDD)
  • 지속적인 통합 (CI)
  • 리팩토링 중시

---

4. Lean (린 소프트웨어 개발)

Toyota의 린 생산방식을 소프트웨어에 적용

• 특징:
  • 낭비 제거
  • 빠른 피드백
  • 지식 창출
  • 팀 권한 강화

---

5. DSDM (Dynamic Systems Development Method)

기업 환경에 맞춘 빠르고 통제된 개발 방식

• 특징:
  • 시간과 예산을 고정하고 범위를 조정
  • 반복적인 개발과 지속적인 피드백

---

6. FDD (Feature-Driven Development)

기능 중심으로 개발을 계획하고 진행

• 특징:
  • "기능" 단위로 계획 → 설계 → 개발
  • 모델링과 설계 중심
  • 큰 조직이나 유지보수에 적합

---

7. Crystal

팀 규모와 프로젝트 중요도에 따라 프로세스를 유연하게 조정

• 특징:
  • 문서화 수준과 절차를 팀 상황에 맞게 조절
  • 경량화되고 실용적인 접근

다음 글에서는 Epic, Story, Task 에 는 어떤걸 적어야 할지 실무관점에서 살펴보도록 합니다.

https://joonikiwoogi.tistory.com/78

어떻게 하면 Jira Ticket을 잘 만들 수 있을까(2)-Epic, Story, Task