스타일쉐어에서 PM을 맡고 있는 박성환입니다. 저희 팀은 2년 가까이 스크럼을 기반으로 개발을 해오고 있습니다. 그러면서 스크럼을 저희 방식에 맞게 약간씩 수정한 부분들을 한번 정리해보는게 좋을 것 같다싶어 이 슬라이드를 작성하게 되었습니다. 목차 1. 이 슬라이드를 만드는 이유 : 어떤 이유로 우리팀의 스크럼에 대한 내용을 슬라이드로 만들었는지에 대한 내용을 적어보았습니다. 이 슬라이드의 ‘목적’이라고도 할 수 있습니다. 2. 간단한 정리 : 스크럼에 대해 잘 모르시는 분들을 위해 간단하게 주요 내용을 정리해보았습니다. 3. 스타일쉐어팀의 기본 스크럼 방식 : 각 팀마다 스크럼 방식이 다를 텐데 주요 내용(스프린트 주기, 스토리 포인트, 사용중인 서비스)에 대해 정리했습니다. 4. 변경한 규칙 : 지난 반년동안 우리팀에 맞게 약간씩 바꾼 스크럼 규칙들을 나열해보았습니다. 5. 다만, 아직까지 남아있는 고민 : 아직 저희팀도 문제점은 있지만 개선방향을 못잡은 내용에 대해 적어보았습니다. 6. 스크럼이 조직에 잘 녹아들기 위한 조건 : 다른 조직에서도 여러 이유로 스크럼을 도입해봤지만 실패도 해보고 매끄럽게 진행도 해보면서 느꼈던 차이점에 대해 개인적인 경험을 정리해보았습니다. 몇몇 조직에서 스크럼을 경험해보고 다른 방식들도 겪어보면서 제 개인적인 생각엔 스크럼은 ‘공유’가 바탕이된 문화라고 생각합니다. 서로간의 일하는 방식, 문제점에 대해 쉽게 공유할 수 있는 환경을 만들어주는데 도움을 많이 주는 것 같습니다. 또 이런 문화가 잘 바탕이 되어 있는 조직일 수록 더 매끄럽게 돌아갔던 것 같습니다. 이 슬라이드가 다음 스크럼마스터에게도 좋은 도움이 되었으면 하고, 큰 도움은 되지 않겠지만 스크럼을 사용중인 다른 조직에게도 참고할수 있는 내용이 되길 바랍니다. 보시고 궁금하신 내용이나 의견들은 이메일 혹은 트위터를 통해서 언제든지 문의주시면 성실히 답변드리겠습니다. 감사합니다.

1. 스타일쉐어의 스크럼이 지나온 길
Scrum 프로세스 변경 History
박성환

2. 이 슬라이드를 만드는 이유
● 약 6개월 동안 Scrum Master를 겸직함으로써 개선/변경하고 그에 따라 느
낀 부분을 기록하기 위함
● 스타일쉐어팀에 새롭게 참여할 멤버와 후속 Scrum Master의 가이드가 되었
으면 하는 바램
● 우리와 비슷한 경험을 하고 있는 조직에 약간이나마 도움이 되었으면 하는
바램

3. 간단한 정리
● 스크럼이란? :
○ 각 일감에 대한 우선순위를 부여한다.
(Product Backlog)
○ 각 개발주기마다 적용할 기능 혹은 개선
에 대한 목록을 작성한다. (Sprint
Backlog)
○ 상황에 맞는 개발주기(1주~4주)를 설정
하고 목록의 일감들을 한 주기 동안 개발
한다. (Sprint)
○ 매일 5~10분 동안 회의를 가지고 한일/할
일/문제점에 대해 각자 공유한다.
출처 : 위키피디아
프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 공학 중
의 하나이다.

4. 스타일쉐어팀의 기본 스크럼 방식
● 스프린트 주기 : 1 스프린트 = 7일(워킹데이 기준)
● JIRA Agile을 이용해서 프로젝트 진행 (백로그/추정/분석)
● 스토리 포인트 기준 : 일 2점 (= 2시간)
● 데일리 미팅 / 스프린트 회고 진행

