O contrato de sprint é algo novo que estou trabalhando e implementando no momento.
Fiz algumas pesquisas de como implementar um contrato de sprint que na realidade é um contrato com escopo variável.

Conversei com alguns especialistas em contratos como Artem Marchenko e Peter Stevens e redigi melhor essa proposta Ágil é claro. Tudo depende do “mindset” da empresa parceira. Tem que estar apta a rodar o projeto em Scrum… A seguir vou relatar um pouco da experiência com esse tipo de contrato.

Competição de Estimativas:
Em primeiro lugar o Product Owner precisa criar o Product Backlog para a primeira estimativa. Chamamos o candidato o prestador de serviços com seus desenvolvedores e fazemos uma Reunião de Estimativa do backlog. Essa reunião é uma excelente oportunidade para sentir segurança no domínio do assunto por parte dos desenvolvedores. Eles estimarão as user stories de acordo com a visão de complexidade que eles têm sobre o assunto. Você, como contratante, observa as discussões, questionamentos, etc. Depois que terminar essa reunião o PO tem um backlog estimado por uma equipe de desenvolvedores que sabem o que queremos deles e eles sabem o que terão pela frente. Podemos chamar outra empresa e fazer a mesma dinâmica. Teremos o segundo, terceiro, backlog estimados.

Velocidade do Sprint:
Ah, um pequeno detalhe: após a estimativa do backlog, perguntamos ao time quanto eles puxariam para o primeiro sprint (sem ver a pontuação)? Essa resposta será a referência inicial para calcular a velocidade deles.
Depois temos uma estimativa de número de sprints a ser executado. Pontos totais dividido pelo número de pontos puxados para o primeiro sprint.
Exemplo: total estimado do backlog 500 pontos. Estimado para puxar pro primeiro sprint 50 pontos, teremos numa primeira estimativa o trabalho medido para 10 sprints. Vamos supor que desde o início nós calculamos sprints de 10 dias úteis, então esse trabalho será realizado em 100 dias úteis, ou seja, 5 meses (sem muitos cálculos, considerando 1 mês =20 dias úteis).

Custo do Sprint:
Pergunto depois ao responsável da empresa pra me informar quanto custa um Sprint de N dias para um trabalho estimado a ser concluído em 10 sprints?
Ele vai fazer todos os cálculos de overhead, lucro, uso, etc. e vai dizer. Pode até fazer o cálculo da forma tradicional, mas chegará a um número. Exemplo: Sprint custa R$30.000. Faço a seguinte conta: R$30.000 x 10 sprints = R$300.000 será o custo estimado do projeto.

Make or Buy?
Faço os cálculos internamente para decidir se vale a pena fazer o trabalho externamente. Isso depende de uma série de fatores como recursos disponíveis, competências, tempo, carga de trabalho, etc.
Como eu comparo os preços? Tenho um indicador interno de histórico de projetos executados chamado de Man Month Rate (MMR) ou Custo Homem Mês que nada mais é todos os custos exceto investimentos e subcontratados dividido pelo número de efetivos e dividido pelo número de meses.
Exemplo: meu último projeto teve um custo operacional de R$1.000.000 realizado por 10 pessoas em 10 meses. Cálculo: R$1.000.000 / 10 pessoas / 10 meses = R$10.000 é o valor do meu MMR.
Agora, com posse desse dado, sabendo que minha equipe tem condições técnicas de realizar o projeto faço o seguinte cálculo: lembra dos 5 meses calculados anteriormente? Então agora internamente calculo R$10.000 * 10 pessoas * 5meses = R$500.000  o valor estimado pra fazer internamente. Quanto o fornecedor me cobrou? R$300.000. Esse valor está bom, é mais barato fazer fora (Buy).

Estabilização da Execução:
Agora após decidir quem executará o projeto, vamos pra a execução do contrato.

Será estimado inicialmente para finalizar daqui a 5 meses (com base em 10 sprints), pode acabar antes do tempo ou esticar um pouco mais, porém isso é o que tenho no momento.
Sprint1 e Sprint2 serão pagos ao fornecedor sem aplicar penalidades ou bônus. Valores fixos. Para fins de entrosamento, medir velocidade, resolver questões de infra, etc.

Penalidade Insucesso:

A partir do terceiro sprint, começo a aplicar as regras de bônus ou penalidade. No Sprint Planning o PO determina o objetivo esperado do sprint. No Sprint Review, ele confirma de esse objetivo (meta) foi atingido. Caso não tenha sido atingido, o pagamento desse sprint será debitado de um percentual penalidade, pagando apenas os custos do mesmo. Exemplo: penalidade de 20%, custo do sprint R$30.000, pagarei R$24.000 (R$30.000 – R$6.000)

Penalidade/Bônus Progresso:

Caso o objetivo do sprint tenha sido atingido, ainda falta mais uma coisa antes de definir o pagamento do sprint. Qual o percentual de entrega em pontos?

Estabeleci algumas métricas internas para pontuação (delivery). Por exemplo, abaixo de 80% de entregas aplica-se uma penalidade de 10%. Acima de 100% de entrega, aplica-se uma bonificação de 10%. Entre 80% e 100% dos pontos, paga-se o valor cobrado pelo sprint.

Em números: vamos supor que no sprint planning o time puxou 100 pontos e entregou 79 pontos (com objetivo atingido). Nesse caso receberão R$30.000 – R$3.000 = R$27.000.

Caso eles tenham feito entre 80 e 100 pontos, receberão os R$30.000 que cobraram.

Caso tenham feito 101 pontos ou 200 ou mais pontos, receberão R$30.000 + R$3.000 = R$33.000.

Cancelamento Fracasso:

Quando rodamos a partir de terceiro sprint, podemos avaliar o atingimento das metas. Caso sucessivos sprints não atinjam as metas, tem algo errado que deve ser revisto. Ou performance da equipe, gerenciamento do backlog, impedimentos, etc. Pode-se decidir então cancelar o projeto antes que o prejuízo aumente por fracasso.

Cancelamento Sucesso:

O projeto também pode ser cancelado por motivo de sucesso.

Caso no meio do projeto, lá pelo sprint 5, o ROI tenha sido atingido, ou seja, o cliente já está satisfeito com o que tem no momento, pode-se negociar com o fornecedor-parceiro o término adiantado com sucesso mediante uma bonificação sobre os sprints faltantes. Exemplo: faltam 5 sprints de R$30.000 cada, paga-se 20% sobre os 5 sprints que equivale a R$6.000 x 5 = R$30.000 de bônus por cancelamento com sucesso.

Pode ocorrer do fornecedor-parceiro não querer finalizar e receber tal bônus por não ter como alocar as pessoas em outro projeto, nesse caso podemos continuar executando o projeto, que tem escopo dinâmico (product backlog), na base do money for nothing and change for free. Sendo que a partir desse ponto de execução as funcionalidades não agregam mais tanto valor ao produto.

Os percentuais e valores colocados aqui são meramente para exemplificar a dinâmica desse modelo de contrato. Cada empresa pode adotar os percentuais adequados à sua operação, algumas mais conservadoras e outras mais arrojadas.

Espero ter contribuído com essa modalidade de contrato que estou confiante que trará bons resultados pra ambos. É verdadeiramente uma relação ganha-ganha.