---
# System prepended metadata

title: Scrum guide
tags: [' scrum', classting]

---

---
title: Scrum guide
tags: classting, scrum
description: Classting scrum
---

# Scrum guide

<!-- Put the link to this slide here so people can follow -->
Junheon Lee
https://hackmd.io/p/ZR3j5xPjS72KW5PsttqqtA

---

# Scrum

---

## Scrum (rugby)

![scrum-lugby](https://i.imgur.com/VRCzGYT.jpg)
> 출처: Wikipedia

---

## Scrum (rugby)

- 럭비에서 플레이를 다시 시작하는 방법
- 가운데로 공을 넣고 선수들은 몸을 부딧치며 
- 볼의 소유권을 얻기 위해 시도

---

## Scrum

- 1986
    - The new new product development game / Harvard business review / 노나카 이쿠지로, 타케우지 히로타가
- 1995 
    - Ken Schwaber, Jeff Sutherland 고안

---

## Scrum

- 팀이 함께 목표를 달성하기 위한 프레임워크
- 팀이 목표를 향해 달려가며
    - 문제를 함께 해결하기 위해 머리를 맞대고
    - 문제 해결 경험을 통해 배우고
    - 성공과 실패를 프로세스에 반영하여
    - 점진적/지속적 개선하도록

---

## Scrum & lean

거창한 제품보단 고객에게 가장 중요한 가치를 전달

---

## Scrum

![scrum-process](https://i.imgur.com/JccLzoU.jpg)

---

## Scrum roles

Scrum roles != Job titles

---

## Scrum roles

- 스크럼 구성원의 역할에 따른 책임
- 직군/직책과 역할은 다른것
- 어떤 직군이던 하나의 역할을 수행

---

## Scrum roles

- Product owner
- Scrum master
- Development team members

---

## Scrum roles

- 스크럼은
    - 경험주의
    - 자기 조직화
    - 점진적 개선
- 역할은
    - 최소한의 역할
    - 역할간 긴밀한 상호작용 

---

## Scrum roles
### Product owner

![product-owner](https://i.imgur.com/VQCkjR5.png)

---

## Scrum roles
### Product owner

- 제품의 비전
- 제품의 로드맵, 릴리즈 관리
- 백로그 관리
- 비즈니와의 소통

---

## Scrum roles
### Scrum master

![scrum-master](https://i.imgur.com/FGJoP2M.png)

---

## Scrum roles
### Scrum master

- 스크럼 리더
- 퍼실리테이터
- 애자일 코칭
- 방법을 개선하고 적용

---

## Scrum roles
### Development team members

![scrum-dev-team-members](https://i.imgur.com/SXvI7kh.png)


---

## Scrum roles
### Development team members

- 제품 디자이너 / 프로그래머 / QA엔지니어 등
- 스프린트를 통해 목표 달성을 위한 제품 개발
- 데일리 스크럼을 통해 작업의 투명성 보장

---

## Scrum process

![scrum-process](https://i.imgur.com/JccLzoU.jpg)

---

시작해봅시다!

---

## Scrum process

- Sprint planning
- Sprint
- Sprint review
- Sprint retrospective

---

## Backlogs
### User story

![](https://i.imgur.com/0uI1iw2.jpg)


---

## Backlogs
### User story

![](https://i.imgur.com/PiRPEl0.png)

---

## Backlogs
### User story

- 작업보단 결과에 집중
- 고객에 전달할 가치를 고객 입장에서 정의
- 앞장에는 고객 입장의 가치
- 뒷장에는 고객 입장의 행동을 통한 테스트

---

### Tips.

너무 구체적이지 않도록, 
결과물을 사용자 관점에서 정의합니다.
테스트 케이스를 A-Z까지 정의하면
그것은 유즈케이스 스펙이에요.

---

## Sprint planning

- Backlogs를 우선순위별로 정렬
- 디자인 결과물 설명
    - 사용자 스토리
    - 테스크 플로우
    - 프로토타입
- 스토리 포인트 예측

---

## Sprint planning
### Planning poker

- 스크럼 마스터가 진행자 역할
- 프로덕트 오너가 목표와 사용자 스토리를 설명
- 디자이너가 부가 설명이나 질의 응답
- 이때, 뒷장의 인수 테스트를 참고
- 대화를 통해 인수 테스트를 보충

---

## Sprint planning
### Planning poker

![](https://i.imgur.com/APATw7F.jpg)

---

## Sprint planning
### Planning poker

- Developer team 멤버 각자 한장의 카드 제출
- 모두의 예측이 같을 때까지 반복
- 예측이 다르다면 가장 적은, 가장 많은 예측을 한 멤버가 설명

---

## Sprint planning
### Planning poker

- 3 이상이라면 스토리가 너무 비대하다는 신호
- 이때, 스토리를 그자리에서 더 작은 단위로 분리
- 1~2 포인트가 최적
- 최대 3을 넘지 않도록 구성

---

## Sprint planning

- Developer team 멤버가 스프린트간 가능한 작업일 조사
- 조사를 바탕으로 인원당 가용 가능한 포인트를 50~70% 사이로 조정
- 사용자 스토리를 리뷰하며 각 멤버에게 할당
- 스프린트 골 확정

---

![](https://i.imgur.com/2YxE35V.jpg)


---

### Tips.

처음에는 4시간을 목표로 시작하세요.

---

### Tips.

백로그가 잘 관리되고 경험이 쌓이기 시작하면
2시간 이내에 끝낼 수 있도록 목표를 재조정합니다.

---

### Tips.

가능한 종이로 스토리 카드를 준비해주세요.
주위가 분산되지 않고 집중도를 높히는데 좋습니다.
(바로바로 메모하고 쪼개고 재정렬하기 좋아요.)

---

## Sprint

고객 가치를 전달하기 위해 열심히 달리자!

---

## Sprint
### Daily scrum (daily stand-up)

- 했던 일, 할 일, 당면한 이슈 공유하기
- 번다운 차트를 함께 보며 진행 현황 파악

---

### Burndown
![](https://i.imgur.com/KAFycS2.jpg)
[Understanding the Scrum Burndown Chart](http://www.methodsandtools.com/archive/scrumburndown.php)


---

### Tips.

이때,
스크럼 마스터는 당면한 이슈를 파악하기 위해 노력합니다.
(a.k.a 블로커)
멤버 모두 당면 이슈 해결을 최우선으로 집중합니다.

---

### Tips.

문제 해결을 위한 자료 조사를 도와줄 수도 있고, 
테스트를 도와 현상 파악에 도움을 줄 수 있습니다.
리뷰를 빨리 하도록 독려할 수도 있겠지요.

---

### Tips.

또는 방해자를 제거할 수도 있어요.

---

### Tips.

기억하세요. 블로커 제거가 1순위입니다.
(듣고만 넘어가면 안되요.)

---

## Sprint review

a.k.a. 스프린트 세레모니

---

## Sprint review
### 참석자

- 모든 스크럼 멤버
- 이해관계자
    - 비즈니스 오너
    - 마케터
    - 고객 담당 등

---

## Sprint review

스프린트 목표를 다시 공유하고 결과를 공유합니다.
이때 결과는 눈으로 볼 수 있는 결과물을 말합니다.
제품에 대한 간단한 피드백을 주고받습니다.

---

그리고 2주간 고생한 멤버에게 박수쳐주세요.
(처음부터 목표를 달성하기 어렵습니다.)

---

### Tips.

완료 기준을 정해주세요.
PR 리뷰 완료를 기준으로 할 수도 있고,
제품 릴리즈를 기준으로 할 수도 있습니다.
제품 특성별로 다릅니다.

---

### Tips.

시간은 30분 ~ 1시간
스크럼 마스터는 미팅이 길어지지 않도록 
중재자 역할을 합니다.
(모든것을 논의하는 자리가 아니에요.)

---

# Sprint retrospective

---

![](https://i.imgur.com/UzVDxOz.jpg)

---

![](https://i.imgur.com/fbfZ4VC.jpg)


---

## Sprint retrospective

- 방법에 대한 개선미팅
- 마스터가 퍼실리테이터 역할
- 모든 멤버가 적극적으로 참여할 수 있도록 독려

---

## Sprint retrospective

2주간 스프린트에 대해 마스터가 공유합니다.
이때, 목표달성/번다운/해결한 이슈 등을 활용합니다.
(일종의 기억을 되살리는 방법입니다.)

---

## Sprint retrospective

잘한일, 더 잘 했어야 하는일을 수집합니다.
이때, 포스트잇을 활용하여 자료를 모으는데에 집중하세요.
(10~20분간 모으는 것을 권장합니다.)

---

## Sprint retrospective

자료가 모였으면 멤버의 도움을 받아
자료를 재 그룹핑합니다.

---

## Sprint retrospective

먼저 잘한일을 논의해볼까요?

논의를 통해 잘한일의
구체적 방법을 찾도록 노력하세요.

---

## Sprint retrospective

더 잘 했어야 하는일을 논의해봅시다.

이때, 잘 했어야 하는 일의 문제를 구체화하고
개선점을 도출합니다.

---

## Sprint retrospective

마지막으로 다음 스프린트에 적용할 
개선점을 1~3개 선정합니다.

---

### Tips.

회고전 워밍업을 해주세요.
멤버의 컨디션을 5점 만점으로 파악하고
스프린트를 통한 현재 컨디션을 
공유하는것으로 시작합니다.

---

### Tips.

마스터는 회의 방향이 어긋나지 
않도록 퍼실리테이터 역할을 수행합니다.

---

### Tips.

잘한 일, 더 잘했어야 하는 일은
스프린트와 연관성이 있어야 합니다.
회고는 프로세스를 개선하는 자리입니다.

---

### Tips.

실제로 7명의 멤버면 약 1시간 ~ 1시간 30분
가까이 소요됩니다.
시간을 30분 단위로 쪼개어 진행하고 
시간을 연장할 수 있도록 하세요.
목표는 1시간 내에 끝내는 것입니다.

---

![scrum-lugby](https://i.imgur.com/VRCzGYT.jpg)
> 출처: Wikipedia

---

우리는 더 나아질 수 있습니다.

---

끝.
QnA