## 들어가는 글

스크럼은 방법론이 아닌 프레임워크이며 정확히 무엇을 해야 하는지 알려주지 않는다.

이 책(스크럼과 XP)은 스크럼을 저자가 어떻게 적용했는지 상세하게 설명하는 것이 장점이고, 저자가 적용한 스크럼만 언급하기 때문에 단점이라고 볼 수 있음을 미리 말한다. 따라서 저자와 다른 상황에 있다면 다른 방식으로 스크럼을 진행해야하며, 스크럼의 장점이자 단점은 **처한 상황에 맞게 융통성을 발휘**해야 한다고 한다.

> 즉, 이 책에선 스크럼을 실행하는 정도(正道)를 주장하려는 것이 아님

그럼에도 책을 쓴 이유는 실전 경험에서 얻은 소중한 정보를 풀어서 다른사람에게 유용한 피드백을 주기 위함이라고 함.

## 제품 백로그 만들기

제품 백로그는 **기본적으로 우선순위가 매겨진 요구사항의 목록으로 스크럼의 핵심**이다. 요구사항 대신 스토리나 기능 혹은 다른 어떤 이름이라도 상관 없고, 이것들을 스토리 또는 백로그 아이템이라고 부른다.

스토리에는 아래와 같은 항목이 포함된다.

- ID: 자동으로 매겨지는 고유 식별자(이름이 변경되어도 스토리 추적을 위함)
- 이름: 스토리를 설명하는 짧은 이름(ex: 개인 트랜잭션 이력 보기)
- 중요도: 제품 책임자가 생각하는 스토리의 중요도(점수)
- 최소 추정치: 다른 스토리와 비교하여 스토리를 구현하는 데 상대적으로 얼마나 많은 노력이 필요한지에 대한 팀의 최초 추정치. 단위는 스토리 점수이고 이상적인 맨데이에 해당
- 데모 방법: 스프린트 데모에서 이 스토리를 어떤 형태로 데모할 것인지에 대한 상위 수준 묘사
- 참고: 그 밖의 다른 정보나 설명, 참고사항 등


위와 같은 문서를 제품 책임자가 관리하면서 다른 사람들이 편집할 수 있게 공유 폴더에 넣어둔다. 개발자가 문서를 열어 어떤 사항을 구체화하거나 추정치를 변경하기도 함.

**추가 스토리 항목**

- 트랙: 대강의 스토리 분류로 '백 오피스'나 '최적화' 같은 것을 의미
- 컴포넌트: 보통 엑셀 문서의 '체크박스'로 표현되며 데이터베이스, 서버, 클라이언트 같은 것을 의미 → 해당 스토리 구현 시 어떤 팀이 어떤 스토리를 가져갈지 결정할 때 유용하게 사용
- 요청자: 해당 아이템을 처음으로 요청한 사람을 기억해두고 진척 상황을 알리고 싶어하는 경우 사용
- 버그추적: 스토리ㅗ아 관련 버그들 사이의 추적성 부여를 위해 사용

**제품 백로그를 비즈니스 수준으로 유지하기**

제품 책임자는 비즈니스 목표에만 집중해야한다. 문제를 해결하는 방법은 팀이 더 잘 알기 때문이다. 기술적인 관점에서 작성된 스토리는 그 밑바탕에 깔려있는 본래의 목적이 드러나도록 스토리를 다시 쓴다.

예를들어, 이벤트 테이블에 인덱스 추가하기라는 스토리는 기술적인 관점이 들어가있으며 이 '인덱스 추가하기' 라는 진짜 목적(ex: 백오피스 이벤트 검색 폼 속도 개선)이 드러난 스토리를 적어야한다.

## 스프린트 계획회의 준비하기

스프린트 계획회의 이전에 제품 백로그를 깔끔하게 정리해 두어야한다는 교훈을 얻는다. 이것이 의미하는 바는 아래와 같다.

