이 자료는 scrum.org에서 2021년 1월에 발표한 스크럼 사용자를 위한 칸반 가이드를 기준으로, 한글로 정리하고 이해하기 쉽도록 조정하였다. 일부 내용은 생략하였고, 일부 내용은 추가 되고 변경되었다.

원문은 아래 링크에서 다운로드 할 수 있다.

https://www.scrum.org/resources/kanban-guide-scrum-teams

칸반(Kanban) 

칸반은 시각적이고 WIP(Work-In-Progress)로 제약된 풀 시스템(Pull system)의 프로세스를 통해 가치 흐름을 최적화 하기 위한 전략이다.

흐름과 경험 

칸반의 핵심은 흐름이다. 흐름은 제품개발 시스템 전반에 걸친 가치의 움직임이다. 칸반은 프로세스의 전반적인 효율성, 효과성, 그리고 예측가능성을 개선하여 흐름을 최적화한다.

스크럼 환경에서 흐름을 최적화하려면 흐름의 의미를 명확하게 이해하고 있어야 한다.  스크럼은 경험적 프로세스 제어 이론 또는 경험주의를 기반으로 한다. 경험적 프로세스 제어의 핵심은 투명성, 검사 및 적응 사이클의 빈도이다. 이것은 피드백 루프까지의 사이클 시간이다.

칸반을 스크럼에 적용할 때 피드백 루프를 통해 흐름의 개선에 중점을 둔다. 제품과 프로세스의 투명성과 검사 및 적응의 빈도를 최적화한다.

 

흐름의 기본 메트릭스 

칸반을 사용하는 스크럼 팀이 추적해야 하는 흐름의 네 가지 기본 메트릭스는 다음과 같다.

• 진행 중인 작업(WIP): 시작되었지만 완료되지 않은 작업 항목의 수. 팀은 WIP 지표를 사용하여 WIP를 줄이고 흐름을 개선하기 위한 진행 상황에 대한 투명성을 제공할 수 있다. WIP 지표와 스크럼 팀이 WIP를 제한하는 데 사용하는 정책 간에는 차이가 있다.

• 사이클 시간(Cycle time): 작업 항목이 시작되어 끝날 때까지 경과된 시간

• 작업 경과 기간(Work item age): 작업 항목의 시작부터 현재까지의 시간. 진행 중인 항목에만 적용된다.

• 처리량(Throughput): 단위 시간당 완료된 작업 항목 수.

 

리틀의 법칙(Little’s law) – 흐름을 지배하는 열쇠 

흐름 이론의 핵심 이론은 아래와 같이 관계를 설정하는 지침인 리틀의 법칙이다.

평균 사이클 시간 = 평균 WIP / 평균 처리량

리틀의 법칙은 일정한 처리량이 있는 프로세스에 일정 시간에 더 많은 수의 작업을 수행할수록 해당 작업을 완료하는데 더 오래 걸린다는 것이다.

사이클 시간이 너무 길면 스크럼 팀이 고려해야 할 첫 번째 조치는 WIP를 낮추는 것이다. 칸반의 다른 요소 대부분은 WIP와 사이클 시간 간의 관계를 기반으로 한다.

리틀의 법칙은 또한 흐름 메트릭스와 데이터를 사용하여 과거 흐름에 대한 데이터를 사용하여 흐름에 대한 검사 및 적응 실험에 정보를 제공함으로써 흐름 이론이 경험론에 의존하는 방식을 보여준다.

 

칸반 실무 

스크럼 팀은 다음 네 가지 방법을 사용하여 흐름을 최적화한다.

• 작업흐름(workflow)의 시각화

• 진행 중인 작업 제한(WIP)

• 진행 중인 작업 항목의 능동적인 관리

• 팀의 작업흐름 정의 검사 및 조정

 

작업흐름의 정의 

네 가지 칸반 실무는 스크럼 팀의 작업흐름을 이해하고 있을 때 유용하다. 칸반을 사용하는 스크럼 팀의 작업흐름을 이해하면, 작업의 투명성을 높이고 자기 관리가 가능하게 된다.

작업흐름 정의는 스프린트와 스프린트 백로그를 넘어 확장될 수 있다. 예를 들어, 스크럼 팀의 작업흐름은 스프린트 내부 또는 외부의 흐름을 포함할 수 있다.

작업흐름을 만들고 적용하는 것은 스크럼 팀의 역할이다. 스크럼 팀은 스스로 작업흐름을 형성해야 한다.

 

작업흐름 시각화 – 칸반 보드 

칸반 보드를 사용한 시각화는 스크럼 팀이 작업흐름을 투명하게 만드는 방법이다. 상급관리자는 적시에 적절한 대화를 유도하고 개선 기회를 사전에 제안해야 한다.

시각화에는 다음이 포함된다.

• 스크럼 팀 작업을 시작하고 완료될 것으로 추정되는 지점.