5. 스타일쉐어팀의 기본 스크럼 방식
● 스프린트 주기 : 1 스프린트 = 7일(워킹데이 기준)
○ 스프린트 주기에 따른 장단점
■ 짧은 스프린트 주기(1~2주 이내)
● 빠른 피드백 및 유연한 일감 우선순위 선정
● 일감 추정회의 시간의 단축(추정 대상일감의 수가 적음)
● 영업일이 짧다보니 한 스프린트내에 한 단위를 개발완료하기 어려움
■ 긴 스프린트 주기(3~4주)
● 일감이 많아 추정회의 시간은 길지만 3~4주에 1회만 필요
● 스프린트 도중 갑자기 일감이 추가되는 상황이 다수 발생할 수 있음

6. ● 스프린트 주기 : 1 스프린트 = 7일(워킹데이 기준)
○ 스타일쉐어의 경우 스프린트 주기를 7일로 가져가고 있음(QA주간은 4
일)
■ 상황에 따른 변화를 빠르게 가져가기 위해 짧은 스프린트 주기를
운용
스타일쉐어팀의 기본 스크럼 방식
스프린트 1 스프린트 2
스프린트 3
(QA)
App 릴리즈
7일 7일 4일

7. 스타일쉐어팀의 기본 스크럼 방식
● JIRA Agile을 이용해서 프로젝트 진행 (백로그/추정/분석)
○ 일감 생성/우선순위/추정/스프린트 생성 및 진행과정 확인

8. 스타일쉐어팀의 기본 스크럼 방식
● JIRA Agile을 이용해서 프로젝트 진행 (백로그/추정/분석)
○ Velocity Chart, Burndown Chart를 이용해 현황 파악 및 개선점 탐색

9. 스타일쉐어팀의 기본 스크럼 방식
● 스토리 포인트 기준 : 1일 2점 (2점 = 2시간)
○ 스토리 포인트 : 각 일감(스토리)을 해결하는데 예측되는 점수
○ 스프린트 주기의 일수에 맞춰 개인별로 스토리 포인트를 가져감
○ 회의시간/버그수정/개발을 위한 리서치 등의 시간은 스토리 포인트에
서 제외 됨
○ 개발에만 온전히 집중하였을때 소요되는 시간을 기준으로 함

10. 스타일쉐어팀의 기본 스크럼 방식
● 데일리 미팅 / 스프린트 회고 진행
○ 데일리 미팅 (매일 10분)
■ 스타일쉐어 개발팀은 매일 오후 4시에 전원(8명)이 모여 오늘 한일/할일/문
제점을 공유하고 있습니다.
■ 그 날 개발하는데 문제가 있거나 고민이 있는 부분을 빠르게 공유하여 팀이
함께 이슈를 파악하고 해결할 수 있도록 도움을 줍니다.

11. 스타일쉐어팀의 기본 스크럼 방식
● 데일리 미팅 / 스프린트 회고 진행
○ 스프린트 회고 진행
■ 매 스프린트 기간마다 1회씩 스프린트 회의를 진행하는데 이때 해당 스프
린트에 대한 회고를 매번 진행합니다.
■ 이번 스프린트에 아쉬웠던 점, 좋았던 점을 공유하여 스프린트 혹은 일하는
환경 개선을 위해 빠르게 피드백을 받습니다.

12. 변경한 규칙 1) 일감 추정 순서
● 일감 추정?
o 백로그에 쌓여져 있는 일감을 추정회의를 통해 해당 일감을 완료하는
데 소요되는 스토리 포인트(작업시간)를 예측합니다.
o 일감을 생성/담당한 개발자가 이 기능의 스펙/목적/개발방식에 대해 설
명하고 담당자와 팀이 필요한 스토리 포인트에 대해 추정합니다.
o 한 스프린트(7일)에서 워킹데이 기준으로 일별 스토리 포인트를 부여하
여 총합을 각자가 일감으로 가져갑니다.
 ex : 7일(워킹데이) * 2점(1일) = 14점 스토리 포인트

13. 변경한 규칙 1) 일감 추정 순서
- 기존에는 일감 추정을 일감 등록한 순서로 진행
- 일감에 클라이언트/백엔드/웹프론트 일감 및 여러 주제의 일감이 섞여 있어
컨텍스트 파악이 어려움
- 연결되어 있는 일감(동일 Epic)들을 우선적으로 추정
- 연결된 일감이 없으면 동일한 플랫폼(iOS/Android/Backend/Web)별로 나누
어서 추정 진행
기존
변경

