메뉴

스크럼 아티팩트 : 제품 백 로그, 스프린트 백 로그 및 제품 증분

  • 메인
  • 다른
  • 스크럼 아티팩트 : 제품 백 로그, 스프린트 백 로그 및 제품 증분

scrum artifacts product backlog

문제를 제거하기 위해 도구를 사용해보십시오

스크럼 아티팩트 소개 :

이 시리즈의 이전 기사에서 우리는 애자일 및 다양한 애자일 방법론 . 또한 다양한 방법론이 어떻게 다른지 배웠습니다.

지난 튜토리얼에서는 Scrum에 대해 자세히 살펴 보았습니다. 스크럼 역할 제품 소유자, 스크럼 마스터 및 스크럼 팀과 같이 각자의 책임이 무엇인지 확인했습니다.

이 자습서에서는 Scrum을 계속 진행하고 다른 스크럼 아티팩트에 대한 세부 정보로 이동합니다.

스크럼 아티팩트

학습 내용 :

다양한 스크럼 아티팩트

3 가지 유형의 스크럼 아티팩트는 다음과 같습니다.

  • 제품 백 로그
  • 스프린트 백 로그 및
  • 제품 증분

이제이 용어가 의미하는 바와 이러한 아티팩트를 만드는 방법을 살펴 보겠습니다.

스크럼 아티팩트 유형

제품 백 로그

간단히 말해서 제품 백로 그는 제품에 필요한 모든 항목의 목록입니다. 제품과 관련된 모든 사항에 대해 스크럼 팀에서 참조 할 최종 문서입니다. 제품 소유자 (PO)가 소유하는 주문 된 항목 목록입니다.

PO는이 목록을 만들고, 유지하고, 우선 순위를 지정할 책임이 있습니다. PO는이 제품 백 로그를 사용하여 스크럼 팀에 스프린트 중에 수행해야하는 주요 요구 사항을 설명합니다.

이 목록의 항목은 기술 언어 일 수도 있고 아닐 수도 있습니다. 평신도의 언어 일 수도 있지만 모든 제품 요구 사항과 이에 수반되는 변경 사항을 포함해야합니다. 또한 제품 백 로그가 있다고해서 스크럼 팀이이 아티팩트 만 따를 것이라는 의미는 아닙니다.

자체 세부 아티팩트를 생성 할 수 있지만 이는 모순되거나 제품 백 로그를 대체하지 않습니다. 오히려 제품 백 로그 요구 사항과 일치 할 것입니다.

다음은 일반적인 제품 백 로그의 예입니다.

이야기견적우선 순위
로그인하고 싶습니다41
로그 아웃하고 싶습니다두두
비밀번호를 변경하고 싶습니다1삼
주소를 업데이트하고 싶습니다삼4
새 집 전화 번호를 추가하고 싶습니다.15

이것은 우리에게 질문을 던집니다. 좋은 제품 백 로그를 만드는 방법은 무엇입니까?

제품 백로 그는 이상적으로 아래 규칙을 따라야합니다.

(i) 우선 순위가 지정되어야합니다. – 제품 백 로그의 항목은 우선 순위에 따라 주문해야합니다. 이 우선 순위는 PO와 스크럼 팀이 함께 결정할 수 있습니다. 우선 순위 요소는 스토리 포인트의 이점, 생성과 관련된 노력, 복잡성, 고객 우선 순위 등이 될 수 있습니다.

팀이 먼저 전달해야하는 항목을 이해하는 데 도움이됩니다.

(ii) 추정되어야한다 – 이야기는 어떤 것이 든 합의 된 정의에 따라 항상 추정되어야합니다. 이것은 우선 순위 지정에도 사용할 수 있습니다.

(iii) 높은 수준이어야합니다. – 제품 백 로그의 스토리는 높은 수준을 의미하며 세부 사항으로 들어가서는 안됩니다. 요구 사항에 따라 자세한 사용자 스토리를 만드는 것은 PO가 아닌 스크럼 팀에 달려 있습니다.

