스프린트를 도입하기 전에 맞춰야 할 것

스프린트를 도입한다는 말은 쉽지만, 보드와 회의 이름만 가져오면 팀의 일이 더 잘 보이지 않을 수 있습니다. 《스크럼과 XP》를 읽으며 적어 둔 절차를 다시 보니 핵심은 짧은 기간 안에 계획하고, 결과를 보여주고, 다음 방식을 고치는 주기를 만드는 데 있었습니다.

스프린트 한 바퀴

단계	만들어야 할 것	팀이 답할 질문
제품 백로그	가치와 우선순위가 있는 일 목록	누구에게 어떤 변화가 생기는가
계획 준비	후보 항목과 완료 기준	시작할 만큼 요구사항이 분명한가
스프린트 계획	이번 주기의 목표와 범위	이 기간에 하나의 결과로 묶이는가
실행	작업 보드와 매일의 조정	막힌 일을 누가 함께 풀어야 하는가
데모	실제로 동작하는 결과	이해관계자가 확인할 변화가 있는가
회고	다음 주기에 바꿀 행동	무엇을 유지하고 무엇을 실험할까

각 행사는 독립된 회의가 아니라 다음 단계의 입력을 만듭니다. 계획에서 완료 기준이 흐리면 데모가 의견 수렴 자리로 변하고, 데모에서 실제 피드백을 받지 못하면 다음 백로그의 우선순위도 나아지기 어렵습니다.

제품 백로그는 할 일 보관함이 아니다

백로그에 떠오르는 일을 모두 쌓기만 하면 우선순위가 없는 창고가 됩니다. 항목은 사용자나 사업에 주는 가치, 긴급성, 위험과 학습 효과를 기준으로 정렬하고, 가까운 항목일수록 더 구체적으로 다듬어야 합니다.

스프린트 계획에서는 가능한 작업량을 맞추기 전에 목표를 한 문장으로 합의합니다. 목표가 있으면 예상치 못한 일이 생겼을 때 무엇을 지키고 무엇을 미룰지 판단할 수 있어요.

일일 스크럼은 보고 시간이 아니다

매일 모이는 목적은 관리자를 위한 진행률 보고가 아니라 팀이 목표를 향해 흐름을 조정하는 것입니다. 어제 한 일의 목록보다 다음 질문이 중요합니다.

• 스프린트 목표를 막는 것이 있는가
• 리뷰가 밀리거나 한 사람에게 일이 몰렸는가
• 계획과 다른 사실을 발견했는가
• 오늘 함께 해결해야 할 일이 무엇인가

문제를 자세히 푸는 회의는 필요한 사람끼리 이어서 하고, 짧은 동기화 시간에는 도움을 요청할 신호를 놓치지 않습니다.

데모와 회고를 분리한다

데모에서는 만든 제품과 사용자 가치를 확인하고, 회고에서는 팀이 일한 방식을 돌아봅니다. 제품 피드백과 사람 평가가 섞이면 솔직한 회고가 어려워져요.

회고에서 실행 항목을 너무 많이 정하면 다음 스프린트에 사라지기 쉽습니다. 한두 가지 행동을 골라 담당자와 확인 시점을 정하고, 다음 회고에서 실제로 달라졌는지 봅니다. 휴식이나 정리 시간을 스프린트 사이에 두는 것도 지속 가능한 속도를 위해 고려할 수 있습니다.

떨어져 일하는 팀이라면

분산 팀에서는 보드와 문서가 실제 업무 상태를 대신 설명할 수 있어야 합니다. 회의 시간대의 불리함을 번갈아 나누고, 결정은 대화방에만 남기지 않고 기록합니다. 동시에 모든 대화를 문서로 바꾸려 하지 말고 복잡한 문제는 짧게 함께 이야기한 뒤 결론과 배경을 남기는 편이 효율적입니다.

도입 전 확인할 최소 조건

• 제품의 우선순위를 결정할 책임자가 있는가
• 팀이 완료의 의미를 합의했는가
• 스프린트 중 갑작스러운 일을 어떻게 받을지 정했는가
• 데모할 수 있는 작은 결과로 일을 나눌 수 있는가
• 회고에서 정한 행동을 다음 주기에 확인하는가

스크럼은 회의를 추가하는 방법이 아니라 팀의 불확실성을 짧은 학습 주기로 다루는 방법이었습니다. 형식을 얼마나 정확히 재현했는지보다 한 주기가 끝난 뒤 제품과 일하는 방식에 실제 피드백이 생겼는지를 보는 것이 더 중요합니다.

이어 읽기

• 2016년의 작은 기록들 — 초기 프로젝트에서 마일스톤과 완료 조건을 처음 고민했던 기록입니다.
• 개발자로 성장하며 남긴 질문들 — 목표를 세우고 중간 점검하는 개인 회고가 팀의 피드백 주기와 어떻게 닮았는지 볼 수 있어요.
• 프론트엔드 멘토링 진행 노트 — 작은 결과물, 리뷰와 다음 질문을 반복하는 학습 흐름으로 연결합니다.