스크럼 : 사용자 스토리의 디자인 / UX가 구현과 동일한 스프린트에서 발생해도 괜찮습니까?

나는 현재 디자이너가 특정 사용자 스토리의 요구 사항과 UX를 정의하는 일을하는 스프린트 (2 주)에 있습니다.

같은 스프린트에서이 디자인을 구현해야합니다. 스프린트 계획 중에이 정의되지 않은 사용자 스토리가 얼마나 오래 걸리는지 추측해야했습니다.

오늘 나는 마침내 디자인을 받았다. 불행히도, 디자인은 불완전하고 모호하며 디자인보다 고객의 요구 사항과 유사합니다. 그러나 이것으로부터, 나는 여전히 충분히 추정하지 못했다는 것을 알 수 있습니다.

설상가상으로 이것은 처음이 아닙니다. 마지막 스프린트에서 똑같은 일이 일어났습니다. 나는 회고에 그것을 표시했고, 스크럼 마스터는 "그냥 당신을위한 개발"이라고 말하는 대신 이것을 해결하는 방법에 대한 답을 얻지 못했다. 아이러니하게도 번 다운이 목표물에 있지 않으면 짜증이납니다 ...

이제 디자이너와 함께 일을 끝내기 위해 요청 / 작업해야합니다. 다른 모든 작업을 완료하면이 문제가 해결됩니다.

그래서 제 질문은

스프린트 계획에서 종속성을 어떻게 처리합니까?

이상적으로는 스프린트 계획 전에 비 개발 종속성이 처리되므로 백 로그 항목을 올바르게 정의하여 노력을 평가할 수 있습니다.

그러나 만약 이것이 마지막 스프린트 인 "당신을위한 개발"이었다면, 아마도이 스프린트를위한 개발 일 것입니다. 그래서 당신은 실제로 그 추정치를 증가시킨 다음에 비슷한 상태에있는 다가오는 작업에 대해 실제로 증가시켜야합니다. 이것은 득실 거리지 않으며, 그렇게되게하는 것은 실수 일 것입니다.

그것이하는 것은 비교적 견고하게 추정 할 설계없이 추정의 불확실성을 보여줍니다. 아마도 관리자는 제품 백 로그 항목이 올바르게 정의되어 있는지 확인해야 할 것입니다. 그러나 최악의 경우에는 등을 덮을 것입니다. 일자리가 부족할 때 아무도 불평하지 않습니다.

그러나, 당신은 그렇게하지 않았으며, 지금 당신의 질문은 ...

스프린트에 어떻게 접근해야합니까?

프로젝트 관리 도구 인 Scrum의 전체 목적은 문제를 조기에 식별하는 것입니다. 스프린트로 무엇을할지 결정하게하세요. 그들이 당신을 탓하려고한다면, 겸손하게 행동하고, 그것이 공정하다고 믿지 않더라도 같은 문제를 피하기 위해 앞으로 비슷한 상황에 접근 할 것을 제안하는 방법을 물어보십시오.

하루가 끝날 무렵, 이들은 프로젝트 관리 문제이며, 자신의 버블 안에서 문제를 해결하려고하면 실패하게됩니다. 그리고 그렇게하면 문제를 신고했을 때 문제를 해결하지 못한 관리자가 아니라 자신에게 넘어지기 때문에 화를 낼 것입니다.

우선, 스토리 / 태스크 간의 의존성과 스토리 / 태스크의 범위 / 노력 불확실성 간에는 큰 차이가 있습니다.

종속 작업 / 스토리가 종속 된 작업 / 스토리보다 우선 순위가 낮고 다른 작업 / 스토리가 완료되기 전에 시작할 수없는 주석을 제공하여 종속성을 처리합니다.

스토리에서 수행해야 할 작업을 명확히하여 계획 회의에서 불확실성 을 해결해야합니다. 불확실성을 충분히 제거 할 수없는 경우 스토리는 "준비 정의"를 충족하지 못하고 스프린트로 받아 들여서는 안됩니다.
어떤 이유로 스토리가 실제로 스프린트로 진행되어야하는 경우, 유일한 옵션은 추정에 리스크 버퍼를 추가하는 것입니다.

현재 스프린트의 경우 스토리에서 작업 할 수없는 경우 다음 일일 미팅에서보고하고 팀의 전체 스프린트 목표에 도달하기 위해 가능한 모든 작업을 수행하십시오. 스토리가 차단되고 무엇에 의해 스토리에 주석을 달 수도 있습니다.
스프린트가 시작된 후 스프린트에 새로운 작업을 추가하는 것은 원칙적으로 불가능합니다.
또한 작업이 예상보다 많은 작업으로 판명되면 추정을 변경하지 않지만 작업의 진행 상황과 남은 노력이 무엇인지 충실하게보고합니다.

