스크럼의 스토리 추정 [닫기]

Question

Scrum/XP로 관리할 프로젝트를 시작했습니다.우리는 평가 목적으로 전체 제품 백로그를 미리 작성했습니다.우리는 모든 스토리가 고객 중심인지 확인하고 다음을 통해 스토리를 평가합니다.

• 스토리 비즈니스 가치: 모스크바 기술 - 이것을 구현해야 합니다, 해야 합니다, 할 수 있습니다, 할 것입니다/하지 않을 것입니다
• 스토리 노력/복잡성 (= 스토리 포인트):1, 2, 3, 5, 8, 13, 21, 100 - 이상적인 기간보다는 스토리 복잡성/노력과 관련됨

100개의 스토리 포인트에는 가질 수도/없을 수도 있는 스토리가 있을 수 있습니다. 왜냐하면 실제로는 필요한 경우 나중에 분해될 ​​더 크고 복잡한 스토리이기 때문입니다.

계획된 이야기의 중요성 MoSCoW 이야기를 중복하지 않고 가치와 노력을 바탕으로 합니다.

그러나 100개 포인트 스토리가 없으면 지금까지의 스토리(역시 세분화됨)는 2에서 8 사이의 복잡성을 가지며 이는 마이크로 관리를 피하기에 적절한 스토리 크기라고 생각합니다.그러나 일부 이야기는 서로 연관되거나 의존하게 되었습니다.먼저 완료하면 더 많은 시간이 걸릴 수 있는 이야기가 있고, 그 전에 다른 이야기가 완료되면 더 적은 시간이 걸릴 수 있습니다.

질문
스토리 포인트를 재평가하고, 새 항목을 추가하고, 기존 항목을 제거할 수 있는 스토리 작업과 같이 나중에 개발 중에 스토리 포인트를 조정할 수 있습니까? 아니면 스토리의 경우에는 그렇지 않습니까?복잡성을 변경하면 계획된 속도에 따라 종료 날짜 추정도 변경됩니다.이 경우 가장 좋은 방법은 무엇입니까?

Answer 1

당신은 당신의 이야기를 다시 평가할 수 있고 그렇게 해야 합니다.포인트는 스프린트 시작 직전 스프린트 계획 세션에서 팀이 약속한 경우에만 잠깁니다.

제가 사용한 한 가지 방법은 개별 스프린트 계획을 세울 때 각 스토리를 다시 평가해야 한다는 것입니다.팀은 시간이 지남에 따라 학습하고 예측 및 종속성 식별을 통해 더욱 정확해질 것입니다.스프린트에 들어가는 것은 팀에 달려 있으며, 제품 소유자는 전체 백로그를 정의합니다.프로젝트에 시간 제한이 있는 경우 견적을 종료일에 맞추려고 하지 마십시오. 그렇게 하면 실패할 위험이 있습니다.

Velocity에서는 무엇을 달성할 수 있을지 추측하는 것부터 시작한다는 점을 기억하세요.일반적으로 3번째 또는 4번째 스프린트가 되어서야 팀이 관리할 수 있는 현실적인 속도를 식별할 수 있습니다.예, 이는 팀이 스프린트당 20포인트를 제공할 수 있다고 가정했지만 실제로는 15포인트만 제공할 수 있다는 의미입니다.예, 이는 배송 시간이 늦어지거나 스토리가 컷라인 아래로 떨어진다는 의미입니다.

의존적 스토리의 경우 제품 소유자와 협력해야 합니다.팀이 그들과 이야기를 나누면 일반적으로 이야기를 재정렬할 수 있습니다.대부분의 사람들은 "지금 A를 하면 전체 스프린트가 필요하지만 나중에 A를 하면 스프린트의 15%가 필요합니다"라고 말하는 사람을 잘 받아들입니다. 이는 꽤 설득력이 있습니다.

시도해 볼 수 있는 유용한 방법은 스프린트 내에서 스토리를 예약하는 것입니다.계획 세션 동안 모든 이야기가 검증되고 논의되면 팀은 일정을 표시하고 언제 작업을 완료할지 논의합니다.달력에 목표 날짜를 입력하면 스토리 간의 중복과 종속성을 식별하는 데 도움이 됩니다.이를 통해 본질적으로 연속적인 항목을 식별할 수 있으며 스프린트 실패를 유발할 수 있습니다.