- 제품 백로그는 반드시 존재해야 함.
- 제품당 **제품 백로그가 하나, 제품 책임자가 한명**이어야 함.
- 중요한 아이템에 중요도를 부여할 때, 모두 **서로 다른** 값을 부여
- 다음 스프린트에 포함될 가능성이 희박한 모든 스토리에는 특별한 중요도 값을 동일하게 부여
- 중요도 값은 아잍메을 정렬하는 용도로만 사용
- 중요도 사이에 간격을 둠
- 제품 책임자는 각 스토리를 **이해하고 있어야** 함

> 중요도는 제품 책임자가, 개발 시간 추정은 팀이 한다.

저자의 팀이 시도했던 방법

- 제품 백로그 용으로 Jira를 사용했는데 너무 많은 클릭을 필요로 해 MS 엑셀 사용
- VersionOne, ScrumWorks, XPlanner 같은 애자일 프로세스 지원 도구 사용

## 스프린트 계획 수립하기

스프린트는 스크럼에서 가장 중요한 이벤트이다. 이것이 잘못되면 스프린트 전체를 망칠 수 있기 때문이다. 스프린트 계획회의는 팀에게 충분한 정보를 주고, 팀원들이 그렇게 할 수 있도록 제품 책임자에게 충분한 신뢰를 주는 데 있다.

스프린트 계획회의에서는 아래와 같은 **구체적인 산출물**이 나와야한다

- 하나의 스프린트 목표
- 팀원의 목록
- 스프린트 백로그
- 확정된 스프린트 데모 날짜
- 확정된 일일 스크럼을 위한 시간과 장소

### 제품 책임자가 회의에 참석해야하는 이유

모든 스토리가 서로 깊이 연관된 3개의 변수(범위, 중요도, 추정치)를 갖고 있기 때문이다. 범위와 중요도는 제품 책임자에 의해 결정되고 추정치는 팀에 의해 결정된다. 이 변수들은 계속적으로 세밀하게 대화를 통해 조정된다.

대화를 통해 스토리를 검토하고 추정하며 범위를 확인하고 다시 추정하는 직접적인 협력은 스크럼의 핵심 요소이며 모든 애자일 소프트웨어 개발의 핵심 요소이다.

### 왜 품질은 협상의 대상이 아닌가?

품질은 내적 품질과 외적 품질로 구분할 수 있다.

- 외적 품질: 시스템을 사용하는 사람들이 인식하는 품질
- 외적 품질은 범위의 한 부분이라고 볼 수 있다. 좋지않은 UI더라도 먼저 출시한 후 추후 깔끔한 버전을 출시하는 것이 비즈니스 관점에서 전혀 문제가 없는 결정일 수 있기 때문이다.
- 내적 품질: 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는것을 지칭(설계 일관성, 테스트 커버리지, 코드의 가독성, 리팩터링 등)
- 논의의 대상이 될 수 없다. 팀은 내적 품질을 유지하는 것에 책임을 져야한다.

내적품질을 희생하는 것은 나중에 품질을 되돌려 놓기 어렵게 한다. 따라서 이를 희생하려는 논의가 생기면 범위 쪽으로 논의를 전개하여 내적 품질은 협상의 대상이 아니라는 점을 강조해야함.

### 질질 늘어지는 스프린트 계획회의

스프린트 계획회의에서 가장 어려운 부분은 **오래 걸린다**는 것이다. 그래서 **타임박스**를 가지고 이 시간에 끝나지 않으면 무자비하게 끝낸다 이렇게 끝내면 스프린트가 고전하게 될 수 있지만, 팀은 교훈을 얻고, 다음번 스프린트 계획은 훨씬 더 효율적으로 진행될 것이다.

> 타임박스의 길이를 현실적으로 정하는 방법을 익히고 그 타임박스를 고수해야 함

**스프린트 계획회의 시간표**

스프린트 계획회의의 시간표를 사전에 짜두면 타임박스를 지키지 못하는 리스크를 줄일 수 있다.

