이야기의 스크럼 재 추정

매일 일어나서 팀과 저는 각 이야기에 대한 추정치를 업데이트합니다. 우리가하는 방식에 문제가 있다는 느낌이 들기 때문에 도움이 필요합니다.

이것이 우리가하는 방법입니다 :

사례 A 추정치 : 24 시간 (하루 8 시간- "이상적인 날"을 측정 값으로 사용)

• N 일 : 개발자가 아침에 스토리 A에 대한 작업을 시작합니다 (8 시간 동안 작업 완료)
• N + 1 일 : 스토리 A 재 추정 = 16 시간 (N 일부터 스토리 A에서 1 일 근무)
• N + 2 일 : 스토리 A 재 추정 = 8 시간 (N + 1 일부터 스토리 A에서 1 일 근무)
• N + 3 일 : 스토리 A는 지금까지 완료되어야합니다. 그러나 그렇지 않습니다. 개발자는 완료하는 데 3 시간이 더 걸릴 것이라고 생각합니다. 우리는 화이트 보드의 이야기를 업데이트하고 그에 따라 번 다운 합니다.
• N + 4 일 : 스토리 A가 3 시간이 아닌 하루 종일 완료되었습니다! 이제 끝났습니다. 5 시간의 차이는 계획에서 완전히 설명되지 않습니다.

우리는 어떻게 이야기를 매일 다시 추정해야합니까?

5h의 차이는 계획에서 완전히 설명되지 않았습니다.

예, 다음 작업이 지연되어 암시 적으로 설명됩니다. 해당 개발자에 대한 번 다운 차트가있는 경우 개발자가 다른 작업을 수행 할 수있을만큼 일찍 완료 한 경우 곡선이 하루 동안 "평평한"상태로 유지 된 것을 볼 수 있습니다.

일일 회의에서 재추 정하는 방식에는 아무런 문제가 없습니다. 재 추정은 각 작업의 정확한 지체를 추적하는 것보다 스프린트가 끝날 때까지 해결할 수 있는지 파악하는 것입니다. 스크럼에서 매일 계획을 조정하기 위해 필요한 것은 스프린트 진행 상황과 스프린트 목표를 달성하는 데 걸리는 거리 (일반적으로 번 다운 차트)를 나타내는 것입니다.

당신이 묻는 질문은 : 우리는 우리의 이야기를 재 추정해야 하는가?

나는 당신이 Agile "매직"이 다음에 대한 속도를 계산할 때 반복에 대한 과소 평가와 과대 평가의 균형을 유지해야한다고 주장합니다 (이는 값을 수정하는 유일한 이유입니다). 자세한 내용은 Mike Cohn의 Agile Estimating and Planning 을 참조하십시오.

그러나 재 추정해야 할 경우가 있습니다. 작업 범주에 대해 배운 것이 앞으로 모든 추정치를 조정하는 경우입니다.

예. 데이터베이스에 열을 추가하는 이상적인 시간이 걸릴 것으로 예상하지만, 아무도 생각 없음으로 인해 일부 요소 3 시간이 걸릴 것으로 판명 된 경우 와 그 요인은 데이터베이스에 필드를 추가 할 때마다 적용 할 것 같습니다 그런 다음 작업중인 것을 포함하여 해당 자연의 작업에 대한 모든 추정치를 조정해야합니다.

내가 가장 효과적인 것으로 밝혀진 것은 :

• 포인트 별 스토리 크기 (또는 티셔츠 크기)
• 언제든지 제품 백 로그의 모든 스토리를 다시 추정하십시오 (특히 스프린트 계획 직전).
• 이 스프린트로 예정된 이야기를 재 추정하지 마십시오. 스탠드 업시 문제를 제기 할 수 있지만 예상치를 변경하지 마십시오.
• 스프린트 예약을 위해 어제 날씨 사용

스토리가 가짜 추정치로 스프린트 에 들어가는 경우, 스프린트 전 계획 재 추정을 통해 문제가 발생하기 전에이를 해결할 수 있습니다. 팀이 너무 낙관적이어서 스토리가 예상보다 오래 걸리는 경우 어제의 날씨로 인해 추적이 가능합니다.

질문에 설명 된대로 남아있는 것을 매일 다시 추정하는 것은 완전히 가짜 경향이 있습니다. 완성 된 작업 / 남은 작업은 "충분히 열심히"일하는 것처럼 보이도록 설계된 가짜 숫자입니다. 훨씬 더 나은 방법은 "언제 언제 완료 될 것이라고 생각합니까?"라는 질문을하는 것입니다. 스토리에 문제가있는 경우 팀이 도움을 청할 것임을 분명히하십시오.

나는 이것이 문제가되지 않는다고 생각한다. 오히려 경험이 부족할 수 있습니다. 스크럼을 따를수록 더 정확한 평가를 제공하는 데 더 많은 개발자가 익숙해집니다. 5 개월 후 스크럼을 구현 한 경험입니다.

에서 포커 계획 세션을, 우리의 개발자들은 매우 다양 각 PBI에 대한 추정 및 첫 번째 전력 질주에서 각 작업을 제안했다. 그러나 이제는 시간과 추정이 거의 동일합니다. 스크럼을 사용한지 얼마나 되었습니까? 그렇게 많지 않으면 시간을 내십시오. 그러나 시간이 오래 걸리면 @pdr이 제안한 것처럼 위험 이 높은 작업에 여유를 추가하는 것이 좋습니다 . 예를 들어, 우리 팀이 UI 크로스 브라우저를 만들 때마다 우리는 추정을 통과합니다. 따라서 우리는 항상 브라우저 간 작업의 추정치에 계수를 곱하여이를 처리 할 수 ​​있는지 확인합니다.

스프린트 중에 커밋 된 사용자 스토리를 다시 추정하는 것은 의미가 없습니다. 시간 낭비입니다. 당신은 이미 약속을했고 재 추정을하는지 여부는 중요하지 않습니다.

다른 상황은 현재 스프린트에 전념하지 않은 사용자 스토리입니다. 때때로 재추 정하는 것이 좋습니다 (계획 전에 스프린트 당 한 번만). 재 추정이 합리적인 이유는 다음과 같습니다.

• 제품 소유자가 사용자 스토리를 변경했습니다
• 제품 소유자가 사용자 스토리를 분할 또는 병합
• 제품 소유자가 사용자 스토리를 추가 함
• 마지막 사용자 스토리 중에 사용할 수 없었던 추가 지식이 있습니다.
• 일부 사용자 스토리가 관련되어 있으며 아직 커밋되지 않은 다른 사용자 스토리의 일부를 수행했습니다.
• 기타

모든 사용자 스토리를 반드시 재 추정 할 필요는 없지만 가능합니다. 완전한 재 추정을 위해서는 일반적으로 빠른 방법이 필요합니다. 포커 계획은 속도가 느리고 비효율적이며 지루하며 때로는 10-20 개 이상의 스토리를 취하면 정확하지 않을 수 있습니다. 대안은 매직 추정 일 수 있습니다 .