스크럼: 책임·이벤트·산출물

스크럼이란

스크럼(Scrum)은 복잡한 문제를 풀면서 가치를 만들기 위한 가벼운 프레임워크다. 애자일이라는 가치 체계를 실천하는 가장 흔한 방법이지만, 애자일과 같은 말은 아니다. 애자일 전반과 다른 방법론과의 비교는 애자일과 스프린트에 있다.

스크럼은 경험주의(empiricism)에 기댄다. 미리 다 계획하지 않고, 해 보고 관찰한 것을 바탕으로 결정한다.

기둥	뜻
투명성(Transparency)	일과 진행 상황이 하는 사람과 받는 사람 모두에게 보인다
검토(Inspection)	산출물과 목표를 향한 진척을 자주 들여다본다
적응(Adaptation)	어긋난 것을 발견하면 바로 조정한다

다섯 가지 가치(확약 · 집중 · 개방 · 존중 · 용기)는 이 세 기둥이 실제로 작동하게 하는 팀의 태도다.

세 가지 책임

2020년판부터 스크럼은 "역할" 대신 책임(accountability)이라는 말을 쓰고, 개발팀이라는 하위 팀 없이 한 스크럼 팀 안에 세 책임을 둔다. 팀은 보통 10명 이하이고 위계가 없다.

책임	무엇을 책임지나	흔한 오해
제품 책임자(Product Owner)	제품 가치를 최대화한다. 제품 목표를 세우고, 제품 백로그 항목을 만들고 순서를 정하고, 백로그가 투명하게 이해되게 한다	위원회가 아니라 한 사람이다. 다른 사람에게 일을 맡길 수는 있어도 책임은 PO에게 남는다
스크럼 마스터(Scrum Master)	스크럼 팀의 효과성을 책임진다. 팀과 조직이 스크럼을 이해하게 코칭하고, 진척을 막는 장애물을 없앤다	회의 진행자나 일정 관리자가 아니다. 이벤트가 열리고 목적대로 끝나게 할 뿐, 모든 이벤트를 직접 주도할 필요는 없다
개발자(Developers)	매 스프린트 쓸 수 있는 증분을 만든다. 스프린트 백로그를 만들고 완료의 정의를 지킨다	코드를 쓰는 사람만 뜻하지 않는다. 디자이너·QA 등 증분을 만드는 모두가 개발자다

비슷한 직함과의 차이

직함	초점	스크럼 책임과의 관계
프로덕트 매니저	제품 전략, 시장 적합성, "왜·무엇"	스크럼 바깥의 직무명이다. 작은 조직에서는 PO를 겸하고, 큰 조직에서는 PM이 방향을 정하고 PO가 백로그로 실행을 이끈다
프로젝트 매니저	일정·범위·예산, 작업 배정	스크럼에는 대응하는 책임이 없다. 작업 배정은 개발자가 스스로 하고, 장애물 제거는 스크럼 마스터가 돕는다

다섯 가지 이벤트

모든 이벤트에는 시간 제한(timebox)이 있다. 아래 수치는 한 달짜리 스프린트의 최대치이고, 스프린트가 짧으면 대개 비례해서 줄인다.

이벤트	언제	최대 시간	목적과 결과
스프린트(Sprint)	끝나자마자 다음이 시작	1개월 이하 고정 길이	나머지 이벤트를 담는 그릇. 이 안에서 아이디어가 가치로 바뀐다
스프린트 계획(Sprint Planning)	스프린트 시작	8시간	세 질문에 답한다: 왜 가치 있나(스프린트 목표), 무엇을 하나(고른 백로그 항목), 어떻게 하나(실행 계획). 결과가 스프린트 백로그다
데일리 스크럼(Daily Scrum)	매일 같은 시간·장소	15분	개발자가 스프린트 목표를 향한 진척을 점검하고 다음 하루 계획을 고친다. 상세 논의는 끝난 뒤 따로 한다
스프린트 리뷰(Sprint Review)	스프린트 끝	4시간	이해관계자에게 결과를 보여 주고 다음에 할 일을 함께 조정한다. 발표회가 아니라 작업 세션이다
스프린트 회고(Sprint Retrospective)	스프린트 마지막	3시간	사람·상호작용·프로세스·도구·완료의 정의를 돌아보고, 가장 도움이 될 개선을 고른다

2주 스프린트라면 계획 2~4시간, 리뷰 2시간, 회고 1.5시간 안팎이 흔한 어림셈이다. 같은 이벤트를 매 스프린트 같은 요일·시간에 잡으면 리듬이 생긴다.
리뷰는 결과물(무엇을 만들었나), 회고는 일하는 방식(어떻게 일했나)을 본다. 둘을 섞으면 회고가 결과 평가로 변해 방어적이 된다.
2020년판은 데일리 스크럼의 "어제 한 일·오늘 할 일·장애물" 세 질문을 필수에서 뺐다. 형식은 개발자가 정하고, 목표를 향한 진척만 다루면 된다.
스프린트는 PO만 취소할 수 있고, 스프린트 목표가 쓸모없어졌을 때만 취소한다.