(iv) 동적이어야합니다. – 제품 백로 그는 최종 정적 문서가 아닙니다. PO가 스크럼 팀으로부터 입력을 받고 고객 요구 사항이 점점 더 명확 해짐에 따라 다시 검토해야합니다. 따라서 프로젝트가 진행됨에 따라 예상되는 추가 / 삭제 / 수정이 있기 때문에 문서 요구 사항은 처음에 바로 고정되지 않습니다.

마지막 요점이 가장 관련성이 높은 점입니다. 제품 백 로그의 목적은 활성 요구 사항 소스가되는 것입니다. 처음에 생성 한 다음 저장 위치에 보관해서는 안됩니다.

대신 변경 사항이 계속 적용됨에 따라 계속해서 공유해야합니다. 진행이 진행됨에 따라 새로운 요구 사항이 발생할 수 있으며 이로 인해 백 로그 항목의 우선 순위도 변경 될 수 있습니다. 새 요구 사항이 백 로그의 다른 항목에 종속되어 항목 우선 순위를 다시 조정해야하는 상황이있을 수 있습니다.

또는 PO 및 스크럼 팀이 결정한 요소에 따라 우선 순위가 높지 않더라도 고객이 다른 사람보다 먼저 그것을보고 싶어하기 때문에 먼저 구현해야 할 중요한 사용자 스토리가있을 수 있습니다.

따라서 제품 백로 그는 PO가 소유하고 프로젝트가 진행됨에 따라 여러 번 방문한 비즈니스 요구 사항의 순서가 지정된 목록입니다.

스프린트 백 로그

스크럼 팀은 스프린트라고하는 2 ~ 4주의 짧은 반복 작업을 수행한다는 것을 기억할 것입니다. 이러한 스프린트 동안 스크럼 팀은 PO에서 생성 한 제품 백 로그에서 항목을 식별하고 다음 반복의 일부로 제공 할 계획입니다. 스크럼 팀이 작업하기 위해 선택한 항목은 스프린트 백 로그의 일부가됩니다.

따라서 그들은 다음 제품 반복에 어떤 기능이 있을지 결정합니다. 스크럼 팀은 작업 할 사람이므로 스프린트 백 로그에 들어갈 내용을 결정하는 사람입니다.

따라서 그들은 그러한 이야기를 구현하고 얼마나 전달할 수 있는지 결정하는 데 필요한 노력을 추정해야하는 사람들입니다.

팀은 작업 할 제품 백 로그에서 항목을 선택할뿐만 아니라 해당 기능을 개발하는 데 걸리는 시간도 추정합니다. 또한 스프린트 목표를 달성하는 데 필요한 세부 작업을 생성하여 높은 수준의 사용자 스토리를 추가합니다.

Windows에 appium을 설치하는 방법

스크럼 팀은 또한 스프린트 중 필요할 때 스프린트 백 로그를 계속 업데이트 할 수 있지만 스프린트 백 로그를 변경할 수있는 것은 스크럼 팀뿐입니다.

일반적인 스프린트 백로 그는 아래와 같습니다.

스프린트 백 로그

팀은이 정보를 하루에 한 번 이상적으로 업데이트 할 수 있으며 스크럼 마스터는이 정보를 사용하여 스프린트 번 다운 차트를 만들 수 있습니다. 이 번 다운 차트는 팀이 스프린트에 대해 아직 남은 작업량을 확인하는 데 도움이되며 그에 따라 작업을 계획 할 수 있습니다. 필요한 경우 작업을 추가하거나 제거 할 수도 있습니다.

스프린트 백 로그를 만드는 동안 몇 가지 모범 사례는 다음과 같습니다.

# 1) 그룹 결정 – 스크럼 마스터 나 백 로그를 결정하는 다른 스크럼 팀 구성원이 아니어야합니다. 오히려 전체 팀이 함께 스프린트 백 로그에 포함 할 항목과이를위한 계획 방법을 결정해야합니다.

