“스프린트 계획회의 이전에 제품 백로그를 깔끔하게 정리한다.” 이 말의 의미는 무엇인가?

• 제품 백로그는 반드시 존재해야 한다.
• 반드시 제품 백로그는 하나, 제품 책임자가 한 명이어야 한다.
• 중요한 아이템에 중요도를 부여할 때, 모두 서로 다른 값을 부여해야 한다.
• 제품 책임자는 각 스토리를 이해하고 있어야 한다.

스프린트 계획회의는 스크럼에서 가장 중요한 이벤트일 것이다. 스프린트 계획회의가 잘못 진행되면 스프린트 전체를 망쳐 놓을 수 있기 때문이다.

• 팀에게 충분한 정보를 제공
• 팀원이 제품 책임자에게 작업 진행에 대한 신뢰를 제공

• 하나의 스프린트 목표
• 팀원의 목록
• 스프린트 백로그
• 확정된 스프린트 데모일
• 확정된 일일스크럼을 위한 시간과 장소

전체 팀원과 제품 책임자가 스프린트 계획회의에 참여해야 하는 이유는 모든 스토리가 서로 깊이 연관된 3개의 변수를 갖고 있기 때문이다.

범위와 중요도는 제품 책임자에 의해 결정되고, 추정치는 팀에 의해 결정된다. 스프린트 계획회의에서 이 세가지 변수는 팀원과 제품 책임자가 대화를 통해 지속적으로 세밀하게 조정된다.

직접적인 협력(collaboration)은 스크럼의 핵심 요소이며, 모든 애자일 소프트웨어 개발의 핵심 요소이다.

스프린트 계획회의 시간표를 사전에 작성해 두면 타임박스를 지키지 못하게 되는 리스크를 줄일 수 있다.

스프린트는 짧은 것이 좋다. 짧은 스프린트는 회사를 '기민하게' 다시 말해서 자주 방향 수정을 할 수 있게 해 준다.

짧은 스프린트 = 짧은 피드백 주기 = 더 잦은 출시 = 더 잦은 고객 피드백 = 잘못된 방향에 따른 시간 낭비 감소 = 학습 및 개선 가속화

일반적으로 제품 책임자는 짧은 스프린트를 선호하고, 개발자는 긴 스프린트를 선호한다. 따라서 스프린트 길이는 절충되어야 한다.

일단 스프린트 길이를 가지고 직접 실험을 해보고 결정하면 된다. 많은 스크럼팀들이 사용하는 스트린트 길이는 3주정도 이다. 이것을 일정하게 유지하면 이 주기는 모든 사람이 편안하게 적응하는 심장 박동같이 된다. 릴리즈 날짜를 두고 논쟁하는 일도 없다. 왜냐하면 모든 사람이 3주마다 릴리즈가 있음을 알기 때문이다.

스프린트의 목표는 팀 밖의 사람들이 이해할 수 있는 말로 표현되어야 한다.

“우리는 왜 이 스프린트를 진행하는가?” 라는 근본적인 질문에 답을 줄 수 있어야 한다.

또한 스프린트의 목표는 팀의 위키 페이지나 공용으로 사용하는 시스템에 게시하여 항상 눈에 띄게 하는 것이 매우 유용하다. 사람들이 무엇을 해야 하는지 혼란스워하기 시작하는 순간 그것의 진가를 발휘하게 될 것이다.

스프린트 계획회의의 주요 활동 중 하나는 해당 스프린트에 어떤 스토리를 포함시킬지 결정하는 것이다. 더 구체적으로 말하자면, 제품 백로그에서 어떤 스토리를 복사해서 스프린트 백로그에 붙여 넣을 것인가를 결정하는 것이다.

스프린트 백로그를 결정할 때 제품 책임자는 속도 추정을 간섭 할 수 없는 것이 일반적이지만, 어떤 스토리를 스프린트에 넣을지, 말지에는 영향력을 미칠 수 있다. 따라서 제품 책임자는 중요도에 따라, 범위 조정을 함으로써, 스토리를 둘 이상으로 나누어서 스프린트 백로그를 결정할 수 있다. 팀은 직감과 속도 계산을 통하여 스프린트 백로그를 결정할 수 있다.

* 속도 추정 방법 : yesterday's weather이 방법은 팀의 이력을 보는 것이다. 지난 몇 번의 스프린트에서 팀의 속도는 얼마였는가? 그렇다면 다음 스프린트의 속도를 가정할 수 있다. 주의할 점은 지난 번 스프린트의 속도는 일반 환경일 때를 생각해야 한다. 예를 들어 팀원들이 감기로 인해 몇 일 결근을하거나 기타 상황으로 인해 집중도가 낮았다면 집중도를 약간 높여야 잡아야 한다는 것이다.