이 정보가 도움이 되기를 바랍니다.

Answer 2

귀하의 설명에 따르면 귀하는 이미 훌륭한 일을 하고 있습니다.물론 의존성이 있는 이야기는 항상 있을 것입니다.일부는 고객 가치가 직접적으로 보이지 않을 수도 있습니다.즉.아키텍처 및 일부 프레임워크를 설정하기 위한 초기 노력)하지만 이를 제외하면 많은 기술적 부채가 발생하게 됩니다.가능하다면 방정식을 완성하고 어떻게든 작업 간의 관계를 보여 주는 것이 좋습니다.

예를 들어:- 과제 3은 과제 2 이후에 완료하면 8점, 독립적으로 완료하면 12점입니다.

이렇게 하면 제품 소유자는 종속성을 무시하는 고통을 느끼지만 여전히 가장 가치 있는 스토리를 먼저 수행하도록 선택할 수 있습니다.제품 소유자가 모든 스토리가 다음 스프린트에서 성공할 것이라고 확신한다면 가장 효율적인 순서로 스토리를 구현하도록 방향을 잡을 수 있습니다.예를 들어 종속성이 충족되지 않은 항목을 차단함으로써(예:스토리 '웹 버전'이 완료된 후에만 '웹 사이트에서 내 로고 변경' 기능을 사용할 수 있습니다.)

행운을 빌어요!

Answer 3

나는 내 경험만을 설명할 수 있다.

첫 번째 스프린트를 계획할 때 우리는 18포인트를 달성할 수 있다고 결정했습니다.그래서 여러 이야기를 받아 총 평가액이 15점이었습니다.위에서 언급했듯이 우리는 스크럼의 첫 단계를 밟고 있었고 이것이 바로 우리가 사용하지 않은 3개의 포인트와 폼 팩터 0.6이 우리의 성공을 보장하기로 결정한 이유입니다.

그러나 각 이야기에 대한 우리의 추정은 대략적인 것에 불과했습니다.우리는 또한 의존적인 이야기를 가지고 있었습니다.그리고 애자일 방법론으로는 불필요하다고 생각하여 각 스토리의 구현 계획을 세우지 않았습니다.

결과적으로 우리는 단 8개의 완전한 포인트로 첫 번째 스프린트에 실패했습니다.

두 번째 스프린트 전에 나는 오래된 간단한 계단식 및 반복 방법론에서 뭔가를 취해야 한다고 결정했습니다(그리고 저는 스크럼 마스터였습니다).그래서 다음 봄에 올바른 추정을 하기 위해 간단한 다이어그램, 모든 종속성, 구현 세부 사항 등을 사용하여 각 스토리(스토리당 약 20분)를 계획했습니다.기획이 어려워서 2번의 회의가 걸렸습니다.

그러나 두 번째 스프린트는 훨씬 나아졌고 거의 모든 작업을 수행했습니다(실제로 일부 버그를 제외하고는 모두 수행했습니다).제 생각에는 3번째 스프린트에서는 폼 팩터를 덜 사용하게 될 것이고 성공할 것입니다.

Answer 4

사용자 스토리를 투자 상태로 유지하는 방식으로 분할하는 데 도움이 되는 몇 가지 패턴이 있습니다. 즉, 특히 종속성, 크기, 테스트 가능성 및 가치를 저장하려고 시도한다는 의미입니다.이에 대한 자세한 내용은 여기에서 확인할 수 있습니다. http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard는 이를 적극적으로 적용하고 개선하고 있으며 혼자가 아닙니다 ;-)

간트 차트에서 중요한 경로를 생성하는 것과 같은 종속성을 분할하고 유지하는 것은 팀의 창의성과 해당 스토리에 대한 협상 능력을 압도하고 "가치 없는" 요소를 숨길 수도 있다는 점을 명심하세요. -제안".

HTH
안드레아트