스크럼 리파인먼트 단계별 접근법
저자는 효과적인 리파인먼트 미팅을 위해 다음 세 단계를 제안합니다.
1. 백로그 열기
미팅 시작 전, 프로세스 오너는 팀이 관리하는 모든 백로그를 미리 열어두어 미팅 중 불필요한 브라우저 조작 시간을 줄입니다. 가능한 경우 티켓의 우선순위를 빠르게 검토하며, 이미 스프린트 중이거나 심지어 진행 중인 티켓이라도 변경 비용이 적게 드는 지금 정제하는 것을 권장합니다.
2. 티켓 정제
정제의 목표는 팀원 모두가 이해하고 작업할 수 있는 작고 품질 좋은 티켓을 만드는 것입니다.
-
읽기 및 검토: 각 티켓을 소리 내어 읽고, 모든 관련 아티팩트(이미지, 서버 로그 등)를 함께 검토하여 논의 속도를 조절합니다.
-
명확화 및 단순화: 모호한 표현, 익숙하지 않은 전문 용어, 약어, 곁가지 대화는 피하고 내용을 명확하고 단순하게 만듭니다.
-
형식: 버그의 경우 훌륭한 버그 리포트를, 기능의 경우 Given/When/Then 형식을, 태스크는 명확한 요약과 하위 태스크를 활용합니다.
-
참여 유도: 조용한 팀원, 특히 신규 팀원에게 “어떻게 생각하세요?”, “무엇이 명확하지 않나요?”, “이 티켓에 무엇이 문제인가요?”와 같은 질문으로 참여를 유도합니다.
-
주의: 리파인먼트는 문제 해결 과정이 아닙니다. 프로그래머의 문제 해결 본능을 억제하고, 계획을 평가하는 데 집중해야 합니다.
3. 포인트 할당
포인트 할당은 복잡성에 대한 빠르고 협력적인 논의입니다.
-
복잡성 vs. 시간: 시간(예: “반나절”)이 아닌 복잡성(“중간 복잡성”)을 기준으로 합니다. 이 구분은 숨겨진 복잡성을 드러내는 데 중요한 역할을 합니다.
-
포인트 시스템: 1, 2, 4, 8과 같은 배수 시스템을 사용하며, 8점짜리 스토리는 너무 커서 분할합니다.
-
방법: 플래닝 포커(Planning Poker) 방식을 선호하며, 이례적인 투표(예: 다른 사람이 2점일 때 4점)를 한 사람은 자신의 근거를 설명할 기회를 가집니다.
버그 포인트 할당에 대한 견해
저자는 버그에 포인트를 할당하지 않고 정제만 합니다. 그 이유는 다음과 같습니다.
-
복잡성 예측의 어려움: 버그의 복잡성은 실제 작업을 시작하기 전까지는 알기 어렵습니다. 이는 “집의 금이 간 기초를 고치는 데 얼마나 복잡한가?”와 같은 질문과 유사합니다.
-
잘못된 지표 기여: 버그 포인트는 벨로시티와 같은 지표에 기여하여 버그를 기능과 조직적으로 비교 가능하게 만듭니다. 그러나 버그는 오버헤드에 가깝기 때문에 지표에서 제외하는 것이 바람직합니다.