스크럼-백 로그를 기울이지 않고 부분적으로 완전한 사용자 스토리를 다음 스프린트로 전달하는 방법

우리는 Scrum을 사용하고 있으며 때로는 계획된 스프린트에서 사용자 스토리를 끝내지 못하는 경우가 있습니다. 진정한 Scrum 스타일에서는 소프트웨어를 배송하고 다음 스프린트 계획 세션 동안 다음 스프린트에 사용자 스토리를 포함시키는 것을 고려합니다. 우리가 수행하는 사용자 스토리가 부분적으로 완료되었다고 가정 할 때 다음 스프린트 계획 세션에서이를 어떻게 정확하게 추정합니까? 우리는 다음을 고려했습니다.

a) 사용자 스토리를 완성하기 위해 남은 작업 만 반영하도록 스토리 포인트 수를 조정합니다. 불행히도 이것은 제품 백 로그보고를 망칠 것입니다.

b) 부분적으로 완성 된 사용자 스토리를 닫고 스토리 포인트가 적은 나머지 기능을 구현하기 위해 새로운 스토리를 올리십시오. 이는 스프린트에서 완료되지 않은 것을 소급하여 볼 수있는 능력에 영향을 미치며 약간의 시간이 소요됩니다.

c) a 또는 b를 귀찮게하지 말고 Sprint Planning에서 "사용자 스토리는 X 스토리 포인트 일 수 있습니다. 그러나 95 % 완료된 것으로 알고 있으므로 잘 맞을 것입니다."

현재 팀에서는 c)를합니다.

속도는 스프린트에서 팀이 실제로 끝내는 것을 설명해야합니다. 전달되지 않은 것은 고객에게 가치가 없으므로 우리는 그 점을 세지 않으며 전부 또는 전혀 아닙니다.

그래서 우리는 완성되지 않은 이야기 전체를 ​​다음 스프린트로 옮기고 모든 스토리 포인트는 다음 스프린트 속도에 추가됩니다. 시간이 지남에 따라 속도가 빨라지고 미래의 속도를 추정하기 위해 이전 스프린트의 평균을 참조합니다.

옵션 A는 일반적으로 권장되는 조치 과정입니다. 이전 스프린트에 대한 스토리 완료에 대한 포인트를 부여하지 않고 스토리를 제품 백 로그로 다시 이동하여 우선 순위를 정합니다. 완성 된 사용자 스토리와 부가가치에 따라 속도 (및 기타 메트릭)를 계산합니다. 다음 스프린트 계획을 시작하면 비즈니스 우선 순위가 변경된 경우 완료되지 않은 스토리를 포함하거나 포함하지 않을 수있는 가치에 따라 우선 순위가 가장 높은 스토리를 취합니다. 스토리를 추정 할 때는 스토리의 새로운 포인트를 고려할 때 이미 수행 한 작업을 포함하십시오.

물론, 대안적인 옵션 (및 나의 선호도)은 원래 추정 된 수의 스토리 포인트를 사용하는 것입니다. 이것은 과거에 해왔 던 것입니다. 이것은 당신의 추정치가 좋고 근거가 있다고 가정하지만 스프린트를 위해 너무 많은 작업을 중단했습니다 (예 : 이야기는 실제로 3 점의 가치가 있지만 문제는 당신이 13) 만 풀어야합니다. 추정을 수행 할 수있는 능력에 확신이 없으면 팀과 프로세스에 따라 작동 할 수 있습니다.

그러나 이것이 "제품 백 로그보고에 영향을 줄 것"이라고 언급합니다. 제품 백로 그는 기술, 시스템, 요구 사항 및 고객에 대한 이해가 높아짐에 따라 각 스토리의 순서와 추정치가 바뀌면서 역동적이어야합니다. 일반적으로 제품 백 로그에서보고되는 것은 사용자 스토리 수와 총 스토리 포인트 수입니다. 우선 순위가 변경되고 새로운 요구 사항이 추가되고 유효하지 않은 요구 사항이 제거되며 더 많은 정보가 학습됨에 따라 변경 될 수 있습니다.

이것에 대해 너무 많이 생각하면 그것이보다 복잡해 보입니다 ... 실제로는 매우 간단합니다.

옵션 C

불완전한 스토리는 포인트가 변경되지 않고 제품 백 로그로 되돌아갑니다. 다음 스프린트를 계획 할 때 수행 할 수있는 작업에는 많은 작업이 이미 완료되었다는 사실이 논의에 포함되어야합니다. 팀이 스프린트에 맞출 수 있다고 결정하면 원래 포인트 수와 함께 들어갑니다. 그렇지 않은 경우 백 로그에 남아 있습니다. 끝난. 스토리가 완료된 스프린트에 점수가 부여됩니다.

