스크럼 프레임 워크의 스토리 포인트에 대한 측정 규모 [폐쇄]

Question

이 스크럼 기사 :

스토리 포인트는 직접적으로 번역하지 않는 상대 값입니다. 특정 시간 수. 대신 이야기 포인트가 팀이 정량화하는 데 도움이됩니다 사용자 이야기의 일반적인 크기. 이러한 상대적인 추정치는 적습니다 그들이 결정하기 위해 노력하는 노력이 덜 필요하고, 그들은 붙잡을 수 있도록 정확합니다. 시간이 지남에 따라 더 나은. 스토리 포인트를 추정함으로써 귀하의 팀은 의지입니다 사용자 이야기의 일반적인 크기를 지금 제공하고 더 많은 것을 개발하십시오. 팀 구성원이 나중에 나중에 일하는 시간의 상세한 추정 사용자 이야기를 구현하려고합니다.

누구도 명확하게 할 수 있습니다 :

1. 스토리 포인트의 측정 규모 여야하는 것은 무엇입니까? 주어진 제품 백 로그에 할당 된 10, 100 또는 가장 높은 스토리 포인트가 없어야합니까?
2. (약간의 오프 토픽) '제품 백 로그 항목'(첨부 된 이미지 확인)은 프로젝트의 모든 사용자 스토리로 구성되어 있으며 Sprint Backlog에는 제품 백 로그의 이야기의 하위 집합이 포함되어 있습니다. 라고 한; 하나의 제품 백 로그가 충분하다면 TFS가 우리가 여러 개의 제품 백 로그 항목을 가질 수있는 이유는 무엇입니까? 에 대한 제품 백 로그 항목

Answer 1

1. You can use any scale you like. What I tend to do is the Fibbonaci (1, 2, 3, 5, 8, 13, 21, ...). To set the baseline of the scale we took a golden story which was average size and valued that with an 8 and one with a little less size and valued that 5. We now just value all the other stories to those two. And since you are working Agile you are just continuously improving. So if you feel that you need to have different golden stories: just do it.
2. The PBI (Product Backlog Item) work item is not the Product Backlog itself. It is the story on the backlog. The Product backlog list all the stories you would like to implement at some point in a specific order (hopefully the one with the highest business value is on top). When you want to pull a story into a sprint you change the iteration path. It is now pulled off the product backlog and shown on the sprint backlog.