14. 변경한 규칙 1) 일감 추정 순서
● 한 주제내의 일감들을 이어져서 추정을 하니 일감에 대한 전체적인 이해도
증가
● 반복 설명해야되는 상황이 줄어들어 일감 추정회의 시간의 길이가 짧아짐
개선효과

15. 변경한 규칙 2) 담당자 부재시 추정방식
- 스프린트 시작 전 일감추정 및 지난 스프린트 회고를 위한 회의가 필요
- 다만, 휴가일정 및 개인사정으로 인해 스프린트 회의시 담당자가 부재할 경
우 발생
- 스프린트 회의 일정 변경으로 해결하기에는 다른 팀원들의 일정 및 스프린
트 점수 부족등의 상황으로 무리가 있음
- 동일 플랫폼(iOS/Android/Backend/Web)의 개발자가 부재하는 담당자의 스
토리
포인트까지 추가로 받아 추정 후 일감 해당 개발자에게 할당
기존
변경

16. 변경한 규칙 2) 담당자 부재시 추정방식
● 개선효과
● 스프린트 회의를 고정적인 날에 진행할 수 있어 스케쥴 예측에 효과적
● 개인 휴가일정을 스프린트 회의에 상관없이 유연하게 사용가능
개선효과

17. 변경한 규칙 3) 스프린트 회의날은 일감파악만
AS-IS
- 스프린트 회의 시간 바로 전까지 개인별 스프린트 마감을 위해 배포 및 적용
하느라 다음 스프린트 추정일감의 파악 시간이 적어짐
- 추정할 일감의 이해도가 적어지면서 일감 설명 및 개발 방식이 정해지지 않
아 전체적인 일감 추정회의 시간이 길어짐
- 스프린트 회의일 00시 부터는 기존 스프린트 일감에 대한 개발작업을 하지
않음(Pull Request 및 Merge 금지)
- 스프린트 회의시간(14:00시)까지 다음 스프린트 일감에 대한 파악 및 개발
방식 고민의 시간으로 사용
기존
변경

18. 변경한 규칙 3) 스프린트 회의날은 일감파악만
● 추정할 일감에 대해 개발방식 및 필요성에 고민하는 시간이 많아지면서 추
정회의 때에는 기존 목적인 개발 방식의 공유 및 피드백에 집중할 수 있음
● 개발방식을 미리 고민해 일감 추정회의 시간 단축
개선효과

19. 변경한 규칙 4) 추정이 없는 일감
- 리팩토링 및 코드 분석과 같은 일감의 경우 추정의 오차가 큼
- 일감 완료의 정의가 애매한 일감으로 인해 많은 시간을 한 일감에만 사용해
기존에 가져간 다른 일감들의 진행이 안되는 부분 다수 발생
- 리팩토링 및 코드 분석과 같이 일감의 완료 정의가 어려운 경우 추정을 하지
않고 기준이 될 스토리포인트를 책정함.
- 추정 없이 책정한 스토리 포인트에 맞게 개발을 진행하고, 초과할 경우 데일
리 미팅에서 내용을 공유하고, 추가 개발을 할지 다음 일감으로 넘어갈지에
대해서 논의
기존
변경

20. 변경한 규칙 4) 추정이 없는 일감
● 개발완료가 정의되지 않은 일감의 가이드라인을 제공해 너무 과도한 시간
을 사용하지 않게 기준을 제공
● 한 일감에 과도한 시간을 사용해 다른 주요 일감들이 계속 미뤄지는 부분을
방지
개선효과

21. 변경한 규칙 5) 일감은 모두 5점(스토리 포인트)
이하
- 한 기능의 개발을 하나의 일감으로 작성 및 추정
- 일감의 개발크기가 크다보니 일감 추정의 오차가 다수 발생
- 한 스프린트에 가져가는 일감의 수가 적음으로 인해 완료에 대한 피드백을
받는것이 적음
- 각 일감을 2~3시간 내에 작업완료 할 수 있는 task로 분리하여 등록
- 스토리 포인트 5점이 나오는 경우에도 일감을 더 잘게 나눌 수 있는지에 대
해서 논의 후 진행(가능할 경우 일감을 나누어서 재추정)
기존
변경

