스프린트 플래닝 진행자(Sprint Planning Facilitator)

스프린트 플래닝은 모두의 시간을 낭비하는 회의일 필요가 없다

익숙한 장면이 있을 겁니다. 엔지니어 8명, PM 1명, scrum master 1명이 방에 앉아 두 시간을 씁니다. 누군가는 티켓 설명을 소리 내어 읽고, 다른 누군가는 여섯 번째로 "테스트는요?"라고 묻습니다. 회의가 끝날 때쯤 손에 쥔 sprint plan은 수요일이면 이미 낡아 있을 가능성이 큽니다.

스프린트 플래닝은 평판이 좋지 않고, 대부분은 그 평가가 맞습니다. 하지만 망가진 것은 회의 자체가 아니라 준비 과정입니다.

왜 Sprint Planning은 실패하는가

Atlassian의 2024 State of Agile 보고서에 따르면 agile 팀의 54%는 sprint planning 세션이 필요 이상으로 길다고 말하고, 38%는 그 결과로 나온 commitment가 자주 부정확하다고 답합니다. 이것은 agile의 문제가 아니라 preparation의 문제입니다.

제가 가장 자주 보는 실패 패턴은 이렇습니다. PM이 명확한 sprint goal 없이 회의실에 들어옵니다. backlog 안에는 티켓이 가득하지만, 이번 sprint가 하나의 단위로 무엇을 성취해야 하는지에 대한 서사는 없습니다. 결국 엔지니어는 그때그때 가장 급해 보이는 것을 집어 들고, sprint는 관련 없는 작업들의 grab bag이 됩니다.

Jeff Patton은 story mapping 작업에서 이 점을 자주 강조합니다. 좋은 sprint plan은 단순한 목록이 아니라 사용자 가치의 단면입니다. 작더라도 사용자가 실제로 경험할 수 있는 무언가를 매 sprint에 전달해야 합니다. 티켓 수가 아니라 goal을 중심으로 계획하면, estimation, capacity, scope cut 같은 나머지 의사결정도 훨씬 쉬워집니다. 판단의 기준점이 생기기 때문입니다.

이 프롬프트가 돕는 방식

이 프롬프트는 준비 단계에서 옆에 앉아 있는 시니어 scrum master처럼 작동합니다. velocity, capacity, backlog 상태, dependency 같은 sprint context를 바탕으로, 세션을 1시간 안에 끝낼 수 있도록 구조화해줍니다. 회의가 시작되기 전에 draft sprint goal, capacity 기반의 권장 story selection, dependency map, risk flag까지 손에 넣을 수 있습니다.

핵심은 대부분의 팀이 건너뛰는 규율을 강제한다는 점입니다. 먼저 sprint goal을 정의하고, 그다음 그 goal을 뒷받침하는 story를 고르는 것입니다. 순서를 반대로 하지 않습니다.

언제 꺼내 쓸까

• 스프린트 세리머니까지 함께 운영하는 PM이고, 플래닝 회의를 2시간에서 45분으로 줄이고 싶을 때
• 팀이 매 sprint마다 과도하게 약속하고 마지막 이틀 동안 허둥대는 패턴이 반복될 때
• 새 엔지니어링 팀을 온보딩하며 첫날부터 좋은 sprint hygiene를 만들고 싶을 때
• cross-team dependency가 자꾸 sprint를 터뜨리고 있어, 이를 초기에 체계적으로 표시하는 방법이 필요할 때
• Kanban에서 Scrum으로 전환하며 planning muscle을 길러야 할 때

좋은 결과물의 모습

잘 구조화된 sprint plan에는 팀 전체가 한 문장으로 말할 수 있는 단 하나의 명확한 goal이 있고, capacity의 85-90% 안에서 추정된 story가 선택되어 있으며, owner와 due date가 붙은 dependency가 식별되어 있고, mitigation plan이 붙은 명시적 risk가 포함되어 있습니다. sprint goal을 한 문장으로 설명할 수 없다면, 계획은 아직 덜 다듬어진 것입니다.

참고 자료

• State of Agile Report 2024 — Atlassian
• Story Mapping: Discover the Whole Story — Jeff Patton & Associates
• Sprint Planning Done Right — Scrum.org