「스크럼 개발 방법론은 속도 지향적입니다」 Sprint(단거리 경기, 전력 질주 🏃), Velocity(움직임의 빠르기, 속도)와 같은 단어에서 느낄 수 있고, 스크럼 가이드에서 권유(?)하는 이터레이션의 주기 또한 1~4주 사이로 짧은 데서도 알 수 있습니다.

「스크럼 개발 방법론은 성과 지향적입니다」스크럼 가이드에서 “스크럼의 핵심(heart)은 한 달 이내 유저에게 가치를 제공하고 잠정적으로 배포 가능한 개발 증분을 완료하는 스프린트에 있다.” 라고 합니다. 이로 인해 스크럼 팀 구성원들은 주간 잡지에 글을 기고하는 것처럼 어떻게든 마감일 이전에 산출물을 만들어내야 하는 심리적인 압박에 놓입니다.

이러한 속도전에서 올바른 성과를 내기 위해서는 충분한 정도의 기획 상세, 기술 검토, 연관성 분석, 사전 모의와 같은 과정이 선행되어야 합니다. 그 결과로 스프린트 시작과 동시에 내달릴 수 있도록 작업물(유저 스토리)을 충분히

• 명확하게 (Clear)
• 스프린트 내에 완료 가능한 수준의 크기로 (Small)
• 추정 가능하도록 (Estimable)
• 바로 실행 가능하도록 (Actionable)

스프린트 시작 이전에 다듬어야 합니다.

가끔 (혹은 많은 경우 😅) 충분히 준비되지 못한 유저스토리를 무리하게 진행하는 경우가 있습니다.

개발 시작 이전에 구체적인 상세와 논의를 요구하는 것은 기획과 개발의 단계를 나누는 행위이고 이를 곧 워터폴 개발 방식으로 간주하여 금기시 여기는 잘못된 인식 때문이기도 하고,

그럼에도 불구하고 과감히 도전하여 성공해내는 이런 드라마틱한 성공사례가 애자일의 워너비처럼 되어있는 영향도 있는 것 같습니다.

하지만 준비가 부족한 시작은 결국 의사결정을 위한 핑퐁게임에 짧은 스프린트 일정을 많이 소비하게 만들고, 작업의 지연 혹은 재작업이 발생하게 되고, 촉박한 일정 내 만들어내는 데만 급급하게된 나머지 개발 산출물의 결이 기대했던 유저 가치와 달라지거나, 개발 산출물의 퀄리티가 잠정적으로 배포 가능한 수준에 이르지 못하게 된다거나, 충분히 고려되지 못한 기술적 단기책들은 기술부채로 이어지기도 합니다.

스크럼에서는 이러한 준비작업은 Backlog Refinement(Backlog Grooming) 과정을 통해서 지속적으로 진행되어야 한다고 가이드합니다.

변칙적으로 Sprint 0나 Spike(POC, Rearch) 스토리와 같은 것을 두는 경우도 있고 Definition of Ready와 같은 기준을 두기도 합니다. (스크럼 협회들에서는 옳지 않다 얘기하지만… Why not?)

부족한 상황에서 과감히 도전하여 역경을 이겨내고 성공을 일구어내는 모습은 보는 이를 짜릿하게 만드는 홈럼과도 같습니다. 하지만 홈런에만 기대어 매 스프린트가 Winning하기를 바랄 순 없습니다.

시작이 반입니다. 여러분들이 내달리려는 스프린트 아이템이 얼마나 준비되어 있느냐에 따라 절반의 성공일 수 있고 절반의 실패일 수 있습니다.

연관 글 : ‘잦은 기획의 변경은 무조건 용인되어야 하나?’