스프린트 계획회의 진행을 실제로 진행할 때 인덱스 카드를 사용하는 것이 좋다. 엑셀 파일을 직접 수정하거나 회의록을 기록하는 것보다 큰 포스트-잇이나 독서 카드 등을 이용하여 인덱스 카드를 만들어 벽에 붙이는 것이 효율적이다.

스프린트 계획회의가 끝나면 스크럼 마스터는 인덱스 카드에 작업한 내용을 엑셀로 되어 있는 제품 백로그에 반영한다.

애자일 팀이 작업 일정이나 규모를 추정할 때 사용하는 도구.

팀 전체가 참여하고 의사소통을 활발히 하여 신뢰성있는 추정치를 얻을 수 있다.

사용방법은…

1. 팀원들이 카드를 한 벌씩 나누어 갖는다.
2. 제품 책임자나 팀원은 추정해야 할 아이템을 제시한다.
3. 정확히 어떤 기능인지 등을 파악하며 아이템에 대해 논의한다.
4. 각 추정자는 자신의 추정치가 적힌 카드 한 장을 다른 사람이 볼 수 없게 뒤집어 내려 놓는다.
5. 모두 카드를 내려 놓았으면 동시에 카드를 뒤집는다.
6. 모두 같은 카드가 나오면 그 값으로 추정은 확정된다.
7. 가장 높은 값과 낮은 값을 제시한 추정자들은 그렇게 생각한 이유에 대해 설명한다.
8. 견해 차이에 대해 계속 논의하며 기능을 구체화한다.
9. 추정치가 수렴될 때까지 반복한다.

몇 가지 주목할만한 특수 카드들이 있다.

• 0 : 이 스토리는 이미 완료된 것이다. 혹은 이 스토리는 일도 아니다. 단 몇 분 안에 끝낼 수 있다.
• ? : 정말 뭔지 모르겠다.
• 커피 컵 : 생각하느라 너무 지쳤다. 커피 한잔 하러 갑시다.

일반적으로 스토리는 너무 작거나 너무 크면 안된다. 스토리를 작은 스토리들로 나눌 때 나눈 스토리들이 항상 비지니스 가치를 제공할 수 있는 출시 가능한 단위인지 확인해야 한다.

또한, 스토리를 작업(task) 단위로 나눌 수도 있다.

스토리는 제품 책임자가 관심을 갖는 전달 가능한 것을 말하고, 작업은 전달할 수 없는 것이거나 제품 책임자가 관심을 갖지 않는 것을 말한다.

제품 책임자에게 직접적인 가치를 제공하는 것도 아니지만, 전달할 수 있는 것도 아니고, 다른 특정 스토리에 직접적으로 관련되지 않으면서도 완료해야 하는 일이 있다. 이것이 '기술 스토리'이다. 예를 들면 개발 서버 구축 및 업그레이드, 시스템 설계 개요 작성, 버그 추적 시스템 업그레이드 등이다.

스프린트 계획회의가 스크럼에서 가장 중요한 활동이다. 이 회의에서 많은 힘을 쏟으면 나머지 일들이 훨씬 더 쉬워질 것이다. 하지만 스프린트 계획회의가 성공적이었다해고 모든 일이 완전히 잘못될 수도 있다. 그래도 스프린트 계획회의를 비난할 수는 없을 것이다.

회사의 모든 구성원이 현재 벌어지고 있는 일에 대하여 알고 있는 것은 중요하다. '스프린트 정보 페이지'를 이용하거나 회사의 실정에 맞게 알림 시스템을 구축하면 좋다.

알림 게시판 예

스프린트 계획회의를 어설프게나마 진행해 보았다.

긴 시간동안 스프린트 백로그를 정하고, 추정하는 등의 일련의 과정들이 조금은 번잡스러워 보이기 까지했다. 생각보다 추정하는 시간은 그리 오래 걸리지는 않았다. 의견 차이가 있을 때는 해당 백로그에 대한 상세한 설명과 이유들을 말하며 의견을 좁혀 나갔다.

추정값이 수렴되기 까지 옆사람의 눈치를 보는듯한 느낌도 있었고, 처음 진행하는 플래닝 포커 게임에 익숙하지 않은 면도 드러나 보였다.

어쨌거나 스프린트 계획 회의가 일단락되었다. 이후, 실제 스프린트가 진행되고 생각대로 스프린트는 진행되지 않았다.

작업 속도가 나지 않는 것이었다. 왜 일까? 이제 스프린트가 겨우 3일 정도 남았는데 소멸 차트에는 남아 있는 작업이 2/3 정도 있다.

추정이 잘 못된 것일까? 여러가지 원인이 있을 것이다. 해외 출장을 일주일간 멤버, 중간 중간 다른 일들의 간섭 부분도 무시할 수는 없을 것이다 그러나, 이런 외부 요인을 감안하더라도 작업 진도는 너무 느리다. ???