장기 계획 (릴리스 계획)이 스토리 포인트에 있어야한다는 것을 알고 있습니다.
하지만 스프린트 계획의 경우에는 헌신해야합니다.
제품 백 로그 항목 / 사용자 스토리를 작업으로 나누고 작업을 추정하고 팀이 제품 백 로그 항목을 제공 할 수 있는지 스스로 물어 본 다음 가득 찰 때까지 반복합니까?
3 주 스프린트 동안 한 사람의 각 스토리는 얼마나 커야합니까?
또한 일부 팀은이 작업 기반 계획을 없애고 2 일 길이의 스토리를 가지고 있음을 보았습니다. ?
내 팀을 위해 이것을 표준화해야합니까?
스프린트 전에 내 이야기를이 표준에 맞는 짧은 이야기로 나누었습니다.
제발, 이에 대한 귀하의 견해를 알려주십시오. 일반적인 관행은 무엇인가요?
댓글
Answer
TL; DR
기본적으로 전체 계획 가정은 민첩하지 않습니다. “반복을 어떻게 계획하고 있는지, 팀이 현재 반복에 대해 완료 될 수 있다고 생각하는 작업을 추정하는 방법을 다시 검토해야합니다. 자세한 분석은 다음과 같습니다.
상세 분석
장기 계획 (출시 계획)이 스토리 포인트에 있어야한다는 것을 알고 있습니다. [sic]
아니요. 애자일 릴리스 계획은 반복 으로 수행됩니다. 따라서 스크럼 프로젝트 계획은 최소 실행 가능한 제품에 도달하거나 초기 제품 백 로그를 완료하는 데 필요한 대략적인 반복 범위를 추정합니다. 백 로그 내용은 시간이 지남에 따라 변경되고 추정의 길이와 정확성도 불확실성의 원뿔 과 함께 변경되므로 추정치입니다.
하지만 스프린트 계획의 경우 약정 기반이어야합니다.
다시 말하지만 Sprint Planning은 용량 기반 . 유일한 추적 지점 (또는 팀의 평균 속도에 대한 초기 추측 값을 만드는 것은 시간이 지남에 따라 팀의 지속 가능한 작업 능력을 찾는 것입니다. 팀은 속도 범위 또는 평균이 사용 가능한 용량이 있어야한다고 말하고 있기 때문에 스프린트에서 작업하기 위해 과도하게 노력하지 않아야하지만 팀 구성, 가용성을 고려하여 현재 반복을 계획하는 것은 팀의 책임입니다. , 그리고 현재 스프린트에 영향을 미치는 기타 요인을 고려합니다.
스프린트가 “커밋 기반”이라고 말하는 것은 팀이 참여하도록 유도하는 감정적 실수로 사용될 가능성이 높습니다. 당연히 팀 구성원이 “약속”되어야하기 때문에 그들이해야하는 것보다 더 많이 일합니다. 그러나 그것은 오용입니다. 현실 세계에서 팀 역량은 일반적으로 감소되어야하지만 계획 중에는 거의 부풀려지지 않습니다. 팀이 부족한 작업을 수행 한 경우 필요에 따라 추가 작업을 제품 백 로그에서 제거 할 수 있지만 범위 조정은 거의 항상 정치적으로 어려움을 겪고 종종 스프린트 목표를 위험에 빠뜨립니다. 그러니 그렇게하지 마세요.
용량은 상대적으로 객관적인 측정 항목이 될 수 있습니다 . 반면에 헌신 (애국심과 매우 유사)은 “당신이 아니면”측정 할 수 없습니다. 민첩한 지속 가능성이라는 전제에 반대되는 궁극의 희생을 사람들에게 요청합니다. 절대 죽음 행진 을 약속하지 마세요.
3 주 스프린트의 경우 각 스토리의 크기는 어느 정도 여야합니까?
이 책은 아니요로 가득 찬 전체 책에 해당합니다. 이야기는 개인에 맞게 크기가 조정되거나 수용되지 않습니다. 모든 이야기는 함께 함께 작업하는 교차 기능 팀의 전체 조정 리소스를 기반으로 추정됩니다. em> 각 스토리를 완료합니다. 스토리는 다음 여부에 따라 수락 또는 거부됩니다.
- 현재 스프린트 목표에 필수적입니다.
- 예상 용량에 맞을 것입니다. 현재 Sprint에서 사용할 수 있습니다.
단일 제품 백 로그 항목은 언제든지 가능합니다. 0 스토리 포인트에서 전체 스프린트에 사용할 수있는 최대 값까지. 그러나 INVEST 기준 을 충족하는 좋은 스토리는 일반적으로 약 0.5 일에서 2.0 일 길이의 Sprint Backlog 작업으로 구성됩니다. 작업이나 스토리가 작을수록 일반적으로 추정치가 더 정확하므로 일반적으로 단일 60 포인트 스토리보다 12 개의 5 포인트 스토리 (정확하게 추정 된 경우)가 더 신뢰할 수 있습니다. 그러나 팀 성숙도와 추정 정확도는 확실히 다를 수 있습니다.
답변
사용자 스토리는 팀 구성원별로 제공되지 않습니다.
여러 팀 구성원이 동일한 사용자에 대해 작업해야합니다. 동시에 이야기. 이것은 요구 사항이 아니라 권장 사항입니다. 럭비 용어 인 스크럼 의 핵심으로 팀이 하나의 단위로 골라인을 향해 나아갑니다. 이 개념을 swarming 이라고합니다. 모든 사람은 주어진 순간에 하나 (또는 그 이하)의 작업에 집중하고이를 완료하고 다음 작업 (반복)을 처리합니다. 이점 :
- kees_in progress_ 항목이 더 적습니다.
- 스프린트가 끝날 때까지 모든 것이 완료되는 대신 스프린트 전체에 분산 된 스프린트 백 로그 항목을 완료 할 수 있습니다.
- 스프린트 기간 동안 qa / 테스트로드를 균등하게 분산합니다.
- 전체 팀이 코드 지식을 얻고 기술적 제안을 제공 할 수 있습니다.
팀은 이야기를 골라서 기술적 인 작업으로 나눕니다. 이 경우 일상적인 스크럼 회의 중에 도움이되는 책임이 명확하기 때문에 한 사람 만 하나의 기술 작업을 수행해야합니다. 이상적으로는 하나의 기술 작업이 하루 동안 완료 될 수 있도록 충분히 작아야합니다.
사용자 스토리의 크기
Scrum은 어떤 것도 정의하지 않습니다. 사용자 스토리의 권장 크기. 그러나 스토리는 한 번의 스프린트 동안 완료 될 수 있도록 크기가 조정되어야합니다. 완료는 완료의 정의를 포함 함을 의미합니다.
스토리는 명확하게 이해되어야하며 동일한 스프린트 동안 확인되는 명시적인 수락 기준 이 있어야합니다. 일반적으로 큰 이야기를 정리하고 모든 허용 기준을 철자하는 것이 더 어렵 기 때문에 이야기는 충분히 잘 추정하고 테스트 할 수있는 작은 크기 여야합니다.
이야기는 충분히 커야합니다. 이해 관계자에게 구체적인 비즈니스 가치를 제공합니다.
따라서 답은 너무 작지도 크지도 않습니다 입니다. 연습과 경험을 통해 사용자 스토리를 작성하고 나누는 데 더 유용합니다. 과학보다는 예술에 가깝습니다.
답변
스프린트 계획도 스토리 포인트에 있어야합니다. 프로세스는 장기 계획과 동일합니다. 속도와 능력을 확인하고 (휴일 등으로 인해 팀원이 몇 명 일지) 스프린트 2를 계획하고 있다면 스프린트 1에서 속도 (예 : 10 포인트)를 확인하고 10 포인트에 해당하는 사용자 스토리를 반복 백 로그에 넣습니다.
스프린트 3을 계획하는 경우 스프린트 1에서 2까지의 속도 추세를 확인하고 약정 할 수있는 양을 찾습니다.
스프린트 1을 계획하는 경우 다음과 같이 추가합니다. 당신은 적합하다고 생각합니다.
사람이 할 수있는 포인트를 보지 마십시오. 스크럼은 사람이 아닌 팀에 대해. 예를 들어 후배는 시니어보다 적게 할 수 있지만 서로 돕는 사람들은 “서로”만큼 많은 것을 전달할 수 없습니다. 팀과 함께 작업하고 계산합니다. , 더 이해하기 쉽고 더 쉽습니다.
댓글
- 예, 참조 할 이전 스프린트의 총 스토리 포인트에 동의하며 사용자 / CodeGnome이 말했듯이 용량도 고려해야합니다. 사실, 얼마나 짧아야하는지 혼란 스럽습니다. " 각 " 스토리를 통해 별도의 테스트 단계가 없으므로 병렬로 테스트 할 수 있습니다.
- 또한 이전에 다음을 참조했습니다. mountaingoatsoftware.com/blog/ …
- @Roop, 다른 사람들이 말했듯이, " 각 " 스토리는 충분히 짧을 필요는 없습니다. 여러 팀원이 작업하지만 스토리 내의 작업은 0.5 일 ~ 2 일 보관
-" 예측 ". 여기에서 변경 이유를 읽을 수 있습니다.