Azure Boards 작업 항목 작성 가이드

Epic, Feature, User Story, Task를 효과적으로 관리하는 방법

Azure Boards에서 작업 항목을 체계적으로 작성하고 관리하는 실용적인 방법을 알아본다. 실제 프로젝트 예시를 통해 Epic부터 Task까지의 계층 구조와 작성 원칙을 이해한다.

Engineering
DevOps
저자

Kwangmin Kim

공개

2023년 01월 03일

1 작업 항목 계층 구조 이해

Azure Boards에서 작업 항목은 다음과 같은 계층 구조를 가진다:

각 레벨의 목적과 특징을 이해하는 것이 효과적인 프로젝트 관리의 첫걸음이다.

2 Epic 작성 가이드

Epic은 큰 비즈니스 목표나 테마를 나타내는 최상위 작업 항목이다.

2.1 Epic 제목 작성 원칙

“[비즈니스 영역] + [목적]” 형태로 작성

2.1.1 좋은 Epic 제목 예시

  • “온라인 쇼핑몰 구축”
  • “사용자 인증 시스템 개발”
  • “모바일 앱 성능 최적화”
  • “데이터 분석 대시보드 구현”

2.1.2 나쁜 Epic 제목 예시

  • “개발 작업” (너무 모호함)
  • “버그 수정” (Epic 수준이 아님)
  • “로그인 버튼 추가” (너무 구체적함)

2.2 Epic 작성 템플릿

# Epic: [비즈니스 목표]  

## 비즈니스 가치  
- 왜 이 Epic이 필요한가?  
- 어떤 비즈니스 문제를 해결하는가?  

## 성공 기준  
- [ ] 구체적이고 측정 가능한 목표 1  
- [ ] 구체적이고 측정 가능한 목표 2  
- [ ] 구체적이고 측정 가능한 목표 3  

## 예상 일정  
- 시작일: YYYY-MM-DD  
- 목표 완료일: YYYY-MM-DD  

## 관련 이해관계자  
- 제품 책임자: [이름]  
- 개발 팀: [팀명]  
- 비즈니스 담당자: [이름]  

2.3 실제 Epic 예시

Epic: “전자상거래 결제 시스템 구축”

## 비즈니스 가치  
- 고객이 다양한 결제 수단으로 안전하게 결제할 수 있도록 함  
- 결제 성공률을 95% 이상으로 향상  
- 월 매출 30% 증가 목표  

## 성공 기준  
- [ ] 신용카드, 계좌이체, 간편결제 지원  
- [ ] 결제 성공률 95% 이상 달성  
- [ ] 평균 결제 완료 시간 30초 이내  
- [ ] PCI DSS 보안 인증 획득  

## 예상 일정  
- 시작일: 2023-06-01  
- 목표 완료일: 2023-09-30  

3 Feature 작성 가이드

Feature는 Epic을 구성하는 주요 기능 단위이다.

3.1 Feature 제목 작성 원칙

3.1.1 좋은 Feature 제목 예시

  • “신용카드 결제 기능”
  • “사용자 회원가입 프로세스”
  • “상품 검색 필터링”
  • “주문 이력 조회 기능”

3.1.2 Feature 제목 패턴

  • “[기능명] + 기능” 형태 사용
  • 명사형으로 작성
  • 구체적이지만 너무 세부적이지 않게

3.2 Feature 작성 템플릿

# Feature: [주요 기능명]  

## 기능 개요  
이 기능이 무엇을 하는지 간단히 설명  

## 주요 요구사항  
- 요구사항 1  
- 요구사항 2  
- 요구사항 3  

## 기술적 고려사항  
- 사용할 기술 스택  
- 성능 요구사항  
- 보안 고려사항  

## Definition of Done  
- [ ] 개발 완료  
- [ ] 단위 테스트 작성  
- [ ] 코드 리뷰 완료  
- [ ] QA 테스트 통과  

3.3 실제 Feature 예시

Feature: “신용카드 결제 기능”

## 기능 개요  
사용자가 신용카드로 안전하게 결제할 수 있는 기능  

## 주요 요구사항  
- Visa, MasterCard, AMEX 지원  
- 3D Secure 인증 지원  
- 카드 정보 암호화 저장  
- 결제 실패 시 재시도 기능  

## 기술적 고려사항  
- PG사 API 연동 (토스페이먼츠)  
- SSL/TLS 암호화 통신  
- 카드 정보 토큰화  
- 응답시간 5초 이내  

## Definition of Done  
- [ ] PG사 연동 API 개발 완료  
- [ ] 카드 정보 암호화 구현  
- [ ] 결제 프로세스 단위 테스트 작성  
- [ ] 보안 취약점 검사 통과  
- [ ] 사용자 시나리오 테스트 완료  

4 User Story 작성 가이드

User Story는 사용자 관점에서 기능을 설명하는 작업 항목이다.

4.1 User Story 작성 공식

“As a [사용자 유형], I want [기능], so that [목적/이유]”

