스크럼 프레임워크 및 스프린트 운영편집자 확인

스크럼 프레임워크는 세 가지 명확한 역할을 정의한다. 이는 제품 책임자, 스크럼 마스터, 그리고 개발팀이다. 각 역할은 상호 보완적이며, 팀이 가치 있는 제품 증분을 효과적으로 생성하고 전달하는 데 기여한다.

제품 책임자는 '무엇을' 만들어야 하는지에 대한 최종 책임을 진다. 주요 업무는 제품 백로그를 관리하는 것이다. 여기에는 백로그 항목의 우선순위를 설정하고, 항목을 명확히 설명하며, 이해관계자들의 요구사항을 대표하여 팀의 작업이 최대의 가치를 창출하도록 보장하는 일이 포함된다. 제품 책임자는 단일 인물이 담당하는 것이 이상적이며, 이해관계자들의 다양한 의견을 조율하여 하나의 비전으로 통합한다.

스크럼 마스터는 스크럼 프레임워크가 올바르게 이해되고 실행되도록 돕는 서번트 리더이다. 이 역할은 팀을 코칭하고, 스크럼 이벤트가 효과적으로 진행되도록 촉진하며, 팀 내외부의 장애물을 제거하는 데 중점을 둔다. 스크럼 마스터는 일일 스크럼 회의를 주관하거나, 팀이 스프린트 회고를 통해 지속적으로 개선할 수 있도록 지원한다. 관리자나 팀 리더가 아닌, 팀의 효율성을 높이는 파수꾼 역할을 한다.

개발팀은 제품 증분을 실제로 설계, 구축, 테스트하는 사람들로 구성된다. 이 팀은 다기능적이고 자기 조직화되어 있으며, 일반적으로 3명에서 9명 사이의 규모를 유지한다. 팀원들은 분석가, 개발자, 테스터, 디자이너 등 다양한 전문성을 가지고 있지만, 역할 구분 없이 공동의 목표인 스프린트 목표를 달성하기 위해 협력한다. 개발팀은 작업을 어떻게 수행할지에 대한 자율권을 가지며, 작업량을 스스로 추정하고 할당한다.

스크럼 프레임워크 내에서 이벤트는 규칙적인 리듬을 제공하고 투명성을 창출하며 검사와 적응의 기회를 마련하는 정해진 회의 또는 활동을 의미한다. 모든 이벤트는 시간 제한이 있으며, 이를 타임박스라고 부른다. 이는 집중도를 높이고 효율성을 유지하기 위한 핵심 장치이다.

주요 이벤트는 스프린트라는 정해진 기간을 중심으로 구성된다. 가장 중요한 이벤트는 스프린트 자체이며, 이는 다른 모든 이벤트가 발생하는 컨테이너 역할을 한다. 각 스프린트는 다음과 같은 표준 이벤트 시퀀스를 포함한다.

이벤트들은 서로 연결되어 피드백 루프를 형성한다. 스프린트 계획은 작업 범위를 정의하고, 일일 스크럼은 진행 상황을 점검하며, 스프린트 리뷰는 제품에 대한 피드백을 수집하고, 스프린트 회고는 프로세스 자체를 개선한다. 이러한 구조화된 반복은 지속적 개선과 예측 가능성을 가능하게 하는 스크럼의 핵심 동력이다.

아티팩트는 스크럼 프레임워크에서 작업의 투명성과 검사를 위해 공식적으로 정의된 정보 객체이다. 주요 아티팩트로는 제품 백로그, 스프린트 백로그, 그리고 증분이 있다. 각 아티팩트는 특정한 약속을 포함하여 팀이 목표를 향해 나아가는 데 필요한 집중과 명확성을 제공한다.

제품 백로그는 제품에 필요한 모든 기능, 요구사항, 개선사항, 수정사항을 우선순위가 정렬된 목록으로 관리하는 동적인 문서이다. 제품 책임자가 소유권을 가지며, 시장 변화나 이해관계자의 피드백에 따라 지속적으로 갱신된다. 스프린트 백로그는 단일 스프린트 동안 완료하기로 선택된 제품 백로그 항목들로 구성된다. 이는 개발팀에 의해 생성되고 관리되며, 스프린트 목표를 달성하기 위한 구체적인 실행 계획을 담는다.

