스크럼은 최대 1개월 길이로 반복되는 주기적인 스프린트 라는 방식으로 일을 조직한다. 이 포스팅에서는 스프린트가 무엇인지에 대해 더 자세히 설명할 예정이다. 그러고나서 다음과 같은 스프린트의 몇 가지 주요 특징들에 대해 논의할 것이다.

• 스프린트 는 타임박스(timebox) 로 구성되어 있다.
• 짧거나 지속적인 기간을 가진다.
• 한 번 시작한 이상 바뀌어서는 안 되는 목표를 가지며, 팀이 정의 정의한 완료에 최종적으로 도달해야 한다.

개요

스프린트는 스크럼 프레임워크의 뼈대이다. 모든 스프린트는 타임박스 로 구성되어 있는데, 이는 고정된 시작일과 종료일이 있다는 것을 읨히나다. 또한 스프린트는 짧아야 하고 1주일에서 1개월 사이의 길이를 가진다. 특정한 상황 아래에서는 예외가 있겠지만 스프린트 길이는 일정해야 한다. 스프린트 중에는 개발 범위의 목표나 인원에 대한 변경을 허용하지 않는다 는 규칙이 있다. 마지막으로 각 스프린트에서는 잠재적으로 출시 가능하고 스크럼 팀이 합의한 완료 정의에 맞는 수준의 제품 증분이 완성되어야 한다.

이미지 출처 : https://brainhub.eu/blog/differences-lean-agile-scrum/

비록 각 조직마다 고유의 방식으로 스크럼을 수행하겠지만, 위의 스프린트의 특징은 앞으로 탐구할 몇 가지 예외를 제외하고는 모든 스프린트와 모든 팀에 적용되는 것이 기본이다. 왜 그런지 이해하기 위해 각 특징을 아래에서 설명할 예정이다.

타임박스

스프린트는 일의 실행과 범위를 관리하는데 도움이 되는 시간 관리 기법인 타임박스(timebox) 라는 개념에 그 뿌리를 두고 있다. 각 스프린트는 명확한 시작과 끝을 갖는 시간 틀을 갖는데, 이를 타임박스라 부른다. 이 타임박스 안에서 팀은 스프린트 목표에 맞추어 선택된 일을 지속 가능한 속도로 한다.

타임박스를 사용하는데는 아래와 같은 몇 가지 이유가 있다.

• 진행 중인 일에 제한 설정
• 우선순위 결정
• 진행 상황 명시
• 불필요한 완벽주의를 방지
• 마무리를 장려
• 예측성 증진

진행 중인 일에 제한 설정

타임박스는 진행 중인 일(WIP)의 양을 제한하기 위한 기술이다. 진행 중인 일은 시작은 했지만 아직 끝내지 않은 일의 재고를 나타낸다. 제대로 관리하지 않으면 심각한 경제적 결과를 초래할 수 있다. 팀은 해당 스프린트 안에 시작하고 끝낼 수 있다고 믿는 일정한 아이템만 처리하도록 계획을 세우기 때문에 타임박스는 각 스프린트에서 진행 중인 일에 대한 제한(limit)을 설정한다.

우선순위의 결정

타임박스는 우선순위를 결정하고 적은 양의 중요한 일을 시행하게 만든다. 이는 무언가 가치 이쓴ㄴ 일을 빠르게 완료하려는 우리의 주안점을 더 분명하게 한다.

진행 상황 명시

타임박스는 일을 완성하기 위한 상대적인 진행 속도를 보여 주고 알려진 날짜(스프린트가 끝나는 날)에 일의 중요한 부분을 완성했는지 확인하는데 도움을 준다. 또한 타임박스는 하나 이상의 타임박스를 요구하는 큰 기능에 대한 진행 상황을 보여주는데 도움을 준다. 이러한 제품 기능을 완성할 때, 매 스프린트마다 가치 있고 측정 가능한 결과가 만들어지도록 한다. 또한 전체 기능을 완성하기 위해 이해관계자들과 팀이 해야 할 일이 정확히 무엇이 남아 있는지 학습할 수 있게 돕는다.

불필요한 완벽주의 방지