이 교차 기능 팀의 모든 구성원은 자신의 기술을 가지고 있으며 가능한 최상의 백 로그를 생성하기 위해 그들의 경험을 활용하는 것이 필수적입니다.

# 2) 작업을 할당하지 마십시오 – 애자일 문헌에서 여러 번 반복되었으므로 팀 구성원에게 작업을 할당하지 마십시오. 스크럼 팀은 자급 자족해야하며 스스로 작업을 구성하는 방법을 알아야합니다.

따라서 작업을 할당하는 대신 팀이 스스로 작업을 선택하고 진행 방법을 스스로 결정하도록해야합니다.

# 3) 완료의 정의 – 이해 관계자들이 동의 할뿐만 아니라 스프린트 목표와 관련하여 결정을 내려야 할 때마다 모든 지점에서 팀이 명확하게 볼 수 있도록해야합니다. 이는 배송 가능한 제품을 배송하기 전에 정확히 무엇을해야하는지 알려주는 역할을합니다.

# 4) 백 로그 계속 업데이트 – 스프린트가 발전함에 따라 팀은 더 큰 이해를 얻을 수 있으므로 이에 따라 스프린트 백 로그를 업데이트하여 더 큰 이해도를 반영해야합니다. 언제든지 정적 문서가되어서는 안됩니다.

# 5) 작업 추가 – 이 작업은 코딩과 관련된 것이 아니라 배송 가능한 제품을 제공하는 데 필수적 일 수 있습니다. 따라서 백 로그에서도 이러한 작업을 언급합니다.

제품 증분

이것은 제품 증분 인 마지막 스크럼 아티팩트를 가져옵니다. 스크럼 가이드에 정의 된대로 Increment는 모든 제품 백 로그 항목 동안 완료 스프린트 그리고 모든 이전 스프린트의 증분 값. 지금까지 잘 알고 있듯이 스크럼은 반복적 인 프로세스입니다.

각 반복의 결과는이 제품 증분이며 이러한 각 제품 증분은 팀이 최종 제품을 제공하기 위해 한 걸음 더 다가가는 데 도움이됩니다.

이것이 의미하는 바는 스프린트의 결과가 증가한다는 것입니다. 결과가 증분으로 간주 되려면 먼저 사전 정의 된 완료 정의를 충족해야합니다. 즉, 최종 결과는 '배송'할 수있는 사용 가능한 제품이어야합니다.

정의에 따라 실제로 '완료'되었는지 확인하기 위해 확인, 사용 및 테스트 할 수 있으며 제품 소유자가 원하는 경우 출시되어 라이브로 출시 될 수도 있습니다.

이 제품 증분을 제공하는 가장 중요한 것은 모든 사람이 이해하는 '완료 정의'를 공유하는 것입니다.

스크럼 팀은 자신이하는 일이 받아 들여질 지 아닌지 의심해서는 안됩니다. 의심스러운 점이있는 경우 완료의 정의는 추가 진행 방법을 안내하기에 충분해야합니다. 이 정의만을 기반으로 스크럼 팀은 스프린트를 위해 선택할 제품 백 로그 항목 수를 결정합니다.

이것은 스프린트에서 예상되는 최소값입니다.

결론

이 튜토리얼에서 우리는 더 나은 품질의 아티팩트를 만드는 데 도움이 될 몇 가지 모범 사례와 함께이를 소유 한 3 개의 스크럼 아티팩트가 무엇인지 이해했습니다. 이 시리즈의 다음 튜토리얼에서는 Scrum 이벤트에 대해 논의하고 해당 이벤트를 실행하는 방법을 살펴 봅니다.

다가오는‘Scrum 이벤트 , ’각 스크럼 이벤트에 대해 자세히 논의 할 것입니다!

이전 튜토리얼 | NEXT 튜토리얼

추천 도서

^