우리는 첫 스프린트의 한가운데에 있으며 우리에게 뭔가 새벽이 있습니다.
우리는이 2 주 반복에 대해 114 개의 이상적인 시간을 계획했으며 첫 주가 끝날 무렵 스프린트 전체를 완료했습니다. 우리는 지금 무엇을합니까? "책"은 백 로그에서 다음으로 우선 순위가 높은 항목을 가져와야한다고 말합니다. 그렇지만 어떻게 그것들을 번 다운 차트에 추가합니까? 마치 처음부터 시작된 것처럼 이야기를 설명하기 위해 다시 작성합니까? 아니면 우리가 작업을 시작한 날에 y 축에 추정치를 추가하십시오 (90o 각도 점프 표시)?
모든 의견을 환영합니다!
답변:
번 다운 차트를 만드는 목적 중 하나는 시간이 지남에 따라 투명하게 가치가 제공되는 방법을 보여주는 것입니다.
새로운 사용자 이야기는 처음에 스프린트에 없었으므로, 그들이 가장 한 것처럼 보이기는 다소 까다로워 보입니다. 현재 번 다운 차트에 추가하면 현재 추정 수준이 아직 예비 진화 단계에 있음을 정확하게 보여줍니다.
이것은 귀하와 귀하의 제품 소유자에게 좋습니다. 이 프로젝트 관리 시스템을 사용하여 어떻게 더 나은 평가자가 될 수 있는지 보여줄 것입니다.
당신은 처음부터 과도하게 추정 한 다음, 과소 평가되고, 약간 더 적게 추정하지만, 약간 더 적게 추정한다는 것을 처음부터 볼 수있을 것입니다.
사용자 스토리를 추정하는 것이 스프린트에서 가장 어려운 부분 중 하나라고 생각합니다. 팀이 함께 진화하는 법을 배우면 프로세스에서 점점 더 효율적이 될 것입니다. 번 다운 차트와 같이 사용중인 도구를 통해이를 설명하는 것이 좋습니다.
스프린트 를 취소 해도 현재 속도를 고려하여 다음 스프린트를 계획 해도 문제가되지 않습니다 .
공식 스크럼 안내서에서 :
스프린트 시간 상자가 끝나기 전에 스프린트를 취소 할 수 있습니다. Sprint를 취소 할 권한은 제품 소유자에게만 있지만 이해 당사자, 팀 또는 ScrumMaster의 영향을받을 수 있습니다.
스프린트 계획은 제품 소유자, 스크럼 마스터 및 팀과의 논의 내에서 수행되어야하므로 다음 사용자 스토리를 간단히 선택하는 것이 역효과를 낳습니다.
당신이 약간 사전에있는 경우, 당신은 다음으로 우선 순위가 높은 다음 이야기를 고를 수 있었지만 여기서는 상황이 매우 다릅니다.
번업 차트를 추가 할 수 있습니다 . 그들은 언제, 얼마나 많은 새로운 작품을 추가했는지 모호하지 않고 보여줍니다.
이 차트는 팀이 반복 5에서 20 포인트 더 많은 작업 포인트를 추가 한 것을 보여줍니다.
이것을 시각화하는 여러 가지 기술이 있습니다.
그 중 하나는 새 스토리가 추가 된 날에 y 축 (가로축)에 오프셋을 도입하고 실제 번 다운 그래프를 사용하여 원래 "0"레벨 아래로 이동하는 것입니다.
다른 하나는 시작부터 존재했던 척하는 것입니다 (CGI 기반 번 다운 그래프를 사용하는 것이 훨씬 쉽습니다).
그리고 당신은 당신의 자신을 생각 해낼 수 있습니다.
가장 중요한 것은 팀, 스크럼 마스터 및 제품 소유자간에이를 논의하여이 상황에서 수행하려는 작업에 대한 합의에 도달하는 것입니다. 기본 규칙 이외의 스크럼에서 아무것도 수행 할 수있는 고정 된 방법은 없습니다. 스크럼은 환경의 요구에 가장 잘 맞도록 시간이 지남에 따라 진화하기위한 것입니다.
OP의 문제를 세 가지 별개의 질문으로 나누고 싶습니다 .
다른 질문에 언급 된 번 다운 및 번업 차트는 유용하지만 OP의 "지금 무엇을해야합니까?"
계속 또는 취소 : 저는 Pierre와 함께 있습니다.이 스프린트를 취소하고 즉시 다음 스프린트를 계획하는 것이 좋습니다. 스프린트 취소는 다른 팀이 있고 스프린트를 동기화해야하는 경우 옵션이 아닙니다 (대부분의 스크럼 전문가는 동기화해야 함을 권장합니다).
스프린트가 계속되는 경우 : 진행중인 작업 제한 . 한 번에 하나의 스토리 만 작업하고 일주일 미만의 마무리 작업에 집중하십시오. 스프린트 종료시 부분적으로 완료된 상태의 스토리가 없는지 확인하십시오.
다음 계획을 세우는 방법 : 여기서 옵션은 상대 크기 추정을 시도하거나 Henrik Kniberg의 "Trenches의 스크럼 및 XP"책에 설명 된대로 스토리 포인트-사람-일 당량과 초점 요소를 근사치로 사용하는 것입니다. 우리는 이미 다른 스레드에서 논의했습니다 .
절반의 시간 안에 완료하는 것은 추정치와 큰 차이가 있습니다. 나에게 이것은 스프린트 시작 부분에서 사용자가 예상 한 것과 팀이 실제로 일을 수행했을 때의 중대한 위험을 나타냅니다. 또한 Sprint는 이제 PO의 새로운 피드백을받을 수있는 충분한 기능을 제공해야합니다.
따라서 PB 상단에서 물건을 가져 와서 계속할 때의 위험은 PB 상단에있는 항목이 오래되어 (콘텐츠 및 우선 순위 모두) 팀이 마지막 스프린트에서 잘못되었다는 것입니다 그리고 당신은 단지 PO로부터 피드백을 얻지 않고 그 실수들을 만들어 낼 것입니다.
가장 합리적인 조치는 스프린트를 완료하고 일반적인 스프린트 검토 종료, 회의 및 소급 계획을 세우고 다음 스프린트에서 시작하는 것입니다.
번 다운 차트에 관해서는, 원래의 질문은 그것이 무엇인지의 요점을 놓친 것 같습니다. 스프린트 중 진행 상황에 문제가 있는지 판단하는 도구 일뿐입니다. 설명 된 바와 같이, 스프린트 작업의 2, 3 일에 팀이 스프린트 작업 일정보다 앞선 것으로 나타 났을 때,이 상황에서 번 다운 차트가 작동해야했습니다. 그런 다음 "왜?"라는 질문을하고 추정치가 잘못되었는지 또는 프로그래머가 작업을 잘못 해석하고 있는지 또는 어떤 식 으로든 어떤 방식으로 레일에서 나가는 지 확인하십시오.
그러나 번 다운 차트를 무시하고 이상한 일이없는 것처럼 순항하는 경우 "책"이 알려주기 때문에 생성 한 무의미한 유물로 취급하는 것처럼 보입니다. 제 생각에는 PB 상단에서 더 많은 물건을 꺼내 두 번째 주에 계속하기로 결정한 경우 두 번째 주에 새로운 번 다운을 시작하십시오 (그리고 당신이 한 일을 한 것처럼 무시할 수 있습니다) 첫 주).