누구나 한 번쯤은 무언가 필요한 만큼만 해도 되는데도 완벽하게 하려고 너무 많은 시간을 허비해 본 적이 있을 것이다. 타임박스는 끝이 없을지도 모르는 일을 스프린트의 고정된 종료일을 설정함으로써 정해진 기간동안 좋은 해결책을 찾아 완성해야 하는 일로 마무리를 짓게 만든다.

마무리 장려

필자의 경험상 팀이 마감일을 알고 있을 때 일을 끝낼 확률이 더 높다. 마감일을 모른다면 일을 끝내려는 긴박함이 덜해질 것이다. 스프린트에 고정된 마감일이라는 끝이 있다는 사실은 팀원들이 더 일에 성실하게 매진해 시간 내에 마무리할 수 있도록 한다.

예측 가능성 증진

앞으로 1년 동안 할 일에 대해서는 정화갛게 상황을 예측하기 어렵지만, 짧은 다음 스프린트에서 완료할 일에 대한 예측은 기대할 수 있다.

짧은 기간

스프린트의 짧은 기간 은 아래와 같이 이점이 많다.

• 쉬운 계획
• 빠른 피드백
• 오류 제한
• 투자 수익률 증진
• 흥미를 되찾음
• 빈번한 검토 지점

쉬운 계획

스프린트 기간이 짧기 때문에 계획을 더 쉽게 세울 수 있다. 몇 주간의 업무 계획을 세우는 것이 6개월 동안의 업무 계획을 세우는 것보다 쉽다. 또한 짧은 시간 내의 계획을 세우는 것이 더 긴 시간 내의 계획을 세우는 것보다 훨씬 더 적은 노력을 필요로 하고 더 정확할 수 있다.

빠른 피드백

짧은 기간의 스프린트는 빠른 피드백을 ㅁ나들어 낸다. 각 스프린트 기간 동안 작동 가능한 소프트웨어가 만들어지면 이를 검토하고 무엇을 어떻게 만들지를 조정해 나갈 기회를 갖게 된다.(스프린트 리뷰) 빠른 피드백은 나쁜 결정이 쌓이기 전에 좋지 않은 제품이나 개발법을 빠르게 쳐낼 수 있도록 한다. 또한 시간에 민감한 새로운 기회들을 더 빠르게 발견하고 이용할 수 있도록 한다.

투자 승익률 증진

짧은 기간의 스프린트는 빠르게 더 자주 결과물을 내놓을 수 있게 한다. 그 결과 수익을 더 빨리 창출할 기회를 갖게되고 전체적인 투자 수익률이 증진다.

오류 제한

2주간의 스프린트에서 뭐가 얼마나 잘못될 수 잇겠는가? 만약 모든 작업량을 날리더라도 단지 2주를 잃을 뿐이다. 우리는 빈번한 조정과 피드백을 제공하기에 짧은 스프린트를 고수한다. 여기서 생기는 실수는 최악의 경우에도 그 위험이 적다.

흥미를 되찾음

짧은 기간의 스프린트는 흥미를 되찾도록 도와 줄 수 있다. 만족감을 위해 더 오래 기다릴 수록 관심가 흥미가 줄어드는 것이 사람의 본성이다. 아주 오랫동안 한 가지 프로젝트에 임하는 경우 실패할 가능성이 커질 뿐만 아니라 결국에는 노력할 열정을 잃게 될 가능성도 커진다. 눈에 보이는 진전과 결과가 없으면 사람들은 점점 관심을 잃기 시작한다. 막바지에는 다른 제품으로 옮겨 가기 위해 다른 사람에게 돈을 내는 것도 마다하지 않을지도 모른다.

Note: 짧은 기간의 스프린트는 이용 가능한 자산을 자주 내놓음으로써 참여자들의 흥미를 유지시킨다. 일찍부터 자주 결과를 얻을 수 있으면, 거기서 얻는 만족감을 통해 목표를 향한 지속적 관심과 욕구를 되살릴 수 있다.

빈번한 체크 포인트

책의 이미지를 보자마자 어떤 내용인지 바로 직감적으로 와닿았다. 일반 폭포수 모델의 같은 경우 각 단계가 끝날때마다 검토와 조정의 과정을 거치게 될 것이다. 하지만 스크럼의 경우 매 스프린트마다 스프린트 리뷰 를 통해 더 많은 체크 포인트를 제공하게 된다. 이를 통해 모든 이해관계자, 관리자, 제품 책임자들이 입증 가능하고 작동 가능한 제품 긴으을 바탕으로 결정을 내릴 수 있게 한다.

