애자일 에픽: 정의, 예시 및 템플릿

애자일 및 DevOps를 채택할 때 에픽은 작업을 관리하는 역할을 합니다. 고객 또는 최종 사용자의 요구/요청에 따라 특정 작업("스토리" 또는 "사용자 스토리")으로 세분화되는 정의된 작업 구조입니다. 작업 추적 템플릿을 사용하면 팀이 작업을 효과적으로 체계화하고 우선 순위를 지정하고 모니터링할 수 있습니다.

에픽은 작업을 구성하고 계층 구조를 만드는 데 유용한 방법입니다. 아이디어는 작업을 제공 가능한 작업으로 나눠 대규모 프로젝트를 실제로 수행하고 정기적으로 고객에게 가치를 제공할 수 있게 합니다. 에픽은 팀이 작업을 나눠 동시에 더 큰 목표를 향해 계속 노력할 수 있도록 도와줍니다.

에픽과 같은 대규모 작업을 구성할 때 민첩성을 유지하는 것은 작은 일이 아닙니다. 에픽이 건강한 애자일 및 DevOps 모범 사례와 어떤 관련이 있는지 배우는 것은 조직 규모에 관계없이 필수적인 기술입니다.

에픽은 여러 개의 작은 스토리(또는 종종 Jira에서 “이슈”라고 부름)로 나뉠 수 있는 대규모 작업입니다. 에픽은 종종 여러 프로젝트의 여러 팀을 포괄하며 여러 보드에서 추적할 수도 있습니다.

에픽은 거의 항상 스프린트의 집합을 통해 제공됩니다. 팀이 개발 및 고객 피드백을 통해 에픽 대해 더 많이 알게 되면 필요에 따라 사용자 스토리를 추가 및 제거합니다. 이것이 애자일 에픽의 핵심입니다 - 범위는 유연하며 고객 피드백과 팀 케이던스를 기반으로 합니다.

지금은 2050년이고 레크리에이션 우주 여행 조직에서 일한다고 가정해 보겠습니다. 우리는 일년에 약 12번의 발사를 수행하므로 각 발사가 1년 동안 하는 가장 큰 일은 아니지만 여전히 일상적인 작업과는 거리가 멀고 완료하는 데 많은 인력과 시간이 소요될 것입니다. 그러한 규모는 에픽에 적합합니다.

예시 에픽인 “2050년 3월 우주 관광 로켓 발사”에는 우주 여행 티켓을 구매하는 고객부터 로켓 자체 발사에 이르기까지 왕복선 발사의 주요 측면을 개선하기 위한 스토리뿐 아니라 일상적인 작업 항목에 대한 스토리가 포함되어 있습니다. 따라서 여러 팀이 다양한 스토리를 만들어 이 에픽에 기여할 것입니다.

2050년 3월 발사 티켓 구매를 지원하는 소프트웨어 팀은 다음과 같이 에픽을 구성할 수 있습니다.

동시에 추진력 팀은 다음 스토리를 통해 동일한 에픽에 기여할 수 있습니다.

에픽은 개발 팀이 성공하는 데 필요한 모든 것을 제공해야 합니다. 실질적인 관점에서 볼 때 에픽은 작업 계층 구조의 최상위 계층입니다. 그러나 에픽이 다른 애자일 구조와 어떻게 관련되어 있는지 이해하면 일상적인 개발 작업에 중요한 컨텍스트를 얻을 수 있습니다.

• 제품 로드맵은 시간이 지남에 따라 제품 또는 솔루션이 어떻게 발전할 것인지에 대한 실행 계획입니다.
• 테마는 에픽과 이니셔티브의 창출을 주도하는 조직 목표입니다.
• 제품 로드맵은 타임라인을 따라 플롯한 일련의 이니셔티브로 표현되고 시각화됩니다.
• 이니셔티브를 에픽으로 분할하면 팀의 일상 업무(작은 스토리로 표현)가 전반적인 비즈니스 목표와 연결될 수 있습니다.

완성된 일련의 에픽은 특정 이니셔티브를 주도하여 조직의 테마 외에도 시장 및 고객 요구에 따라 전체 제품을 개발하고 발전시킵니다.

위의 예시에서 테마는 우주 왕복선 발사를 늘리는 것이고, 로드맵은 분기당 3회에서 4회로 증가한 발사를 추적하는 것이며, 이니셔티브는 비용을 낮추고 티켓 판매를 늘리는 것이고, 각 에픽은 이니셔티브로 롤업됩니다.

새로운 에픽을 만들 때는 팀이 이미 갖추고 있을 수 있는 다른 계획 및 구성 도구를 고려하세요. 팀의 분기별 목표 또는 OKR을 중심으로 에픽을 만드는 것은 좋은 시작입니다. 에픽을 만들 때는 다음 사항을 고려하세요.

