적절한 Ready for Sprint 정의에는 무엇이 포함되어야 합니까?

Question

우리 회사의 팀은 적절한 백로그 정리를 수행하기 위해 우리가 원하는 만큼 많은 시간을 할애할 수 없는 위치에 있는 제품 소유자를 처리합니다.

따라서 시간 제약을 완화하기 위해 "Ready for Sprint" 스토리를 가져오는 기술을 구현하기 시작했습니다. 즉, 스토리를 스프린트로 가져갈 만큼 충분히 알고/이해한 상태로 만드는 기술을 구현하기 시작했습니다.

불행히도 우리는 'Ready For Sprint'의 적절한 정의가 무엇인지 아직 생소하기 때문에 백로그 Ready for Sprint에서 스토리를 얻을 때 염두에 두면 좋은 점은 무엇인지에 대한 질문입니다.

[편집하다]

Ryathal과 Donal Fellows의 답변과 의견에 대한 응답으로 저는 우리가 실제로 이야기를 만들 의도가 아님을 설명하려고 합니다.우리는 이 블로그 게시물에 설명된 대로 기존 스토리를 "스프린트 준비"로 가져오는 관행을 적용하고 싶습니다. 제품 소유자는 아마도 여기에 추가해야 하지만 언급한 바와 같이 우리는 제품 소유자와 (아직) 최고의 위치에 있지 않습니다.

노력 포인트가 5 이하인 경우 스토리가 준비 상태에 있거나 스토리에 최소 허용 기준이 정의되어 있어야 하거나 Balsamiq Mockup 등이 있어야 하는 것과 같은 정의를 만들 수 있다는 것을 읽었습니다.

제 질문은 다른 사람들이 정의에 사용한 것과 효과가 있는 것을 찾는 데 맞춰져 있습니다.:)

Answer 1

스프린트가 끝날 때 수락이 문제가 되지 않을 만큼 충분한 정보가 포함되어야 합니다.

때로는 한 문장으로 충분합니다.

종종 일부 팀 구성원은 아무도 마음을 바꾸지 않고 합의된 모든 내용을 기억할 수 있도록 더 많은 정보/요구 사항을 기록하기를 원할 것입니다.

기록된 모든 것은 가능한 한 객관적/검증 가능해야 합니다.나는 'given/when/then' 및 'as ... i ... so that ...' 형식을 좋아합니다. 많은 정보와 검증 가능한 요구 사항을 간결한 형식으로 전달하기 때문입니다.

스토리 라이프사이클(스프린트 준비, 승인...)의 여러 단계에 대한 '규칙' 또는 게이트를 정의하려는 몇 가지 시도를 보았고 내 경험으로는 규칙만으로는 잘 작동하지 않습니다.스토리가 고려해야 할 사항(사용 사례, 테스트 계획, 모형, 승인 기준, 문서 등)에 대한 지나치게 포괄적인 목록을 갖게 되는 것은 매우 쉽습니다.이러한 항목이 '좋은' 것인지 확인하는 것은 매우 어렵습니다.그리고 많은 경우(많은 공유 컨텍스트 또는 놀라운 콘텐츠가 포함된 단순한 이야기), 모의, 테스트 계획 및 세부 정보는 시간 낭비입니다.

최근의 예: 'XI가 Y를 원할 때'를 권장하면서 결국 '관리자로서 플랫폼에서 데이터 기밀성과 무결성이 유지되기를 기대합니다.'지침을 충족하지만 개발자에게 전달/테스트/문서화에 필요한 것을 알려주는 데는 전혀 쓸모가 없습니다.

PO와 dev 사이에 좋은 의사 소통에서 벗어날 수 없다고 생각하고, 각자가 생각하는 것에 대한 좋은 느낌이면 충분합니다.

Answer 2

다음과 같은 경우 스토리가 "스프린트 준비"가 된 것입니다.

• 검증 가능한 요구 사항을 포함하고
• 고객이 원하는 것과 일치한다고 생각합니다.

또한 소유자와 협력하여 함께 작업하는 데 할애할 수 있는 시간을 늘리고 아직 할 수 없는 경우 소유자가 스스로 일부 백로그 정리를 할 수 있는 방법을 찾아야 합니다.더 많은 참여를 유도하는 가장 좋은 방법은 현재 수준의 상호 작용으로 품질을 제공하고 더 많은 참여가 결과를 더욱 향상시킬 수 있다고 설명하는 것입니다.

Answer 3

나는 ready 의 정의가 꽤 자명하며, 명시적으로 정의할 가치가 없다고 생각합니다.

스프린트가 끝날 때까지 PO가 사라지고(발생할 수 있음) 팀이 스토리에서 말하는 대로 빌드하면 제품 소유자가 '이것은 우리가 합의한 사항이 아닙니다'라고 말할 수 있는 방법이 있습니까?그렇지 않은 경우 준비가 된 것입니다.

스프린트에 대한 PO의 참여와 스토리 유형에 따라 매우 상세하거나 매우 간단할 수 있습니다.