가장 중요한 아티팩트는 증분이다. 증분은 하나의 스프린트 동안 완성된 모든 제품 백로그 항목들의 합과 지난 스프린트들의 모든 증분을 더한, 작동 가능하고 사용 가능한 제품의 조각이다. 각 스프린트의 끝에는 새로운 증분이 생성되어야 하며, 이는 "완료"의 정의에 따라 완전히 작동하고 테스트된 상태여야 한다. 이 증분은 스프린트 리뷰에서 이해관계자에게 시연되는 결과물이다.

이 아티팩트들은 서로 긴밀하게 연결되어 있다. 제품 백로그에서 항목이 선택되어 스프린트 백로그로 이동하고, 개발 작업을 거쳐 최종적으로 증분으로 통합된다. 각 아티팩트의 투명성은 효과적인 검사와 적응의 기반이 된다.

스프린트 계획은 새로운 스프린트를 시작하기 위해 팀이 모여 실행 가능한 계획을 수립하는 시간 제한 이벤트이다. 일반적으로 2주 스프린트 기준 최대 4시간, 4주 스프린트 기준 최대 8시간을 넘지 않도록 한다. 이 회의의 주된 목표는 무엇을(What) 만들 것인지, 그리고 어떻게(How) 그 일을 수행할 것인지에 대한 합의를 도출하는 것이다.

첫 번째 부분에서는 제품 책임자가 제품 백로그에서 이번 스프린트에서 다루기 적합한 우선순위 높은 항목들을 제시한다. 개발 팀은 이 항목들에 대해 논의하고, 제품 책임자에게 질문하여 요구사항을 명확히 한 후, 스프린트에서 완료할 수 있을 만큼의 작업량을 선정한다. 이렇게 선정된 항목들의 집합을 스프린트 목표라고 하며, 이는 스프린트가 제공할 가치를 한 문장으로 요약한 것이다.

두 번째 부분에서는 개발 팀이 선정된 제품 백로그 항목들을 어떻게 완료할지 구체적인 실행 계획을 세운다. 팀은 각 항목을 더 작은 작업 단위로 분해하고, 필요한 기술적 접근 방식을 논의하며, 초기 작업 할당을 논의할 수 있다. 이 과정의 결과물은 스프린트 백로그이며, 이는 스프린트 동안 수행할 모든 작업 항목과 작업 목록을 포함한다. 계획이 수립되면 개발 팀은 제품 책임자에게 약속한 스프린트 목표와 스프린트 백로그를 달성할 수 있다고 자신 있게 설명할 수 있어야 한다.

일일 스크럼은 스프린트 기간 동안 매일 정해진 시간에 같은 장소에서 진행되는 짧은 스크럼 팀의 동기화 회의이다. 이 이벤트의 주요 목적은 지난 24시간 동안의 작업을 검토하고, 향후 24시간 동안 수행할 작업을 계획하며, 스프린트 목표를 달성하는 데 방해가 되는 장애물을 식별하는 것이다. 전통적으로 시간 박스는 15분으로 제한되며, 이를 초과하지 않도록 한다.

회의는 스크럼 마스터가 진행을 촉진하지만, 실제 발언은 개발팀 구성원이 주도한다. 각 개발팀 구성원은 일반적으로 세 가지 핵심 질문에 답변하는 형식으로 진행 상황을 공유한다: 어제 무엇을 했는가, 오늘 무엇을 할 것인가, 작업을 진행하는 데 방해 요소는 없는가. 이 구조는 집중력을 유지하기 위한 가이드일 뿐이며, 구체적인 문제 해결이나 상세한 기술 논의는 별도의 회의에서 이루어져야 한다.

일일 스크럼은 정보의 투명성을 높이고 팀의 협응력을 증진시키는 데 기여한다. 이를 통해 작업의 진행 상황이 모든 구성원에게 가시화되고, 잠재적인 지연이나 문제가 조기에 발견되어 신속하게 대응할 수 있다. 또한 팀원 간의 책임감과 공동 목표 의식을 강화한다.

성공적인 일일 스크럼 운영을 위한 몇 가지 실천법은 다음과 같다.

• 시간 엄수: 회의는 항상 정시에 시작하고 15분을 초과하지 않는다.