결국, 스크럼에서는 무언가를 제공하겠다고 약속하는 팀입니다. 그러한 약속을 할 수 없다면, 팀 전체의 개인이 아니라 팀 전체가 실패한 것입니다.

스프린트 계획 중에이 정의되지 않은 사용자 스토리가 얼마나 오래 걸리는지 추측해야했습니다.

그것은 당신이 한 실수입니다. 누구도 팀이 스프린트에서 작업을 수락하도록 강요 할 수 없으며 최소한 와이어 프레임이없는 한 스프린트에서 작업을 추정하고 수락 할 수 없다고 말하는 것이 귀하의 임무입니다. 스크럼 마스터는 실제로 프로젝트 관리자 인 것 같습니다.

스프린트 내에서이를 달성해야하는 경우 (유효한 사업상의 이유로) 그러한 작업에 접근하는 방법은 무엇입니까? 글쎄, 먼저 디자인 마감일을 설정해야한다. 그 후에는 구현할 수 없다. 예를 들어, 이야기는 받아 들여지지 만 디자인은 첫 주 안에 전달되고 두 번째 주 안에 구현되어야합니다. 다음으로, 스프린트에서 구현 될 수 있도록 디자이너와 긴밀히 협력해야합니다. 스크럼은 부서 간 기능을 담당하는 팀을 전제로하며 디자이너와 함께 작업을 구성하는 것은 사용자의 책임입니다. 단, 스프린트에서 작업을 결정하는 것은 팀에 달려 있습니다. 스프린트 내에서 완료되는 방식으로 작업을 관리하고 관련 위험을 관리하는 것은 팀의 책임입니다. 다른 사람이 자신의 일을 마칠 때까지 기다리지 말아야합니다. 조직에서 더 큰 기능 장애를 밝힐 수 있습니다.

디자인에 관한 과제는 이야기로 표현되고 팀의 정의는 무엇입니까?

• 이야기가 준비되었습니다
• 이야기가 끝났다

각 스토리에는 고유 한 요구 사항과 수용 조건이 있어야하지만 모든 스토리에 적용 할 수있는 규칙 집합을 갖는 것이 좋습니다. 예를 들어, 스토리는 다음과 같은 경우에만 가능합니다. 엔드 투 엔드 아키텍처 연구가 완료되고 설계가 가능하며 스토리는 팀에 의해 추정되었습니다. 최소 수락 조건은 다음과 같습니다. 자동화 된 테스트가 완료되고, 테스트 슈트에 통합되었으며, 코드 검토가 수행됩니다.

스토리가 준비되지 않은 경우 스프린트에 스토리를 포함시키지 마십시오. 수락 조건이 충족되지 않으면 완료되지 않습니다.

귀하의 경우, 팀은 준비가 되겠다고 결정할 수 있습니다. 개발 스토리는 완벽한 디자인을 가져야합니다 (적어도 와이어 프레임은 이것을 자신의 현실에 맞게 조정하십시오). 그렇다면 같은 스프린트에서 디자인과 개발자를 처리 할 수 ​​없습니다. 또한 팀은 UX / 디자인 스토리가 최소한 와이어 프레임 디자인을 생성해야한다고 결정할 수 있습니다. 그렇지 않은 경우 스토리가 승인되지 않으므로 스토리가 시작될 수 없습니다.

스프린트 중에 복잡한 규칙을 재평가하는 것은 나쁜 습관입니다. 이는 팀의 속도가 불확실하며 관리자로서 팀의 작업과 미래에 대한 나쁜 비전을 가지고 있음을 의미합니다.

스프린트는 일반적으로 스토리가 명확 할 때 시작됩니다.이 단계에서 제품 백 로그가 설정되고 우선 순위가 결정됩니다. 디자인을하지 않고 시작한 경우 디자인없이 수행 할 수있는 작업과 수행 할 수없는 작업을 명확히해야합니다.

디자인이 클라이언트와 PO 사이에서 '범프'하는 동안 즉흥적으로 개선해야하는 경우 PO는 새로운 기능이 표시되는 즉시 팀에 알려야합니다. 이는 Scrum에서 '유연성'의 의미입니다. 상태. 개발팀, 스크럼 마스터 및 제품 소유자는 영구적으로 의사 소통해야합니다. 그렇지 않으면 변경에 대한 실시간 반응이 없습니다.

더 많은 교육은 해를 끼칠 수 없습니다 ... 아마도 디자이너와 함께 일하는 것이 새로운 UX 기술을 습득 할 수있는 기회일까요? ... 유리가 절반이 아닌 절반으로 가득 찬 것을 관찰합니다 :))