나는 이것이 드문 주제가 아니라고 확신합니다. 우리는 스토리 포인트를 사용하여 사용자 스토리를 추정하는 작업을 수행하는 두 개의 스크럼 팀을 보유하고 있습니다 (현재 팀 별자리는 약 8 개월 이었지만 팀 구성원은 수년간 스크럼 경험이 있습니다). 그러나 회사의 비즈니스 부분이 사용자 스토리와 관련이있는 것은 어렵습니다. 실제 시간 단위 (또는 "스토리 포인트를 시간으로 변환하는 공식")를 사용하여 상황이 준비 될시기에 대한 계획을 세울 수 있습니다 ( "고객에게 Feature X가 프로덕션에 있음을 알릴 수있는 시점을 알아야 함) " ).
저와 스크럼 마스터 전임자들은 물론 "스토리 포인트와 실제 시간 사이에는 명확한 관계가 없으며"스토리 포인트는 팀이 스프린트에 얼마나 적합한지를 결정하는 데 사용됩니다 "라고 설명했습니다. 그들이 그 대답에 얼마나 만족했는지 추측 할 수 있습니다. 그들은 여전히 우리가 백 로그에서 27 번째 사용자 스토리를 볼 수있는 달력 시간을 알고 싶어합니다.
어쨌든 일부 통계를 수집하고 있으며 SP 추정값 은 스크럼 보드 소프트웨어로 측정 한 것처럼 실제 작업 시간이 크게 다른 결과 로 변환됩니다. 티켓은 "작업 중"열에 소요 된 시간을 추적합니다. ). 1-SP 사용자 스토리의 경우, 매우 짧은 시간 범위 (때로는 폭발로)에 대한 큰 편견이 있지만, 특히 2-SP 스토리의 경우에는 여기 저기 있습니다. "가장 빠른"완성과 "가장 느린"완성 사이. 3, 5, 8-SP 스토리의 경우 스프레드는 2 배 이상입니다.
이는 (a) 유사한 복잡성에 대한 사용자 스토리를 추정 할 때 팀이 훨씬 더 일관성이 있어야하고 (b) 시간보고의 정확성을 개선해야한다는 것을 나타냅니다 (즉, 티켓을 외부로 이동시키는 것을 기억해야 함). 회의 중이거나 점심을 먹거나 축구를 할 때 "작업".
나는 (a)와 (b)를 모두 개선 할 계획이 있지만, 이것으로 충분하지 않다고 생각합니다. 비즈니스는 이러한 이니셔티브가 산출하는 것보다 "더 구체적"을 기대합니다.
비즈니스 측면 을 적용 할 때 좋은 전략은 무엇입니까? 따라서 우리가 일하는 방식을 너무 많이 방해하지 않도록하십시오 (예 : 별도의 시간 추적을 사용하여 IMHO가 어쩌면 덜 정확하기 때문에 바보 일 것입니다) 현재의 "자동"추적)과 동시에 스토리가 언제 이루어질 지에 대한 구체적인 측정치를 얻을 수 있습니까?
(역사적으로 계획 중에는 사용자 스토리를 작업 항목으로 세분 한 다음 실제 작업 시간으로 개별적으로 추정 했지만 여기에서 내가 말하는 것은 백 로그의 사용자 스토리가 해당 레벨의 세부 사항을 갖지 않거나 깨지지 않습니다. -내려가는.)
업데이트 : 관리자는 이야기 당 소요 시간의 종 곡선 분포가 있었지만 직감 한 데이터와 그가 만든 그래프가 그 개념에 대해 반박했습니다. :-)