• 작업 항목의 정의 – 스크럼 팀의 시스템을 통해 흐르는 개별 가치 단위(이해관계자, 지식, 프로세스 개선, 대부분 제품 백로그 항목(PBI)).

• 작업흐름의 정의에서는 작업 항목별 시작부터 끝까지의 흐름을 설명한다.

• 작업이 각 상태를 통과하는 방식에 대한 명시적 정책(스크럼 팀의 완료 정의 항목 및 단계 간 풀 정책 항목 포함).

• 진행 중인 작업(WIP)을 제한하기 위한 정책.

 

진행 중인 작업(WIP) 제한하기 

진행 중인 작업(WIP)은 스크럼 팀이 시작했지만 아직 완료되지 않은 작업 항목이다.

칸반을 사용하는 스크럼 팀은 진행 중인 이러한 작업 항목의 수를 명시적으로 제한해야 한다. 스크럼 팀은 WIP를 명시적으로 제한할 수 있고, 일단 설정되면 해당 제한 조건을 준수해야 한다.

WIP를 제한하는 주요 효과는 풀 시스템(Pull system)을 생성한다는 것이다. 팀이 작업을 수행할 수 있는 능력이 있는 것이 분명한 경우에만 항목에 대한 작업을 시작(가져옴)하기 때문에 풀 시스템이라고 한다. WIP가 정해진 한계 이하로 떨어지면 새로운 작업을 시작하라는 신호이다. 이것은 요청될 때마다 항목에 대한 작업이 시작되도록 요구하는 푸시 시스템과 구별된다.

WIP를 제한하면 스크럼 팀의 자기 관리, 집중, 헌신 및 협업이 원활해지고 향상된다.

 

진행 중인 작업 항목의 적극적인 관리 

WIP를 제한하는 것은 흐름 형성하는데 필요하지만 그것 만으로 충분하지 않다. 흐름을 형성하기 위해서 진행 중인 작업 항목을 능동적으로 관리해야 한다. 스프린트 내에서 스크럼 팀은 다음과 같은 관리를 해야 한다.

• 작업 항목이 작업흐름에서 나가는 속도와 거의 동일한 속도로 작업흐름으로만 끌어오는지 확인한다.

• 작업 항목이 불필요하게 정체되지 않도록 한다.

• 차단된 작업항목, 대기 중인 작업항목, 팀의 예상 사이클 시간 수준을 초과하는 작업 항목에 신속하게 대응한다 (서비스 수준 기대치 – SLE 참조).

 

SLE(서비스 수준 기대치, Service Level Expectation) 

SLE(서비스 수준 기대)는 작업 항목이 스크럼 팀의 작업흐름 내에서 처음부터 끝까지 흐름에 걸리는 시간을 예측한다. 스크럼 팀은 SLE를 사용하여 흐름 문제를 찾고, 기대치에 못 미치는 경우를 검사하고 조정한다.

SLE는 두 부분으로 구성된다: 경과된 일자와 해당 기간과 관련된 확률(예: 작업 항목의 85%가 8일 이내에 완료되어야 함). SLE는 스크럼 팀의 과거 사이클 시간을 기반으로 해야 하며, 일단 계산되면 스크럼 팀은 이를 투명하게 만들어야 한다. 과거 사이클 시간 데이터가 없는 경우 스크럼 팀은 최선을 다해 추정한다. 적절한 SLE 계산을 수행하기에 충분한 과거 데이터가 있으면 검사하고 조정해야 한다.

 

작업흐름 정의 검사 및 조정 

스크럼 팀은 기존 스크럼 이벤트를 사용하여 작업흐름 정의를 검사하고 적용하여 경험치를 개선하고 스크럼 팀이 제공하는 가치를 최적화한다.

다음은 스크럼 팀의 작업흐름 정책들이다.

• 시각화 정책 – 작업흐름 상태는 실제 작업흐름을 변경하거나 팀이 검사 및 조정하려는 영역에서 투명성이 형성된다.

• 작업 방식 정책 – 장애를 직접 해결할 수 있다. 예를 들어, WIP 한도 및 SLE를 조정하거나 배치 크기(항목을 가져오는 빈도)를 변경하여 개선할 수 있다.

 

흐름기반 이벤트(Flow-based Events) 

스크럼 환경에서 칸반은 스크럼 가이드에 설명된 이벤트 외에 추가 이벤트가 필요하지 않다. 그러나 스크럼 이벤트에서 흐름기반 관점과 메트릭스를 사용하면 스크럼의 경험적 접근 방식이 강화된다.

 

스프린트(Sprint) 

스프린트와 이벤트는 제품과 프로세스 모두를 검사하고 개선할 수 있도록 한다. 팀이 스프린트당 한 번만 가치를 전달할 수 있다는 것은 일반적인 오해이다. 스프린트당 적어도 한 번은 가치를 전달해야 한다. 칸반과 함께 스크럼을 사용하는 팀은 스프린트 및 해당 이벤트를 작업흐름 정의와 흐름 메트릭스를 공동으로 검사하고 조정함으로써 피드백 개선 루프로 사용한다.