도움이되는 경우 사용자 스토리별로 별도의 "잔여 작업"메트릭을 추적 할 수 있으므로 스프린트가 끝날 때까지 스토리가 완료되지 않은 경우 남은 예상 작업을 스토리에 기록하고 언제 고려할 수 있습니다 후속 스프린트에 포함 계획. 그러나 그때도 원래 이야기의 가치를 바꾸지 마십시오.

보고 도구가 옵션 A를 정확하게 처리 할 수없는 경우 메트릭을 사용할 희망이 없으면 옵션 B를 사용합니다.

어떤 경우에는 옵션 B를 수행하고 닫으려는 이전 작업의 범위를 좁히고 남아있는 범위에 대한 새 작업 만 만들어서 닫힌 의미를 왜곡하지 않을 수 있습니다. 이것은 역사가 의미 적으로 더 의미가있게하며 일반적으로 작업을 더 세분화해야하는 장소를 나타냅니다. 때때로 이것은 불가능하거나 논리적이지 않으며 단순히 그 정도의 문제가 있거나 그 수준의 문제에 부딪히는 작업이 있습니다.

편집 : 이것은 (OP가 가정 한 것처럼) 거의 완전한 작업이 우선 순위에서 무너지지 않았으며 이전 노력에 대한 대가를 얻는 것이 목록에서 계속 작업을 계속할 수 있다고 가정합니다. 나는 몇몇 상점들이 이것을하지 않는다는 것을 알고 있지만, 내가 일한 대부분의 장소는 무언가가 급격히 변하지 않는 한 거의 계속 될 수있는 거의 남은 일을 끝내는 것이 가치 있다고 생각합니다. 상황을 바꾸는 것에 대한 형벌은 종종 순서를 바꿀 가치가 없다.

우리가 수행하는 사용자 스토리가 부분적으로 완료되었다고 가정 할 때 다음 스프린트 계획 세션에서이를 어떻게 정확하게 추정합니까?

나는 옵션 A부터 C까지는 좋지 않다고 생각합니다. 주로 팀 속도와 관련하여 가장 중요하게 생각하는 것은 평균 속도이며 주어진 스프린트의 속도가 올라가거나 내려 갔는지 여부가 아니기 때문입니다.

사용자 스토리가 정의되면 승인 기준이 있어야합니다. 허용 기준에 아무것도 경우 되지 완료 후, 팀은 단순히 포인트의 적립되지 않습니다. 스토리가 완료되면 (즉, PO에 의해 코딩, 테스트 및 수락) 팀은 모든 포인트를 얻습니다.

이것은 팀이 주어진 스프린트 속도보다는 평균 속도 에 집중할 때 효과적 입니다.

그의 책에있는 M. Cohn처럼, 나는 전혀 또는 전혀없는 시나리오를 선호하는 경향이 있습니다. 결국, 8 포인트 스토리 중 5 포인트를 완료했는지 또는 6 또는 7 포인트가 다른 추측 게임이 될지 추정하려고 시도하고 있습니다. 견적 방법. 가장 간단한 방법을 사용하고 실제로 완료 한 후 모든 포인트를 얻는 것이 좋습니다.

그의 책 ¹ (제 강조)에서 인용 한 콕 (M. Cohn) 인용 :

나는 일반적으로 속도를 세는 것에 대해 전적으로 또는 아무것도하지 않는 입장을 선호합니다 : 이야기가 (제품 소유자가 코딩하고 테스트하고 받아들이면) 팀은 모든 점수를 얻지 만 이야기의 어떤 것이라도 그렇지 않으면 하지 않으면 그들은 아무것도 얻지 못합니다. 반복이 끝나면 평가하기가 가장 쉬운 경우입니다. 모든 것이 완료되면 모든 포인트를 얻습니다. 빠진 것이 있으면 점수가 없습니다. 팀이 다음 반복에서 스토리의 나머지 부분을 차지할 가능성이 높으면 잘 작동합니다. 첫 번째 반복에서의 속도는 스토리를 부분적으로 완료 한 것으로 인정받지 못했기 때문에 예상보다 약간 낮습니다. 그러나 두 번째 반복에서는 반복이 시작되기 전에 일부 작업이 완료 되었더라도 모든 포인트를 얻을 수 있기 때문에 속도가 예상보다 높습니다.주어진 반복에서 속도가 올라가거나 내려가는 것이 아니라 시간이 지남에 따라 팀의 평균 속도에 관심이 있다는 것을 모두가 기억하는 한 이것은 잘 작동합니다.

¹ 민첩한 추정 및 계획 , 부분적으로 완성 된 사례 재 추정, p.66

우리 팀은 이전에 일부 이의 제기에도 불구하고 부분 포인트를 할당하려고 시도했지만 전혀 효과가 없다고 생각합니다. (우리는 더 이상하지 않습니다 ... 그림으로 이동하십시오) 이것은 이야기가 팀으로 추정되기 때문에 특히 그렇습니다. 하지만 한 사람 만 작업하면 팀 이 더 어려워 집니다. 개인 이 실제로 얼마나 많은 것을 완료 했는지 알 수 있습니다. 애자일은 특정 스프린트가 "좋아"보이는 것보다는 팀의 평균 속도에 더 관심이 있습니다.