시간표 예시(4시간, 1시간마다 10분 휴식)

- 제품 책임자가 스프린트 목표 검토 제품 백로그 요약(30분)
- 팀이 시간 추정, 필요에 따라 항목 세분화. 제품 책임자가 중요도 업데이트(1시간 30분)
- 팀이 스프린트에 포함시킬 스토리 선정(1시간)
- 일일 스크럼 회의의 시간과 장소 정함(1시간)

이를 철저하게 지켜야 하는것은 아님

### 스프린트 길이 결정하기

적절한 스프린트 길이란 얼마일까? 짧은 스프린트는 회사를 기민하게, 긴 스프린트는 팀의 추진력을 얻는데 충분한 시간과 목표 달성을 위한 충분한 여력을 갖게 해준다.

제품 책임자는 짧은 스프린트를 선호하고, 개발자는 긴 스프린트를 선호함. 저자는 약 3주가 적절한 길이라고 생각. 적절한 스프린트 길이를 위해 분석에 힘쓰기보다 직접 실험을 해보고 일정 기간은 이를 고수해보는 것을 추천한다.

### 스프린트 목표 결정하기

스프린트 목표를 세우기란 어렵다. **중요한 것은 목표를 비즈니스적인 말로 나타내야 한다**는 것이다. 또한 아직까지 달성하지 못한 것이어야 한다.

이러한 스프린트 목표는 스프린트 중반에 사람들이 무엇을 해야 하는지 혼란스러워하기 시작하는 순간에 진가를 드러낸다. 목표를 잘 보이는 곳에 게시해두자.

### 스프린트에 구현할 스토리 고르기

스프린트 동안 어떤 스토리를 포함시킬지 결정해야한다. 제품 백로그 → 스프린트 백로그를 결정하는 일이다.


네모 상자의 크기는 스토리 점수로 표현되는 시간 추정치이며 괄호 친 부분의 길이는 팀의 추정속도(다음 스프린트에서 완료할 수 있을 것으로 생각되는 스토리 점수) 이다.

얼마나 많은 스토리를 포함할지는 팀이 결정한다. 이 과정에서 아래와 같은 의문점이 생길 것 이다.

- 제품 책임자가 팀의 결정에 영향을 미치려면 어떻게 해야하는가?
- 중요도에 따른 순서를 재조정 한다.
- 범위를 변경한다.(스토리 하나의 범위 조정)
- 스토리를 둘로 나눈다.
- 팀은 스프린트에 포함시킬 스토리를 어떻게 결정하는가?
- 직감
- 속도 계산

속도 계산은 두 단계로 진행된다.

1. 추정 속도 정하기
2. 추정 속도 내에서 스토리를 얼마나 추가할 수 있는지 계산

속도는 '왼료한 작업의 양'에 대한 측정 값이다. 아래 그림은 스프린트를 시작할 때의 추정 속도와 그 스프린트가 끝날 때의 실제 속도의 예이다.


실제 속도는 각 스토리의 초기 추정치를 기준으로 계산되었다. 스프린트 중에 거의 완료한 스토리는 포함하지 않는데, 이는 **스크럼이 완전히 출시 가능한 형태로 완료한 것만 인정한다는 사실을 강조**한다

속도를 추정하는 방법으로 팀의 이력을 보는 것이다. **어제의 날씨**라고 알려진 방법을 활용해 지난 몇 번의 팀의 속도가 얼마였는지 측정한다.

추정한 단위가 스토리 점수, 이상적인 맨-데이에 해당하는 값이기 때문에 집중도라는 값도 활용한다.

스프린트의 추정속도 = 가능한 맨-데이 x 집중도

집중도는 팀이 얼마나 집중할 수 있는지 추정한 값이다. 이를 통해 이번 스프린트의 추정 속도는 아래의 식으로 구할 수 있다.

> 저자의 기본 집중도는 70% 정도로 설정한다고 한다.

