16. 타임박스
17. 릴리즈 플래닝
18. 스프린트 개요


스프린트 5% 가 스프린트 플래닝에 소요한다.
- 충분한 논의를 이끌어 내야 하고
- 이는 스크럼 마스터가 해야한다.
리뷰/ 회고
- 리뷰 5% 회고 5%
이 모든 세레모니를 스크럼 마스터가 필요한 시점에 일어날 수 있도록 조율하는 것. 필요한 부분들이 잘 논의될 수 있도록 하는것.이 스크럼 마스터의 역할임
19. 스프린트 플래닝 & 스프린트 백로그

완료되지 않은일은 다음 스프린트로 넘겨서 완료시킴
한번 해보고 다음번에 더 나아지기 위해서 해야함
세번쨰는 PO가 추가할때 스크럼마스터가 막아주어야 함
아무때나 시도때도 없이 바꿔달라는게 아님
큰 덩어리 하나만큼은 지켜주어야 함.
바꾸고 싶은 내용이 있다면 이 스프린트가 끝난 후 변경
기본적으로 이 스프린트 하나는 지켜주자
이건 외부의 이해관계자가 이해해줘야 함
- 스크럼마스터가 보호해줘야 함
프로덕트 백로그 vs 스프린트 백로그
이번 스프린트동안 해야 할 일들이 스프린트 백로그임
PO가 이번 스프린트동안 해야할 일들을 말함
개발자들이 세부 할일들을 정의함

서로가 제대로 논의를 나눌 수 있도록 스크럼 마스터가
제대로 해줘야함 Task를 전 팀원들이 모여서 나눈다

각 단위가 어느정도 걸릴지 추정한다.
누가 담당할지도 맡아야 함
스프린트 목표

PO가 작성하게 된다.
클래식한 방법은 포스트잇으로 붙이긴 한다.
트랠로같은거, 아사나 지라 노션 등으로 서로의 업무를 공유할 수 있음
프로덕트 백로그의 주인은 → PO
스프린트 백로그의 주인은 → 개발팀/ 개발자들 임
세부 테스크들은 개발팀/ 개발자들이 마음대로 추가 삭제 가능
전혀 비효율적이지 않음
혼자 할 수 있을까? Yes
일주일에 한번 내가 이번주에 해야할 일들 작성
시간추정
일 시작
20. 스프린트 플래닝 FAQ
Q1. 스프린트 플래닝 너무 오래 걸리는데, 그냥 PO가 혼자하면 안될까요?
앞단에서 문제를 명확하게 했다면 그래야 더 플젝이 잘 굴러간다.
기획자가 다 스프린트 플래닝을 해버리고 뭐 그런다면, 이해 안되는 부분들이 많아질 수 있음
함께 논의해야 하고, 따라서 결코 혼자 논의할 수 없으니
최대한 같이 하는 방향으로 나아가야 한다.
결과적으로 퀄리티가 낮아질 수 있음
반드시 필요한것이다라는 믿음과 합의가 필요함
Q2. 저는 이미 제 할일을 다 했는데 굳이 스프린트 플래닝에 참여해야 하나요?
이름만 스크럼인 스크럼을 할 수도 있음
이름만 팀일뿐 팀으로 일하고 있지 않다.
각자 자기가 할일만 하면 1+1 > 2 이게 일어날 수 없음
그렇다면 혼자일하지 굳이 사무실에서 같이 할 필요가?
폭포수 모델처럼 일을 하고 있는것일 수 있음
스크럼의 장점을 볼 수 없음
쉽지는 않지만 하나의 일에 집중해서 모든 전문가들이 붙어서 하는것이 좋을 수 있음
모든 구성원이 하나의 일을 집중하는것이 시너지를 낼 수 있음. 쉽지는 않다. 이걸 할 수 있도록 시도하는것은 좋은 경험이 될 수 있을 것이다.
Q3. 스프린트에 하는 일들이 중구난방이라 스프린트 목표를 한줄로 못쓰겠어요

- 이름만 스크럼일 수 있음
각자가 다른일을 하고 있을 수 잇음

- 주객전도
끝내질 못했다면 통채로 다음 스프린트로 넘긴다면
다 자질구레하게 넘어가버리면 누군가 명확하게 끝나지 못했던 일들이 남아버리는
예전 스프린트의 일들을 다 못끝내서 이번 스프린트의 일을 못할 수 있음
PO가 이 업무는 ~~ 조건을 충족했을때 완료라고 할 수 있다.
회원가입이라면, 구글, 카카오, 로그인이 가능해야 한다.
흐지부지 하게 머 이정도면 됐다고 합시다 이런거 x
- 노 비전, 노 로드맵, 노 릴리즈 플래닝
이 전체적인 흐름이 없다면 그냥 그떄그때 해야하는일 중구난방으로 하고 있을 수 있음