이처럼 점검과 조정의 기회를 제공하는 조치 가능한 체크 포인트가 더 많을 때 사람들은 복잡한 환경을 더 잘 다룰 수 있게 된다.

일정한 기간

하나의 개발 프로젝트를 진행할 때 일정한 스프린트 길이를 정하고, 설득력 있는 이유가 없다면 바꾸지 않아야 한다는 규칙이 있다. 설득력 있는 이유란 아래와 같은 경우다.

• 더 자주 피드백을 받기 위해 4주 스프린트에서 2주 스프린트로 변경할 것을 고려하고 잇으나 먼저 2주 스프린트를 몇 번 시도해 본 후에 결정하고 싶다.
• 연휴나 회계연도 말에는 평소처럼 2주 스프린트를 하는 것보다 3주 스프린트를 하는 것이 더 실용적일 수 있다.
• 제품 출시를 일주일 앞두고 있으므로 2주 스프린트 낭비다.

현재 스프린트 기간 안에 모든 일을 마칠 수 없다는 사실은 시간을 늘릴 만한 설득력이 없다. 하지만 위와 같은 실용적인 이유 때문이라면 바꿀 이유가 된다.

같은 길이의 스프린트를 사용하면 리듬이 단순해져 계획을 하는데 이득을 볼 수 잇따.

리듬이 주는 이득

스프린트에서 길이를 동일하게 유지하는 것(cadence)은 스컮 개발 모델에 정기적이고 예측 가능한 리듬 혹은 심장 박동을 제공한다. 꾸준하고 건강한 심장 박동은 스크럼 팀과 조직이 빠르고 유연한 비즈니스 가치의 흘므을 성취하기 위해 언제 일을 진행해야 하는지에 대해 잘 알 수 있도록 하는 중요한 리듬을 얻게 해준다. 필자의 경험으로 리듬이 주는 이득은 아래와 같다.

• 사람들이 몰입하거나, 거침 없이 나가거나, 흐름을 탈 수 있게 해준다. 이는 규칙적인 리듬이 일상적이지만 필요한 활동들은 습관화함으로써 재미있고 가치를 더하는 일에 집중할 수 있도록 정신을 자유롭게 하기 때문일 것이다.
• 짧은 스프린트 리듬은 또한 일의 집중도를 높이는 경향이 있다. 전통적인 순차적 개발에서 후반 단계에 집중도가 가파르게 올라가는 것과 달리, 각 스프린트마다 집중도에 흐름이 있다. 이러한 스프린트의 리듬은 팀이 지속적인 속도로 일할 수 있게 한다.
• 규칙적인 리듬의 스피른트는 또한 조정 비용을 상당히 줄인다. 스프린트의 기간이 정해져 잇으면 많은 스프린트에 대해 동시에 스프린트 계획, 스프린트 리뷰, 스프린트 회고 일정을 예측해서 짤 수 있다. 모두가 언제 각 활동이 일어날지 알고 있으므로 여러 개의 스프린트 일정을 짜른 간접비가 상당히 줄어든다.
• 마지막으로 같은 프로젝트에 참여하는 여러 팀이 있다면, 모든 팀의 일이 동기화될 수 있게 해준다.(더 자세한 논의는 12장을 참고)

계획 간소화

지속적으로 같은 기간을 사용하는 것은 계획 활동도 간소화시킨다. 모든 스프린트 기간이 같으면 팀은 그런 종류의 스프린트 안에 끝낼 수 있는 일(이를 속도(velocity)라 한다)에 익숙해진다. 속도는 보통 스프린트에 맞춰 표준화된다. 만일 스프린트 길이가 모두 다르면 표준화된 스프린트 단위를 가질 수 없게 된다. 이런 경우 “저 팀은 평균적으로 스프린트마다 20점의 속도를 가지고 있다” 라고 하는 것은 별 의미가 없게 된다.

스프린트 기간이 변동적이어도 팀의 속도를 계산할 순 있지만 더 복잡하다. 따라서 스프린트 길이를 유지하는 것은 팀의 속도 데이터 기록을 바탕으로 하는 계산을 간소화한다.

