1. 제품 백로그 > 스프린트 백로그
- 사용자 스토리는 스프린트 계획 회의 전에 스프린트동안 개발할 수 있도록 충분하게 상세화되어 있으며 크기도 적절하게 분할되어 있어야 함 => 정제화, 구체화할 필요성
- 스프린트 계획 회의에서 스프린트동안 스프린트 목표 달성을 위해 할 일을 제품 백로그에서 가져옴
1. 백로그 정제 회의
- Backlog refinement(grooming) meeting
- 에픽(한 스프린트 내에서 완성할 수 없을 정도로 큰 사용자 스토리)을 보다 작은 사용자 스토리로 분할하고 분할된 사용자 스토리들에 대한 스토리 포인트 추정
- 다음 다가올 스프린트에 완성할 사용자 스토리들을 정제하는 작업
- 새로운 사용자 스토리에 대한 크기(스토리 포인트) 추정
- 필요하다면 기존의 사용자 스토리에 대한 재추정
- 우선 순위 조정
- 스프린트 10% 이내 시간 할애
- 새 사용자 스토리 추가/삭제/상세화
그림 https://m.blog.naver.com/if_you-/220972891329
Capacity based Sprint Planning
- capacity: 한 스프린트동안 사용할 수 있는 팀의 가용 시간
- 각 팀의 가용시간 파악: 회의/이메일/휴가 등을 제외하고 오로지 프로젝트에 관련된 일만 할 수 있는 시간만을 고려
- 전체 가용 시간에서 Scrum events(스프린트 계획 회의, 일일 스크럼 미팅, 스프린트 리뷰 및 회고) 및 백로그 정제 회의에 참여하는 시간을 고려하여 계산
2. 준비의 정의(Definition of Ready, DoR)
- 제품 백로그에서 스프린트 백로그로 이동하기 위해 만족되어야 하는 요건 목록
- 가치가 명확하게 기술되었다.
- 의존 사항이 모두 식별되었다.
- 인수 기준이 명확하며 테스트 가능하다.
- PBI가 스프린트 내에 완성할 수 있을 만큼 충분히 작게 추정되었다.
- 제품 백로그의 PBI들이 DoR을 만족하도록 정제하는 회의가 백로그 정제 회의
- 스토리가 DoR 요건을 만족하면 스프린트에서 개발할 수 있는 준비 상태에 있다는 의미
- 백로그 정제 회의에서 개발 대상 스토리를 DoR 요건을 만족하도록 정제
- 팀이 결정하기 때문에 팀마다 다를 수 있음
3. 속도(Velocity)
- 속도: 한 스프린트 동안에 완료된 스토리 포인트들의 합
- 스크럼 팀은 이 속도를 기반으로 다음 스프린트 계획을 만들어 나가게 됨
만약, 우리팀의 속도가 50이라면, 다음 스프린트에는 50포인트 정도의 스토리들을 해결할 수 있다는 것을 예측할 수 있고 거기에 맞춰 스프린트 계획을 세우게 됨 - 속도는 완전히 완료된 스토리들의 스토리 포인트 합
- 완료되지 못한 스토리들은 우선 순위를 고려하여 다음 스프린트에서 개발을 계속할 수 있다.
- 만약 스프린트 백로그에 있는 모든 스토리를 예정보다 빨리 완성하면 제품 백로그에서 우선 순위에 따라 사용자 스토리를 가져옴
- 팀의 진도를 평가하는 수단
날짜가 고정되었을 때 개발 범위 결정
ex) 속도가 20으로 추정되는 팀이 2달 프로젝트(2주짜리 4개의 스프린트)를 수행한다고 가정
개발범위
1) 만들어 질 스토리의 크기: 최소 보정치 x 20(속도) x 4(스프린트 개수)
2) 만들 수 있는 스토리의 크기: 최대 보정치 x 20(속도) x 4(스프린트 개수)
4. 완료의 정의(Definition of Done, DoD)
- 완료(Done) 상태로 가기 위해 만족해야 할 요건 목록
- 모든 스토리에 적용
-> 스토리가 DoD의 요건을 만족하면 완료되었다고 할 수 있음 - 백로그 정제 회의에서 스토리들을 준비 상태로 만든 후에(DoR 요건을 만족) 스프린트동안 DoD 요건을 만족하도록 함
- DoD의 요건을 만족하지 못하는 스토리의 스토리 포인트는 속도를 게산할 때 고려되지 않음
- DoD는 모든 스토리에 적용되는 체크리스트이지만 인수 기준은 개개인의 특정 스토리에 적용됨
-> 인수 기준은 스토리마다 다름
=> 스프린트동안에 DoR을 만족하는 스토리를 DoD를 만족하도록 함
5. 릴리스 계획(출시 계획)
-
Time, Cost 3요소를 고려하여 무엇(Scope)을 전달할 수 있을지를 추정
-
시간과 비용을 고정할 때 범위를 결정
-
iron triangle 뒤집어서 봄
-
case1) 해야할 일이 우리가 최소로 할 수 있는 양보다는 크고 최대한 할 수 있는 일의 양보다는 작을 때
- 위험을 감수하고 개발 진행하고 개발에서 획득한 지식을 바탕으로 개발 진행 여부를 결정
- 릴리스 날짜를 연기하거나 개발 인력을 추가(time, cost 증가)
- 기술적 채무(앞으로 해야할 일을 하는데 필요한 시간을 담보로 오늘 빚을 냄, 소프트웨어 개발 과정에서 장기적으로 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용을 선택)
- 기술적 채무가 있다면 너무 많이 쌓이기 전에 중간중간 채무를 갚아야 함
- 나쁜 설계, 결함, 불충분한 테스트 범위, 자동 테스트 대신에 수동 테스트
case2) 출시해야하는 일의 양이 개발 팀이 최대로 할 수 있는 일의 양보다 큰 경우
- 개발 중단
- 릴리스 날짜 연기
- 개발 인력 추가
- 기술적 채무2. 스크럼 도구
1. 스크럼 태스크 보드
-
프로젝트 현황판
-
매일 기록
-
지속적으로 팀에게 프로젝트의 진행 상황을 보여줌
-
태스크의 상태는 To Do(아직 시작 안 된 태스크), In Progress(개발 중인 태스크), Done(완료된 태스크) 3가지가 기본이지만 Testing(테스트 중인 태스크)와 같은 다른 상태의 태스크를 추가할 수 있음
2. Burn down charts
-
시간 대비 남아 있는 일을 그래프로 표현한 것
-
Agile 방법론에서 사용되는 상호 작용 기법
그림 https://viblo.asia/p/scrum-burndown-chart-cach-phan-tich-tien-do-dieu-chinh-sprint-thong-qua-burndown-chart-oOVlYMarl8W -
이상적인 그래프를 기준으로 아래쪽에 위치하면 현재 스크럼 진행상황이 빠르다는 것을, 위쪽에 위치하면 뒤쳐지고 있다는 것을 의미
3. Burn up charts
-
x축은 경과된 스프린트, y축은 스프린트동안 한 일의 양, 프로젝트동안 한 일의 양을 나타냄
-
프로젝트동안 어느 정도의 양이 추가되고 제거되는지 보여줌
-
어느 정도의 속도 하에서 어느 정도의 양만큼 일할 수 있을지 예측 가능
그림 
그림 