집중도 x 가능한 맨-데이 = 스토리 점수

> 어제의 날씨는 상식에 맞게 사용해야한다. ex) 새로운 멤버가 스프린트에 합류하는 경우 교육을 위해 집중도를 낮춤.

### 우리가 인덱스 카드를 사용하는 이유

스프린트 계획회의의 대부분은 제품 백로그에 있는 스토리를 가지고 진행한다. 이를 키보드를 가진 사람이 엑셀에서 조정하며 사람들이 화면을 보며 진행하는 것보다, **인덱스 카드를 만들어 벽에 붙이는 것**이 좋다.

그 이유는 아래와 같다.

- 사람들이 서서 걸어 다녀 졸지 않고 주의를 기울임.
- 개개인 모두 더 적극적으로 참여하고 있다고 느낌.
- 여러 스토리 동시 수정 가능.
- 인덱스 카드를 옮겨 우선순위 조정 가능.
- 회의 끝나면 인덱스 카드를 가져다가 작업 현황판에 사용 가능

이러한 인덱스 카드에 작업한 내용을 스크럼 마스터가 엑셀로 되어있는 제품 백로그에 반영한다. 처음 엑셀로 정한 중요도보다 벽에 붙어 있는 실제 정렬 순서가 중요도를 나타내며 이를 액셀에 다시 갱신해야한다.

시간 추정은 스토리를 작업단위로 나누면 더 쉬워지는데 스토리 아래에 작은 포스트잇을 붙이는 식으로 이뤄진다. 하지만 작업 나누기는 엑셀에 반영하지 않는데 작업 나누기는 **일시적인 경향**이 강하며, 제품 책임자가 **세부적인 사항에까지 관여할 필요가 없기** 때문이다.

### 완료의 정의

'출시할 준비가 되었음'을 완료 정의로 사용하지만 '테스트 서버에 배치되고, 인수 테스트에 넣을 준비가 되었음'으로 정의해야 할 때도 있다. 하지만 실제로 모든 스토리를 동일하게 취급할 수 없으며 가끔 상식이 형식적인 체크리스트보다 더 낫다.

### 플래닝 포커를 사용하여 시간 추정하기

추정은 팀 활동이며 팀원 전원이 참여한다.

- 계획 단계에서 누가 어떤 스토리의 어느 부분을 구현할지 알 수 없음.
- 스토리 구현을 위해 다양한 분야의 전문가가 필요.
- 추정치를 제시하기 위해 팀원이 스토리가 어떤 것인지 어느 정도 이해할 필요 있음.
- 완전히 다른 추정치를 내놓은 두 팀원의 견해차를 발견하고 토론할 수 있음.

플래닝 포커는 각 팀원이 자신이 생각하는 시간 추정치를 의미하는 카드를 선택해 다른사람의 추정치에 흔들리지 않고 자신의 생각대로 할 수 있게 한다. 추정시에 중요한 점은 해당 스토리에 포함된 전체 일의 양을 추정해야 한다는 것인데, '자기' 부분만 추정하지 않는다는 이야기다.

### 스토리 명확하게 하기

제품 책임자가 데모 이후에 자신이 생각한 제품과 다르다고 생각이 들면 최악의 상황이다. 하나의 스토리에 대해 제품 책임자와 팀간 발생하는 명백한 오해를 확인하는 몇 가지 방법이 있다. 가장 간단한 방법은 각 스토리의 필드를 모두 채웠는지 확인하는 것이다.

예시

- '사용자 추가'라는 스토리의 추정치가 없는 경우
- 팀은 추가/삭제/검색이 가능한 웹이라 생각해서 스토리 점수 20점을 추정
- 제품 책임자는 단지 SQL을 사용해 수작업으로 DB에 사용자 추가를 의미
- 다시 추정해 5점으로 결정

> 간단히 기술하는 것만으로도 스토리의 범위에 대한 중대한 오해가 풀릴 수 있다.