그러나 저자 는 팀이 다음 반복에서 나머지 작업을 처리하지 않을 경우 부분 점수를 할당하는 것을 고려할 수 있다고 언급합니다. 이 경우 팀은 남아있는 작업을 추정하고 원하는 크기로 새로운 사용자 스토리로 분류합니다. 저자가 언급 한대로 ² :

합산 추정치가 원래 추정치와 같을 필요는 없습니다 ...

² 디토, p.66

팀에게 더 나은 권장 사항은 이런 종류의 문제를 피하기 위해 스토리를 충분히 작은 크기로 나누는 것입니다 ³ :

그러나 불완전한 스토리에 포인트를 할당하는 가장 좋은 두 가지 해결책은 불완전한 스토리가없고 부분 크레딧이 문제가되지 않는 충분히 작은 스토리를 사용하는 것입니다.

³ 디토, p.67

도움이 되었기를 바랍니다.

나는 이것에 대한 정답이없는 것처럼 놀랍습니다. 나는 "옵션 D, 더미"의 코러스를 기대하고있었습니다!

우리는 명백한 것을 빠뜨리지 않은 것처럼 보였으므로, 이것이 각 팀이 자신의 업무 방식과 가장 중요한 지표에 따라 스스로 결정해야하는 결정 중 하나라고 생각했습니다.

우리는 구현 한 사용자 스토리를 정확하게 기록하는 것이 필수적이며, 이것이 옵션 B를 배제하는 테스트, 지원 문서 및 릴리스 노트의 기초를 형성하기 때문에 필수적이라고 결정했습니다.

다음으로, 스프린트 계획을 정확하게 수행 할 수있는 것이 필수적이라고 생각했습니다. 옵션 C를 배제했습니다.

따라서 우리는 옵션 A가 우리에게 옳은 결론을 내 렸습니다. 이후 스프린트에서 적절히 계획 할 수 있도록 스프린트에서 부분적으로 완료 한 스토리의 스토리 포인트를 다시 추정 할 것입니다. 시간이 지남에 따라 제품 백로 그는 우리가 구현 한 스토리 포인트의 양을 약간보고하지 않지만 이는 다른 옵션보다 문제가되지 않으며 기록 유지 및보고를 변경하여 해결할 수 있습니다.

우리는 대문자 사용을 위해 스프린트 반복에 소요 된 시간 (사용자 스토리와 관련된 작업에 소요 된 시간)을 추적하고 PO의 목표가 다음 스프린트 동안 계속 트럭 킹을 계속하는 것이라면 뾰족한 사용자 스토리를 이동시킵니다. 같은 점.

PO의 목표가 다른 무언가를 그 자리로 옮기는 것이라면 완료되지 않은 이야기를 백 로그에 넣고 원하는 모든 것을 수행합니다. 당신이 씹을 수있는 것보다 더 많은 것을 버리는 습관이 있다면, 모든 스프린트에서, 당신은 스프린트에서 스토리 포인트를 "완료"하고 완전히 완료되지 않은 것이기 때문입니다. 시험 품목.

스프린트에 무언가를 남기고 싶거나 발송해야한다면 원래 이야기 내에서 슬라이스 포인트를 결정하고 완료 지점에 도달 한 다음 그 작은 조각을 커밋한다고 생각합니다. 반복합니다. 그런 다음 나머지를 다시 지적하여 백 로그에 넣을 수 있습니다. 팀과 합의하여 스토리를 여러 조각으로 나누기 때문에 다시 추정 할 수 있습니다.

첫 번째 질문은 Story Point의 의미는 무엇입니까? 스토리 포인트를 "작업 엔지니어링 수행 량"으로 정의하면 모든 대답이 가능합니다. 그러나 스토리 포인트를 "비즈니스에 얼마나 많은 가치가 전달되는지"로 정의하면 스토리가 100 % 완료되고 수락되어 100 % 전달 될 때까지 크레딧을 제공하지 않는 것이 중요합니다. 완료된 내용을 기반으로 스프린트 후 스토리 포인트를 수정하면 실제 문제 만 숨겨집니다 .a) 스토리에 대한 명확한 이해가 없었습니다. ) 스토리를 완성하기위한 작업 또는 종속성에 대한 충분한 이해가 부족합니다 .e) 스토리를 테스트하려는 노력을 과소 평가했습니다 .f) 스토리 포인트를 너무 많이 내 렸습니다 .g) ... 여기에 이유를 삽입하십시오 ...

민첩성의 목표는 예측 가능하면서 유연해야합니다. 제 생각에 일관성을 유지하는 가장 좋은 방법은 원래의 이야기 추정치를 수정하지 않고 무엇이 잘못되었는지 알아내는 것입니다.