Planejamento, Cronograma e Custos
Cronograma com sprints: exemplo para projetos híbridos
Um cronograma com sprints resolve um conflito comum em projetos híbridos: o time de desenvolvimento trabalha em ciclos curtos, com escopo que se ajusta a cada sprint, enquanto o patrocinador, as lojas, o fornecedor e o treinamento precisam de datas. O erro é escolher um dos lados: ou o cronograma detalha cada funcionalidade como se o escopo estivesse fechado, ou o time diz que "no ágil não tem data" e as áreas que dependem dele ficam sem como se programar.
A saída é um cronograma em que as datas são fixas e o escopo é flexível dentro de cada release, com as atividades preditivas ligadas às entregas das sprints. Abaixo está um exemplo completo, com a previsão de escopo e o que fazer quando a velocidade do time fica abaixo do esperado. Se o seu desafio é converter um cronograma tradicional existente em entregas incrementais, comece por como transformar cronograma em entregas ágeis; aqui o foco é a forma do cronograma pronto.
Formação relacionada
Microsoft Project Professional
Cronogramas confiáveis, linha de base, controle de desvio e relatórios que sustentam decisão de diretoria.
O que um cronograma com sprints precisa mostrar
- As sprints em sequência, com duração fixa. O Guia do Scrum limita a sprint a no máximo um mês; muitos times usam duas semanas. A duração não muda de uma sprint para outra.
- Os releases, ou seja, os pontos em que um conjunto de entregas vai para uso real, com data e meta.
- As atividades preditivas: contratações, infraestrutura, integrações com fornecedores, treinamento, implantação, comunicação.
- As dependências entre as duas partes: o que a parte preditiva precisa receber das sprints, e o que as sprints precisam receber da parte preditiva.
- Os marcos que o patrocinador acompanha.
O que não vai no cronograma: os itens do backlog de cada sprint. Eles são decididos no planejamento de cada sprint e mudariam o cronograma a cada duas semanas.
Exemplo de cronograma com sprints
O exemplo é ilustrativo. Uma rede com 30 restaurantes vai lançar um aplicativo próprio de pedidos. O projeto tem 17 semanas, sprints de duas semanas e dois releases: um piloto em 2 restaurantes e a versão para toda a rede.
| Semanas | Item | Abordagem | Depende de |
|---|---|---|---|
| 1 a 3 | Preparação: ambiente em nuvem, arquitetura, backlog inicial priorizado | Preditiva | |
| Fim da 3 | Marco M1: ambiente pronto e backlog do Release 1 refinado | Marco | Preparação |
| 4 a 5 | Sprint 1 | Ágil | M1 |
| 4 a 11 | Integração com o meio de pagamento (fornecedor) | Preditiva | M1 |
| 6 a 7 | Sprint 2 | Ágil | Sprint 1 |
| 8 a 9 | Sprint 3 | Ágil | Sprint 2 |
| Fim da 9 | Marco M2: Release 1 em piloto em 2 restaurantes | Marco | Sprint 3 |
| 10 a 11 | Sprint 4 | Ágil | Sprint 3 |
| 12 a 13 | Sprint 5 (pagamento no aplicativo) | Ágil | Sprint 4 e integração com o meio de pagamento |
| 12 a 15 | Material de treinamento das equipes | Preditiva | M2 |
| 14 a 15 | Sprint 6 | Ágil | Sprint 5 |
| Fim da 15 | Marco M3: Release 2 aprovado para a rede | Marco | Sprint 6 |
| 16 | Implantação, onda 1: 10 restaurantes, com treinamento no local | Preditiva | M3 e material de treinamento |
| 17 | Implantação, onda 2: 18 restaurantes | Preditiva | Onda 1 |
| Fim da 17 | Marco M4: aplicativo em operação nos 30 restaurantes | Marco | Onda 2 |
Conferindo as contas: 3 semanas de preparação, mais 6 sprints de 2 semanas (12 semanas), mais 2 semanas de implantação, somam 17. Os restaurantes também fecham: 2 no piloto, 10 na primeira onda e 18 na segunda, total de 30.
Três dependências merecem atenção:
- Sprint 5 depende do fornecedor. As funcionalidades de pagamento só entram no planejamento da Sprint 5 se a integração estiver pronta no fim da semana 11. Se o fornecedor atrasar, o dono do produto antecipa outros itens e o pagamento vai para a Sprint 6. Por isso a integração está no cronograma com data, e não só no backlog.
- O material de treinamento começa no piloto. Ele usa o que o Release 1 já mostra e é ajustado depois das revisões das Sprints 5 e 6.
- As ondas dependem do release e do treinamento. Elas são atividades preditivas clássicas, com lista de restaurantes, datas e responsáveis.
Como prever o escopo de cada release
Com datas fixas, a pergunta passa a ser: quanto do backlog cabe em cada release? A resposta vem da velocidade do time, medida em pontos ou em quantidade de itens concluídos por sprint.
No exemplo, o time estimou uma velocidade entre 25 e 30 pontos por sprint. O backlog do Release 1 foi dividido em 70 pontos obrigatórios (o mínimo para o piloto fazer sentido) e 10 pontos desejáveis. Com 3 sprints, a previsão era entregar entre 75 e 90 pontos: os obrigatórios caberiam com folga.
O Release 2 tem 75 pontos, o que exige pelo menos 25 por sprint nas Sprints 4, 5 e 6.
Esse formato, com obrigatórios e desejáveis, é o que torna as datas confiáveis. O patrocinador sabe o que vai receber com certeza e o que depende do ritmo do time. O artigo sobre plano de releases do projeto detalha como agrupar entregas por ondas e definir o conteúdo de cada release.
Quando a velocidade fica abaixo do previsto
No fim da Sprint 2, o time entregou 20 e 22 pontos, média de 21. Feitas as contas:
- Concluído até agora: 20 + 22 = 42 pontos.
- Faltam para os obrigatórios do Release 1: 70 − 42 = 28 pontos.
- Previsão para a Sprint 3, pela média: 21 pontos. Faltariam 7.
O cronograma com sprints deixa a decisão clara, com três opções:
| Opção | Efeito no cronograma | Efeito no escopo |
|---|---|---|
| Mover 7 pontos de itens obrigatórios de menor valor para o Release 2 | M2 mantido na semana 9 | Piloto com menos funcionalidades; Release 2 cresce |
| Acrescentar uma sprint antes do piloto | M2, M3 e M4 deslocam 2 semanas; projeto termina na semana 19 | Escopo do Release 1 mantido |
| Reforçar o time | Datas mantidas no papel | Ganho incerto no curto prazo, porque gente nova leva tempo para produzir |
A mesma conta vale para o Release 2: a 21 pontos por sprint, três sprints entregam 63 dos 75 pontos previstos, 12 a menos. Melhor saber isso na semana 7, com tempo para negociar, do que na semana 15.
Repare que a decisão é do patrocinador com o dono do produto, e não do time. Em projetos com comitê, mover escopo entre releases ou deslocar marcos pode exigir aprovação formal, conforme as regras de mudança do plano.
Como representar as sprints no gráfico de Gantt
- Uma barra por sprint, com a duração fixa, ligada à anterior. Não detalhe os itens do backlog.
- Releases e entregas importantes como marcos de duração zero. Veja como escolher e acompanhar bons marcos em marcos do projeto.
- Atividades preditivas com predecessoras reais. A implantação depende do marco do release, não de uma data digitada.
- Linha de base nos marcos. O que o patrocinador acompanha é a data dos releases; se ela se mover, fica visível.
- Previsão de escopo fora do Gantt, num quadro simples com pontos planejados, concluídos e projetados por release, atualizado ao fim de cada sprint.
Erros comuns em cronogramas com sprints
- Colocar o backlog no Gantt. O cronograma passa a mudar a cada sprint e perde a função de mostrar datas.
- Variar a duração das sprints para "caber" uma entrega. A previsão por velocidade deixa de funcionar.
- Deixar fornecedores e implantação fora do cronograma. São justamente as partes que precisam de data e que o time ágil não controla.
- Prometer todo o backlog numa data. Com data fixa, o escopo precisa ter uma parte obrigatória e uma parte que depende do ritmo.
- Não refazer a previsão. A velocidade das primeiras sprints é a melhor informação que o projeto tem. Atualize a projeção ao fim de cada uma.
O guia de planejamento de projetos mostra como escolher a abordagem, preditiva, ágil ou híbrida, para cada parte do projeto antes de montar o cronograma.
Para montar o esqueleto do seu cronograma híbrido, use a ferramenta de cronograma da Projeto Diário: cadastre cada sprint como uma atividade de duração fixa em dias úteis (10 dias para sprints de duas semanas), os releases como marcos de duração zero e as atividades preditivas com as predecessoras certas. A ferramenta calcula as datas sem fins de semana e feriados nacionais, mostra o caminho crítico no Gantt e exporta para Excel, onde você pode manter ao lado a previsão de escopo por release.
