Scrumban이란?

Scrumban은 실제로 무엇인가

Scrumban은 칸반과 Scrum에서 제 몫을 하는 부분만 남기고 나머지를 버립니다. 칸반에서는 눈에 보이는 보드, 컬럼 기반의 워크플로, 그리고 진행 중인 일의 양에 대한 명시적인 제한 — 흐름을 읽을 수 있게 만드는 것들을 가져옵니다. Scrum에서는 기간이 정해진 스프린트 — 백로그를 계획으로 바꾸는 것 — 을 가져옵니다.

버리는 것: 매일 아침 스탠드업, 백로그 그루밍 회의, 스토리 포인트 의식, 의례가 되어 버린 회고. 잘 다듬어진 조직의 엔지니어 열 명에게는 통하지만, 토요일에 뭔가를 내보내려는 창업자 한 명에게는 통하지 않습니다.

이름은 Corey Ladas에게서 왔습니다. 그의 에세이와 이후의 책 Scrumban은 Scrum 팀이 고정된 이터레이션에서 당겨 오는(pull) 흐름으로 옮겨 가는 방법을 설명했습니다.

Scrumban vs 칸반 vs Scrum: 무엇이 다른가

셋의 차이는 주로 두 가지입니다. 일을 정해진 기간 단위로 계획하는가, 그리고 보드 주변에 프로세스가 얼마나 붙어 있는가.

출처: 스프린트, 역할, 이벤트는 Scrum Guide, 흐름과 진행 중 작업 제한은 Kanban Guide.

Scrumban 보드는 어떻게 생겼나

Scrumban 보드는 칸반 보드 위에 스프린트를 겹친 것입니다. 컬럼은 일이 어디에 있는지를, 스프린트는 이번 주가 백로그의 어느 부분에 관한 것인지를 보여 줍니다. 최소한의 보드에는 컬럼이 네 개 있습니다.

• Backlog — 할 수도 있는 모든 일. 아래쪽은 정렬하지 않고, 위쪽만 정렬합니다.
• Todo — 다음에 하기로 정한 일. 일부러 작게 둡니다. 이것이 줄어들면 계획할 때라는 신호입니다.
• Doing — 누군가(사람 또는 AI 에이전트)가 지금 작업 중인 일.
• Done — 끝난 일. 스프린트가 끝나면 비우거나 보관합니다.

Scrumban 보드 만드는 법

1. 컬럼 네 개를 만듭니다: Backlog, Todo, Doing, Done.
2. 알고 있는 일을 모두 Backlog에 넣습니다. 전부 정렬하지 말고, 위쪽만 정렬합니다.
3. Doing에 한 번에 몇 개까지 둘지 정합니다. 혼자라면 한두 개, 작은 팀이라면 한 사람당 하나 정도.
4. 스프린트 길이를 1주나 2주로 정하고, 한 문장짜리 목표를 씁니다. 그 목표에 도움이 되는 일만 Todo로 가져옵니다.
5. 당겨 오는 방식으로 일합니다. Doing의 일이 끝나면 Todo 맨 위의 다음 카드를 가져옵니다. 누구도 남에게 일을 밀어 넣지 않습니다.
6. 계획은 달력이 아니라 Todo가 줄어들 때 합니다. 스프린트가 끝나면 무엇이 끝났고 무엇이 안 끝났는지 보고, 다음 스프린트를 시작합니다.

Weft가 Scrumban을 고른 이유

Weft가 있는 이유는, 대부분의 작업 관리 도구가 두 극단 중 하나에 맞춰져 있기 때문입니다. 혼자 쓰는 할 일 앱(끝없는 목록, 리듬 없음)이거나, 50명짜리 애자일 세트(1인 회사에는 과한 프로세스 비용)이거나. Scrumban은 정확히 그 가운데에 있습니다. 주간이나 격주 출시를 강제할 만큼의 구조는 있고, 출시일을 관리 작업으로 다 써 버릴 만큼은 아닙니다.

Weft는 이것을 어떻게 구현하는가

• 기본 컬럼 네 개: Backlog, Todo, Doing, Done. 진행 중 작업은 컬럼마다 붙인 숫자가 아니라, 당신을 기다리는 일의 양으로 제한됩니다. Kanban Guide는 진행 중 작업을 제한하는 명시적인 정책을 워크플로 정의의 일부로 보며, 여유가 생길 때만 새 항목을 당겨 오도록 합니다.
• 진행 중인 스프린트는 한 번에 하나이고, 목표는 선택입니다. 스프린트 자체도 선택입니다. 순수한 칸반이 맞는다면 쓰지 않아도 됩니다. Scrum Guide는 스프린트를 한 달 이하의 고정된 길이를 가진 이벤트로 정의하며, 이전 스프린트가 끝나면 곧바로 새 스프린트가 시작됩니다.
• 작업에는 우선순위, 예상 시간, 마감일, 그리고 선택적인 스프린트 연결이 있습니다. 에픽도, 워크플로도, 커스텀 필드도 없습니다.
• 사이클 타임은 작업이 semantic="doing" 인 컬럼으로 들어갈 때 시작해 "done" 에서 끝납니다. 숫자는 정직한 사용에서 나오는 것이지, 스토리 포인트 산수에서 나오는 것이 아닙니다.

AI 에이전트와 함께하는 Scrumban

당겨 오는 방식은 AI 에이전트에게도 Scrumban이 통하게 만드는 이유입니다. MCP로 Weft에 연결된 에이전트는 다음 카드를 스스로 가져갑니다. start_task가 카드를 점유하므로 다른 에이전트가 같은 카드를 집을 수 없고, complete_task가 무엇을 했는지와 그 증거를 남기며 카드를 마칩니다. 결정이 필요하면 에이전트는 추측하지 않고 당신에게 묻습니다. 그리고 끝난 일이 너무 많이 당신을 기다리는 동안에는 새 작업을 시작하지 않습니다. 이것이 칸반의 진행 중 작업 제한을, 늘릴 수 없는 단 하나의 자원 — 당신의 주의력 — 에 적용한 것입니다.

Scrumban이 맞지 않을 때

• 여러 Scrum 팀을 동시에 굴리고 있다. Scrum Guide는 Scrum 팀을 보통 10명 이하로 보고, 더 큰 제품은 하나의 제품 목표와 하나의 제품 백로그를 공유하는 여러 Scrum 팀으로 나눠야 한다고 말합니다. 프로그램 단위 보고, 공유 벨로시티, 팀 간 의존 — 그런 곳에서는 Jira의 완전한 Scrum이 값을 합니다. Nexus Guide는 바로 그런 상황을 위해 쓰였습니다. 하나의 제품 백로그로 일하는 여러 Scrum 팀이, 팀 간 의존을 드러내고 해결하기 위한 추가 관행을 갖추는 방식입니다.
• 순수한 지원 업무나 상시 운영을 한다. 스프린트 리듬이 필요 없습니다. 순수한 칸반이나 티켓 시스템이 더 잘 맞습니다.
• 간트 차트와 타임라인이 필요하다. Scrumban은 스프린트 중심이지, 의존 그래프 중심이 아닙니다.

Scrumban에 대해 자주 묻는 질문