4.2 좋은 User Story 예시

  • “고객으로서, 저장된 카드 정보를 선택하여 결제하고 싶다. 매번 카드 정보를 입력하는 번거로움을 줄이기 위해서”
  • “관리자로서, 일일 결제 통계를 확인하고 싶다. 매출 현황을 실시간으로 파악하기 위해서”
  • “사용자로서, 결제 실패 시 알림을 받고 싶다. 결제 상태를 즉시 알 수 있도록”

4.3 User Story 작성 템플릿

# User Story: [간단한 제목]  

## 사용자 스토리  
As a [사용자 유형]  
I want [원하는 기능]  
So that [목적/이유]  

## 인수 기준 (Acceptance Criteria)  
- [ ] Given [전제조건] When [행동] Then [결과]  
- [ ] Given [전제조건] When [행동] Then [결과]  
- [ ] Given [전제조건] When [행동] Then [결과]  

## 추가 정보  
- 우선순위: High/Medium/Low  
- 스토리 포인트: [추정값]  
- 비즈니스 가치: [점수]  

4.4 실제 User Story 예시

User Story: “저장된 카드로 결제하기”

## 사용자 스토리  
As a 기존 고객  
I want 이전에 저장한 카드 정보를 선택하여 결제하고 싶다  
So that 매번 카드 정보를 다시 입력하는 번거로움을 피할 수 있다  

## 인수 기준  
- [ ] Given 로그인한 사용자가 저장된 카드가 있을 때 When 결제 페이지에 접근하면 Then 저장된 카드 목록이 표시된다  
- [ ] Given 저장된 카드를 선택했을 때 When 결제 버튼을 클릭하면 Then CVV만 입력하고 결제가 진행된다  
- [ ] Given 결제가 성공했을 때 When 결제 완료되면 Then 결제 완료 페이지로 이동한다  
- [ ] Given 저장된 카드 정보가 없을 때 When 결제 페이지에 접근하면 Then 새 카드 입력 폼이 표시된다  

## 추가 정보  
- 우선순위: High  
- 스토리 포인트: 5  
- 비즈니스 가치: 8/10  

5 Task 작성 가이드

Task는 User Story를 구현하기 위한 구체적인 작업 단위이다.

5.1 Task 제목 작성 원칙

5.1.1 좋은 Task 제목 예시

  • “카드 정보 암호화 API 개발”
  • “결제 완료 페이지 UI 구현”
  • “PG사 연동 테스트 코드 작성”
  • “카드 저장 기능 데이터베이스 설계”

5.1.2 Task 제목 패턴

  • 동사 + 명사 형태 (예: “개발”, “구현”, “작성”, “설계”)
  • 구체적이고 실행 가능한 작업으로 표현
  • 완료 기준이 명확해야 함

5.2 Task 작성 템플릿

# Task: [구체적인 작업명]  

## 작업 설명  
이 작업에서 무엇을 할 것인지 구체적으로 설명  

## 상세 요구사항  
- 구체적인 요구사항 1  
- 구체적인 요구사항 2  
- 구체적인 요구사항 3  

## 완료 조건  
- [ ] 완료 조건 1  
- [ ] 완료 조건 2  
- [ ] 완료 조건 3  

## 추정 시간  
- 예상 소요 시간: X시간  

## 의존성  
- 선행 작업: [Task 링크]  
- 관련 작업: [Task 링크]  

5.3 실제 Task 예시들

5.3.1 Task 1: “카드 정보 암호화 저장 API 개발”

## 작업 설명  
사용자가 입력한 카드 정보를 안전하게 암호화하여 데이터베이스에 저장하는 API 개발  

## 상세 요구사항  
- AES-256 암호화 알고리즘 사용  
- 카드 번호는 토큰화하여 저장  
- PCI DSS 규정 준수  
- 카드 유효성 검증 로직 포함  

## 완료 조건  
- [ ] 카드 정보 암호화 함수 구현  
- [ ] 데이터베이스 저장 API 구현  
- [ ] 카드 유효성 검증 로직 구현  
- [ ] 단위 테스트 작성 (커버리지 90% 이상)  
- [ ] 보안 검토 완료  

## 추정 시간  
- 예상 소요 시간: 16시간  

5.3.2 Task 2: “결제 완료 페이지 UI 구현”

## 작업 설명  
결제 성공 후 사용자에게 보여줄 완료 페이지 UI 구현  

## 상세 요구사항  
- 결제 성공 메시지 표시  
- 주문 정보 요약 표시  
- 영수증 다운로드 버튼  
- 쇼핑 계속하기 버튼  
- 모바일 반응형 디자인  

## 완료 조건  
- [ ] HTML/CSS 마크업 완료  
- [ ] JavaScript 인터랙션 구현  
- [ ] 반응형 디자인 적용  
- [ ] 크로스 브라우저 테스트 완료  
- [ ] 디자인 시스템 가이드 준수  

## 추정 시간  
- 예상 소요 시간: 12시간  