• 준비성: 각 팀원은 회의 전 자신의 작업 현황을 점검하고 간결하게 전달할 준비를 한다.

• 장애물 기록: 식별된 장애물은 스크럼 마스터가 기록하고, 회의 후 즉시 해결을 위해 노력한다.

• 적절한 장소: 모든 팀원이 참석 가능한 장소에서 진행하며, 원격 팀의 경우 화상 회의 도구를 효과적으로 활용한다.

스프린트 리뷰는 스프린트가 끝날 때 진행되는 공식 회의이다. 이 이벤트의 주요 목적은 완성된 증분을 검토하고 필요에 따라 제품 백로그를 조정하는 것이다. 스크럼 팀은 이해관계자들을 초대하여 완료된 작업을 시연하고 피드백을 수집한다.

회의는 일반적으로 스크럼 마스터가 진행을 돕지만, 제품 책임자가 주도한다. 팀은 '완료'의 정의에 따라 검증된 기능을 중심으로 증분을 시연한다. 이해관계자들은 제품에 대한 질문을 하고, 시장 상황이나 비즈니스 요구사항의 변화에 대한 정보를 제공할 수 있다. 이를 바탕으로 참석자들은 다음 스프린트를 위한 협의를 진행한다.

스프린트 리뷰의 구체적인 산출물과 논의 사항은 다음과 같다.

이 회의는 단순한 보고가 아니라 협업과 적응을 위한 작업 세션이다. 수집된 피드백은 제품의 다음 방향성을 결정하는 중요한 입력이 되며, 이를 통해 제품은 지속적으로 고객의 가치에 부합하도록 발전한다. 스프린트 리뷰는 시간 제한이 있는 이벤트로, 일반적으로 1개월 스프린트의 경우 최대 4시간을 넘지 않는다.

스프린트 회고는 스프린트가 종료된 직후에 진행되는 정기적인 회의이다. 이 이벤트의 목적은 방금 끝난 스프린트 동안의 프로세스, 도구, 팀의 협업 방식을 검토하고, 다음 스프린트에서 적용할 개선 사항을 식별하는 데 있다. 스크럼 마스터는 회고가 건설적이고 안전한 분위기에서 이루어지도록 촉진한다.

회고는 일반적으로 "잘한 점", "개선할 점", "시도해 볼 점"과 같은 프레임워크를 사용하여 구조화된다. 팀은 일일 스크럼, 스프린트 계획, 소통, 기술적 실천 방식 등 스프린트 전반을 돌아보며 데이터와 사실에 기반한 논의를 진행한다. 핵심은 문제나 실패를 개인의 탓으로 돌리지 않고, 시스템과 프로세스의 관점에서 개선 방안을 모색하는 것이다.

논의 결과, 팀은 실행 가능한 하나 이상의 개선 항목을 도출하고, 다음 스프린트에서 이를 스프린트 백로그에 반영한다. 이는 지속적 개선의 핵심 실천 방식으로, 팀이 점진적으로 더 효율적이고 즐겁게 일할 수 있는 환경을 만들어간다. 효과적인 회고는 팀의 자기 조직화 능력을 강화시키는 동력이 된다.

제품 백로그는 스크럼 프레임워크에서 개발할 제품의 모든 요구사항, 기능, 개선 사항, 수정 사항을 우선순위가 부여된 목록 형태로 담고 있는 동적인 문서이다. 이는 제품 책임자가 단독으로 소유하고 관리하는 핵심 아티팩트이며, 제품의 개발 방향과 로드맵을 정의하는 근간이 된다. 제품 백로그는 완성된 상태가 아니라 제품, 시장, 이해관계자의 요구에 따라 지속적으로 진화하는 살아있는 목록이다.

제품 백로그의 항목은 일반적으로 사용자 스토리 형식으로 작성되며, 각 항목에는 설명, 우선순위, 추정치(예: 스토리 포인트)가 포함된다. 우선순위는 비즈니스 가치, 위험, 의존성, 시장 요구 등을 종합적으로 고려하여 결정된다. 가장 높은 가치를 지닌 항목이 목록의 상단에 위치하여 다음 스프린트에서 개발될 가능성이 높아진다. 제품 백로그 정제 활동을 통해 항목들은 더 세분화되고 명확해지며, 추정이 더 정확해진다.

