스프린트 백로그: 두 판 사이의 차이
IT 위키
편집 요약 없음 |
편집 요약 없음 |
||
6번째 줄: | 6번째 줄: | ||
[[파일:스프린트 백로그2.png|500px]] | [[파일:스프린트 백로그2.png|500px]] | ||
[[파일:스프린트 백로그3.png|500px]] | [[파일:스프린트 백로그3.png|500px]] | ||
== 구성 요소== | |||
스프린트 백로그는 다음 요소들로 이루어진다: | |||
*스프린트 목표 (Sprint Goal) | |||
**왜 이 스프린트를 하는가에 대한 단일한 목적 <ref>Scrum Guide, “How will the chosen work get done?”</ref> | |||
*선택된 제품 백로그 항목들 (Product Backlog Items, PBIs) | |||
**해당 스프린트에서 완료될 가능성이 있는 기능, 개선, 버그 수정 등 <ref>Scrum Guide; Scrum Alliance</ref> | |||
*실행 계획 (Actionable Plan) | |||
**PBIs를 인크리먼트(Increment)로 완성하기 위해 필요한 작업(Task) 및 절차 | |||
**개발자들이 “무엇을 어떻게 할 것인지” 세부적으로 나눔 <ref>Scrum Guide; Atlassian; CPrime</ref> | |||
==특징== | |||
스프린트 백로그가 갖는 중요한 특징들은 다음과 같다: | |||
*개발자 소유 | |||
**개발 팀이 스프린트 백로그를 구성하고 유지 관리함 <ref>CPrime; Scrum.org</ref> | |||
*투명성과 실시간성 | |||
**스프린트 기간 동안 지속적으로 업데이트됨 | |||
**새로운 학습이나 정보가 생길 때마다 조정함 <ref>Scrum Guide; Scrum Alliance; Atlassian</ref> | |||
*스프린트 중 조정 가능성 | |||
**작업(Task)의 세부사항, 우선순위, 작업량 등이 변경될 수 있음 | |||
**단, 스프린트 목표(Sprint Goal)는 변경하지 않음 <ref>Scrum Guide; Scrum.org</ref> | |||
*하루 단위 점검 가능 | |||
**데일리 스크럼(Daily Scrum)에서 진행 상태를 검토하고 계획을 조정함 <ref>Scrum Guide; Mountaingoatsoftware</ref> | |||
==스프린트 플래닝에서의 생성 과정== | |||
스프린트 백로그는 스프린트 계획 회의(Sprint Planning) 중에 생성된다: | |||
*제품 책임자(Product Owner)와 개발자(Developers)가 협력하여 스프린트 목표를 수립함 | |||
*제품 백로그에서 우선순위가 높은 항목들을 선정하여 개발 가능한 범위를 결정함 | |||
*개발자들이 PBIs를 더 작은 작업(Task) 단위로 나눔 | |||
*각 작업의 노력(estimation) 및 리소스, 시간(capacity) 등을 고려함 <ref>Atlassian; Scrum Guide</ref> | |||
==스프린트 백로그 vs 제품 백로그== | |||
{| class="wikitable" | |||
!항목 | |||
!제품 백로그 (Product Backlog) | |||
!스프린트 백로그 (Sprint Backlog) | |||
|- | |||
|범위 및 기간 | |||
|제품 전체의 요구사항, 장기적 계획 | |||
|특정 한 스프린트 기간 동안 완료할 항목 | |||
|- | |||
|소유자 | |||
|제품 책임자(Product Owner) | |||
|개발자 팀(Developers) | |||
|- | |||
|변경 가능성 | |||
|자주 변경됨, 우선순위 조정됨 | |||
|스프린트 내에서는 조정 가능하지만 목표는 유지됨 | |||
|- | |||
|상세 수준 | |||
|상위 수준, 사용자 스토리 수준 | |||
|작업(Task) 단위로 세분화됨 | |||
|} | |||
==장점== | |||
스프린트 백로그를 잘 활용하면 다음과 같은 장점이 있다: | |||
*집중력 유지 — 팀이 스프린트 목표에 집중할 수 있게 함 | |||
*투명성 강화 — 팀 내외의 이해관계자가 현재 진행 상황을 명확히 알 수 있음 | |||
*변화에 빠른 대응 가능 — 실제 작업 중에 발생하는 불확실성이나 새로운 정보에 기반한 조정 가능 | |||
*성취감 및 예측 가능성 증가 — 스프린트가 끝날 때 무엇이 완료될지 명확함 | |||
==주의사항 및 한계== | |||
*목표 변경 방지 — 스프린트 목표는 스프린트 기간 중에 변경되어서는 안 됨 | |||
*과도한 항목 선정 주의 — 팀의 용량(capacity)을 고려하지 않고 작업을 너무 많이 선정하면 실패 가능성 높음 | |||
*작업 세분화 부족 방지 — 너무 거시적으로 계획하면 진척 상태 추적 및 조정이 어려움 | |||
==같이 보기== | |||
* [[SCRUM]] | |||
* [[애자일]] | |||
* [[칸반]] | |||
==참고 문헌== | |||
==각주== | |||
<references /> | |||
== 같이 보기 == | == 같이 보기 == | ||
* [[스크럼]] | * [[스크럼]] | ||
* [[번다운 차트]] | * [[번다운 차트]] |
2025년 9월 17일 (수) 06:40 판
구성 요소
스프린트 백로그는 다음 요소들로 이루어진다:
- 스프린트 목표 (Sprint Goal)
- 왜 이 스프린트를 하는가에 대한 단일한 목적 [1]
- 선택된 제품 백로그 항목들 (Product Backlog Items, PBIs)
- 해당 스프린트에서 완료될 가능성이 있는 기능, 개선, 버그 수정 등 [2]
- 실행 계획 (Actionable Plan)
- PBIs를 인크리먼트(Increment)로 완성하기 위해 필요한 작업(Task) 및 절차
- 개발자들이 “무엇을 어떻게 할 것인지” 세부적으로 나눔 [3]
특징
스프린트 백로그가 갖는 중요한 특징들은 다음과 같다:
- 개발자 소유
- 개발 팀이 스프린트 백로그를 구성하고 유지 관리함 [4]
- 투명성과 실시간성
- 스프린트 기간 동안 지속적으로 업데이트됨
- 새로운 학습이나 정보가 생길 때마다 조정함 [5]
- 스프린트 중 조정 가능성
- 작업(Task)의 세부사항, 우선순위, 작업량 등이 변경될 수 있음
- 단, 스프린트 목표(Sprint Goal)는 변경하지 않음 [6]
- 하루 단위 점검 가능
- 데일리 스크럼(Daily Scrum)에서 진행 상태를 검토하고 계획을 조정함 [7]
스프린트 플래닝에서의 생성 과정
스프린트 백로그는 스프린트 계획 회의(Sprint Planning) 중에 생성된다:
- 제품 책임자(Product Owner)와 개발자(Developers)가 협력하여 스프린트 목표를 수립함
- 제품 백로그에서 우선순위가 높은 항목들을 선정하여 개발 가능한 범위를 결정함
- 개발자들이 PBIs를 더 작은 작업(Task) 단위로 나눔
- 각 작업의 노력(estimation) 및 리소스, 시간(capacity) 등을 고려함 [8]
스프린트 백로그 vs 제품 백로그
항목 | 제품 백로그 (Product Backlog) | 스프린트 백로그 (Sprint Backlog) |
---|---|---|
범위 및 기간 | 제품 전체의 요구사항, 장기적 계획 | 특정 한 스프린트 기간 동안 완료할 항목 |
소유자 | 제품 책임자(Product Owner) | 개발자 팀(Developers) |
변경 가능성 | 자주 변경됨, 우선순위 조정됨 | 스프린트 내에서는 조정 가능하지만 목표는 유지됨 |
상세 수준 | 상위 수준, 사용자 스토리 수준 | 작업(Task) 단위로 세분화됨 |
장점
스프린트 백로그를 잘 활용하면 다음과 같은 장점이 있다:
- 집중력 유지 — 팀이 스프린트 목표에 집중할 수 있게 함
- 투명성 강화 — 팀 내외의 이해관계자가 현재 진행 상황을 명확히 알 수 있음
- 변화에 빠른 대응 가능 — 실제 작업 중에 발생하는 불확실성이나 새로운 정보에 기반한 조정 가능
- 성취감 및 예측 가능성 증가 — 스프린트가 끝날 때 무엇이 완료될지 명확함
주의사항 및 한계
- 목표 변경 방지 — 스프린트 목표는 스프린트 기간 중에 변경되어서는 안 됨
- 과도한 항목 선정 주의 — 팀의 용량(capacity)을 고려하지 않고 작업을 너무 많이 선정하면 실패 가능성 높음
- 작업 세분화 부족 방지 — 너무 거시적으로 계획하면 진척 상태 추적 및 조정이 어려움