### 스토리를 작은 스토리로 분해하기

스토리가 너무 작거나 크면 안된다. 크다면 작은 스토리로 쪼개고, 작다면 그 스토리들이 비즈니스 가치를 제공할 수 있는 출시 가능한 단위인지 확인하라.

> 저자의 팀은 전형적인 팀의 속도이 40~60이고 하나의 스프린트는 평균적으로 10개 정도의 스토리를 갖게된다고 한다. 가끔은 5개가 되고 15개가 될때도 있다고 한다.

### 스토리를 작업 단위로 나누기

스토리: 제품 책임자가 관심을 갖는 전달 가능한 것
작업: 전달할 수 없는 것이나 제품 책임자가 관심을 갖지 않은 것


이런 과정에서 흥미로운 점이 있다.

- 이처럼 사전에 스토리를 작업으로 나누느라 시간을 보내는 것을 내켜하지 않는다.
- 스토리를 명확하게 이해하고 있다면 사전에 작업 단위로 나누는게 용이하다.
- 이렇게 하다보면 추가적으로 해야할 일이 생겨 시간 추정치가 늘어나는 경우가 종종 발생한다. 그래서 더 **실제에 가까운 스프린트 계획**인 된다.
- 사전에 작업 나누기를 하는 방식은 일일 스크럼 회의를 더 효과적으로 진행할 수 있게 한다.

> 저자는 이 과정을 포함시킬 만큼 스프린트 계획회의의 타임 박스를 길게 잡는다고 한다. 시간이 모자라다면 이 과정을 누락시킨다.

### 일일 스크럼의 시간과 장소 결정하기

일일 스크럼은 모든 사람들이 일의 시작을 선언하는 킥오프다.

오후 스크럼의 단점: 오늘 할 일이 무엇인지 어제 이야기한 내용이 무엇인지 기억해야함.
아침 스크럼의 단점: 어제 일한 내용이 무엇인지 기억해야 함.

저자는 첫 번째 단점이 더 나쁘다고 생각하는데 가장 중요한 것은 이제 무엇을 할 것인가이지 무엇을 했느냐가 아니기 때문이다.

### 어디에 선을 그을까

시간이 모자란 경우 쳐내야할 저자가 생각하는 우선순위는 아래와 같다.

- 우선순위 1: 스프린트 목적과 데모 날짜
- 우선순위 2: 이번 스프린트에 포함하기로 인정한 스토리 목록
- 우선순위 3: 스토리에 대한 추정치
- 우선순위 4: 각 스토리에 대한 데모 방법
- 우선순위 5: 스프린트 계획의 현실성 검증을 위한 속도 및 자원 계산
- 우선순위 6: 일일 스크럼의 시간과 장소 결정
- 우선순위 7: 스토리를 작업으로 나누기

### 기술 스토리

기술 스토리라는 복잡한 문제가 있다. 이는 다른 특정 스토리에 직접적으로 관련되지 않으면서도, 완료해야 하는 일이다.

아래와 같은 것들이 기술 스토리가 될 수 있다.

- 지속 빌드 서버 구축(개발자들의 시간 절약)
- 시스템 설계 개요 작성(전체적인 설계, 일관된 코드를 위한 것)
- DAO 레이어 리팩터링(DAO 레이어를 위한 것)
- Jira 업그레이드(현재 버전이 버그가 많고 느리다면 업그레이드를 해야함)

저자는 기술스토리를 다루기 위해 아래와 같은 방법을 취한다.

1. 기술 스토리를 피하고 비즈니스 가치가 드러나는 일반적인 스토리를 바꿀 수 있는 방법을 찾으려고 한다.
2. 일반 스토리로 바꿀 수 없다면 다른 스토리의 하위 작업으로 처리할 수 있는지 확인한다.
3. 기술 스토리를 정의하고 기술 스토리들만 모아 별도의 목록으로 관리한다. 이를 구현할 시간을 확보하는데 '집중도'와 '추정 속도'를 이용한다.