일정한 스프린트 기간은 또한 나머지 계획의 계산을 간단하게 만든다. 에를 들어, 정해진 출시 일자 를 정해놓고 일을 하는 경우 스플니트 기간이 일정하다면 출시까지 얼마나 많은 스프린트가 필요할지 달력을 보고 계산하기만 하면 된다. 만일 스프린트 기간이 일정하지 않다면 춸씬 더 어렵고 불필요한 간접비를 들게 하며, 그 결과를 신뢰하기 어려울 것이다.

변경 없는 목표

중요한 스크럼 규칙 한 가지는 스프린트 목표 를 정하고 스프린트 실행이 시작되었으면 스프린트 목표에 질적으로 영향을 미칠 수 있는 변화가 있어서는 안된다는 것이다.

스프린트 목표란?

각 스프린트는 해당 스프린트의 비즈니스 목적과 가치를 설명하는 스프린트 목표(sprint goal)로 요약될 수 있다. 보통 스프린트 목표는 아래와 같이 명확한 하나의 초점을 가지고 있다.

• 리포트 생성 지원
• 북아메리카 지도 자료 탑재 및 관리.
• 통합된 소프트웨어, 펌웨어, 하드웨어 좋바을 통해 문자 메시지를 보낼 수 있다는 것을 입증한다.

스프린트 목표가 다양한 측면을 가질 수도 있다. 예를 들어, “기본적인 인쇄가 가능하게 하고 날짜별로 검색할 수 있게 하는 것”이 스프린트트 목표가 될 수 있다.

스프린트 계획 동안 개발 팀은 스프린트의 목표를 다듬고 합의해 제품 백로그 항목 중에 스프린트가 끝날 때까지 마칠 항목을 정하는데 사용한다(자세한 것은 19장 참고). 이러한 제품 백로그는 스프린트 목표를 다듬는데 도움이 된다.

상호 약속

스프린트 목표는 팀과 제품 책임자가 하는 상호 약속 의 바탕이 된다.

• 팀: 스프린트가 끝낼때까지 목표 완수하는 것
• 제품 책임자: 해당 스프린트 기간동안 목표를 바꾸지 않는 것

이러한 상호 약속은 스플니트에서 변화하는 요구사항과 팀이 짧고 고정된 시간 내에 집중하여 효율적으로 재능을 살려 가치를 만들어 내는 것의 균형이 중요함을 보여준다.스프린트 목표를 정하고 이를 바꾸지 않음으로서 스크럼 팀은 잘 정의되고 가치 있는 목표에 계속 집중(몰입) 할 수 있다.

변화와 명확성

스프린트의 목표를 질적으로 바꿔서(changed)는 안되지만, 명확히 하는 것(clarify)은 괜찮다.

질적으로 바꾸는 것은 경제적 낭비나, 일의 흐름을 방해하거나, 스프리느 기간 안에 일의 범위를 바꿀 잠재적 가능성이 있는 일이나, 자원의 변경이다. 스프린트에서 제품 백로그 항목을 더하거나 뺴는 것 혹은 스프린트 안에 이미 있는 제품 백로그 항목의 범위를 많이 바꾸는 것이 해당된다. 예시로는 아래와 같다.

example: 제품 책임자: “제가 청소년 범죄자 경찰 데이터베이스 검색 기능을 만들어야 한다고 했을때는 이름이랑 성씨 기준으로만 하는게 아니라 문신 글미을 이용해서도 찾을 수 잇어야 한다는 거였습니다!!!”

그림 검색 기능을 추가하는 것은 훨씬 더 많은 노력이 요구된다는 것을 의미할 것이고 이는 팀이 세운 마감일을 지킬 가능성에 영향을 미칠 것이다. 이 경우 제품 책임자는 그림 검색 기능을 다음 스프린트에서 작업하도록 새로운 제품 백로그 항목을 만들어 제품 백로그에 추가하는 것을 고려해야 한다.

명확성(calrity)은 스프린트 기간 동안 목표를 이룰 수 있도록 돕는 추가적인 세부사항이다. 제품 백로그 항목과 관련된 세부 사항이 스프린트 초기에 완전히 알려져 있지 않거나 명시되어 있지 않을 수 있다.(5장에서 논의) 그러므로 스프린트 기간동안 팀이 이에 대해 질문하고 제품 책임자가 대답하는 것은 전적으로 타당한 일이다. 다음 예시를 통해 명확성을 설명해 보자.

1
2
3
4
5

