스프린트 계획
스프린트 계획 회의 (Sprint Planning) : 스크럼 이벤트라 불리는 5가지 중 하나!
time-boxed : 시간이 정해져있음 (제한돼있음)
스프린트 목표 달성을 위해 해야할 일을 우선순위에 따라 제품백로그에서 가져옴. 가져온 각 스토리에 대해 실제로 개발 가능하도록 태스크로 분할함.
스프린트 계획회의는 스프린트를 준비하기 위한 회의임
Part 1 : 무엇을 할지 결정 (what)
- 참가자 : 제품 책임자, 팀, 스크럼 마스터
- 스프린트 목표 설정, 백로그 검토
Part 2 : 어떻게 작업할 것인지（how)
- 참가자 : 팀, 스크럼마스터, 제품 책임자 (선택이지만, 질문이 있으면 연락할 수 있어야 한다)
- 팀이 스프린트 내에 할 수 있는 아이템 선정
- 아이템(스토리)를 태스크 단위로 분할
태스크 분할 / 소요시간 추정
사용자 스토리 : 사용자 관점 / 태스크 : 개발자 관점
실제로 사용자 스토리를 개발하기 위해서는 사용자 스토리를 개발하기 위한 작업(태스크)들로 분할할 필요가 있다
스토리를 태스크로 분할
1. 스토리에 대해 토론
2. 스토리를 태스크로 분할
분할하는 이유는? 스토리 하나를 개발자 한 명이 처음부터 끝까지 개발하지 않음. 개발자마다 전문분야가 있고, 또 일을 분담하는 것이 스토리를 더 빨리 구현할 수 있기 때문이다.
3. 각 작업마다 개발자 한 명이 책임 맡음
4. 작업량 추정
<제품 백로그 -> 스프린트 백로그>
Capacity based Scrum Planning
Capacity : 한 스프린트 동안 사용할 수 있는 팀의 가용 시간 (쓸 수 있는 시간)
어떻게 결정하는가? 각 팀원의 가용시간 파악 : 회의/이메일/휴가 등 제외하고 오로지 프로젝트에 관련된 일만 할 수 있는 시간만을 고려
전체 가용 시간에서 스크럼 이벤트 및 백로그 정제 회의에 참여하는 시간은 빼고 계산 (5가지 이벤트 중 sprint 제외하고! 스프린트 계획 회의, 일일 스크럼 미팅, 스프린트 리뷰/회고)
사용자 스토리를 태스크로 분할하고 각 태스크 완료하는데 걸리는 시간을 추정
이와 같은 과정을 팀의 capacity(가용시간)이 넘지 않을 때까지 반복해 사용자 스토리 추가 (넘게 되면, 그 스토리는 스프린트 백로그에 넣지 않게됨)
*사용자 스토리는 스프린트 계획 회의 전에 스프린트 동안 개발할 수 있도록 충분하게 상세화 돼있고 크기도 적절하게 분할돼있어야 한다! (스프린트 계획 회의에서 하기엔 시간 부족!)
그럼 어디서 해야하는가?
↓
제품백로그 정제 회의 (Backlog refinement meeting) - 스크럼 이벤트 x
- 에픽 (한 스프린트 내에서 완성할 수 없을 정도로 큰 사용자 스토리)을 보다 작은 사용자 스토리로 분할하고 분할된 사용자 스토리들에 대한 스토리 포인트 추정
- 다음 다가올 스프린트에 완성할 사용자 스토리들을 정제하는 작업 (넣어줌)
- 새로운 사용자 스토리에 대한 크기(스토리 포인트) 추정
- 필요하다면 기존의 사용자 스토리에 대한 재추정
- 우선 순위 조정
- 스프린트 10%이내 시간 할애
준비의 정의(Definition of Ready, DoR) : 제품 백로그에서 스프린트 백로그로 이동하기 위해 만족돼야 하는 요건 목록
가치가 명확하게 기술돼있음
인수기준이 명확하며 테스트 가능하다
의존 사항이 모두 식별돼서 (어떤 사용자 스토리를 먼저 개발해야하는지?)
PBI가 스프린트 내에 완성할 수 있을만큼 충분히 작게 추정됐다
--> 제품백로그의 PBI들이 DoR 만족하도록 정제하는 회의가 백로그 정제회의다! 팀마다 다름
속도 추정
- ★속도 : 한 스프린트 동안 개발팀이 완료시킨 스토리 포인트들의 합
-> 스크럼 팀은 이 속도를 기반으로 다음 스프린트 계획 만들어나감.
스프린트가 끝나지 않았는데 계획된 모든 스토리를 완전히 완료했다면, 새로운 스토리를 제품 백로그에서 가져옴
속도 (velocity)
- 팀의 진도를 평가하는 수단
이터레이션(스프린트)동안 완성된 스토리들의 총합
- 속도를 계산할 땐? 완전히 완성된 것만 계산 해야함
완료의 정의 (Definition of Done, DoD) : 완료 상태(Done)로 가기 위해 만족해야 할 요건 목록
모든 스토리에 적용. 스프린트 동안에 스토리를 DoD를 만족하도록 한다
백로그 정제 회의에서 스토리들을 준비 상태로 만든 후 (DoR요건 만족)에 스프린트 동안 DoD요건을 만족하도록 한다.
DoD의 예
- Unit Test 통과
- 코드 리뷰
- 리그레션 테스팅, 기능 테스팅 통과
- 인수 기준 만족
- 사용자 문서 갱신
- 성능 테스팅 통과
- UX 디자이너 승인
- 제품 책임자 승인
DoD의 요건을 만족하지 못하는 스토리의 스토리 포인트는 속도를 계산할 때 고려되지 않음!
DoD는 모든 스토리에 적용되는 체크리스트(완료기준) 이지만, 인수 기준은 스토리마다 다름
Velocity Charts : 속도를 나타내는 그래프
불확실성을 고려한 속도 추정
초기엔 추정치와 실제로 완료된 스프린트 속도가 차이가 있음