6 작업 항목 관리 베스트 프랙티스

6.1 제목 작성 규칙

6.1.1 Epic 제목

  • 패턴: “[비즈니스 영역] + [목적]”
  • 예시: “전자상거래 결제 시스템 구축”, “사용자 경험 개선”

6.1.2 Feature 제목

  • 패턴: “[기능명] + 기능”
  • 예시: “신용카드 결제 기능”, “사용자 인증 기능”

6.1.3 User Story 제목

  • 패턴: “[사용자 행동] + [목적]”
  • 예시: “저장된 카드로 결제하기”, “결제 이력 조회하기”

6.1.4 Task 제목

  • 패턴: “[동사] + [구체적 작업]”
  • 예시: “API 개발”, “UI 구현”, “테스트 작성”

6.2 우선순위 설정 기준

우선순위 기준 예시
Critical 시스템 장애, 보안 이슈 결제 시스템 오류
High 핵심 비즈니스 기능 회원가입, 로그인
Medium 사용자 편의성 개선 UI/UX 개선
Low 부가 기능 통계, 리포트

6.3 스토리 포인트 추정

6.3.1 피보나치 수열 사용 (1, 2, 3, 5, 8, 13, 21)

  • 1점: 매우 간단 (1-2시간)
  • 2점: 간단 (반나절)
  • 3점: 보통 (1일)
  • 5점: 복잡 (2-3일)
  • 8점: 매우 복잡 (1주)
  • 13점: 분할 필요 (Epic으로 분리)

6.4 작업 항목 연결 관리

6.5 진행 상태 관리

6.5.1 Epic/Feature 상태 정의

  • New: 새로 생성된 작업 항목으로, 아직 작업이 시작되지 않은 상태
  • In Progress: 현재 작업이 진행 중인 상태
  • Done: 작업이 완료된 상태
  • Close: 작업이 최종적으로 완료되고 더 이상 작업이 필요하지 않은 상태

6.5.2 User Story 상태 정의

  • To Do: 작업이 계획되었지만 아직 시작되지 않은 상태
  • In Progress: 작업이 진행 중인 상태
  • Resolved: 작업이 완료되었지만 최종 검토나 승인이 필요한 상태
  • Reopened: 완료된 작업이 다시 열려 추가 작업이 필요한 상태
  • Pending: 작업이 일시적으로 중단된 상태
  • Done: 작업이 완료된 상태
  • Close: 작업이 최종적으로 완료되고 더 이상 작업이 필요하지 않은 상태

6.5.3 Task 상태 정의

New (신규)

  • 새로 생성된 작업 항목의 초기 상태
  • 아직 누구에게도 할당되지 않았거나 작업이 시작되지 않은 상태
  • 백로그에서 대기 중인 상태

Active (활성)

  • 현재 작업 중인 상태
  • 담당자가 할당되어 실제로 작업을 진행하고 있는 상태
  • 진행 중(In Progress)을 의미

Resolved (해결됨)

  • 작업이 완료되었지만 아직 최종 검증이나 승인이 필요한 상태
  • 개발자가 작업을 완료했지만 테스터나 요청자의 확인이 필요한 단계
  • 코드 리뷰나 QA 테스트를 기다리는 상태

Closed (완료)

  • 모든 작업이 완전히 완료되고 검증된 최종 상태
  • 더 이상 추가 작업이 필요하지 않은 상태
  • 배포 완료 및 승인된 상태

일반적인 작업 흐름은 New → Active → Resolved → Closed 순서로 진행

6.5.3.1 상태 전환 규칙

  1. New → Active: 작업 시작 시
  2. Active → Resolved: 개발 완료 후
  3. Resolved → Closed: 검토 및 테스트 완료 후

7 실무 활용 팁

7.1 정기적인 백로그 정리

  • 매주 백로그 리뷰: 우선순위 재조정
  • 분기별 Epic 검토: 비즈니스 목표 정렬
  • 완료된 항목 아카이브: 성과 측정 자료로 활용

7.2 팀 협업 향상

  • 작업 항목에 명확한 담당자 지정
  • 진행 상황 정기적 업데이트
  • 블로커 발생 시 즉시 공유

7.3 메트릭 활용

  • 번다운 차트: 스프린트 진행 상황 추적
  • 속도 차트: 팀 생산성 측정
  • 완료율: 계획 대비 실제 성과 비교

8 결론

효과적인 작업 항목 관리는 성공적인 프로젝트 수행의 핵심이다. Epic부터 Task까지의 계층 구조를 이해하고, 각 레벨에 맞는 적절한 제목과 내용을 작성하는 것이 중요하다.

특히 User Story 작성 시 사용자 관점에서 생각하고, Task는 개발자가 실제로 수행할 수 있는 구체적인 단위로 나누는 것이 핵심이다. 이를 통해 팀 전체가 프로젝트의 목표와 진행 상황을 명확히 파악할 수 있다.

Subscribe

Enjoy this blog? Get notified of new posts by email: