소요시간 : 2~4시간 내외

Sprint는 팀프로젝트에서는 주단위로 진행합니다. 매주 시작하는 날 금주에 진행할 업무들을 정리하는 시간을 가지고, 불명확한 부분들을 명확하게 하는 시간을 가집니다. 이 시간이 낭비라고 생각이 드실 수도 있겟지만, 길게 보자면 시간을 절약하게 될 확률이 매우 높으니, 진행하시길 바랍니다.

정리된 이슈는 Github의 Issus로 등록하고 Milston을 해당 Sprint의 마지막으로 설정합니다.

가장 중요한 점은 일을 작은 단위로 쪼개는 것입니다.

Story Point란

Planning을 진행하는 Host ( 팀장이나, 돌아가면서 진행하여도 무방함 )의 주도하에 진행해야 하는 이슈들을 일단 나열하고, 대략적인 구체화를 진행합니다. 업무량의 추정이 가능할 정도로 구체화가 되었다면, 예상되는 일정에 대해 Story point로 sizing을 진행하도록 합시다. 1인이 하루에 소화할 수 있는 작업량을 1 로 설정합니다.

우리는 팀 프로젝트를 진행중이니, 이슈의 단위가 2가 넘지 않도록 합니다. 이슈의 사이즈가 2보다 더 크다면 너무 크게 이슈를 잡은 것이니 분리 하는 것을 권장합니다. ( ex. Login 기능 구현의 사이즈가 크다면 OAuth2 연동, 로그인 API 구현 등으로 쪼개서 ). 사이즈는 0.5, 1, 2, 3, 5 등으로 피버노치로 증가합니다. 여러분은 학생 레벨의 프로젝트를 진행중이니 0.25 까지 쪼개셔도 좋을 것 같습니다. ( 선택)

주말까지 size를 잡아야할 지는 여러분의 선택이 될 것 같고, 한 스프린트에 진행 가능한 작업에 + 2~30% 정도까지를 sizing 해 놓도록 합시다. 여러분의 작업이 일찍 끝날지 늦게 끝날지 모르니, 스프린트를 앞당기는 것 보다 작업의 Backlog를 좀 더 여유있게 만들어 놓는 것이 좋습니다.

일반적으로는 업무가 빨리 진행될 경우 진행하지 못한 내역들이 쌓여있는 Backlog에서 가져오나, 여러분은 쌓여있는 Backlog가 없을 것이지 좀 더 크게 사이징을 해 놓는 것입니다.

Planning Sample - MD와 Size는 유사한 개념이라고 생각하시면 될 것 같습니다.

아래 시트를 참고하거나, 복사해서 사용해 주세요. Backend와 FrontEnd 각각 하나의 테이블을 활용하시면 좋을 것 같습니다.