스크럼(scrum)은 [그림 2-25]처럼 원래 럭비 경기에서 사용되던 용어이다. 럭비에는 스크럼과 라인 아웃(line out)이라는 두 가지 기본 대형이 있다. 이 중 스크럼은 반칙으로 인해 경기가 중단됐을 때 쓰는 대형이다. 반칙이 행해진 장소에 되도록 가까운 곳에서, 양 팀의 7∼8명이 서로 밀집하여 팔을 꼭 끼고 하나의 집단을 형성해 상대 팀을 앞으로 밀치는 대형을 말한다. 이렇게 럭비 경기에서 쓰이던 용어가 소프트웨어 개발 프로세스에서 사용되는 것은 팀이라는 단어가 주는 의미를 개발 팀에 적용하여 효율적인 성과를 얻기 위해서이다.
그림 2-25 럭비 경기의 스크럼 대형
스크럼 개발 프로세스는 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론으로, 경험적 관리 기법 중 하나이다. 지금까지 배운 다른 소프트웨어 개발 방법들처럼 구체적인 프로세스를 명확하게 제시하지 않는다. 어떻게 보면 개발 팀(조직)을 운영하는 효율적인 운영 방식(지침)이라고 생각할 수 있다.
1. 스크럼 방식의 진행 과정
스크럼 방식에서 알아야 할 용어를 예와 함께 알아본 후 스크럼 방식의 진행 절차를 살펴보자.
그림 2-26 스크럼 방식의 진행 과정
■ 제품 기능 목록(product backlog) 작성
제품 기능 목록은 일반적인 개발 방법의 요구 사항에서 기능 목록과 같다고 보면 이해하기 쉽다. 즉 사용자가 요구하는 제품의 기능 목록을 말하며, 제품에 관한 모든 요구 사항에 대해 우선순위가 정해져 있다. 이 우선순위는 고객 측 대표인 제품 책임자(product owner)가 결정한다. 즉 제품 책임자가 요구 사항 목록에 우선순위를 매겨 제품 기능 목록을 작성한다.
따라서 제품 기능 목록은 우선순위가 매겨진, 사용자의 요구 사항 목록이라고 할 수 있다. 또 사용자와 계속 미팅하면서 목록이 완성된다. 한 번 결정된 제품 기능 목록은 확정된 것이 아니고 개발 중이라도 수정이 가능하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는다.
소프트웨어 공학을 주제로 집필하는 경우를 예로 들어보자. [표 2-3]은 소프트웨어 공학 원고에서 제품 기능 목록의 예이다. 여기서 제품 기능 목록은 원고를 써내려갈 때 우선순위(반드시 1장, 2장, ···, 10장의 순서는 아니다. 저자가 쓰고 싶은 순서를 말한다)가 결정된 소프트웨어 공학의 원고 목록을 말한다.
표 2-3 제품 기능 목록의 예 : 소프트웨어 공학 원고 목록
순위 | 요구 사항 목록 | 요구 사항 내역 | 작업 소요 기간 | 작업 월 |
1 | 품질(9장) | 프로세스 품질과 제품 품질에 대해 기술한다. | 30일 | 2015. 12. |
2 | 테스트(8장) | 테스트의 종류를 분류하고 단계별로 설명한다. | 40일 | 2016. 1. |
3 | 요구 분석(4장) | 사용자 요구 사항을 정의하는 방법에 대해 기술한다. | 20일 | 2016. 2. |
··· | ······ | ······ | 30일 | ······ |
9 | 소프트웨어 개발 프로세스(2장) | 개발 프로세스의 종류에 대해 기술한다. | 20일 | 2016. 4. |
10 | 소프트웨어 공학 소개(1장) | 소프트웨어 공학의 일반적인 내용을 기술한다. | 10일 | 2016. 5. |
실제 원고를 쓸 때는 이 제품 기능 목록(원고의 각 장)을 10~40일 분량의 스프린트 구현 목록(sprint backlog) 단위로 잘라서 스프린트(sprint)를 진행하여 원고를 쓴다. 그런데 어떤 장(chapter)은 40일이 걸릴 수도 있고, 어떤 장은 20일이면 끝날 수도 있다. 따라서 스프린트 기간이 반드시 같을 필요는 없다.
■ 사용자 스토리(user story) 작성
사용자 스토리는 [그림 2-27]처럼 메모지 한 장에 쓰인 사용자 요구 사항이다. 구현할 기능이 사용자 관점에서 사용자 언어로 작성되어 있다. 사용자 스토리는 다음과 같이 설명할 수 있다.
- 제품 기능 목록에 정의된 사용자 관점에서의 기능임.
- 사용자에게 가치를 평가 받을 수 있도록 기능을 표현한 것임.
- 보통 작은 인덱스 카드를 사용해 필요한 것만 짧게 표현함.
- 고객의 요구 사항을 문서화한 것이라기보다는 표현했다고 보는 것이 적합함.
- 유스케이스보다 작은 규모임.
- 사용자 스토리는 반복을 마치면 사라지지만 유스케이스는 개발 기간 동안 지속됨.
- 사용자와 충분히 대화하여 세부 사항을 구체적으로 서술함.
- 테스트를 통해 스토리가 완료된 것을 확인함.
- 다른 스토리에 종속되지 않고 독립적이며, 협상 가능해야 함.
- 추정 및 측정 가능해야 함.
- 사용자 스토리는 스토리가 큰 것보다는 많은 것이 좋음.
- 테스트가 가능해야 좋은 사용자 스토리임.
그림 2-27 사용자 스토리
■ 스토리 포인트(story point) 산정
작성된 사용자 스토리는 [그림 2-27]처럼 스토리 보드에 나열되어 있다. 각각의 사용자 스토리는 우선순위가 정해져야 하고, 하나의 사용자 스토리에 대한 업무량을 파악하여 수행하는 데 걸리는 개발 기간도 산정해야 한다. 이때 상대적인 개발 시간을 스토리 포인트라고 한다.
그런데 누가 사용자 스토리를 추출하고 스토리 포인트를 산정하는 걸까? 프로젝트에 참여하는 구성원이 다 함께 진행하면 좋지만, 대체로 개발자들이 주도적인 역할을 한다. 또 우선순위를 매기기 위한 사용자 스토리의 중요도를 판단하는 일은 주로 업무 분석가가 한다.
■ 스프린트(sprint)
스프린트의 사전적 의미는 '전력 질주'이다. [그림 2-28]처럼 달리기 경기에서 단거리 달리기를 스프린트 레이스(sprint race)라고 한다. 사전적 의미와 단거리 달리기에서 느껴지는 것처럼 스프린트는 순발력이 좋고 출발 속도가 빠른 것이다.
이제 스프린트가 소프트웨어 개발에서는 어떤 의미로 사용되는지 짐작할 수 있을 것이다. 전력 질주가 마라톤 같은 장거리 달리기가 아닌 단거리 달리기에서 가능한 것처럼, 스프린트는 작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧다. 결국 작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다는 뜻으로 보면 된다.
그림 2-28 단거리 달리기 같은 스프린트
소프트웨어 공학 원고를 1년 동안 10일 또는 40일에 한 장씩 총 10장을 써서 완성하는 것으로 계획을 세웠다면, 10~40일 단위가 반복되어 원고가 완성될 것이다. 여기서 10~40일 단위가 반복 주기이고, 스크럼에서는 이것(10~40일 단위)을 스프린트라고 한다.
스크럼에서 반복 주기의 기간은 스프린트 계획 회의를 통해 결정하는데, 보통은 2~4주 정도로 수행한다. 요구 사항이 안정적이고, 개발 팀이 애자일 방법에 대해 지식과 경험이 풍부하다면 2주 정도의 짧은 기간을 스프린트 주기로 한다. 그러나 요구 사항의 변화가 많고, 개발 팀의 역량이 낮다면 4주 정도의 기간을 스프린트 주기로 한다.
스프린트 주기가 결정되면, 개발 팀은 팀원의 역량에 맞게 스프린트에 배정된 작업을 중간에 멈추는 일이 없이 전력 질주해서 끝내야 한다. 그러려면 결정된 스프린트의 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 그 누구도 팀원들의 동의 없이 바꿀 수 없다는 원칙을 지켜야 한다.
이때 스크럼 마스터의 중요한 역할은 외부로부터 오는 개발 방해 요소를 차단하는 것이다. 이렇게 해서 하나의 스프린트에 대한 개발이 완료되면 사용자에게 시연해 보이고 사용자는 피드백을 제공해야 한다. 그런데 개발이 완료되어 시연까지 하면 좋지만, 계획된 일정 안에 개발을 마치지 못할 수도 있다. 그렇다 해도 하나의 스프린트는 개발 완료 여부와 관계없이 정해진 일정이 지나면 끝난다.
[표 2-4]는 소프트웨어 공학을 집필하는 예에서 제품 기능 목록 중 우선순위가 가장 높은 품질 항목에 대한 세부 작업 항목과 날짜별 작업 시간, 총 남은 시간을 나타낸다. 표에서는 세부 항목을 하루에 하나씩 작업한 것으로 나타냈다. 그러나 실제 프로젝트에서는 세부 항목들이 여러 개발자에 의해 병행으로 수행되고, 작업도 0.5일이 걸리는 등 계획된 만큼 하지 못하는 경우가 빈번하다.
표 2-4 스프린트 구현 목록의 진척 관리
제품 기능 목록 | 세부 작업 항목(일) | 1일 | 2일 | 3일 | 4일 | 5일 | 6일 | 7일 | 8일 | 9일 | 10일 | 11일 | 12일 | 13일 | 14일 | 15일 | 16일 | 17일 |
품질(9장) | ISO/IEC 9126(5일) | 1 | 1 | 1 | 1 | 1 | ||||||||||||
ㅤ | ISO/IEC 14598(4일) | 1 | 1 | 1 | 1 | |||||||||||||
ㅤ | ISO/IEC 12119(3일) | 1 | 1 | 1 | ||||||||||||||
ㅤ | CMMI(5일) | 1 | 1 | 1 | 1 | 1 | ||||||||||||
총 남은 시간 | ㅤ | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
스크럼의 한 주기가 끝나면 '실행 가능한 제품(shippable product)'이 만들어진다. 이 제품을 통해 목표가 완료되었는지 확인할 수 있다. 그리고 제품의 완성도를 단순 기능 구현 정도로 할 것인지, 버그 하나 없이 완벽할 정도의 높은 수준으로 할 것인지는 회의를 통해서 결정한다.
■ 스프린트 구현 목록(sprint backlog)
제품 기능 목록이 사용자가 원하는 우선순위가 부여된 제품의 기능 목록이라면, 스프린트 구현 목록은 각각의 스프린트 주기에서 개발할 작업 목록을 말한다. 작업 목록에는 세부적으로 어떤 것을 구현해야 하는지에 대한 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 [표 2-5]처럼 작성한다. 이와 같은 자료를 기반으로 스프린트를 개발하는 데 걸리는 일정을 계산할 수 있고, 필요한 자원도 확보하여 최종적으로는 개발이 어떻게 진행되고 있는지 진척 상황을 파악할 수 있다.
표 2-5 스프린트 구현 목록의 예
작업 목록 | 세부 작업 항목 | 예상 작업 시간 | 작업자 |
품질 | 제품 품질의 ISO/IEC 9126에 대해 기술한다. | 5일 | |
ㅤ | 제품 품질의 ISO/IEC 14598에 대해 기술한다. | 4일 | |
ㅤ | 제품 품질의 ISO/IEC 12119에 대해 기술한다. | 3일 | |
ㅤ | 프로세스 품질의 CMMI에 대해 기술한다. | 5일 | |
테스트 | 블랙박스 테스트에 대해 기술한다. | 4일 | |
ㅤ | 화이트박스 테스트에 대해 기술한다. | 4일 |
스프린트 구현 목록은 스프린트 계획 회의에서 결정하며, 이 작업 목록 하나하나가 개발 완료되면 스프린트 주기는 완성된다.
■ 소멸 차트(burndown chart)
일반적으로 대부분의 차트가 시간이 지남에 따라 증가되는 모습을 보이는 반면, 소멸 차트는 시간이 지남에 따라 소멸되고 남은 것을 표현한다. 소멸 차트는 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량으로 나타낸다. [그림 2-29]처럼 가로축, 세로축, 계획 그래프, 실제 그래프로 구성되어 있다.
그림 2-29 소멸 차트
- 가로축 : 시간 축으로 스프린트 반복 주기 날짜 수
- 세로축 : 완료된 작업의 추정 일수(스토리 포인트로 표현)
- 계획 그래프 : 처음 계획을 세웠을 때 날짜별로 남은 작업량(점선으로 표시)
- 실제 그래프 : 작업을 수행하면서 날짜별로 실제 남은 작업량(실선으로 표시)
소멸 차트는 처음 계획된 작업 소진 그래프를 그려놓고, 시간이 지남에 따라 실제로 얼마나 작업량이 줄어드는지 비교할 수 있도록 개발이 완료되기까지 남은 작업량을 보여준다. 이때 각 반복 구간별로 남은 작업량을 스토리 포인트로 나타낸다.
소멸 차트를 통해 계획 대비 작업량이 실제 얼마나 줄어들고 있는지를 정량적으로 알 수 있고, 그래프의 기울기를 보면 작업 수행 속도를 알 수 있다. 즉 그래프의 기울기가 급하면 그만큼 작업이 빠르게 진행된 것이고, 기울기가 완만하면 진행 속도가 느리다고 볼 수 있다. 그리고 같은 날짜에서 현재 남은 작업량의 그래프가 계획된 작업량의 그래프보다 위에 놓여 있으면 계획 대비 늦게 진행되는 것이고, 아래에 놓여 있으면 그만큼 남은 작업량이 적기 때문에 계획보다 더 빨리 진행되었다는 것을 알 수 있다.
■ 스프린트 계획 회의(sprint planning meeting)
스프린트가 무엇인지 알았다면, 이제 스프린트를 구현하기 위해 사전에 하는 일을 알아보도록 하자. 그중 하나가 스프린트에 대한 계획을 세우는 일이다. 스프린트 계획은 스프린트 계획 회의를 통해 세운다.
스프린트 계획은 각 스프린트에 대한 목표를 세우는 일과 제품 기능 목록에서 어떤 항목을 스프린트에서 진행할지 선택하는 것이다. 그리고 선택된 각 항목에 대해 개발자를 배정하고 세부적인 작업 단위로 계획을 수립하는 것이다.
스프린트 계획을 세우기 위한 계획 회의는 크게 다음 두 가지로 나눌 수 있다.
- 전체적인 스프린트 계획 회의 : 스프린트 계획 회의 시작 단계에서는 사용자의 대변인 격인 제품 책임자를 통해 사용자가 원하는 것이 무엇인지를 파악하는 데 중점을 둔다. 이를 위해 스크럼 마스터는 제품 기능 목록을 검토하면서 어떤 항목을 가장 높은 순위로 놓았는지에 관심을 갖고, 그 배경과 목표에 대해 팀원들과 토의하며 제품 책임자의 의도를 파악한다.
- 세부적인 스프린트 계획 회의 : 전체적인 스프린트 계획 회의에서 스크럼 마스터를 중심으로 팀원들과 전체적인 논의를 하였다면, 세부적인 계획 회의에서는 우선순위가 높은 항목을 어떻게 구현할 것인지 구체적인 작업 계획을 세운다. 먼저 우선순위가 매겨진 사용자 요구 사항 목록인 제품 기능 목록에서 개발 항목을 결정하고 스프린트 구현 목록을 작성한다. 또 팀원들은 정해진 작업을 수행하는 데 소요되는 시간을 추정한다.
■ 일일 스크럼 회의(daily scrum meeting)
일일 스크럼 회의는 스프린트 기간에 하는 회의로 다음과 같은 특징이 있다.
- 매일 한다.
- 서서 한다.
- 약속된 시간에 한다.
- 짧게(15분 정도) 한다.
- 진행 상황만 점검한다.
- 스프린트 작업 목록을 잘 개발하고 있는지 확인한다.
- 모든 팀원이 참석한다.
- 한 사람씩 어제 한 일을 얘기한다.
(예) 소프트웨어 공학 원고 작성에서 품질 항목의 'ISO 9126'를 작성함.
- 한 사람씩 오늘 할 일을 얘기한다.
(예) 소프트웨어 공학 원고 작성에서 품질 항목의 'ISO 14598'를 작성할 예정임.
- 한 사람씩 문제점 및 어려운 점 정도만 얘기한다.
(예) 문제점 : 준비된 자료 부족, 어려운 점 : 예제 만들기
- 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트한다.
- 개별 팀원에 대한 진척 상태를 확인한다.
- 그날의 남은 작업량을 소멸 차트에 표시한다.
일일 스크럼 회의에서 스크럼 마스터의 역할은 다음과 같다.
- 팀원들이 개발하는 데 방해되는 요소를 찾아 문제를 해결한다.
- 개발자 개개인이 수행하고 있는 일의 진행 상황을 확인하다.
- 소멸 차트에 그날의 남은 작업량을 표시한다.
■ 스프린트 현황판(task board)
개발 팀의 개발 현황(진척도, 남은 작업, 진행 속도)을 나타낸다.
그림 2-30 스프린트 현황판의 예
■ 최종 제품(finished work)
모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품이 완성된다.
■ 스프린트 검토 회의(sprint review)
스프린트 검토 회의에서는 하나의 스프린트 반복 주기(2~4주)가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토한다. 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하고, 전체 흐름을 확인하여 비즈니스 가치를 점검하는 데 중점을 둔다.
스크럼 팀은 스프린트 동안 작업한 결과를 참석자(고객 포함)들에게 시연하고 요구 사항에 얼마나 부합하는지 검토한다. 그리고 개선할 점 등에 관해 피드백을 받는다. 이때, 스크럼 마스터는 스프린트 동안 잘된 점, 아쉬운 점, 개선할 사항 등을 찾기 위한 회고를 진행할 수 있다. 검토는 가능한 한 4시간 안에 마친다.
■ 스프린트 회고(sprint retrospective)
회고는 지나간 일을 돌이켜 생각해보는 것이다. 그러므로 스프린트 회고는 그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아보고, 개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토하는 것이다. 이때 팀의 단점을 찾기보다는 강점을 찾아 더 극대화하는 데 주안점을 둔다. 또한 문제점에 대한 해결 방안을 찾는 회의가 아니므로 문제점을 확인하고 기록하는 정도로만 진행한다. 그리고 추정 속도와 실제 속도를 비교해보고, 차이가 크면 그 이유를 분석해본다. 그러나 프로세스 품질은 측정하지 않는다.
■ 배포 목록(release backlog)
배포(release)는 사용자에게 시스템 일부를 제공하는 것이다. 그리고 배포 목록은 제품 기능 목록의 항목 중에서 이번 배포 본에 포함하기로 결정한 항목을 말한다. 따라서 배포 목록을 작성하면 이번 배포 본의 개발 범위와 일정을 수립할 수 있다. 또 사용자에게 전달되는 배포 본의 기능 내역과 시기, 스프린트 주기, 배포 일정을 결정하게 된다.
예를 들어, 출판사에 소프트웨어 공학 원고를 장(chapter)별로 넘기기로 했다고 가정해보자. 1파트는 1~3장 정도로 간주한다. 여기서 1파트를 배포 본으로 생각하면 된다.
표 2-6 배포 목록
장 | 내역 | 작업 기간 | 스프린트 주기 |
1장 | 소프트웨어 공학의 개요 | 10일 | 스프린트 1 |
2장 | 소프트웨어 개발 프로세스 | 20일 | 스프린트 2 |
3장 | 계획 | 20일 | 스프린트 3 |
총 남은 시간 | ㅤ | 100일 | |
배포 스프린트 | ㅤ | ㅤ | 총 3스프린트 |
배포 날짜 | ㅤ | ㅤ | 2016년 8월 30일 |
스크럼 방식 진행 절차를 단계별로 정리하면 [표 2-7]과 같다.
표 2-7 스크럼 방식의 진행 절차
단계 | 수행 목록 | 내용 |
1 | 제품 기능 목록 작성 | • 요구 사항 목록에 우선순위를 매겨 제품 기능 목록 작성 |
2 | 스프린트 계획 회의 | • 스프린트 구현 목록 작성
• 스프린트 개발 시간 추정 |
3 | 스프린트 수행 | • 스프린트 개발
• 일일 스크럼 회의
• 스프린트 현황판 변경
• 소멸 차트 표시 |
4 | 스프린트 개발 완료 | • 실행 가능한 최종 제품 생산 |
5 | 스프린트 완료 후 | • 스프린트 검토 회의
• 스프린트 회고
• 두 번째 스프린트 계획 회의 |
스크럼 방식의 진행 절차에서 제품 책임자나 스크럼 마스터의 역할이 각 단계에서 설명되고 있지만 정리하면 [표 2-8]과 같다.
표 2-8 제품 책임자, 스크럼 마스터, 스크럼 팀의 역할
담당자 | 역할 |
제품 책임자(product owner) | • 제품 기능 목록을 만듦.
• 비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목을 추가함.
• 스프린트 계획 수립 시까지만 역할을 수행하고, 스프린트가 시작되면 팀 운영에 관여하지 않음. |
스크럼 마스터(scrum master) | • 제품 책임자를 돕는 조력자
• 업무를 배분만 하고, 일은 강요하지는 않음.
• 스크럼 팀이 스스로 조직하고 관리하도록 지원함.
• 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원함.
• 개발 과정에 방해될 만한 요소를 찾아 제거함. |
스크럼 팀(scrum team) | • 팀원은 보통 5~9명으로 구성되며, 사용자 요구 사항을 사용자 스토리로 도출하고 이를 구현함.
• 기능을 작업 단위로 나누고, 일정이나 속도를 추정해서 제품 책임자에게 알려줌.
• 하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연함.
• 매일 스크럼 회의에 참여하여 진척 상황을 점검함. |
2. 스크럼 방식의 장점과 단점
스크럼의 장점은 다음과 같다.
- 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있다.
- 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능하다.
- 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성된다.
- 다른 개발 방법론들에 비해 단순하고 실천 지향적이다.
- 스크럼 마스터는 개발 팀원들이 목표 달성에 집중할 수 있도록 팀의 문제를 해결한다.
- 프로젝트의 진행 현황을 볼 수 있어, 신속하게 목표와 결과 추정이 가능하다.
- 프로젝트의 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있다.
스크럼의 단점은 다음과 같다.
- 추가 작업 시간 필요 : 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 한다. 이 작업이 많아지면 그만큼의 작업 시간이 더 필요하다.
- 일일 스크럼 회의를 15분 안에 마쳐야 함 : 스크럼 방식에서는 일일 스크럼 회의를 15분 정도로 정해놓았다. 그러나 정확히 15분의 약속이 지켜질까? 일일 스크럼 회의의 특성은 꼭 필요한 것만 매우 짧은 시간에 간략히 회의하는 것이다. 그러나 때로는 회의가 길어져 작업 시작 시간이 늦어지고 그로 인해 작업하는 데 상당히 방해를 받을 수 있다.
- 투입 공수 불측정에 따른 효율성 평가 불가 : 투입 공수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 알기 어렵다.
- 프로세스 품질 평가 불가 : 스크럼은 프로젝트 관리에 무게 중심을 많이 둔 방법이다. 따라서 스프린트 수행 후 검토 회의를 하지만 프로세스 품질을 평가하지 않기 때문에 품질 관련 활동이 미약하고 따라서 품질의 정도를 알 수 없다.
출처: 애자일 개발 방법론, 스크럼 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 김치수)
