반복 도중에 추정치를 변경해도 괜찮습니까?


14

우리는 4 명의 개발자로 구성된 팀에서 Agile / Scrum을 사용하기 시작했습니다. 스토리 추정을 수행하고 제품 백 로그에서 프라이밍 스토리를 주문했습니다.

우리는 일반적인 1,2,3,5,8,13 ... 대신 1에서 5까지의 복잡성에 대한 점 기반 추정으로 시작했습니다.

몇 가지 이야기를 작업 한 후 4 점으로 추정되는 일부 이야기는 2 일 뿐이고 2 점으로 추정되는 다른 이야기는 훨씬 더 복잡하고 5로 추정되어야한다고 생각했습니다. 알고있다:

  • 반복 도중 스토리 추정치를 변경해도 괜찮습니까?
  • 일반적인 1,2,3,5,8,13 ... 대신 1에서 5까지의 현재 추정 점을 사용하는 것이 좋습니다.

개인적으로 두 경우 모두에 해당해서는 안된다고 생각하지만 내 자신의 이해가 명확하지 않기 때문에 나 자신을 백업해야합니다.


4
스스로에게 물어보십시오 : 스프린트 중반을 재추 정하는 데 시간을 소비하면 어떤 이점이 있습니까? 거친 3 대 5와 비교하여 미세 입자 3 대 4 대 5에 대해 '논쟁'하는 데 더 많은 시간을 소비하면 어떤 이점이 있습니까?
휴고

답변:


13

반복 도중 스토리 추정치를 변경해도 괜찮습니까?

절대적으로하지. 우리는 그렇게 될 것으로 기대합니다. 그리고 우리는 오류가 시간이 지남에 따라 균형을 유지할 것으로 기대합니다. Google은 특정 카테고리 (예 : 새 웹 페이지)가 모두 예상했을 때 생각했던 것보다 항상 더 복잡 할 것으로 예상되는 경우에만 예상치를 조정합니다.

서사시 이야기는 작은 이야기로 나뉘어 질 수 있기 때문에 (스프린트 이전에 발생해야 함) 원래 추정치를 조정하는 것처럼 보일 수 있지만 재 추정보다는 정련이라고 부릅니다. 그 당시 우리는 더 명확한 견해를 가지고 있기 때문입니다.

Mike Cohn의 Agile Estimating and Planning 은이 주제에 관한 좋은 책입니다. 나는 그것을 성경 (또는 "애자일 (Agile)"책)을 성경으로 사용하는 것에 대해 경고 할 것이지만, 그것은 당신의 프로세스를 개선하기에 좋은 출발점입니다.

그는 잘못된 평가가 "매직"으로 균형을 잡는 방법에 대해 이야기하지만, 그것이 반복해서 작동하는 것을 강조했습니다.

일반적인 1,2,3,5,8,13 ... 대신 1에서 5까지의 현재 추정 점을 사용하는 것이 좋습니다.

피보나치 일련의 포인트 추정을 사용한다는 것은 이야기가 클수록 예측이 정확하지 않다는 것을 인정하는 것입니다.

그러나 그것이 당신을 위해 작동하지 않는 경우, 특히 모든 작업을 작게 유지하는 경우 사용하지 마십시오. 규칙이 아니라 지침입니다.

티셔츠 사이징 (SML XL XXL)도 인기가 있으며 본질적으로 (1 2 3 4 5)와 다르지 않습니다.


+1 : 회고하는 동안 이것을 토론하십시오. 다음 봄 초에 우선 순위를 다시 정할 때 재 추정하십시오. 이것이 스프린트가있는 이유입니다. 스프린트 동안 관리 오버 헤드가 없습니다. 코드 만 작성하면됩니다.
S.Lott

fabonacci 시리즈 사용에 대해 이야기가 거의 3 일이 소요될 것입니다. 스토리를 수행하는 작업은 A, B, C입니다. 당신은 또한 그것이 매우 복잡하지 않다고 생각하지만 이러한 각 작업은 매일 하루가 걸릴 것입니다. 이야기에 어떤 견적을 하시겠습니까?
tintin

@tintin : 포인트를 사용하는 이유는 "이야기하는 데 거의 3 일이 걸린다는 것을 알고 있습니다"라는 말을 피하기 위해서입니다. 포인트는 상대적으로 임의적이며, 각 작업은 다른 작업과 비교하여 복잡성을 기반으로합니다 (잘못 추정 된 작업을 기준으로 사용하지 않아야 함). 그러나 불확실성을 설명하기 위해 누락 된 숫자를 피하십시오. 따라서 작업 B가 작업 A보다 두 배 복잡하고 작업 A가 2 점으로 표시되면 작업 B를 5 점으로 표시합니다.
pdr

+1 : 이야기가 더 큰, 덜 정확한 추정치입니다
kevchadders

1

반복 도중 스토리 추정치를 변경해도 괜찮습니까?

당연히 그렇습니다-현재 또는 미래의 봄 계획에 영향을 미칠 경우. 민첩성의 요점은 가능한 한 최신 정보를 바탕으로 행동을 취하는 것입니다.

현재 스프린트를 타임 박스에서 완료 할 수 없을 정도로 예상치 못한 결과가 나오면 수정 된 추정치에 따라 조치를 취해야합니다. 새로운 추정치를 기존 추정치를 기반으로하고 (실제로 메모리 / 경험에 의존하기보다는 추정하는 경우) 정확해야합니다.

반면 에 정확한 추정치 에는 실제로 그 자체 로 가치가 없습니다 . 의미없는 통계를 작성하는 데 시간을 낭비하지 마십시오.


우리의 경우 초기 추정치는 큰 것이었고 그 작업은 훨씬 적었습니다. 따라서 현재 스프린트가 제 시간에 완료되지는 않지만 추가 시간이 있습니다. 따라서 관리자는 추정치를 낮추라고 제안합니다.
tintin

@Michael,이 답변은 일부 민첩한 프로세스에 해당 될 수 있지만 문제는 Scrum과 관련이 있습니다. Scrum에서는 스프린트 계획 후에 팀 속도 메트릭이 손상 될 수 있으므로 스토리 포인트를 변경하지 않는 것이 좋습니다.
GuyR

실패한 추정치는 향후 추정을 적절히 조정하는 데 사용할 수 있다는 이점이 있습니다. 예상 시간이 너무 길면 리소스를 충분히 활용하지 못하기 때문에 예상 시간이 너무 짧아 실패로 인한 것입니다. 올바른 추정치의 가치는 릴리스 목표를 달성 할 가능성이 있으며 팀이 완전히 활용되고 있다는 것입니다. 따라서, 당신은 항상 당신의 과거 경험에 기초하여 미래의 추정치를 기반으로하며, 그 과정에서 당신의 추정치에 대해 배운 것에 따라 조정합니다.
S.Robins 2012 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.