개발 팀: "청소년 범죄자를 검색하면 목록이 쭉 나와야 한다고 했을 때, 목록을 어떤 순서로 정리하면 좋을지에 대해 생각해 보셨습니까?"

제품 책임자: "네. 성씨를 가나다순으로 정리하면 좋겠습니다."

개발 팀: "네, 가능합니다."

이런 식으로 제품 책임자(PO)는 스프린트 동안 명확성을 제공할 수 있고 또 그래야 한다.

변화의 대가

목표를 변경할만한 변화가 있어서는 안된다는 규칙이 변화를 받아들어야 하는 스크럼의 핵심 원칙과 충돌하는 것처럼 보일 수 있다. 변화를 받아들여야 하는 것은 맞미나, 균형 잡히고 경제적이며 합리적인 방식으로 되어야 한다.

변화의 경제적인 대가는 변화하는데 들어가는 투자에 비례해서 증가한다. 간단하 예시를 들어 보자. 현재 스프린트에서 작업하기로 한 X라는 제품 기능을 원래는 없었던 Y라는 제품 기능으로 대체한다고 해보자.

• 만일 제품 기능 X를 만들지 않았을 경우
  • 계획에 이밎 시간을 쓴 낭비가 발생
  • X라는 제품 기능이 스프린트의 다른 제품 기능들과 연관되어 있을 수 있기 때문에 이를 바꾸는 것은 하나 혹은 그 이상의 다른 제품 기능에 영향을 미칠 수 있다.
• 만일 제품 기능 X를 만드는 작업이 이미 시작된 경우(위의 언급된 것 외에도 다른 낭비가 더 발생)
  • 제품 기능 X를 만들기 위해 작업했던 것들을 모두 버려야 함(제거하는데도 추가적인 낭비가 듬)
  • 제품 기능 X와 연관된 다른 기능에도 낭비가 생길 수 있음

Note: 직접적인 경제적 낭비와 함께 변화에 동반되는 팀의 잠재적인 동기와 신뢰의 하락도 간접적인 경제적 낭비에 영향을 끼친다. 제품 책임자가 목표를 바꾸지 않기로 약속을 한 후 이를 어기면 팀은 자연스럽게 사기가 떨어지게 되고, 이는 확실히 제품 백로그 항목을 완성하기 위해 성실히 일하고 싶은 마음에 영향을 준다. 또한 약속을 어기면 개발 팀이 제품 개발자가 약속을 지킬 것이라고 믿지 않게 되기 때문에 스크럼 팀 내의 신뢰를 해칠 수 있다.

실용적으로 생각하기

목표에 영향을 미치는 변화가 있으면 안된다는 규칙은 결국 규칙이지 법이 아니다. 스크럼 팀은 실용적이 되어야 한다.

만일 비즈니스 상황이 바뀌어서 스프린트 목표를 바꾸는 것이 타당해 보인다면 어떻게 해야 할까? 스프린트 기간 동안 경쟁사가 새로운 제품을 출시햇다고 해보자. 새 제품을 검토한 후, 우리가 하고 있는 일이 경제적으로 경쟁사가 한 일보다 후러씬 가치가 떨어지기 때문에 목표를 바꿔야 한다고 결론을 내렸다. 이를 무시하고 목표를 바꾸어서는 안된다 는 규칙에 따라 스프린트를 지속해야 할까? 그렇지는 않을 것이다.

만일 중요한 제품 시스템에 심각한 결함이 생겼다하더라도 기존 설정된 스프린트 목표를 중단하면 안되는가? 그렇지 않을 것이다.

결국 실용성이 ‘목표를 바꿀 만한 변화가 있어서는 안된다’는 규칙을 이긴다. 경제적이고 합리적인 방식으로 행동해야 한다. 스크럼 팀에 있는 모두가 이를 충분히 이해할 것이다. 만약 현재 스프린트에 변화가 있다면 앞서 설명한 경제적인 불이익을 경험하게 될 것이다. 하지만 만일 변화로 인한 경제적 대가가, 변화를 미룸으로써 오는 경제적 대가보다 후러씬 적다면 변화를 만드는 것이 더 현명한 비즈니스 결정이 될 것이다. 만일 변화가 있을때와 없을 때를 경제적으로 중요한 차이가 없다면 스프린트 목표에 변화가 있어서는 안된다.

