Scrum
Scrum은 Agile 원칙 및 가치를 기반으로 하여 프로젝트를 실행하기 위한 프레임워크입니다. Scrum을 사용하면 고객에게 중요한 가치를 보다 빠르게 제공하는 데 도움이 되는 일련의 작업을 정의할 수 있습니다. 이러한 작업을 통해 고객은 팀에서 작업을 진행하는 동안 이를 검토하고, 방향을 제시하고, 영향을 줄 수 있습니다. Scrum 방식은 프로젝트를 시작할 때 모든 것을 정의하려고 하지 않습니다. 대신 팀에서 작업을 진행할 때 스프린트라고도 하는 짧은 반복 주기로 작업하면서 계획을 세부적으로 조정합니다. Scrum의 기반이 되는 Agile 원칙 및 가치에 대한 자세한 내용은 Agile 원칙 및 값(Jeff Sutherland)를 참조하십시오.
MSF for Agile Software Development v5.0은 Scrum을 기반으로 합니다. 따라서 팀은 핵심 개발 작업에 통합된 도구를 사용하여 Scrum을 선택할 수 있습니다.
항목 내용
|
.png "Scrum") |
프로젝트 준비
프로젝트를 시작하기 전에 다음과 같은 작업을 수행합니다.
비즈니스 사례 수립
팀 구성
팀 인프라 구축
비즈니스 사례를 수립하려면 비즈니스 요구 사항과 근거를 식별하고, 비전을 정의하고, 자금을 마련합니다. Geoffrey Moore의 저서 "Crossing the Chasm"은 비전을 설정하는 데 유용한 안내서가 될 것입니다. 자세한 내용은 Crossing the Chasm 웹 리소스를 참조하십시오.
비즈니스 사례를 수립한 후에는 팀을 구성하고 Scrum 마스터 및 제품 소유자를 식별해야 합니다. 자세한 내용은 역할을 참조하십시오.
마지막으로 팀의 인프라를 구축해야 합니다. 예를 들어 Visual Studio Team Foundation Server와 Visual Studio ALM(Application Lifecycle Management)을 설치하고, 팀 프로젝트를 만들어 사용자 지정하고, 엔지니어링 방법을 설정합니다. 자세한 내용은 Visual Studio Application Lifecycle Management 시작, 팀 프로젝트 사용자 지정 및 엔지니어링 방법을 참조하십시오.
프로젝트 계획
Scrum 프로젝트에서 팀은 대부분의 시간을 일련의 스프린트로 제품을 개발하는 데 보냅니다. 그러나 팀은 먼저 상위 수준의 프로젝트 계획을 만들어야 합니다. 이 계획은 프로젝트를 진행하는 동안 팀에서 내릴 자세한 의사 결정에 도움이 되는 로드맵입니다. 계획은 팀에서 구현하는 동안 변경됩니다. 팀에서 프로젝트 계획을 끝냈을 때 제품 백로그와 필요한 경우 릴리스 계획을 만들 것입니다.
제품 백로그 작성
제품 백로그는 사용자가 필요로 하고 중요하게 평가하는 요소에 대해 기술하는 사용자 스토리 목록입니다. 사용자 스토리는 비즈니스 가치와 위험에 따라 우선 순위가 지정되고 팀은 스토리 점수라는 추상적 단위로 사용자 스토리를 예측합니다.
.png "사용자 스토리 만들기, 순위 지정 및 예측")
.gif "1단계") |
사용자 스토리 만들기: Mike Cohn은 그의 저서인 "User Stories Applied"에서 “사용자 스토리는 시스템이나 소프트웨어의 구매자 또는 사용자에게 유용한 기능을 기술합니다.”라고 사용자 스토리를 정의합니다. 사용자 스토리는 최종 사용자의 관점에서 작성됩니다. 예를 들면 다음과 같습니다. “재방문한 고객이므로 전에 주문했던 음식을 찾고 싶습니다.” 자세한 내용은 우수한 제품 백로그 만들기를 참조하십시오. |
.gif "2단계") |
사용자 스토리 우선 순위 지정: 제품 소유자는 고객이 중요하게 평가하는 요소를 이해하기 위해 고객과 함께 작업하고 위험 및 종속성을 이해하기 위해 팀과 함께 작업하여 제품 백로그에서 사용자 스토리의 우선 순위를 지정합니다. 제품 소유자는 팀에서 사용자 스토리를 구현하는 순서를 나타내기 위해 각 사용자 스토리에 순위를 할당하여 우선 순위를 지정합니다. 제품 소유자는 다양한 방법을 사용하여 사용자 스토리의 값을 분석하고 비교할 수 있습니다. 팀에서 우선 순위를 지정하는 유용한 방법이 이미 있으면 그 방법을 사용하십시오. Kano 고객 만족 모델 및 Karl Wiegers의 상대적 가중치와 같은 몇몇 우선 순위 지정 방법은 Agile 커뮤니티와 밀접하게 관련되어 있습니다. 상대적 가중치에 대한 자세한 내용은 First Things First: Prioritizing Requirements 웹 페이지를 참조하십시오. 비용 우선 순위 지정, 순 투자 가치, 투자 회수 기간 및 내부 수익률과 같은 기타 우선 순위 지정 방법은 Agile 커뮤니티 외부에서 잘 구성되어 있습니다. 이러한 방법도 Scrum 프로젝트에서 제품 백로그의 우선 순위를 지정하는 데 적합합니다. 자세한 내용은 Agile Estimation and Planning 웹 리소스에 언급된 책에서 "Part II: Estimating Size"를 참조하십시오. |
.gif "3단계") |
사용자 스토리 예측: 팀은 각 사용자 스토리를 스토리 점수 단위로 예측합니다. Mike Cohn은 그의 저서인 "Agile Estimation and Planning"에서 “스토리 점수는 사용자 스토리의 전체 크기, 작업의 기능 또는 기타 요소를 나타내기 위한 측정 단위입니다.”라고 스토리 점수를 정의합니다. 스토리 점수는 구체적인 시간으로 직접 변환되지 않는 상대적인 값입니다. 대신 스토리 점수를 사용하면 팀에서 사용자 스토리의 일반적인 크기를 수치화할 수 있습니다. 이러한 상대적 예측 방법은 정확도가 떨어지므로 쉽게 확인할 수 있으며 시간이 지날수록 좋아집니다. 스토리 점수로 예측하면 팀에서는 지금 사용자 스토리의 일반적인 크기를 제공하고 나중에 팀 멤버가 사용자 스토리를 구현할 때 작업 시간을 보다 자세하게 예측할 것입니다. |
팀의 속도 확인
팀에서 릴리스 계획을 만들고 각 스프린트를 계획하기 전에 팀의 속도를 확인해야 합니다. 팀의 속도는 스프린트에서 완료할 수 있는 스토리 점수의 수입니다.
지정된 기간 동안 팀에서 완료하는 사용자 스토리 수를 보여 주는 데이터를 수집하여 속도를 측정했으면 해당 데이터를 사용합니다. 이 데이터를 보면 팀의 속도를 잘 파악할 수 있습니다. 지금은 데이터가 없지만 Visual Studio ALM 및 MSF for Agile Software Development v5.0을 사용하여 프로젝트 실행을 시작하면 프로젝트가 진행되는 동안 해당 데이터가 수집됩니다. 자세한 내용은 모든 반복의 상태 보고서를 참조하십시오.
사용할 수 있는 기록 데이터가 없으면 팀은 첫 번째 스프린트에서 완료할 수 있는 스토리 점수의 수를 대략적으로 예측할 수 있습니다. 우선 순위 스택의 맨 위에서 예측된 사용자 스토리를 검토하고 스프린트에서 완료할 수 있는 스토리 수를 신속하게 평가합니다. 각 사용자 스토리의 스토리 점수를 추가하여 초기 예측값을 구합니다. 첫 번째 스프린트 후에 기록 데이터를 사용하여 팀의 속도를 확인할 수 있습니다. 처음 몇 번의 스프린트에서 팀이 일관성 있게 예측하는 방법을 익히는 동안 실제 변동을 예상해야 합니다. 여러 번의 스프린트가 진행되는 동안 팀 속도는 보다 안정적으로 측정됩니다. 팀의 측정된 속도가 안정적이면 릴리스 계획을 다시 평가합니다.
스프린트에서 완료할 사용자 스토리 수를 결정할 때 팀 속도의 예측 값을 사용하여 시작할 수는 있지만 이 예측 값이 팀 약속의 기본은 아닙니다. 팀의 약속은 사용자 스토리를 완료하는 데 필요한 작업에 대해 보다 자세한 예측을 기반으로 만들어집니다. 자세한 내용은 제품 계획 통합 문서를 참조하십시오.
릴리스 계획 설정
각 스프린트에서 팀은 제품에 대해 제공할 수 있는 일정 분량을 완료합니다. 팀에서 구현하는 사용자 스토리는 스프린트의 끝에 제공되도록 준비되어 있지만 실제로 제품을 릴리스하기에 충분한 비즈니스 가치를 제공하지는 않습니다. 다음과 같이 이러한 사용자 스토리를 반복에 할당하여 릴리스를 계획합니다.
고객에게 릴리스에 대한 충분한 비즈니스 가치를 제공하는 사용자 스토리 그룹을 식별합니다.
팀에서 이러한 사용자 스토리 그룹을 완료할 수 있을 것으로 예상하는 스프린트를 확인합니다.
팀에서 작업을 진행할 때 제품 백로그에 사용자 스토리가 추가되며 사용자 스토리를 제거할 수도 있습니다. 또한 일부 사용자 스토리의 우선 순위가 변경되며, 일부 사용자 스토리는 원래 예상한 것보다 일찍 또는 늦게 구현될 수 있습니다. 제품 소유자는 제품 주기 과정에서 릴리스 계획을 제품 백로그와 함께 유지 관리합니다.
자세한 내용은 제품 계획 통합 문서를 참조하십시오.
첫 번째 스프린트 준비
스프린트는 지정된 시간 동안 수행되는 개발의 반복 작업으로서 작업별로 대개 1주~4주가 지정되어 팀에서 제공할 수 있는 제품의 증분을 생성합니다. 팀에서 첫 번째 스프린트를 시작하기 전에 제품 소유자는 제품 백로그를 준비합니다. 첫 번째 스프린트에서 우선 순위가 높은 사용자 스토리는 팀에서 구현할 준비가 완료된 것입니다. 제품 소유자는 다음 작업을 수행하여 제품 백로그를 준비해야 합니다.
사용자 스토리를 보다 작은 스토리로 분류합니다.
팀에서 사용자 스토리를 작업으로 분류하는 데 필요한 사용자 스토리 관련 정보를 제공합니다.
제품 소유자는 사용자 스토리가 팀 전체 속도의 상당한 양을 나타내는 경우 해당 스토리가 너무 크다는 것을 알 것입니다. 예를 들어 팀의 속도가 스토리 점수 30점인 경우 스토리 점수가 15점인 사용자 스토리는 너무 커서 스프린트 계획 회의에 포함할 수 없습니다. 이런 경우 팀은 이 사용자 스토리를 완료하는 데만 스프린트의 반을 소비하게 됩니다.
또한 팀은 사용자 스토리를 작업 단위로 분류하고 이러한 작업을 예측할 수 있도록 해당 사용자 스토리에 대한 상세 정보를 요청할 것입니다. 예를 들어 팀에서 "고객이 식사 종류를 검색할 수 있도록 하고 싶습니다."라는 사용자 스토리를 검토할 때 다음과 같은 종류의 질문을 할 수 있습니다.
"자유 텍스트 검색이어야 합니까? 아니면 사용 가능한 종류 목록에서 선택할 수 있습니까?"
"검색과 일치하는 식사 종류를 제공하는 공급업체가 여러 개인 경우 결과를 어떤 방식으로 정렬할 것입니까?"
자세한 내용은 다음 스프린트 준비를 참조하십시오.
스프린트 계획
팀에서 제품 백로그를 개발하고 릴리스 계획을 설정했으면 스프린트에서 작업을 시작할 수 있습니다. 팀은 제품 백로그의 사용자 스토리 집합을 완료할 것을 약속하는 스프린트 계획 회의로 스프린트를 시작합니다. 해당 사용자 스토리 집합은 지원 작업과 함께 스프린트 백로그입니다. 자세한 내용은 제품 백로그와 스프린트 백로그 비교를 참조하십시오.
스프린트가 시작된 후에는 스프린트 백로그의 사용자 스토리가 변경되지 않습니다. 따라서 팀이 확신을 갖고 약속할 수 있도록 상세하게 계획을 세워야 합니다.
자세한 내용은 스프린트 계획 회의를 참조하십시오.
사용자 스토리 선택
팀은 스프린트에서 구현할 수 있는 사용자 스토리를 선택합니다. 이를 위해 우선 순위가 높고 스토리 점수가 예측 속도를 초과하지 않는 사용자 스토리를 식별합니다. 예를 들어 우선 순위가 가장 높은 네 개의 사용자 스토리가 8점, 3점, 7점, 6점 및 2점의 스토리 점수를 가질 수 있습니다. 팀에서 각 스프린트마다 25점의 스토리 점수를 가질 수 있는 경우 팀은 처음 네 개의 스토리를 스프린트 백로그에 포함할 수 있습니다.
자세한 내용은 반복 백로그 통합 문서를 참조하십시오.
작업 식별
팀은 사용자 스토리를 구현하는 데 필요한 작업을 결정하기 위해 각 사용자 스토리를 평가합니다. 팀에서는 사용자 스토리를 작업 단위로 분류하여 사용자 스토리에 대한 이해를 도움으로써 나중에 스프린트 단계에서 사용자 스토리를 확실하게 완료할 수 있도록 준비합니다.
.png "반복 백로그 워크시트")
Scrum 사용 경험이 많은 팀은 사용자 스토리를 작업 단위로 분류하지 않아도 약속할 수 있습니다.
작업 예측
작업이 식별된 후에는 팀에서 각 작업의 소요 시간을 예측합니다. 주로 계획 포커 방법을 사용하여 작업을 예측합니다. 이 방법을 사용하면 팀에서 필요 이상으로 정밀하게 예측하는 번거로움을 줄일 수 있습니다.
사용자 스토리에 대한 약속
팀에서는 모든 작업을 완료하는 데 작업 시간이 충분한지 확인하기 위해 반복 백로그 통합 문서를 사용합니다. 팀이 스프린트에서 사용할 수 있는 것보다 많은 작업이 스프린트에 포함되어 있으면 작업이 스프린트에 대한 팀의 용량 범위 내에 들어올 때까지 순위가 가장 낮은 사용자 스토리를 제거해야 합니다. 우선 순위가 낮은 작은 스토리를 스프린트에 맞지 않는 큰 스토리와 교환할 수 있습니다.
.png "용량 워크시트")
팀은 완료할 수 있다고 확인한 사용자 스토리를 완료할 것을 약속합니다. 이는 제품 소유자가 추가 작업을 적용하거나, 스프린트에서 구현되는 사용자 스토리의 우선 순위를 변경하지 않는다는 것을 조건으로 합니다.
스프린트 실행
스프린트 중에 팀은 스프린트 백로그의 사용자 스토리를 구현하기 위해 필요한 작업을 완료합니다. 팀은 진행률을 추적하고, 각 스프린트를 끝내기 전에 실행이 끝난 소프트웨어에 대해 팀의 기준 및 고객의 승인 기준에 충족되는지 확인할 수 있습니다.
사용자 스토리 완료
팀에서 스프린트를 계획한 후에는 스프린트 중에 완료할 것을 약속한 사용자 스토리 목록이 만들어집니다. 이러한 사용자 스토리는 작업으로 분류되어 있습니다. 스프린트가 시작되면 팀의 각 멤버가 작업에 서명합니다. 해당 작업을 완료한 후 팀 멤버는 상태를 업데이트하고 다른 작업에 서명합니다. 팀은 이런 식으로 전체 작업 목록에서 작업하여 스프린트 백로그의 사용자 스토리를 완료합니다. 팀 멤버는 코드를 체크 인할 때 어떤 작업이 완료되었는지 나타낼 수 있습니다. 자세한 내용은 변경 집합과 작업 항목 연결을 참조하십시오.
작업을 할당하고 작업 상태를 업데이트하는 방법에 대한 자세한 내용은 작업(Agile)을 참조하십시오.
Scrum 방법에서는 종속성을 인식하고 전문 지식을 공유하고 계획된 변경을 효율적으로 적용하기 위해 공식적인 프로세스보다 사용자들이 서로 대화를 나누는 것을 더 중요하게 생각합니다. 전날 완료한 작업, 당일에 완료할 작업, 영향을 줄 수 있거나 다른 팀 멤버의 도움이 필요한 문제 또는 장애 요소 등에 대한 세부적인 내용을 각 팀 멤버가 서로 공유하는 Scrum 회의를 매일 소집합니다. 자세한 내용은 매일 열리는 Scrum 회의를 참조하십시오.
Kent Beck은 그의 저서 "Extreme Programming Explained"에서 버그를 초기에 수정하는 것이 훨씬 더 쉽다는 것을 알려 줍니다. 이 사실을 고려하면 팀은 고객에게 무엇이 중요한지를 이해해야 합니다. 고객은 기능이 많은 것보다는 품질을 보다 중요하게 평가할 것입니다. 고객은 팀에 대한 작업 흐름을 제어하므로 제품 소유자는 이러한 종류의 정보를 알고 있어야 합니다.
Scrum 팀에서 생성하는 소프트웨어에는 오류가 없어야 합니다. 그러나 팀이 프로젝트를 진행하는 동안 버그가 발생할 가능성이 있습니다. 버그는 나중으로 미루는 것보다 발견되었을 때 수정하는 것이 보다 빠르고 쉽다는 것을 명심하고 버그를 처리합니다. 즉 버그를 발견하면 바로 수정합니다. 팀에서 버그를 발견한 날 바로 수정할 수 없으면 Visual Studio ALM에서 버그 작업 항목을 만들고 스프린트가 끝나기 전에 이를 수정해야 합니다.
자세한 내용은 버그(Agile)를 참조하십시오.
스프린트 진행률 추적
팀에서 스프린트 진행률을 추적하여 작업이 예상대로 완료되는지 그리고 승인 기준에 충족되는지 확인할 수 있습니다. Scrum 팀은 스프린트의 전체 진행률을 추적할 때 번다운(Burndown) 보고서를 가장 자주 사용합니다. MSF for Agile Software Development v5.0은 팀에서 스프린트 진행률을 추적할 때 사용할 수 있는 보고서 집합을 제공합니다.
번다운(Burndown) 및 진행 속도 보고서(Agile)
.png "번다운(Burndown) 보고서의 정상적인 버전")
팀에서 스프린트 계획 회의 중에 예측한 것보다 작업 완료 시간이 많이 필요하거나 적게 필요할 때가 종종 있습니다. 이런 종류의 변화는 일반적입니다. 팀에서 작업에 들인 실제 시간을 지정하여 이 정보를 기록할 수 있습니다.
스프린트가 진행되면 팀에서 처음에 예상하지 못했지만 사용자 스토리를 완료하는 데 필요한 작업을 식별할 수 있습니다. 이 경우 작업을 만들고 예측한 다음, 스프린트에 남은 시간 내에 팀에서 해당 작업을 완료할 수 있는지 여부를 확인합니다. 팀에서 작업을 완료할 수 있으면 스프린트를 계속합니다. 스프린트 내에 작업을 완료할 수 없으면 제품 소유자와 만나서 진행 방법을 논의합니다. 제품 소유자와 팀은 다음과 같은 변경 작업을 수행하여 문제를 해결할 수 있습니다.
해당 작업이 불필요한 것이 되도록 사용자 스토리에 대한 승인 기준을 축소합니다.
스프린트 백로그에서 사용자 스토리를 제거합니다.
스프린트를 취소합니다.
스프린트 완료
스프린트의 끝이 가까워지면 팀이 모든 사용자 스토리 또는 요구 사항을 완료하는지 확인합니다. 예를 들어 승인 테스트가 통과하는지 그리고 각 사용자 스토리가 팀에서 정의한 조건을 충족하는지 확인합니다. 완료의 의미에 대한 자세한 내용은 Mitch Lacey & Associates, Inc. 웹 페이지를 참조하십시오.
스프린트의 마지막 날에는 팀에서 완료한 사용자 스토리를 제품 소유자와 고객에게 보여 줍니다. 그러면 제품 소유자와 고객은 각 사용자 스토리의 승인 여부를 결정합니다. 자세한 내용은 스프린트 검토 회의를 참조하십시오.
고객 검토가 끝나면 팀에서 회고 회의를 소집합니다. 자세한 내용은 회고 회의를 참조하십시오.
프로젝트 추적
팀이 스프린트 작업을 통해 프로젝트를 일정 분량씩 전달하면 고객은 남아 있는 요구 사항을 보다 확실하게 이해할 수 있으며 비즈니스 환경의 변경 가능성을 고려해야 합니다. 이러한 변경을 이해하기 위해 제품 소유자는 고객과 함께 작업합니다. 제품 소유자는 제품 백로그 및 릴리스 계획을 유지 관리하여 이러한 변경을 반영하고, 각 스프린트를 시작할 때 필요한 요소가 팀에 있는지 확인합니다. 팀은 제품의 진행률을 전체적으로 추적하여 프로젝트 완료를 위해 정상적으로 진행되는지 확인합니다.
다음 스프린트 준비
제품 백로그의 새로 고침은 프로젝트의 전체 품질 및 완성도와 직접적인 관계가 있습니다. 백로그를 정기적으로 업데이트, 변경 및 재고하여 팀에서 스프린트를 시작할 때마다 바로 사용할 수 있도록 해야 합니다.
제품 소유자는 다음 작업을 수행하여 다음 스프린트를 위한 제품 백로그를 준비합니다.
고객이 변경을 요구하는 경우 사용자 스토리와 해당 우선 순위를 업데이트합니다.
다음 스프린트에서 구현할 사용자 스토리를 분류합니다.
.png "제품 백로그")
팀에서 스프린트를 완료하면 다른 사용자 스토리는 제품 백로그의 맨 위에 더 가까워집니다. 제품 소유자는 맨 위에 있는 이러한 스토리를 분석하고 세분하여 팀이 이후 스프린트에서 이를 구현할 수 있도록 해야 합니다. 자세한 내용은 이 항목 앞부분의 첫 번째 스프린트 준비를 참조하십시오. Mike Cohn은 이 프로세스에 대해 제품 백로그 아이스버그로 종종 얘기합니다. 팀이 기능 집합에 대한 작업을 하는 동안 아이스버그가 사라지고 새 작업이 나타나면서 점점 작아집니다. 이 과정에서는 추가적인 세부 사항이 필요한 시점에 필요한 정도만 나타납니다.
팀은 스프린트를 실행하고 있으므로 제품 소유자는 팀이 첫 번째 스프린트를 준비할 때와 같은 수준으로 제품 백로그 유지 관리 작업에 참여할 것을 기대할 수 없습니다. 제품 소유자가 스프린트 중단을 최소화하면서 제품 백로그를 준비할 수 있도록 하려면 스프린트 진행 과정 중에 제품 소유자와 팀이 제품 백로그에 대한 미해결 문제를 논의합니다.
릴리스 진행률 추적
스프린트 단위로 프로젝트가 진행됨에 따라 팀은 다음 릴리스에 대한 전체 진행률을 추적합니다. 또한 팀은 진행률을 추적하여 팀의 속도를 평가하고 개선합니다. 팀에서 진행률을 추적하는 동안 다음과 같은 종류의 질문에 답해야 합니다.
가장 적절한 사용자 스토리에 대해 작업하고 있습니까? 프로젝트가 진행되는 동안 제품 백로그는 새 사용자 스토리로 조정됩니다. 그러나 각 스프린트의 스토리를 완료하더라도 백로그의 총 스토리 수가 감소하지 않으면 팀에서 원인을 조사해야 합니다. 잘못 선택한 스토리를 완료하고 있을 수 있습니다. 팀은 각 릴리스에 대한 비전과 목표를 가져야 하며, 고객에게 요청되는 것과 스토리가 직접 관련되어야 합니다.
기술적 부채를 가지고 있습니까? 일부 팀은 버그 수정과 같이 완료할 작업이 남아 있는데도 사용자 스토리를 완료 상태로 처리합니다. 이러한 팀은 나중에 대개 많은 비용을 지불해야 하는 기술적 부채를 안게 됩니다.
Visual Studio ALM에서는 많은 스프린트에 대해 팀에서 진행률을 추적하는 데 도움이 되는 몇 가지 보고서를 제공합니다.
.png "모든 반복의 상태의 정상적인 버전")
사용자 지정 보고서와 작업 항목 쿼리를 만들어 진행률을 추적할 수 있습니다. 자세한 내용은 Visual Studio ALM 보고서 만들기, 사용자 지정 및 관리 및 버그, 작업 및 기타 작업 항목 찾기를 참조하십시오.
릴리스 완료
팀이 기술적 부채를 모으고 있지 않으면 해당 릴리스에서 스프린트를 완료할 때 별도의 추가 작업 없이 제품을 릴리스할 수 있습니다. 팀과 제품 소유자는 고객 검토 및 회고 회의를 소집하여 릴리스를 전체적으로 검토합니다.
그러나 기술적 부채는 팀에서 쉽게 제거할 수 없는 어려운 문제입니다. 다른 많은 팀과 마찬가지로 팀에서 기술적 부채를 모으고 있는 경우에는 제품을 릴리스하기 전에 사용자 스토리를 완료하기 위해 미해결 작업을 수행하는 데 시간을 소비해야 합니다. 릴리스를 위한 회고 회의에서 팀은 부채를 더 많이 맡지 않도록 이후 스프린트에서 수행할 작업을 고려해야 합니다.