Exemplo de projeto Scrum na prática: da visão à primeira entrega
Ler o Guia do Scrum explica as regras. Ver um exemplo de projeto Scrum do começo ao fim mostra como elas se encaixam: quem decide o quê, o que existe antes da primeira Sprint, o que acontece quando o plano encontra a realidade e em que momento o usuário recebe algo que pode usar. É essa sequência que costuma faltar para quem vai conduzir o primeiro projeto com o framework.
O exemplo abaixo é ilustrativo. A empresa, as pessoas e os números foram criados para mostrar o raciocínio, e não descrevem um caso real. O cenário é comum no Brasil: uma distribuidora de materiais de construção que quer vender para lojistas por um portal, em vez de depender só de vendedores e telefone.
Se você ainda não conhece os elementos do framework, leia antes o que é Scrum. Aqui o foco é a aplicação, passo a passo.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O ponto de partida: problema, patrocinador e visão
A diretoria comercial percebe três problemas: os pedidos chegam por telefone e mensagem, com erros de digitação; os lojistas não conseguem consultar estoque fora do horário comercial; e os vendedores gastam metade do dia anotando pedidos em vez de visitar clientes.
O diretor comercial patrocina o projeto. Antes de falar em Sprint, ele e a futura Product Owner registram o essencial num termo de abertura curto:
- Problema: pedidos manuais, lentos e com erros.
- Objetivo: lojistas fazem pedidos sozinhos, a qualquer hora, com preço e estoque corretos.
- Indicadores de sucesso: percentual de pedidos feitos pelo portal e redução de pedidos com erro.
- Restrições: integração obrigatória com o sistema de gestão (ERP) atual; orçamento aprovado para seis meses de time dedicado.
- Partes interessadas: vendas, financeiro (crédito dos clientes), logística, TI e um grupo de lojistas parceiros.
O termo não traz lista detalhada de funcionalidades. Ele autoriza o trabalho, define para que ele serve e quem decide. O detalhamento vai para o backlog.
A Meta do Produto e o Scrum Team
Com o objetivo aprovado, a Product Owner escreve a Meta do Produto, o objetivo de longo prazo que orienta o backlog: "o lojista faz o pedido completo pelo portal, sem precisar falar com um vendedor".
O Scrum Team fica assim:
- Product Owner: a coordenadora de vendas internas, que conhece os clientes e tem autoridade para ordenar o backlog.
- Scrum Master: um analista de processos que já trabalhou com times ágeis.
- Developers: quatro pessoas de desenvolvimento, uma de testes e uma de design de interface, dedicadas ao projeto.
As Sprints terão duas semanas. A equipe de TI que mantém o ERP não faz parte do time, mas reserva horas para as integrações, combinadas com o Scrum Master.
O Product Backlog inicial
Numa oficina de um dia com vendedores, financeiro, logística e três lojistas convidados, o time levanta o que o portal precisa ter. A Product Owner ordena os itens pelo valor e pelo risco:
| Ordem | Item | Por que está nessa posição |
|---|---|---|
| 1 | Lojista faz login com o CNPJ cadastrado | Sem acesso, nada funciona |
| 2 | Lojista consulta produtos com preço da sua tabela | Valor alto e risco técnico alto (integração com o ERP) |
| 3 | Lojista vê estoque disponível | Principal pedido dos lojistas na oficina |
| 4 | Lojista monta carrinho e envia pedido | Fecha o fluxo mínimo de valor |
| 5 | Pedido entra no ERP sem redigitação | Elimina o erro manual |
| 6 | Financeiro bloqueia pedido de cliente com crédito vencido | Exigência do financeiro antes de liberar para todos |
| 7 | Lojista acompanha o status do pedido | Reduz ligações para a central |
| 8 | Lojista repete pedido anterior | Ganho de produtividade para clientes recorrentes |
Os itens do topo são refinados até ficarem pequenos e claros. Os de baixo continuam vagos de propósito: vão ser detalhados quando chegarem perto.
A Definição de Pronto
Antes da primeira Sprint, o time escreve a Definição de Pronto:
- código revisado por outra pessoa do time;
- testes automatizados para as regras de preço e estoque;
- funcionando no ambiente de homologação integrado ao ERP;
- validado em celular e computador;
- critérios de aceite conferidos pela Product Owner.
Um item que não cumpre a lista não é apresentado na Sprint Review como concluído.
Sprint 1: provar a integração
Na Sprint Planning, a Product Owner propõe começar pelo maior risco. O time define a Meta da Sprint: "o lojista entra no portal e vê produtos com o preço da sua tabela, vindo do ERP". Entram os itens 1 e 2.
- Daily Scrum: no quarto dia, os Developers descobrem que o ERP só exporta preços por arquivo, uma vez por dia. O Scrum Master leva o impedimento à equipe do ERP, que libera uma consulta direta em homologação no sétimo dia. O time reorganiza o trabalho para não parar.
- Sprint Review: o time mostra o login e a consulta de preços a dois vendedores e um lojista. O lojista pergunta: "e o estoque?". A Product Owner confirma que o item 3 sobe de prioridade.
- Retrospectiva: o time decide envolver a equipe do ERP no refinamento, para não descobrir limitações no meio da Sprint.
O incremento existe e funciona, mas ainda não justifica ser liberado.
Sprint 2: fechar o fluxo mínimo
Meta da Sprint: "o lojista consulta estoque e envia um pedido que chega ao ERP". Entram os itens 3, 4 e 5.
O item 5 não fica pronto: a gravação no ERP funciona, mas falha em pedidos com mais de 50 linhas. Pela Definição de Pronto, ele volta para o Product Backlog. Na Review, o time mostra o que está pronto e explica, com transparência, o que não ficou. A Product Owner decide que o fluxo só será liberado quando o pedido chegar ao ERP sem redigitação.
Na retrospectiva, o time percebe que o item 5 era grande demais e combina critérios mínimos para um item entrar na Sprint, uma prática descrita no artigo sobre Definition of Ready.
Sprint 3: a primeira entrega para usuários reais
Meta da Sprint: "dez lojistas parceiros fazem pedidos reais pelo portal". Entram o restante do item 5 e o item 6, exigido pelo financeiro.
No fim da Sprint, o portal é liberado para dez lojistas. Na Review, a Product Owner traz os números da primeira semana de uso e o retorno dos lojistas: o carrinho funciona, mas a busca por código do fabricante faz falta. O item novo entra no backlog e é ordenado.
Em seis semanas, o projeto saiu de uma ideia para um produto usado por clientes reais. O backlog mudou duas vezes, um item falhou e voltou, e uma dependência externa quase parou o time. Nada disso é desvio: é o Scrum funcionando como previsto.
O que este exemplo de projeto Scrum ensina
- O termo de abertura e o Scrum convivem. O documento autoriza e dá propósito; o backlog detalha e muda.
- Comece pelo maior risco, não pelo item mais fácil. A Sprint 1 provou a integração com o ERP antes de qualquer tela bonita.
- A Meta da Sprint dá foco. Ela orienta as decisões quando algo dá errado no meio do caminho.
- A Definição de Pronto protege a qualidade. O item que falhou voltou para o backlog, em vez de ser entregue pela metade.
- Liberar é decisão de valor. O incremento existiu desde a Sprint 1; a liberação veio quando fez sentido para o negócio.
Para estruturar o seu projeto com uma visão de planejamento e acompanhamento, o artigo sobre modelo de projeto ágil traz um formato pronto, e o guia completo de métodos ágeis e Scrum ajuda a decidir se o Scrum é a abordagem certa para o seu caso.
Comece pelo termo de abertura
Antes da primeira Sprint, registre o problema, o objetivo, o patrocinador, os indicadores de sucesso e as restrições do projeto, como no exemplo. Para fazer isso sem partir do zero, use o gerador de termo de abertura da Projeto Diário: ele percorre oito etapas, da identificação à aprovação, com orientação e exemplo em cada campo, aponta o que falta no checklist e baixa o termo em Word, PDF ou Markdown para a assinatura do patrocinador.