Note: 필자의 경험에 따르면 팀의 사기와 신뢰는 제품 책임자가 진솔하고 경제적인 관점에서 팀원들과 변화의 필요성에 대해 논의할 때 팀원이 그 필요를 이해하고 받아들이면서 유지된다.

비정상적 종료

스프린트 목표가 가치가 없다면 스크럼 팀은 현재 스프린트를 계쏙 진행하는 것은 아무 의미 없다고 결정해 제품 책임자에게 스프린트를 비정상적으로 종료할 것을 권고할 수 있다.

스프린트 종료는 경제적으로 의미 있는 일이 발생했을 때, 에를 들어 경쟁사가 한 일이 우리의 스프린트를 가치 없게 만들거나 제품에 대한 자금 사정이 변했을 때 사용된다.

비록 제품 책임자들이 모든 각각의 스프린트를 취소할 수 있는 선택지를 남겨두기는 하지만 필자의 경험상으론 아주 드물다. 보통 스크럼 팀이 눈앞의 상황에 적응할 수 있는 덜 극단적인 방법들이 있다. 에를 들어 스프린트 기간이 1주일 정도 밖에 남아 있지 않을 수 있기 때문에 경제적으로 스프린트를 계속 진행하는 것이 끝내는 것보다 나을 수 있다. 그리고 많은 경우 스프린트를 종료하는 대신 계속 진행하는 것이 더 나을 수 있다. 그리고 많은 경우 스프린트를 종료하는 대신 중요한 제품 결함을 고칠 시간을 벌기 위해 제품 기능 하나를 포기하는 등 덜 극단적인 선택지를 고를 수 있다.

Note: 스프린트를 일찍 종료하는 것은 사기에 악영향을 끼칠 뿐만이 아니라 빠르고 유연한 일의 흐름에도 방해가 되고 앞에서 이야기한 지속적으로 같은 기간의 스프린트를 유지함으로써 얻는 많은 이익도 무효화시킨다는 사실을 깨다든 것이 중요하다. 스프린트를 종료시키는 것은 마지막 수단이 되어야 한다.

스프린트가 종료되면 팀은 다음 스프린트 길이를 정해야 한다.

여기에는 세 가지 명백한 선택지가 있다.

• 1)원래의 스프린트 길이를 고수한다. 이는 개발 기간 동안 스프린트 길이에 통일성을 유지시켜 준다는 장점이 있따. 만일 여러 개의 스크럼 팀이 하나의 제품을 개발하는데 협력하고 있다면, 다른 스크럼 팀과 스케쥴이 더 이상 맞지 않게 된다.
• 2)다음 스프린트를 원래 스프린트의 종료일까지 짧게 계획한다. 예를 들어, 스크럼 팀이 2주짜리 스프린트를 첫 주에 종료시켰다면, 그 다음 스프린트는 1주일 길이로 해서 원래 스프린트 리듬을 되찾는다.
• 3)다음 스프린트를 현재 남아 있는 스프린트 시간과 다음 꽉 찬 스프린트 시간을 합쳐 일반 스프린트보다 더 크게 만든다. 앞에서 이야기한 예에서는 다음 스프린트를 3주 길이로 만들어 원래 스프린트 리듬을 되찾는다.

만일 여러 팀이 한 가지 개발에 같이 일하고 있다면 2, 3번 선택지가 더 바람직할 것이다. 어떤 경우건 어느 선택지가 가장 최선일지는 각 팀이 처한 특정한 상황을 고려해야 한다.

완료의 정의

스프린트가 끝나면 “잠재적으로 출시 가능한 제품 증분” 이 나온다. 잠재적으로 출시 가능하다는 것은 스프린트에서 만들어진 것이 실제로 완료되었다는 것을 말한다. 또한 사업부에서 출시를 원할 경우, 스프린트 결과물을 출시할 수 있게 되기 전에 완성해야 할 질적으로 중요한 일(중요한 테스트나 통합과 같은)이 모두 마무리되었다는 뜻이다. 즉 ‘필요한 것이 모두 마무리되어 출시할 수 있다’는 자신감의 상태를 말한다. 만들어진 제품이 잠재적으로 출시 가능한가를 결정하기 위해 스크럼 팀은 잘 규정되고 합의된 완료의 정의를 가지고 있어야 한다.

완료의 정의는 무엇인가?