칸반을 활용하면 스크럼 팀은 흐름을 개선하고 검사 및 적응을 기반으로 스프린트를 진행하는 동안 적시에 결정을 할 수 있게 된다. 이 환경에서 스크럼 팀은 스프린트 목표에 집중하고 스크럼 팀원 간 긴밀한 협력을 통해 스프린트에서 전달되는 가치를 최적화한다.

 

스프린트 계획(Sprint Planning) 

흐름기반 스프린트 계획은 흐름 메트릭스를 스프린트 백로그 개발을 위한 보조 수단으로 사용한다. 과거 처리량을 검토하면 스크럼 팀이 다음 스프린트에 대한 용량을 추정할 수 있다.

 

일일스크럼(Daily Scrum) 

흐름기반 일일 스크럼은 개발자가 일관된 흐름을 유지하기 위해 할 수 있는 모든 일에 집중한다. 일일스크럼은 회의가 칸반 보드를 중심으로 진행되며 흐름이 부족한 부분과 이를 되돌리기 위해 개발자가 취할 수 있는 조치에 중점을 둔다.

흐름기반 일일스크럼에서 고려해야 할 추가 사항

• 차단된 작업 항목은 무엇이며 차단을 해제하려면 어떻게 해야 하는가?

• 예상보다 느리게 진행되는 작업은 무엇인가? 진행 중인 각 항목의 작업기간은 얼마나 되는가? 어떤 작업 항목이 SLE를 위반했거나 위반하려고 하며 스크럼 팀은 해당 작업을 완료하기 위해 무엇을 할 수 있는가?

• 현재 작업을 완료하는데 영향을 미칠 수 있는 요소가 있는가?

• 스크럼 팀이 다음 작업계획을 변경하는데 필요한 교훈이 있는가?

• WIP 한도를 초과했는가? 진행 중인 작업을 완료하려면 어떻게 해야 하는가?

 

스프린트 리뷰(Sprint Review) 

스크럼 가이드에 스프린트 리뷰 방법이 설명되어 있다. 리뷰에서 칸반 흐름 메트릭스를 검사하면 제품 목표를 향한 진행 상황을 모니터링하는 것에 대한 새로운 대화 기회를 만들 수 있다. 처리량을 검토하면 제품 소유자가 예상 배송 날짜를 논의할 때 추가 정보를 제공할 수 있다.

 

스프린트 회고(Sprint Retrospective) 

흐름기반 스프린트 회고는 흐름 메트릭스 및 분석 검사를 추가하여 스크럼 팀이 프로세스를 개선할 수 있는지 판단하는 데 도움이 된다. 칸반을 사용하는 스크럼 팀은 또한 다음 스프린트에서 흐름을 최적화하기 위해 작업흐름을 검사하고 조정한다. 누적 흐름도를 사용하여 스크럼 팀의 WIP를 시각화 하면 개략적인 평균 사이클 시간과 평균 처리량을 계산할 수 있다.

스프린트 회고 외에도 스크럼 팀은 스프린트 전반에 걸쳐 나타나는 프로세스 검사 및 적응 기회를 활용해야 한다.

마찬가지로, 스크럼 팀의 작업흐름 정의에 대한 변경은 언제든지 발생할 수 있다. 이러한 변경 사항은 스크럼 팀이 수행하는 방식에 중대한 영향을 미치기 때문에 스프린트 회고 이벤트에서 제공하는 정기 주기 동안 변경 사항은 복잡성을 줄이고 초점, 헌신 및 투명성을 향상시킬 것이다.

 

증분(Increment) 

스크럼은 팀이 매 스프린트마다 가치 있고 유용한 증분을 (최소한) 생성하도록 한다. 스크럼은 스프린트 동안 피드백 루프를 빠르게 검사하고 조정할 수 있도록 가치 있는 증분을 생성하도록 권장한다. 칸반은 이러한 피드백 루프의 흐름을 보다 명시적으로 관리하는 데 도움이 되며 스크럼 팀이 병목 현상, 제약 조건 및 장애를 식별하여 보다 빠르고 지속적인 가치 전달을 가능하게 한다.

맺음말 

스크럼은 프로세스나 기술이 아니다. 높은 가치의 제품을 생산적이고 창의적으로 제공하면서 복잡한 적응 문제를 해결할 수 있는 프레임워크이다. 스크럼은 다른 기술, 방법론 및 관행을 위한 컨테이너 역할을 한다.

칸반의 흐름 최적화 방식은 스크럼 팀에 적절한 시간에 올바른 것을 검사한 다음 해당 검사를 기반으로 필요에 따라 조정할 수 있도록 한다. 칸반의 투명성, 시각화 및 흐름에 대한 집중은 피드백, 경험주의, 가치 전달을 극대화한다.