제품 백로그의 구조와 내용은 제품의 수명 주기 동안 변화한다. 초기에는 대규모의 기능과 요구사항이 포함되지만, 시간이 지남에 따라 더 상세하고 실행 가능한 작업으로 분해된다. 또한 새로운 아이디어가 추가되고, 시장 피드백에 따라 기존 항목의 우선순위가 재조정되거나 제거될 수도 있다. 이는 제품이 끊임없이 변화하는 환경에 적응할 수 있도록 보장한다.

스프린트 백로그는 현재 진행 중인 스프린트 동안 완료하기로 한 작업 목록이다. 이는 제품 백로그에서 선택된 제품 백로그 항목과 이를 완료하기 위한 구체적인 실행 계획으로 구성된다. 스프린트 백로그는 스프린트 계획 회의에서 생성되며, 개발팀이 무엇을 어떻게 수행할지에 대한 동적인 계획을 담고 있다.

스프린트 백로그의 핵심 구성 요소는 다음과 같다.

스프린트 백로그는 개발팀의 소유물이며, 팀이 스프린트 기간 내내 실시간으로 업데이트하고 관리한다. 일일 스크럼 회의에서는 이 백로그를 바탕으로 진행 상황을 점검하고, 남은 작업량을 추정하며, 필요시 계획을 조정한다. 스프린트 백로그는 스프린트가 진행됨에 따라 작업의 세부 사항이 명확해지고 새로운 작업이 발견될 수 있으므로, 지속적으로 진화하는 문서이다.

스프린트 백로그의 가시성은 매우 중요하다. 번다운 차트나 칸반 보드 같은 시각적 관리 도구를 통해 전체 팀이 현재 진행 상태와 남은 작업을 한눈에 파악할 수 있도록 한다. 이를 통해 팀은 자기 조직화를 통해 작업을 조율하고, 스프린트 목표 달성을 위해 집중할 수 있다.

증분은 스프린트 동안 완료된 모든 제품 백로그 항목들의 집합과 이전 모든 스프린트의 증분을 더한 가치 있는 결과물이다. 이는 각 스프린트가 끝날 때마다 잠재적으로 출시 가능한 제품의 상태를 의미한다. 증분은 스프린트 리뷰에서 이해관계자들에게 시연되고 검토되는 핵심 산출물이다.

증분의 핵심은 '완료'의 정의에 있다. 팀은 작업이 완료되었다고 간주하기 위해 충족해야 하는 명확한 기준을 공유한다. 이 기준에는 코드 작성, 테스트 통과, 문서화, 통합 및 검토 과정 등이 포함될 수 있다. 완료된 증분은 새로운 기능이 추가된 작동하는 제품이며, 언제든지 고객에게 전달될 수 있는 상태를 유지해야 한다.

지속적으로 증분을 만들어내는 것은 애자일 개발의 핵심 원칙인 점진적이고 반복적인 가치 제공을 실현하는 방법이다. 이를 통해 팀은 빠른 피드백을 받고 요구사항 변화에 유연하게 대응할 수 있다. 각 증분은 제품의 전체적인 가치를 한 단계씩 높여 나가는 구성 요소가 된다.

스토리 포인트는 작업의 상대적 규모, 복잡성, 위험, 노력량을 추정하기 위해 사용하는 추정 단위이다. 절대적인 시간 단위(예: 시간, 일)가 아닌, 다른 작업과 비교하여 상대적으로 얼마나 큰지를 나타내는 숫자 값이다. 일반적으로 피보나치 수열(1, 2, 3, 5, 8, 13...)이나 2의 배수(1, 2, 4, 8, 16...)와 같은 수열을 사용하여 추정한다. 이 방식은 정확한 시간 예측의 어려움을 인정하고, 팀이 작업의 규모에 대해 빠르게 합의를 이루도록 돕는다.

벨로시티는 스크럼 팀이 하나의 스프린트 동안 완성할 수 있는 작업량의 평균치를 나타내는 지표이다. 일반적으로 스프린트마다 완료된 제품 백로그 항목들의 스토리 포인트 합계로 계산된다. 벨로시티는 팀의 생산성과 예측 가능성을 측정하는 핵심 지표로 활용된다. 예를 들어, 지난 3번의 스프린트에서 각각 20, 25, 22 포인트를 완료한 팀의 평균 벨로시티는 약 22.3 포인트가 된다.