• 보고 — 관리자와 경영진이 주목하려는 프로젝트에 대한 에픽을 만듭니다.
• 스토리텔링 — 에픽과 에픽으로 롤업되는 스토리를 기능 또는 제품의 현재 상태에 어떻게 도달했는지에 대한 스토리를 전달하는 메커니즘으로 사용합니다.
• 문화 — 조직 문화에 따라 에픽의 규모와 세분화 정도가 결정됩니다.
• 시간 — 대부분의 개발 팀은 시간이 아닌 추정 프레임워크에 의존하지만 에픽을 완료하는 데 몇 주가 걸리는지 확인하는 것이 좋습니다. 너무 길지 않고 너무 짧지도 않아야 합니다.

Jira에서 에픽이 어떻게 작동하는지 알아보세요.

에픽을 좀 더 실질적인 스토리로 분할하면 프로젝트를 이해하고 추진력을 유지하는 데 도움이 되지만 초보자에게는 어려운 작업일수 있습니다. 에픽에서 스토리를 만들 수 있는 완벽한 솔루션은 없지만 고려해야 할 좋은 옵션이 많이 있습니다.

• 사용자 역할 또는 페르소나 — '신규 방문자를 위한 더 빠른 로그인”, “재방문 고객을 위한 더 빠른 로그인' 등 각 사용자 페르소나에 대해 고유한 스토리를 만듭니다.
• 순서가 지정된 단계 — 프로세스를 세분화하고 각 단계에 대한 스토리를 만듭니다.
• 문화 — 스토리가 빠른 작업인지 일주일 동안 진행되는 프로젝트인지 팀 기준에 따라 결정하도록 합니다.
• 시간 — 합의된 다른 규칙이 없다면 한 개의 스프린트 이하로 완성할 수 있는 스토리를 디자인합니다.

큰 스토리와 에픽 사이에 선을 긋는 보편적 정의는 없습니다. 일반적으로 팀이 '시간'이나 '일'이 아닌 '주'(또는 그 이상) 단위로 추정하는 모든 작업 범위는 에픽으로 간주하고 더 작은 스토리로 분할해야 합니다.

번다운 차트는 에픽을 시각화하고 팀에 동기를 부여하고 임원진 이해 관계자에게 정보를 제공하는 데 사용할 수 있습니다. 훌륭한 에픽 번다운 차트에서는 조직의 민첩성이 실제로 빛을 발휘합니다.

에픽 번다운 차트는 스프린트 또는 에픽에서 수행해야 할 실제 및 예상 작업량을 보여줍니다. 번다운 차트의 가로 x축은 시간을 나타내고 세로 y축은 스토리 또는 이슈를 나타냅니다.

번다운 차트를 사용하여 남은 총 작업을 추적하고 스프린트 목표 달성 가능성을 예측할 수 있습니다. 반복 과정에서 남은 작업을 추적하여 팀은 진행률을 관리하고 그에 따라 대응할 수 있습니다.

번다운 차트를 모니터링하면 팀이 어떻게 진행하고 있으며 어떤 장애물이 있는지 명확히 파악할 수 있습니다. 이러한 데이터 포인트를 명확하게 표시하면 모든 팀원이 같은 정보를 공유할 수 있으며 제품의 발전 및 완료 예측에 대한 열린 대화가 가능하게 됩니다. 투명성이 신뢰를 쌓는다는 것은 말할 것도 없습니다!

Jira에서 번다운 차트를 구성하는 방법 알아보기

에픽과 스토리를 만드는 기술을 마스터한 후에는 자동화를 사용하여 한 단계 더 나아가 최적화할 수 있습니다. 다음은 Jira에서 스프린트에 사용되는 가장 일반적인 세 가지 자동화 규칙입니다.

1. 에픽을 만들 때 자동으로 세 개의 스토리를 추가합니다. 규칙으로 이동하세요.
2. 에픽이 완료로 표시되면 스토리를 자동으로 닫습니다. 규칙으로 이동하세요.
3. 연결된 이슈 중 하나의 상태가 변경되면 에픽의 상태를 변경합니다. 규칙으로 이동하세요.

Jira Automation 템플릿 라이브러리에서 이러한 자동화 규칙과 수백 개의 추가 자동화 규칙을 확인하세요.

라이브러리로 이동

에픽은 애자일 프로그램의 절대적인 기반은 아니지만 대부분의 애자일 및 DevOps 팀을 위한 실질적인 동인입니다. 건강한 애자일 프로그램에서 에픽의 위치를 이해하면 작업에 대한 컨텍스트를 만들고 스토리로 분류하여 추진력을 만들 수 있습니다.