제품 책임자에게 기술 스토리의 이점을 집중도와 추정속도를 활용해 제공하고, 전체적인 우선순위를 결정하도록 제안한다.

### 버그 추적 시스템과 제품 백로그

저자의 경우 버그 추적시스템은 엑셀로 어렵고, Jira를 활용한다고 한다. 하지만 이 방법은 팀마다 또 모든 스프린트마다 답이 달라질 것이다. 가장 추천하는 방법은 제품 책임자가 우선순위가 높은 Jira 항목을 프린트해서 스프린트 계획회의에 가져오는 것이다.

## 스프린트를 알리는 방법

'스프린트 정보 페이지'를 이용해 어떤 팀이 어떤 일을 하는지 보여줄 수 있다.

스프린트 정보 페이지 예시



스프린트 계획회의 이후, 스크럼 마스터가 이와 같은 페이지를 만들어서 위키에 올린다. 위키에는 '현황판' 페이지를 만들어 현재 진행중인 모든 스프린트의 링크를 넣는다.

이런 스프린트 정보 페이지를 팀방의 바깥 볕에 붙여놓으면 팀이 무슨 일을 하고 있는지 알 수 있다. 또한 스프린트가 끝날 때쯤 스크럼 마스터가 데모에 대해 상기 시키는 메일을 전원에게 보내 회사에서 벌어지고 있는 일을 알릴 수 있다.

> 이를 통해 사람들이 **불만을 갖거나 현재 상황에 대한 억측을 방지**할 수 있고, **현재 벌어지고 있는 일들을 항상 알고 있게** 만들 수 있다.

## 스프린트 백로그 만들기

스프린트 백로그는 스크럼 마스터가 스프린트 계획회의 후, 첫 번째 일일 스크럼 전에 만들어야 한다. 이 백로그를 만들 때 Jira, Excel등 다양한 방법이 있지만 아래 그림처럼 **벽을 이용한 작업 현황판**을 가장 추천한다.


**작업 현황판의 원리**

- 할 일: 오늘 아무도 하지 않는 작업
- 진행 중: 오늘 누군가 하고 있는 작업
- 가끔 큰 팀의 경우 이 작업을 누가하고 있는지 기억 못해 이름을 적어놓는 등의 정책을 도입하기도 함
- 완료!: 아무도 더 이상 하지 않을 작업
- 소멸차트: 일일 스크럼을 마친 뒤 바로 점을 찍을 공간
- 가로는 날짜, 세로는 남은 작업량 추정(스토리 점수)을 의미한다.
- 추세선을 보고 잘 진행되고 있는지 알 수 있어야 한다.
- 계획에 없던 항목: 미처 계획하지 못한 항목
- '스프린트 회고'를 할 때 이것들을 기억해내는 데 유용하다.
- 다음: 스프린트가 끝나기 전에 백로그 항목을 모두 완료하면 새 항목을 가져갈 곳

**날짜로 추정하기와 시간으로 추정하기**

시간으로 추정하는 것(맨-아워)은 너무 잘게 나눠져 있어 지나치게 세부적인 내용까지 관리하는 **미시적인 관리**로 치우치는 경향이 있다. 그래서 작업량을 추정하는 기준으로 맨-데이를 사용한다고 한다.

## 팀방 꾸미기

설계 토의가 주로 작업 현황판 앞에서 즉흥적으로 이루어지는데, 이러한 공간을 '설계 구역'이라 한다.


> '설계 벽면'은 가장 중요한 설계 스케치와 설계 문서(순서도, GUI 프로토타입, 도메인 모델)를 포함한다.

**팀을 한자리에 모아라**

저자는 효과적인 스크럼 팀을 구축하기 위해선 팀을 한자리에 모으는 것이 필수적이라고 한다.

'한자리'가 의미하는 바는 다음과 같다.