백로그 정제(Product Backlog Refinement)는 공식 이벤트가 아니라 계속 이어지는 활동이다. 큰 항목을 작게 쪼개고, 설명·순서·크기를 덧붙여 다음 스프린트에 바로 고를 수 있는 상태로 만든다. 크기 추정은 실제로 일할 개발자가 한다. 많은 팀이 스프린트 중간에 한두 번 시간을 따로 잡는다. 쪼개는 법과 추정은 백로그와 추정에서 다룬다.

세 가지 산출물과 약속

산출물(artifact)마다 진척을 재는 기준이 되는 약속(commitment)이 하나씩 붙는다.

산출물	누가 관리	약속	약속의 뜻
제품 백로그(Product Backlog)	PO	제품 목표(Product Goal)	제품이 도달할 미래 상태. 팀의 장기 목표이며, 하나를 이루거나 버려야 다음 목표로 넘어간다
스프린트 백로그(Sprint Backlog)	개발자	스프린트 목표(Sprint Goal)	이번 스프린트의 유일한 목표. 범위가 바뀌어도 목표가 팀을 묶어 준다
증분(Increment)	개발자	완료의 정의(Definition of Done)	증분이 품질 기준을 충족했다고 말할 수 있는 공식 기준. 충족하지 못한 항목은 리뷰에 올리지 않고 백로그로 돌아간다

제품 백로그에는 기능만이 아니라 버그 수정, 기술 부채 상환, 조사가 필요한 일(스파이크·프로토타입)도 들어간다. 위에 있을수록 더 명확하고 작다.
스프린트 백로그는 스프린트 중에도 고친다. 개발자가 더 알게 되면 일의 쪼갬과 범위를 PO와 다시 협의한다. 바뀌지 않아야 하는 것은 스프린트 목표와, 목표를 위태롭게 하는 변경을 하지 않는다는 원칙이다.
증분은 스프린트 끝에 한 번만 나오는 것이 아니다. 완료의 정의를 충족하면 스프린트 중에도 여러 번 배포할 수 있다.
완료의 정의(DoD)는 팀 전체의 품질 기준이고, 인수 기준(acceptance criteria)은 항목 하나가 끝났는지를 보는 기준이다. 둘 다 충족해야 끝이다.

흔한 변질과 처방

증상	원인	처방
데일리 스크럼이 관리자에게 하는 상태 보고가 된다	목적이 진척 점검이 아니라 감시가 됨	개발자끼리 스프린트 목표 기준으로 이야기한다. 함께 일하지 않는 사람이 섞이면 작업 단위로 나눈다
데일리 스크럼이 15분을 넘긴다	문제 해결을 그 자리에서 함	장애물은 이름만 올리고, 해결은 끝난 뒤 관련자만 남아서 한다
회고가 끝나도 아무것도 바뀌지 않는다	실행 항목이 없거나 주인이 없음	동사로 시작하는 실행 항목에 담당자와 기한을 붙이고, 다음 회고 첫머리에 확인한다
회고에서 아무도 말하지 않는다	심리적 안전감 부족	질문을 미리 공유하고, 의견에 감사를 표하고, 비난 없이 일의 구조를 다룬다
스프린트 중 새 요청이 계속 끼어든다	스프린트 목표가 없음	새 요청은 제품 백로그로 보내 다음 계획에서 고려한다. 목표 자체가 무의미해지면 PO가 스프린트를 취소한다

회의 일반의 설계(결과물 정의, 그라운드 룰, 마감)는 회의 잘하는 법에, 스프린트가 마감 도구로 변질되는 문제는 애자일과 스프린트에 있다.

정리

스크럼은 세 책임 · 다섯 이벤트 · 세 산출물로 이뤄진 가벼운 틀이고, 나머지 실천법(스토리 포인트, 번다운, 칸반 보드)은 팀이 골라 붙이는 것이다.
PO는 무엇을 왜, 개발자는 어떻게, 스크럼 마스터는 이 틀이 잘 돌아가는지를 책임진다.
모든 이벤트는 시간 제한이 있고, 리뷰는 결과물, 회고는 일하는 방식을 본다.
산출물마다 약속이 있다: 제품 목표, 스프린트 목표, 완료의 정의.
스프린트 백로그는 고정된 계약이 아니라 개발자의 살아 있는 계획이다. 지키는 것은 목표다.

버그 제보