Solucionado
A todo momento se fala em relação ao scrum ser aberto a mudanças, quando ocorre uma mudança que mude o valor do projeto, como eles atuam com essa mudança o valor é repassado para o cliente ?
Existem um acordo feito anteriormente junto ao cliente que as mudanças possam gerar custo para eles? como podemos lidar com esse caso em relação ao cliente?
hoje, com a Alura e o Google Gemini
O cliente paga por sprint geralmente, então o que vai acontecer nas sprints futuras pode ser alterado sem problemas. Basta alterar o backlog e verificar com o PO em que sprint aquela mudança será inserida (com base no valor de negócio dela)
Lembre-se que como o Sprint é feito de pedaços pequenos (sprints) colocar uma mudança nova, ou mesmo retirar algo previamento pensado é facil. (NA TEORIA tudo é lindo xD)
Complementando o que disse o Thiago, a questão dos custos vai estar atrelada ao contrato.
Geralmente, como o próprio Thiago disse, vai ser pago por Sprint com algum tipo de multa por cancelamento ou aviso prévio.
Se contratado por Sprint, vai ser um contrato por tempo determinado, renovável a cada Sprint.
O que vejo mais no mercado são contratos onde o cliente em conjunto com o PO faz uma declaração de visão do projeto como um todo e estima-se o escopo, não fixa-se o escopo. Com base nisso se inicia o trabalho. Também estima-se um período mínimo de trabalho, assim após aquele período pode ou não acontecer a renovação.
Ainda, outro tipo de contrato quem tem se tornado usual é o de tempo e material. Paga-se exatamente pelo tempo trabalhado - inclusive podendo ser encerrada uma Sprint que possa ser a final caso aquela Sprint tenha perdido sentido versus o objetivo da Sprint - entrega antecipada, por exemplo.
Temos no curso de Aquisições em Projetos muitos exemplos de tipos de contratos.
Também estamos neste exato momento trabalhando em um curso de práticas ágeis e de agile avançado. Vale a pena seguir acompanhando nossos lançamentos.
Um abraço,
FA
Uma das premissas do manifesto Ágil é estar receptivo a mudanças ("Mudanças são bem-vindas").
Por isso as entregas de valor ao cliente devem ser frequentes, mesmo que pequenas, para que ele possa decidir quando continuar, parar ou mudar, através da avaliação das entregas efetuadas.
Corrijam-me se eu estiver enganado, mas pelo que já conheci sobre práticas Ágeis, falar em valor do projeto como um todo, em vez de tratar o valor das entregas progressivamente, na prática, não está de acordo com o manifesto Ágil.
Entendo sua visão, mas o manifesto estimula e desestimula comportamentos e práticas. Ele não proíbe.
Você pode ter um Project charter baseado em um cronograma de releases e um contrato com base nessa estimativa de escopo, com risco compartilhado. Estimativa, friso meu.
Projetos geram valor, projetos tem um custo. O ideal é ter contratos onde há confiança mútua e pagar por Sprint - na minha opinião e considerando o conceito de Sprint.
Se isso não for possível, nada no manifesto nos diz que devemos ou não trabalhar com mindsets ágeis para execução e contratos que não sejam exatamente o que gostaríamos que fossem.
Além disso, sua proposição é adequada considerando que se tratarmos de valor de projeto por escopo fechado sim, seria o oposto daquilo que o manifesto nos indica priorizar. Contudo, compartilhar riscos e trabalhar de forma colaborativa considerando custos e valores não parece ir contra o manifesto.
Existimos num mercado heterogêneo. É preciso ser ágil, mas também flexível.