- 가청성: 자기 자리를 벗어나거나 소리치는 일 없이도 다른 사람과 이야기할 수 있다.
- 가시성: 팀의 모든 멤버는 다른 멤버들을 모두 볼 수 있다.
- 단절성: 갑작스러운 토의 진행 시, 방해 받을 정도로 가까운 곳에 팀 외부 인원이 있으면 안된다.

분산으로 인해 팀을 한자리에 모을 수 없다면 이 피해를 최소로 줄일 수 있는 기술적 보조 도구(화상 회의, 웹캠, 바탕화면 공유 도구 등)들을 사용하자.

**제품 책임자 떨어뜨려 놓기**

제품 책임자는 팀 가까이서 작업 현황판을 둘러볼 수 있어야 하지만 팀과 같은 자리에 있어서는 안된다. 팀에 깊게 관여하게 되면 팀이 자율적인 관리가 이뤄지지 못하고 생산성이 높은 상태로 갈 수 없기 때문이다.

> 저자의 경험적인 추측이라고 함.

**관리자와 코치 떨어뜨려 놓기**

관리자가 팀에 가까운 곳에 있다면 자율적 관리는 자동적으로 거리가 멀어진다. 스크럼 코치도 마찬가지이다. 스크럼 코치라면 가능한 긴밀하게 참여하면서도 **한정된 기간 동안만** 그렇게 하라.

개선할 부분을 발견하게 된다면 스크럼 마스터를 따로 불러 코치하라. 잘 운영되는 스크럼 팀이라면 그들이 필요한 것들은 모두 스스로 구할 것이라고 믿어라.

## 일일 스크럼 진행하기

일일 스크럼을 팀방, 작업 현황판 바로 앞에서 규칙대로 진행한다. 또한 회의 시간이 15분을 넘는 일이 생기지 않도록 서서한다.

**작업 현황판 업데이트하기**

일일 스크럼 중에 계획을 잡지 못한 일이 있다면 새 포스트잇에 적어 현황판에 붙이고, 기존 추정치에 줄을 그어 새로운 시간 추정치를 적는 등 작업 현황판을 업데이트한다.

> 물론 일일 스크럼 회의가 끝나면 시간 추정치를 모두 합해 스프린트 소멸 차트에 새 점을 그려야한다.

중요한 것은 스프린트 백로그를 최신으로 유지하는 일에는 팀 전체가 참여하도록 해야 한다. 이렇지 않고 스크럼 마스터가 혼자 관리하게 되면 아래와 같은 단점이 생긴다.

- 팀을 지원하고 방해물을 제거하는 대신 관리적인 일에 너무 많은 시간을 빼앗긴다.
- 스프린트 백로그에 팀원들이 관심을 기울일 필요가 없어져 진행상황을 알지 못하게 된다. 따라서 피드백이 부족해지면 팀의 전체적인 기민함이나 집중력이 저하된다.

**지각자 다루기**

1분이라도 지각하면 정해둔 금액만큼 통에 넣어서 이를 친목에 다지는 행사에 사용한다.

**'오늘 할 일을 모르겠어요' 문제 다루기**

작업 현황판의 내용이 실제와 일치하는지, 각 항목들의 의미는 모두 이해하고 있는지 등을 체크한다. 그 이후 다시 물어본다. 그래도 아니라고 하면 **짝 프로그래밍 기회**가 있는지 고려해 본다.

팀이 스프린트 목표를 달성하지 못했음에도 할일을 찾고 있지 못하면?

- 구식 방법: 작업 할당
- 수치심 자극: 집 가거나 그냥 앉아 있게 하기
- 동료 집단의 압력: 할일이 생각 날때까지 같이 서있기
- 강제 노역: 잡일 처리부 역할 맡기

특정 사람이 이런 상황을 자주 발생시키면 심각한 코칭이 필요하다. 중요한 인물이 아니라면 해고시키고, 맞다면 그의 '양치기' 역할을 할 수 있는 누군가와 짝을 지어보자.