Scrum Event시 효율적 시간 활용 방법

6 min readAug 6, 2022

Scrum을 수행하다보면 Event 시간이 길어지고, 점점 시간이 낭비된다고 생각하는 팀원이 생기기 시작합니다. 시간을 효율적으로 사용하기 위한 고려사항을 정리해보았습니다.

1. 공통

일하는 방식에 대한 개선 의견이 있다면 소신있게 이야기
- Sprint가 종료될때 마다 Retrospective를 수행하는 이유입니다.
- 문제 발굴도 중요하지만, 해결방안과 같은 Action Item도 도출
회의시작전 회의의 목적/결과를 공유하고, 의사결정은 빠르게 결정하기
- 의사결정 팀원에게 권한 부여/분산
- 만약 결정이 어려운 것은 일단 실행해보고 문제 발생시 수정
- Facilitator(SM)은 주제에서 벗어나는 이야기는 정리하고, 중간에 남은 회의 시간 공유
- 낭비 사례 : 많은 정보를 공유하고 갑자기 어떤게 나은지 의사결정을 해달라고 하면 의사결정권자가 당황하게 됨. 따라서 오늘 회의는 무엇을 결정하기 위한 논의라고 사전에 공유하면 더 효과적인 회의와 Right Person 참석이 가능
회의는 필수 인력만 참여하고, 결과 공유
- 단, 회의 후 다시 전파 공수가 많이들고, 필수 인력 누락으로 매번 재논의해야 한다면 전체 회의가 더 효율적임
- 낭비 사례 : 회의의 목적에 맞지 않는 사람이 참석하면 그를 위해 배경을 설명하고, 불필요한 질문을 받아야 합니다

목적 : 미완성 User Story 문제를 제거하여, Sprint Planning 시간을 절약할 수 있다.
낭비 제거 방안 : 도메인을 아는 핵심 인력만 참석하여 Sprint Planning전에 사전 조율(User Story 정리)
- 필수참석 : PO, SM(+ 업무 전문가)
- 옵션 : 개발자
고려사항
- 시간 효율화로 필요 인력 없이Refinement가 진행된다면, 결국 , Sprint Planning때 다시 Refinement하게 됨
- 즉, Refinement를 수행하는 동안 업무 설명 공유가 많이 되고, 개발자 의견을 물어봐야 한다면 함께 진행이 효율적임(Sprint Planning때 반복 제거)

목적 : 집중해야 할 Sprint Goal 정의 및 일의 우선순위로 업무 할당한다.
낭비 제거 방안 : Sprint내에 할 업무만 집중하여 논의(안하거나 못할 업무를 미리 하는 논의도 낭비)
시간 : 4주기준 8시간 이내
고려사항
- Story Points는 예측값이지 정확한 견적이 아닙니다. 과거 경험기반으로 유사한 업무와 비슷하게 point 예측하며 업무 노하우가 쌓이다보면 점점 정확해집니다.

목적 : (일반적 방법) 어제한일 / 오늘할일 / 장애요소(공유이지보고 아님)
- 최신 Scrum Guide에서는 Daily Standup 미팅의 구체적 방식은 생략
- 해당 조직에서 더 효율/효과적인 방식이 있다면 그렇게 하세요.
시간 : 매일 15분 (회의가 효과적이라면 규칙적으로 시간은 늘려도 됨)
낭비 제거 방안
- 미팅전에 보드 상태 현행화 하기
- 현재 진행중인 업무의 이슈 중심으로만 공유하기
- Sprint Planning, Review/Retrospective가 있는 Sprint의 첫날과 끝날은 생략 가능
- 공유 중 이야기가 길어질 것 같으면 Daily scrum 종료를 선언하고 계속 이어서 진행(다른 일정이 있는분은 이석 가능)
낭비 사례
- 스크럼 보드가 업데이터 안되어 있어서 미완료 등 이슈로 파악하고 회의에 들어왔지만, 상태 현행화 안된 해결된 issue인 경우도 많음
고려사항
- 다른분들에게 도움이 되는 업무 논의는 짧게 진행 가능(단, 그게 후속 회의보다 더 효율적이라면…)

목적 : 우선순위 중심으로 최대의 Value를 생산하고, 동시 작업을 줄여 미완료 작업을 최소화한다.
낭비 제거 방안
- 품질을 유지하고 재개발 방지
- 동시에 여러 작업 수행(WIP)을 줄이고 한두가지 업무만 빠르게 완료하기 (작업이 빨리 끝나야 후속 작업자들의 대기시간 감소)
- Sprint내에 동시 진행한 2개의 60% 완성된 User Story보다는 1개의 100% 완성된 User story가 나음
- Lead Time : 작업을 하기로 한 후(Sprint 할당) 부터 완료까지 걸리는 시간 (예. 피자 주문접수부터 고객에게 전달한 배송완료까지 시간)
- Cycle Time : 작업을 시작 한 후 부터 완료/전달까지 걸리는 시간 (예. 피자 요리 시작부터 완료 시간)
낭비 사례
- 개발이 끝나야 Tester, PO 리뷰가 수행되지만, Scrum이 끝날 시점에 동시에 개발중인 모든 issue가 완료되기 시작하면 Tester와 PO의 Waiting Time이 길어지고, Review 진행을 위해 검토가 부실해짐

목적 : 이해관계자에게 Sprint 기간 생성한 결과물 및 달성한 Outcome을 보여주고, 검토 결과를 받아 적용한다. (한팀으로 일하는 PO에게 리뷰 받는 시간이 아님)
시간 : 4주 Sprint 기준 4시간 이내
낭비 제거 방안
- 완성된 기능에 대해 시연 (미완성 및 이해관계자에게 도움되지 않는 내용 설명/시연하지 않기)
- 주요 기능 및 다른팀에서 활용해야 하는 내용 및 이슈 회의 중심 공유
낭비 사례
- Review를 위해 너무 과한 리허설과 프리젠테이션 자료를 만드는 사례가 있음

목적 : Product의 품질과 업무 효율을 높이기 위해 우리 스스로 프로세스/문화를 review하고 개선점을 찾고 지속적으로 개선한다.
시간 : 4주 Sprint 기준 3시간 이내
낭비 제거 방안
- 개발자의 시간 효율 방안 등 개선사항은 Retrospective를 통해 항상 도출 필요
- 개선의견 중에 개선하기로 결정했다면 Action Item까지 논의 완료(문제점 발굴 보다는 해결 방안도 함께 논의)
- 소수의견을 무시하면 안되지만, 그렇다고 모두가 만족할 수 없는 경우도 발생(해결 할 수 없는 문제/Risk는 수용)
- Action Item을 지속적으로 개선하고 실천되지 않는다면 시간 낭비로 생각될 수 있음
낭비 사례
- 해결할 수 없는 내용이 반복적으로 나오고, Action Item이 도출되지 않음
- 특히 내(우리)가 반성하고, 내(우리)가 앞으로 무엇을 개선할지는 긍정적이지만, 내가 아닌 타인이 잘못하고, 개선사항 중심으로 이야기한다면 최악의 회고입니다.