22. 변경한 규칙 5) 일감은 모두 5점(스토리 포인트)
이하
● 각 일감의 크기가 작아져 추정 오차가 적어지고 자세한 추정이 가능
● 단계별로 일감이 나누어져 있어 해당 일감의 개발방식에 대한 다른 팀원들
의 이해도 증가
● 각 일감의 빠른 개발완료로 진행상황 및 더 즉각적인 피드백을 받을 수 있음
개선효과

23. 다만, 아직까지 남아있는 고민
1. 인원의 증가
- 개발팀의 인원이 증가함에 따라 일감의 수, 범위, 회의시간이 늘어남
- 팀을 나누기에는 한 제품을 만드는 팀이라 각 일감의 연관성이 있어 구분하
기가 어려움
2. 버그 우선순위에 대한 반영
- 현재 스크럼 방식에서는 버그에 대한 스토리 포인트 부여를 하지 않고 있음
- 스크럼 프로세스의 성과를 보기위해 자주 사용하는 Velocity Chart,
Burndown Chart의 경우 스토리 포인트에 대한 추이만 보여주다 보니 버그
수정에 대한 성과가 표면적으로 나타나지 않음
- 그로인해 버그 수정이 오히려 각 담당자의 우선순위에서 내려가게 되는 상
황 발생

24. 스크럼이 조직에 잘 녹아들기 위한 조건
● 적은 인원 수
o 팀원의 수가 10명 이상 넘어가면 스크럼을 진행하기에 소요되는 다양
한 시간(회의시간, 일감추정, 회고)이 2배 이상 늘어나게 됨
o 소요 시간은 생각보다 매우 중요한 요소 : 소요시간이 길어지면 스크럼
팀 구성원 개개인의 비효율적인 시간이 많아지게 되어 점점 필요성을
못 느끼게 됨
● 연결된 일감
o 스크럼 팀간의 일의 연결성이 있지 않으면 일감에 대한 이해도가 떨어
지게 되어 추정 오차 폭이 커짐
o 자신과 연관이 없는 일감에 대한 논의(데일리 미팅, 스프린트 회의)가
계속되어 집중도가 떨어짐

25. 스크럼이 조직에 잘 녹아들기 위한 조건
● 구성원의 성향
o 결국엔 이 스크럼이라는 것도 각 구성원이 좀 더 나은 환경에서 개발을
하기위한 프로세스
o 스크럼 역시 하나의 개발방식에 불과하기에 팀 구성원들이 어떤 개발
방식/조직문화를 기존에 선호하는지에 대한 파악이 중요

26. 스크럼이 조직에 잘 녹아들기 위한 조건
● 이 프로세스가 왜 필요한지에 대한 논의와 이해
o 스크럼을 새롭게 도입하기 위해서는 이 부분에 대한 논의와 협의가 가
장 중요
o 스크럼의 도입하는 이유는 남이 정한 일정이 아니라 나/팀이 협의하여
정한 일정으로 일하고 해당 일감에만 집중할 수 있는 환경을 만드는 것
이 목적 -> 일정에 따른 관리가 목적이 되면 안됨
o 스크럼은 ‘공유'의 문화이다. 이 문화에 어울리는 조직에 더 적합하지 않
을까. : 스크럼은 내가 지금 어떤 일을 하는지, 어떤 문제가 있는지, 어떻
게 개발하는게 좋은지 팀간에 서로서로 공유하고 발전을 위한 바탕.

27. 끝으로...
아직까지도 개선해야 될 것은 많이 남아있습니다. 그리고 언젠가는 이 스크럼 방
식을 버려야 되는 시기도 오지 않을까 싶습니다.
중요한 것은 어떤 개발방식을 하느냐 안하느냐 보다 우리팀이 좀 더 효율적으로
일하기 위해선 어떤게 필요할지 파악하고 실행해보는 것이 중요한것 같습니다.
더 나은 방법은 항상 존재하니까요.

28. 감사합니다.
박성환
E-mail : walter@stylesha.re
Twitter : @unsteadyflow