스크럼 : 하나의 스프린트보다 긴 백 로그 항목을 처리하는 방법

SCRUM부터 시작해서 한 가지를 이해하는 데 문제가 있습니다. SCRUM은 스프린트 하나보다 오래 걸리는 백 로그 항목을 어떻게 처리합니까?

이러한 항목은 Epic이라고하며 단일 스프린트보다 짧은 더 작은 사용자 스토리로 나눠야하며 그 때문에 계획 할 수 있거나 Epics와 일반 스토리로 나눌 테마가 있습니다. 에픽과 테마는 주요 특성을 공유합니다. 높은 불확실성 = 제대로 추정 할 수 없습니다 (추정은 매우 높으며 단일 스프린트에 맞지 않기 때문에).

따라서 이러한 스토리로 시작하는 것이 좋지만 제품 소유자가 더 작은 특정 스토리로 나누기 전까지는 스토리를 계획 할 수 없습니다. 이 기사는 더 큰 요청 기능 (Epic) 또는 전체 기능 세트 (Theme)를 기록하기 위해서만 사용됩니다. 이 이야기를 깨 뜨리면 기능이 구체화됩니다.

또한 제품 백 로그의 빙산 구조를 따릅니다.

그런 아이템이 없습니다. 있다면 백 로그 항목이 충분히 구체적이지 않고 작은 항목으로 제대로 분류되지 않은 것입니다. 일부 사람들은 백 로그가 아니라 패트롤 로그 항목 이라고 부르며 스크럼에서는 반 패턴으로 간주됩니다.

케이크 유추 사용자 이야기 : 케이크를 먹는 사람으로서 오후에 케이크를 먹고 싶습니다. 나는 오후에 케이크 한 통을 먹을 수 없으므로 먹을 수있는 양에 맞게 얇게 썰어 야합니다.

스크럼이 처음 "발명"되었을 때, 기본 스프린트는 보통 4 주였습니다.

내가 말한 것에 따르면,이 매우 긴 스프린트 크기의 이유는 그 당시 사람들이 짧은 스프린트에서 무엇이든 성취 할 수 있다고 상상하기가 매우 어려웠 기 때문입니다.

팀이 스크럼에 대해 더 자신감을 가지면서 백 로그 항목을 관리하기 쉬운 작은 크기의 항목으로 더 잘 나누는 방법을 배웠고 개발 팀은 초기 디자인을 과장하지 않고 충분하게 수행 할 수있게되었습니다.

오늘날 대부분의 팀은 4 주를 매우 긴 스프린트 기간으로 생각합니다. 나는 2 주가 상당히 정상이라는 인상을 받았습니다. XP 팀은 일주일에 한 번만 반복하며 각 반복에서 완전한 사용자 스토리를 마칩니다.

따라서 백 로그 항목을 더 작은 항목으로 나눌 때마다 최종 제품에 대해 비즈니스 가치가 약간 증가합니다. 그 가능성이 입증되었습니다. (어려울 수있는 매우 전문화 된 도메인이있을 수 있음을 배제하지는 않겠지 만)

나는 요즘 4 주가 긴 스프린트에 동의합니다. 피드백 루프를 줄이고 짧은 반복 단위로 작은 작업 단위를 전환하는 데 더 효과적입니다. 그렇게하면 잘못 될 가능성이 적고, 변경 사항이 적고, 한 번에 관리하기가 더 복잡해집니다.

이야기를 나누는 것은 종종 사람들에게 어려운 부분이지만 더 많이할수록 더 나아질 수 있습니다. PO를 단계별로 제공하고 스프린트에서 여전히 가치를 제공 할 수 있다면 PO와 긴밀히 협력하십시오.

agileforall.com이라는 웹 사이트에서 이야기를 나누는 데 도움이되는 훌륭한 포스터가 여기 있으며 포스터를 찾을 수 있으며 백 로그 항목을 세분화 할 때 유용합니다.

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

한 번의 짧은 스프린트로 무언가를 완수 할 때 명심할 수 있도록 세분화하고 계획 할 때 완료된 정의를 사용하는 것이 좋습니다.