🗓️
스크럼을 한 번도 써 본 적 없는 분들을 위한, 쉬운 말과 그림 중심의 입문서입니다. 읽는 데 약 15분이 걸리며, 사전 지식은 필요 없습니다.
집을 리모델링한다고 생각해 보세요. 거대한 계획 하나를 정해 놓고 1년 뒤에 결과를 볼 수도 있고, 시공자가 방 하나씩 끝낼 때마다 보여 주어 다음 방을 더 좋게 만들 수도 있습니다. 애자일은 두 번째 방식입니다.
| 공식 문구 | 일상에서는 이런 뜻입니다 |
|---|---|
| 사람과 대화가 프로세스와 도구보다 우선 | 서로 이야기하세요. 티켓과 이메일 뒤에 숨지 마세요. |
| 작동하는 제품이 방대한 문서보다 우선 | 아직 존재하지 않는 것에 대한 50쪽짜리 문서보다, 실제로 작동하는 것이 낫습니다. |
| 고객과의 협력이 계약 협상보다 우선 | 우리가 만드는 대상과 가까이 지내며, 올바른 것을 만들고 있는지 계속 확인합니다. |
| 변화에 대응하는 것이 계획을 따르는 것보다 우선 | 계획은 최선의 추측일 뿐입니다. 더 많이 알게 되면 계획을 고칩니다. |
애자일은 왼쪽 항목을 더 중시하지만 오른쪽 항목도 여전히 가치가 있습니다. 강조점의 차이이지 "문서를 쓰지 말라"는 뜻이 아닙니다.
핵심 개념: 스프린트는 길이가 고정된 상자입니다. 일에 맞춰 늘어나지 않고, 대신 맡는 일의 양을 조절합니다. 덕분에 전달 리듬을 예측할 수 있습니다.
하나의 작은 팀(보통 10명 이내)이며, 하위 팀이나 내부 위계가 없습니다. 책임 역할은 세 가지뿐입니다.
사용자와 비즈니스를 대변합니다. 프로덕트 백로그를 관리하고, 다음에 무엇을 만드는 것이 가장 가치 있는지 결정합니다.
비유: 이번 시즌에 팀이 무엇으로 우승을 노릴지 정하는 사람.
실제로 일하는 모든 사람(엔지니어, 디자이너, 테스터, 분석가)입니다. 어떻게 할지, 스프린트에 얼마나 들어갈지 직접 결정합니다.
비유: 경기장에서 뛰는 선수들.
팀이 스크럼을 잘 쓰도록 코칭하고, 장애물을 치우고, 팀의 집중을 지키며 회의가 유익하도록 돕습니다. 프로젝트 매니저가 아닙니다.
비유: 선수들이 마음껏 뛸 수 있도록 길을 터 주는 코치.
만들 수 있는 모든 것을 우선순위대로 정리한 하나의 목록으로, 가장 중요한 것이 맨 위에 있습니다. 끝나는 일이 없고, 배우면서 계속 바뀝니다.
약속: 프로덕트 골, 우리가 향하는 방향.
이번 스프린트를 위해 고른 항목과 그것을 끝내기 위한 계획입니다. 개발자가 관리합니다.
약속: 스프린트 골, 이번 스프린트가 왜 중요한지 한 문장으로.
스프린트가 끝났을 때의 작동하는 결과물입니다. 반쯤 만든 부품 더미가 아니라, 실제로 쓸 수 있는 것입니다.
약속: 완료의 정의(Definition of Done), "끝났다"가 무엇을 뜻하는지에 대한 공동 체크리스트.
모두가 업무의 실제 상태를 볼 수 있습니다. 깜짝 놀랄 일이 없습니다.
정기적으로 멈춰서 확인합니다. 기대한 대로 가고 있나요?
아니라면 비용이 적을 때 빠르게 무언가를 바꿉니다.
2부의 모든 세리머니는 이 세 가지 원칙 중 하나를 뒷받침하기 위해 존재합니다.
스크럼의 공식 용어는 "이벤트"이지만 대부분의 팀은 "세리머니"라고 부릅니다. 각각 시간 제한(최대 길이가 있어 늘어지지 않음)이 있고, 저마다 구체적인 문제를 풉니다. "이 회의를 왜 하지?" 싶을 때는 아래에 답이 있습니다.
예시일 뿐입니다. 실제 요일과 시간은 팀이 정합니다(맨 아래 "우리 팀 합의" 참고).
팁: 보드를 오른쪽에서 왼쪽으로(완료에 가까운 것부터) 훑어 보세요. 질문이 "어제 뭘 했나요?"에서 "이걸 끝내려면 무엇이 필요한가요?"로 바뀝니다.
| 이것을 없애면… | …이런 일이 생깁니다 | 답해 주는 질문 |
|---|---|---|
| 스프린트 플래닝 | 불분명한 목표, 제각각인 일, 과도한 약속 | "무엇을, 왜 하고 있나요?" |
| 데일리 스크럼 | 너무 늦게 발견되는 장애물, 중복 작업 | "오늘 순조로운가요?" |
| 리파인먼트 | 모호한 작업, 길고 고통스러운 플래닝 | "다음 일은 시작할 만큼 명확한가요?" |
| 스프린트 리뷰 | 잘못된 것을 만듦, 이해관계자의 뜻밖의 반응 | "올바른 것을 만들었나요?" |
| 회고 | 같은 문제가 반복되고 개선이 없음 | "어떻게 하면 더 잘 일할 수 있나요?" |
칸반은 일본어로 "간판" 또는 "시각 카드"라는 뜻입니다. 도요타는 다음 공정이 준비되었을 때만 부품을 더 만들도록 공장에서 카드를 썼습니다. 핵심 아이디어는 일을 눈에 보이게 하고, 끝낼 수 있는 것보다 더 많이 시작하지 않는다는 것입니다. 스크럼에서는 칸반 방식의 보드로 스프린트 백로그, 즉 이번 스프린트에 약속한 일을 보여 줍니다.
각 카드는 하나의 업무(Jira의 티켓)입니다. 각 열은 하나의 단계입니다. 카드는 완료될 때까지 왼쪽에서 오른쪽으로 이동합니다.
열 이름 옆의 숫자는 WIP 한도로, 비밀 병기입니다(WIP 한도 글에서 설명합니다).
WIP 한도의 이유가 궁금하다면? WIP 한도는 스크럼이 아니라 칸반과 린에서 온 아이디어라서 별도 글로 옮겼습니다: WIP 한도: 시작은 그만, 끝내기를 시작하세요.
사용자에게 무엇이 바뀌는지 알려 줍니다("검색 필터 추가"). 막연한 활동("검색 관련 작업")은 안 됩니다.
이상적으로는 며칠 안에 끝납니다. 진행 중에 일주일이나 머문다면 쪼개세요.
"제대로 동작하는지 어떻게 알까?"에 답하는 짧은 목록.
누구에게 물어야 하는지 모두가 알도록 합니다. 막힌 카드에는 눈에 띄는 표시를 합니다.
| 스크럼 보드 (우리가 쓰는 방식) | 순수 칸반 | |
|---|---|---|
| 시간 | 스프린트마다 초기화 | 끊김 없는 흐름, 스프린트 없음 |
| 보드 위의 내용 | 이번 스프린트에 약속한 것만 | 진행 중인 모든 것 |
| 역할 | 프로덕트 오너, 스크럼 마스터, 개발자 | 필수 역할 없음 |
| 공통 아이디어 | 일을 눈에 보이게 · 가져가서 일하기 · WIP 제한 · 계속 개선 | |
모든 카드는 두 개의 관문을 지납니다. 시작하기 전에 시작해도 될 만큼 명확한지 확인하는 것이 준비의 정의(Definition of Ready)이고, 끝났다고 말하기 전에 정말 끝났는지 확인하는 것이 완료의 정의(Definition of Done)입니다. 식당 주방을 떠올려 보세요. 요리사는 주문이 분명하고 재료가 조리대에 놓였을 때 시작하고, 요리는 접시에 담아 맛을 보고 안전하게 내놓을 수 있을 때에야 주방을 나갑니다.
팀이 카드를 스프린트로 가져가도 될 만큼 명확한지 알려 주는 짧은 체크리스트입니다. 재료 손질이 끝났는지 확인하는 단계입니다.
묻는 것: “추측하거나 기다리지 않고 내일 바로 시작할 수 있나요?”
카드가 정말 끝났는지 알려 주는 짧은 체크리스트입니다. 요리가 주방을 나가기 전의 품질 확인입니다.
묻는 것: “오늘 사용자가 이것을 써도 문제가 없을까요?”
| 준비의 정의 | 완료의 정의 | |
|---|---|---|
| 질문 | 이 카드는 시작해도 될 만큼 명확한가? | 이 카드는 정말 끝났는가? |
| 언제 확인하나 | 카드가 스프린트에 들어가기 전(리파인먼트와 플래닝에서) | 카드를 완료로 옮기기 전 |
| 누구를 지켜 주나 | 모호하거나 막힌 일을 시작하게 되는 개발자 | 반쯤 끝난 일을 받게 되는 프로덕트 오너와 사용자 |
| 공식 스크럼의 일부인가? | 아니요. 많은 팀이 쓰는 실천 방식이며 선택 사항입니다 | 예. 스크럼 가이드는 모든 인크리먼트에 하나를 요구합니다 |
| 주방에 비유하면 | 주문이 분명하고 재료가 조리대에 있다 | 요리를 접시에 담고, 맛을 보고, 안전하게 내놓을 수 있다 |
시작점으로 삼을 예시입니다. 팀마다 하는 일이 다르므로(디자인 팀의 “완료”는 소프트웨어 팀의 “완료”와 다릅니다) 우리 팀의 일에 맞게 고쳐 쓰세요.
| 세리머니 | 준비와 완료는 어떻게 쓰이나 |
|---|---|
| 🧹 리파인먼트 | 카드가 준비의 정의를 충족할 때까지 명확하게 다듬습니다. |
| 🗓️ 스프린트 플래닝 | 팀은 준비된 카드만 가져오고, 모호한 것은 가져오지 않습니다. |
| ☀️ 데일리 스크럼 | 보드를 보며 이 카드가 완료의 정의를 충족하려면 무엇이 더 필요한지 확인합니다. |
| 🎁 스프린트 리뷰 | 완료의 정의를 충족한 일만 끝난 것으로 보여 줍니다. |
| 🔁 회고 | 두 목록 중 너무 엄격하거나, 느슨하거나, 무시되는 것은 없나요? 개선합니다. |
| 실수 | 어떤 문제가 생기나 |
|---|---|
| 완료의 정의가 공유되지 않음 | “완료”가 사람마다 다른 뜻이 되어, 스프린트 리뷰에서 뜻밖의 일이 터집니다. |
| “거의 끝난” 카드를 완료로 셈 | 90% 끝난 카드는 끝난 것이 아닙니다. 리뷰에서 보여 주지 않고, 프로덕트 백로그로 돌아가 다시 계획합니다. |
| 준비의 정의를 벽처럼 사용 | 모든 요청에 “준비가 안 됐으니 나중에 오세요”라고 답하면 일이 느려집니다. 대화를 위한 체크리스트로 유지하세요. |
| 너무 긴 목록 | 25개 항목을 기억하는 사람은 없으니 아무도 확인하지 않습니다. |
| 스프린트 도중 목록을 슬쩍 바꿈 | 완료였던 카드가 갑자기 완료가 아니게 됩니다. 회고에서 바꾸고 모두에게 알리세요. |
| 아무도 볼 수 없는 목록 | 아무도 열지 않는 문서에 있습니다. 보드에 붙여 두세요. |
알아두기: 스크럼 가이드는 완료의 정의를 요구하지만, 준비의 정의는 없습니다. 한 스프린트 안에 끝낼 수 있을 만큼 작은 항목은 플래닝에서 고를 준비가 된 것이라고만 말합니다. 그래도 많은 팀이 모호한 일이 스프린트에 들어오지 않도록 준비의 정의를 추가하니, 선택적인 도구로 생각하세요.
우리 팀의 목록은 아래 우리 팀 합의에 적어 두세요.
| 오해 | 실제 |
|---|---|
| "애자일은 계획도 문서도 없다는 뜻이다." | 더 작은 단위로 끊임없이 계획하고, 쓸모 있는 문서만 씁니다. |
| "스크럼 마스터는 팀의 상사다." | 코치이자 섬기는 리더입니다. 일을 배정하지 않습니다. |
| "데일리 스크럼은 경영진에게 하는 보고다." | 팀 자신을 위한 계획 회의입니다. |
| "급하면 스프린트 도중에 일을 추가해도 된다." | 스프린트 골은 보호됩니다. 급한 일은 프로덕트 오너와 상의하고, 보통 다음 스프린트를 기다리거나 다른 것을 빼야 합니다. |
| "벨로시티는 성과 점수다." | 예측용 도구일 뿐입니다. 팀끼리 비교하거나 수치를 올리려 하면 추정만 부풀려집니다. |
| "회의가 많아지면 일은 줄어든다." | 세리머니는 스프린트에서 작은 비중이며, 수많은 비정기 회의를 대신합니다. |
| 용어 | 의미 |
|---|---|
| 스프린트 (Sprint) | 작동하는 결과물로 끝나는, 길이가 고정된 작업 주기. |
| 프로덕트 백로그 (Product Backlog) | 만들 수 있는 모든 것을 우선순위대로 정리한 목록. |
| 스프린트 백로그 (Sprint Backlog) | 현재 스프린트를 위해 고른 항목과 그것을 하기 위한 계획. |
| 인크리먼트 (Increment) | 스프린트 동안 만들어진, 쓸 수 있는 완성된 결과. |
| 유저 스토리 (User story) | 사용자 관점에서 필요를 짧게 적은 글: "여행자로서 결과를 필터링하고 싶다. 그래야 필요한 것을 더 빨리 찾을 수 있다." |
| 스토리 포인트 (Story points) | 시간 대신 쓰는 상대적인 크기 추정(작음, 보통, 큼). 스프린트에 얼마나 들어가는지 가늠하는 데 씁니다. |
| 벨로시티 (Velocity) | 팀이 스프린트마다 보통 끝내는 일의 양. 예측용이며 사람을 평가하는 데 쓰지 않습니다. |
| 준비의 정의 (Definition of Ready) | 카드가 스프린트로 가져갈 만큼 명확한지 판단하는 공동 체크리스트. 선택 사항이며 스크럼 가이드에는 없습니다. |
| 완료의 정의 (Definition of Done) | 일이 정말 끝났는지 판단하는 공동 체크리스트. |
| 스프린트 골 (Sprint Goal) | 스프린트의 이유를 한 문장으로 쓴 것. |
| 타임박스 (Time-box) | 활동의 최대 시간. 시간이 다 되면 멈춥니다. |
| WIP | Work In Progress, 시작했지만 끝나지 않은 일. |
| 장애물 (Blocker) | 카드가 앞으로 나아가지 못하게 막는 모든 것. |
| 이해관계자 (Stakeholder) | 우리가 만드는 것에 영향을 받거나 관심이 있는 모든 사람. |
| 세리머니 / 이벤트 | 정기적으로 열리는 스크럼 회의 중 하나. |
스크럼은 프레임워크라서 세부 사항은 팀마다 채웁니다. 킥오프나 첫 회고에서 함께 정해 봅시다.
| 항목 | 우리의 결정 |
|---|---|
| 스프린트 길이 | 예: 2주 |
| 스프린트 시작/종료 요일 | 예: 월요일 시작, 둘째 금요일 종료 |
| 데일리 스크럼 시간과 장소 | 예: 10:00 보드 앞 / 화상 회의 |
| 스프린트 플래닝 | 요일과 시간 |
| 리파인먼트 | 요일과 시간 |
| 리뷰와 회고 | 요일과 시간 |
| 보드 열 | 예: 할 일, 진행 중, 리뷰 중, 완료 |
| WIP 한도 | 예: 진행 중 = 팀원 수, 리뷰 중 = 2 |
| 준비의 정의 | 예: 사용자 필요가 적혀 있고, 인수 기준에 합의했고, 한 스프린트에 들어갈 만큼 작다 |
| 완료의 정의 | 예: 코딩, 동료 리뷰, 테스트, 배포 완료 |
| 보드 위치 | Jira 보드 링크 |
기억하세요: 스크럼은 설명하기는 쉽고 능숙해지기는 어렵습니다. 그래도 괜찮습니다. 첫 스프린트는 어설프게 느껴질 것입니다. 회고는 바로 그래서, 매번 더 나아지기 위해 있습니다.