개념적으로 완료의 정의(definition of done)는 결과물이 잠재적으로 출시 가능하다고 공표하기 전에 팀이 성공적으로 완수해야 한다고 기대되는 일의 체크리스트이다.

물론 자세한 체크리스트 항목은 몇 가지 변수에 따라 다를 것이다.

• 만들고 있는 제품의 본질
• 제품을 만드는데 사용되는 기술
• 제품을 만드는 조직
• 가능성에 영향을 미치는 현존하는 장애물

대개 아주 최소한의 완료의 정의는 설계, 구축, 통합 테스트와 문서화되고 입증된 고객 가치를 전달하는 완성된 제품 기능 일부를 포함해야 한다. 하지만 유용한 체크리스트를 만들기 위해선 이 큰 단위의 항목들을 더 자세히 다듬을 필요가 있따. 예를 들어, 테스트 는 유닛 테스트, 통합 테스트, 시스템 테스트, 플랫폼 테스트 등등 여러 가지 형태의 테스트를 떠올릴 수 있을 것이다.

만약 매 스프린트마다 중요한 형태의 테스트(예를 들어, 성능 테스트)를 하지 않는다면 언젠가는 이를 해야 한다는 것을 명심하자. 성능 테스트가 완료에 중요한 상황에서 나중에 하다 하는 스프린트를 별도로 하게된다면 사실상 매 스프린트가 끝날때마다 나오는 결과물은 잠재적으로 출시 가능한 진짜 제품 증분이 될 수 없다. 더 심각한 것은 실제로 성능 테스틀 ㄹ나중에 했는데 계획대로 되지 않는다면, 중요한 문제를 매우 늦게 발견할 뿐만 아니라 성능 테스트를 그 문제를 고치기 위해 더 많은 시간과 돈이 들어갈 것이라는 점이다.

어떨 대는 테스트가 스프린트 기간보다 더 오래 걸릴 수 도 있다. 만일 이러한 사태가 개발팀이 수동 테스트할 일거리를 쌓아 두어 발생한 것이라면 팀은 테스트를 자동화해 스프린트 내에 끝낼 수 있도록 해야 한다.

만일 스프린트 마지막 날에 심각한 결함이 남아 있다면 어떻게 되는가. 제품 백로그 항목을 완료한 것으로 간주하는가? 아니다. 완료되지 않은 것이다! 또한 규칙상 스프린트를 계획된 타임박스를 넘어 연장하지 않기 때문에 현재 스프린트에 있는 문제를 고치기 위해 스플니트를 하루 이틀 연장하지 않는다. 대신, 계획된 스프린트 종료일에 문제를 고치기 위해 스프린트를 하루 이틀 연장하지 않는다. 대신, 계획된 스프린트 종료일에 현재 스프린트에서 완성되지 않은 제품 백로그 아이템을 가져다 현재 백로그에 있는 다른 항목을 바탕으로 알맞은 순서에 다시 넣으면 된다. 그 후 미완성된 항목은 언제가 앞으로 있을 스프린트에서 마무리된다.

스크럼 팀은 만든 제품이 상위 수준의 품질을 갖고 있고 출시 가능하다는 높은 자신감을 제공하는 탄탄한 완료의 정의를 가지고 있어야 한다. 그렇지 않으면 원하는 시기에 제품을 출시할 기회를 놓치고 기술적 채무(technical dept)가 쌓일 수 있다.(8장에서 논의)

완료의 정의는 시간이 지남에 따라 진화할 수 있다

우리는 완료의 정의를 스프린트 끝에 일의 상태 정의로 생각할 수 있다. 훌륭한 성과를 낸 많은 팀의 최종 목표는 잠재적으로 출시 가능한 결과물을 만드는 것이다.

하지만 많은 팀들이 완료의 의미를 최종적으로 모든 제품 기능이 완성되고 출시된 최종 상태로 말하지 않는다. 이것이 최종 목표라고 해도 개발 초기에 이런 상태에 돌달하지 못하게 하는 실직적인 장애물이 있을 수 있다. 그 결과 최종 상태를 더 작은 것에서 시작했다가 시간이 지나고 장애물이 제거되면서 완료의 정의가 진화할 수 있다.

