스크럼이라고 해서 계획을 세우지 않는 것은 아닙니다. 스크럼에서도 작업 계획 수립은 여전히 중요한 작업입니다. 그래야 언제 릴리즈 할지, 릴리즈 하기 위해서 어디까지 작업을 할지 알 수 있습니다.

스크럼에서는 개략적인 계획을 세우기 위해 ‘프로덕트 백로그(product backlog)’를 사용합니다. 프로덕트 백로그란 할 일을 기록해둔 작업 목록 같은 것입니다. 단순히 할 일을 나열한 목록에 불과하지만 내용을 살펴보면 언제 릴리즈를 할 수 있는지, 언제 어떤 기능을 완성해야 하는지, 뭐가 끝났고 뭐가 남았는지를 알 수 있습니다. 즉, 프로덕트 백로그를 통해 프로젝트의 큰 흐름을 읽을 수 있습니다. 제대로 된 계획을 세우려면 각 항목에 대한 작업량도 가늠해야 합니다.

프로덕트 백로그를 만들기 위해서는 먼저 일감을 도출해야 합니다. 먼저 스크럼 팀이 달성해야 할 목표나 개발할 제품에 대한 자료를 미리 준비하고, 목표를 달성하는 데 필요하다고 생각되는 항목들을 전부 나열해 봅시다. 이때는 항목의 질보다는 양이 중요하니 너무 많아도 걱정하지 말고 도출해야 합니다. 이렇게 다양한 관점에서 해야 할 일감을 도출하다 보면 중요한 작업을 누락하지 않고 잘 정리할 수 있습니다.

프로덕트 백로그에 등록된 순서대로 일감을 처리하기 때문에 중요한 작업이 뒤늦게 추가되면 전체적인 작업 흐름이 깨질 수 있으니 다양한 관점에서 살펴보는 것이 특히 중요합니다.

일감 후보가 충분히 나왔다면 비슷한 항목끼리 모으고, 순서를 정합니다. 개발자는 프로덕트 백로그에 등록된 순서대로 작업하기 때문에 중요하다고 생각되거나 먼저 구현해야 하는 일감을 앞 쪽에 배치해야 합니다. 반대로 급하지 않거나, 중요하지 않은 일감은 뒤에 배치되겠죠.

그런데, 일의 우선순위는 누가 정하는 걸까요? 어떻게 보면 이해관계자가 정하는 게 맞다고 생각이 들 수 있습니다. 하지만 이해관계자가 정한 일의 순서를 개발자 관점에서는 효율적이지 않거나 이해하지 못할 수도 있기 때문에 결국 개발자 스스로가 괜찮다고 생각하는 계획이 나와야 합니다.

스크럼 팀은 일감을 나누는 기준을 정해 분류하고 우선순위를 정할 수 있습니다. 예들 들면 ‘진짜 중요’, ‘조금 중요’, ‘필요함’, ‘있으면 좋고 없어도 그만’ 같은 기준을 세워볼 수 있겠죠. 필요하다면 사용자나 제품 관점에서의 중요도가 아니라 ‘원활한 개발을 위해 먼저 해야 할 일’처럼 별도의 분류를 추가하는 것도 좋습니다.

한편 스크럼에서 작업 순서를 책임지는 건 프로덕트 오너입니다. 프로덕트 오너가 최종 확인하고 모두에게 공유하면 그때서야 비로소 최초의 프로덕트 백로그가 완성됩니다.

계획 수립 과정은 중요하지만 필요 이상으로 많은 시간을 투자하는 것은 좋지 않습니다. 대신 상황에 맞춰서 반복적인 활동으로 계획을 수립하는 것이 좋습니다. 중요한 것은 중요한 작업을 빠트리지 않고 팀원 모두가 프로덕트 백로그를 이해하는 것입니다.