Incremento de Produto Potencialmente Shippable - e se os usuários não gostarem do incremento mais recente?

Seus sprints são muito grandes ou complexos demais. Seus sprints estão falhando em um teste importante, colocando muito trabalho em risco. Acredito que um risco (o usuário não está gostando de uma implementação) não está sendo gerenciado de forma completa ou adequada, causando um extenso retrabalho. O estilo de gerenciamento de projetos de sua equipe é o culpado e você precisa planejar seus sprints de acordo.

Mockups de papel ou tela, acompanhados por muitos handwaves, são muito menos caros do que o código a ser produzido (estou assumindo: você pode ter uma estrutura de simulação de IUs matadora). Uma explicação passo a passo ou a interpretação de papéis com os indivíduos de teste apropriados exige um esforço muito menor do que construir e preparar um sistema para implantação. Como você já sabe que a aceitação do usuário é de alto risco, e que provavelmente não acertará da primeira vez, é possível planejar várias iterações no sprint atual para obter o conjunto de recursos certo.

Como um sprint não deve ter elementos entregáveis que dependam de elementos anteriores no sprint, você não deve planejar entregar os elementos UI / feature que você decidir durante o sprint atual. Em vez disso, os resultados do teste informam o planejamento e o desenvolvimento do seguinte sprint.

Na minha experiência, não é desarrazoado que um sprint inclua, digamos, a) código e finalização para recursos rígidos e rápidos, b) picos de tecnologia para sprints indefinidamente no futuro, ec) UI & testes de recursos para sprints no futuro próximo. Isso permite que você gerencie o material de alto risco enquanto continua a fornecer um código sólido e aceitável com toda a documentação adequada, etc., que acompanha o lançamento de um produto.

No meu último projeto, tivemos uma sprint construída com uma mistura de a) uma descrição de um parágrafo de um recurso ou elemento de interface do usuário para revisão pelo grupo de usuários, b) um passo a passo e uma sessão de aceno de mão c) um protótipo pronto para o teste de um recurso de um sprint anterior, e d) um recurso de teste de aceitação final que foi apresentado pela primeira vez a duas sprints atrás.

O Scrum afirma que o objetivo de um Sprint é produzir um incremento de produto potencialmente liberável. Na situação que você descreve, onde os usuários não gostam do que a equipe produziu, tente entender por quê. Inspecione o raciocínio e adapte-se de acordo.

A boa notícia com o Scrum é que você está encontrando esses problemas agora, no final de um Sprint e não no final de um projeto de desenvolvimento de 18 meses.

Você pode achar que há valor em fazer com que o Dono do Produto se envolva mais com as partes interessadas para entender melhor seus desejos e motivações. Isso, por sua vez, ajuda a ordenar itens no Product Backlog adequadamente e você pode descobrir que é mais capaz de encantar seus stakeholders na próxima Análise da Sprint.

É responsabilidade do Product Owner - criar um produto que atenda às necessidades dos usuários.

Então, você pode se perguntar como o Dono do Produto escreveu as histórias do usuário. Ele não as verificou com os usuários finais? Ele não criou modelos de tela para eles avaliarem? Ele não reuniu suas necessidades?

Se os usuários não gostarem do que você fez, o Dono do Produto deverá descobrir o que deve ser alterado e como e, em seguida, você poderá fazer essas alterações. Se necessário (mas é improvável que eu diga), você pode reverter para o release anterior e construir a partir daí.

Parece que você precisa se envolver mais com seu cliente.

Talvez você já tenha tentado e eles não se envolverão porque estão ocupados com o que eles vêem como seu "trabalho real". Se for assim, em um nível de gerenciamento mais alto, a TI precisa obter a adesão dos clientes para se envolver mais com o projeto.

As fases iniciais de prototipagem podem ajudar.

De alguma forma, torná-los conscientes do custo pode ajudar, apesar de binning dizer que 2 semanas ou o trabalho deve ser indicação suficiente. Mover datas de envio ou recursos de corte de versões futuras pode concentrar suas mentes.