이 두 개념은 스프린트 계획과 릴리스 계획에 밀접하게 연관되어 작동한다. 팀의 평균 벨로시티를 알면, 향후 스프린트에서 얼마만큼의 작업을 계획할 수 있는지 예측하는 데 도움이 된다. 또한 제품 백로그에 있는 전체 항목들의 총 스토리 포인트를 팀의 벨로시티로 나누어 대략적인 릴리스 시기를 가늠해볼 수 있다. 스토리 포인트 추정과 벨로시티 측정은 팀의 내부 용도로, 팀 간 비교나 개인 평가의 도구로 사용되어서는 안 된다는 점이 중요하다.

스크럼 팀은 자기 조직화 팀의 원칙을 핵심으로 운영된다. 이는 관리자나 외부의 지시가 아닌, 팀 스스로가 작업을 계획하고, 업무를 분배하며, 문제를 해결하는 방식을 결정한다는 것을 의미한다. 스크럼 마스터는 이러한 자기 조직화를 촉진하고 팀이 장애물을 극복할 수 있도록 지원하는 역할을 담당하지만, 팀을 관리하거나 통제하지는 않는다.

자기 조직화 팀은 몇 가지 중요한 특성을 지닌다. 첫째, 팀은 스프린트 목표를 달성하기 위해 필요한 모든 기술과 전문성을 내부에 보유한다. 둘째, 팀 구성원들은 어떻게 작업을 수행할지, 누가 어떤 작업을 맡을지에 대해 스스로 결정한다. 이는 구성원들의 책임감과 몰입도를 높이며, 창의적인 문제 해결을 이끌어낸다.

이러한 운영 방식은 여러 이점을 제공한다. 팀은 외부의 간섭 없이 빠르게 의사결정을 내릴 수 있어 대응 속도가 향상된다. 또한, 작업에 대한 소유권이 강화되어 품질과 생산성에 긍정적인 영향을 미친다. 하지만 성공적인 자기 조직화를 위해서는 명확한 목표(제품 백로그 항목 및 스프린트 목표), 투명한 정보 공유, 그리고 팀원 간의 높은 수준의 신뢰와 협력이 필수적으로 요구된다.

지속적 개선은 스크럼 프레임워크의 핵심 원칙 중 하나로, 팀이 자신의 프로세스, 도구, 관계 및 기술을 정기적으로 검토하고 개선하기 위해 노력하는 과정을 의미한다. 이는 주로 스프린트 회고 이벤트를 통해 공식적으로 수행되지만, 팀의 일상적인 사고방식과 문화 속에 스며들어야 한다. 목표는 비효율성을 제거하고, 품질을 높이며, 예측 가능성을 개선하고, 궁극적으로 더 높은 가치를 더 빠르게 전달하는 능력을 강화하는 것이다.

주요 개선 활동은 스프린트 회고에서 이루어진다. 이 회의에서 스크럼 팀은 방금 끝난 스프린트를 되돌아보며 '잘한 점', '개선할 점', '시도해볼 점'을 논의한다. 구체적이고 실행 가능한 개선 항목을 도출하여 다음 스프린트의 스프린트 백로그에 포함시킨다. 이는 개선 작업이 단순한 토론에 그치지 않고, 실제 작업 항목으로 계획되고 실행됨을 보장한다. 예를 들어, 빌드 시간 단축, 테스트 자동화 개선, 커뮤니케이션 프로토콜 변경 등이 개선 항목이 될 수 있다.

지속적 개선은 공식 이벤트를 넘어 자기 조직화 팀의 문화로 자리 잡아야 한다. 팀원들은 일상적으로 일일 스크럼이나 작업 중 발생하는 작은 장애물이나 비효율을 즉시 인지하고, 팀 내에서 해결 방안을 모색하며 적응한다. 이러한 문화는 실패를 비난의 대상이 아닌 학습의 기회로 바라보고, 실험과 새로운 접근법을 장려하는 환경을 조성한다. 결과적으로 팀은 각 스프린트를 통해 점진적으로 더 나은 작업 방식으로 진화하게 된다.