예를 들어, 의료 정보 시스템을 만드는 회사에서 초기에 의학 테스트를 할 수 없는 상황이였기에 의학 테스트를 처음에는 완료 정의에 포함시키진 않았다. 대신 각 출시 마지막 단계에서 의학 테스트 스프린트를 포함시켰다.

해당 회사 부사장은 근처 대학의 의학 실험실을 이용할 수 있게 함으로써 장애물을 없애겠다고 말했고, 제품 책임자는 매 스프린트마다 더 적은 수의 제품 기능을 완성하는 대신 만들어진 모든 제품 기능들이 의학 검사를 마치게 된다는 것은 합리적이라는 것에 동의했다. 이 시점에서 팀은 완료의 정의를 “잠재적으로 출시 가능한” 제품으로 진화시키는 성과를 거두었고, 관련자 모두에게 매 스플니트마다 완성된 제품에 대해 더 높은 수준의 자신감을 주었다.

이처럼 완료의 정의는 시간이 지남에 따라 진화할 수 있음을 인지해야 한다.

완료의 정의와 인수 조건

완료의 정의는 스프린트 기간 동안 개발되는 제품 증분에 적용되며 제품 증분은 일련의 제품 백로그 항목으로 구성되어 있다.

5장의 내용에서 다루겠지만 각 제품 백로그 항목은 스프린트로 들어올때 제품 책임자가 명시한 일련의 충족조건을 가지고 있어야 한다. 이 인수 조건은 최종적으로 제품 책임자에 의해 백로그 항목이 원하던 대로 작동하는지 확인하는 인수테스트에서 인증된다.

예를 들어, 제품 백로그 목록이 “고객이 신용카드 결제가 가능하다” 이면 충족 조건은 “아멕스, 비자, 마스터 카드로 결제가 가능하다” 가 될 수 있다. 따라서 각 제품 백로그 항목은 각기 적합한 일련의 인수 조건을 가질 것이다. 이 기준들은 ‘완료의 정의(definition-of-done) 체크리스트’에 의해 정해진 ‘완료 기준’에 추가되어 해당 항목에만 적용되고, 인수 조건이 완료의 정의를 대신하지 않는다.

제품 백로그 항목은 특정 항목에만 해당하는 인수 조건(예를 들어, “모든 신용카드 결제가 가능하다”)과 스프린트 수준의 완료의 정의(예를 들어, “제품을 서버에 올려 동작하게 한다”) 항목을 모두 충족시켜야 완료된 것으로 간주된다.

만일 인수 조건을 통과한 제품 백로그 항목을 완료라 부르는 것이 헷갈린다면 완성(completed) 혹은 이수됨(accepted) 이라 불러도 된다.

완료의 완전 종료

어떤 팀들은 완료와 완전 종료의 개념을 다르게 사용한다. 왠지 완전 종료는 완료보다 더 완료가 된 것으로 간주된다. 팀은 이 두 가지 다른 개념을 사용할 필욘 없다. 하지만 오해가 생길 순 있다.

예를 들어, 누군가는 “내가 할 준비가 된 만큼의 일을 끝냈다” 라는 의미로 완료의 정의를 내릴 수 있고, 누군가는 전체 일의 종료로 내릴 수 있다. 따라서 이 두 가지 용어에 대한 정의는 팀 내의 통일이 필요하다.

완료라는 말을 고객을 만족시키는데 필요한 일을 모두 마쳤다는 의미로만 사용하는 팀은 두 가지 단어를 사용하지 않아도 된다. 이들에게 종료는 완전 종료를 의미한다!

마무리

위의 내용에서는 스크럼에서 스프린트의 중요한 역할을 강조했다. 스프린트는 스크럼에 다른 활동과 산출물 대부분이 자리를 잡는 중요한 뼈대 를 제공한다. 위의 내용을 정리하면 아래와 같다.

• 스프린트는 짧고 시간 제한이 있으며 그 길이가 일정하다.
• 스프린트는 보통 스프린트의 목표로 정의되며 합당한 경제적인 이유 없이 목표가 바뀌어선 안 된다.
• 스프린트는 잠재적으로 출시 가능한 제품 증분을 생산해야 하고 이는 서로 합의된 완료의 정의에 맞게 완성되어야 한다.

다음 단원(Chapter-5)에서는 요구 사항과 이를 표현하는데 사용되는 일반적인 방법인 사용자 스토리 등 스프린트에 입력되는 것들에 초점을 맞춘다.