번 다운 차트가 감소하지 않음

Question

소프트웨어 엔지니어링 시험을 위해 개정 중이며 질문 중 하나가 궁금합니다. 팀에서 10 일 동안 사용자 스토리를 진행하지 않은 번 다운 차트를 보여줍니다. 문제는 "ScrumMaster가이 시점에서 취할 것을 고려할 수있는 모든 동작의 개요 및 정당화"입니다.

나는 스프린트를 멈추는 것과 같은 과감한 행동을 생각했다. 그런 다음 쌍 프로그래밍을 할당하여 사용자를 돕고 사용자 스토리를 더 많이 분석하는 것을 고려해야합니다. 아무도 다른 제안이 있습니까? (이 문제는 과거 논문에서 네 가지 가치가 있었다.)

Answer 1

필자는 실제로 "좋은"대답을 줄만큼 충분한 정보가 없기 때문에 개인적으로 이와 같은 추상적 인 질문을 싫어합니다. 스프린트는 얼마나 걸립니까? 팀은 무엇을하고 있었습니까? 진보가없는 근본적인 원인은 무엇입니까? 이것들은 당신이 팀의 스크럼 마스터라면 이미 알고있는 모든 것입니다. 결코는 10 일 후에 번 다운 차트를보고 나서해야할 일을 파악할 수있는 위치에 있어야합니다. 예를 들어

:

• 아마 팀은

• 어쩌면 부분적으로 완료되었지만 때문에 완성되지 않은 이야기가있는 프로젝트의 컨텍스트 외부 "비상"작업을 수행하는 임무되었습니다 병목 현상 (예 :테스터를 사용할 수 없거나 디자이너가 없거나 최종 사인을 위해 PO가 없기 때문에 스토리가 완성되지 않음)

• 어쩌면 스토리가 너무 길어서 이야기에 지장이있을 수 있습니다. 매우 복잡한 것으로 판명와

가 진짜 대답은 실제 작업 상황에 따라 달라 조정할 수있는 큰 공의 진흙이고 어려운 시스템의 영역을 노출했다. 나는이 안되고하는 문제에 십일를 해결해야하는 문제가 있다고 파악 왜

1. 알아낼 수있는 알림을 쓰기 : 내가 대답 할 수 밖에 없었다 경우 뭔가처럼 될 것입니다.

2. 는 회고 스프린트이 화제를 불러옵니다 알림을 쓰기 - 나쁜 일이 분명히 병목/문제가 무엇인지

3. 그림을 일어나고 시도하고 그것을 해결되기 때문이다. 우리가 자기 주도적 인 문제 해결에 능숙한 팀을 가지고 있다면, 모든 사람들이 하나의 이야기로 붐비는 작업 모드로 전환 할 것을 제안 할 수 있습니다. 그래서 적어도 몇 가지 일을 끝낼 수 있습니다.

...하지만 진짜 답이는이 사이트에 대한 적절한 질문의 범위 내에 있지 않기 때문에에 정의 된 ;-)

Answer 2

완전한 답변을 제공 할만한 정보가 충분하지 않지만 경험상 스크럼 마스터로서 할 일은 시간이 지남에 따라 스토리 포인트가 아니라 시간이 지남에 따라 업무 시간을 표시하는 번 다운 차트를 보는 것입니다.

시간이 제대로 구워지는 것을 보는 것이 일반적이지만 스토리 포인트는 정적으로 유지됩니다. 팀이 스프린트가 끝날 때까지 테스트를 떠나기 때문에 종종 '미니 폭포'라고 불리기 때문에 스프린트가 끝날 때까지 이야기가 끝나지 않습니다.

스크럼 마스터로서의 시나리오가 맞다면 팀이 스프린트 회고전에서 이런 방식으로 일하는 이유에 대해 이야기를 듣는 데 집중할 수 있도록 시간을 할애했습니다. '가능한 빨리 WIP를 줄이십시오.

Answer 3

왜 이런 일이 발생했는지에 대한 근본적인 분석은 무엇일까요? 스킬 차이인가? 주제에 대한 지식, 팀으로서이 사용자 스토리에 접근하는 방법을 알고, 스프린트 계획 세션에서 사용자 스토리를 작업으로 분해했는지, 전체 프로세스에서 PO 협력에 충분한 참여자인가?

좋은 스프린트 계획이 필요하며 뒤따른 제품 백 로그 그루밍 세션도 이러한 문제를 피할 수 있었다면 발생할 수 있습니다.

더 많은 사람들이 기술 환경/도메인 등을 처음 사용하는 경우 팀이 채택 할 수있는 다양한 기술이 있습니다. 기사 또는 추적기 탄환에 스파이크가있어 편안함을 얻을 수 있습니다.

마지막으로 팀으로 실패하고 스프린트 회고 중에 다시 데려 오게합니다.

이것은 스크럼 마스터가 효과적 일 수있는 좋은 스크럼 마스터가 매일 방해물 로그를 기록하고이를 방지하기 위해 사전 예방 조치를 취한 경우입니다.

이들은 두 개의 센트입니다. 시험에 도움이되기를 바랍니다!