Objetivo
Planejar sprints de desenvolvimento semanais ou quinzenais para freelancer solo, com backlog priorizado, estimativa de tarefas, metas de entrega e revisão de resultado, para ter sempre clareza sobre o que vai ser desenvolvido nesse período, evitar o "comecei 10 coisas e terminei nenhuma" e entregar projetos de forma previsível mesmo tocando múltiplos clientes.
Quando usar
- No início de cada semana ou quinzena para planejar o que vai ser desenvolvido
- Quando o projeto está grande demais e você não sabe por onde começar
- Para decompor um projeto complexo em tarefas que cabem em uma semana
- Para ter uma cadência de entregas parciais que mantém o cliente confiante
Como usar
- Copie o prompt abaixo no Claude ou ChatGPT
- Descreva o projeto, as funcionalidades que faltam e as horas disponíveis
- Receba o plano do sprint completo com backlog priorizado e estimativas
- Execute, anote o que ficou para trás e use no planejamento do próximo sprint
O Prompt
Você é um desenvolvedor sênior com experiência em metodologias ágeis adaptadas para trabalho solo. Seus princípios: (1) sprint solo não é Scrum, mas sim uma disciplina pessoal de foco que elimina a procrastinação por excesso de escolhas, (2) estimativas de desenvolvedor sênior ainda estão erradas em 30% do tempo: adicione buffer, (3) a meta do sprint deve ser um entregável que o cliente consegue ver e testar, não só tarefas técnicas finalizadas, (4) o que não foi entregue no sprint anterior precisa ser a primeira conversa do próximo, não some debaixo do tapete.
**Projeto(s) envolvidos:** [nome e breve descrição de cada]
**Funcionalidades ou tarefas pendentes:** [liste tudo que falta fazer, pode ser bagunçado]
**Horas disponíveis nesse sprint:** [total de horas para esse período]
**Prazo final de entrega do projeto:** [data]
**O que o cliente está esperando ver primeiro:** [o que tem mais valor para ele ver funcionando]
**Dívidas técnicas ou bloqueios conhecidos:** [ex: "preciso migrar o banco antes", "aguardando acesso do cliente"]
Entregue:
**1. Backlog Priorizado**
Lista de todas as tarefas organizadas por prioridade (crítico / importante / desejável), com estimativa de horas para cada uma.
**2. Meta do Sprint**
O entregável principal do período: o que vai estar funcionando ao final que o cliente pode ver e testar.
**3. Plano Dia a Dia**
Distribuição das tarefas nos dias do sprint com sequência lógica e margem para imprevistos.
**4. Critério de Conclusão (Definition of Done)**
O que significa "feito" para cada tarefa principal, sem ambiguidade sobre quando você pode marcar como concluída.
**5. O que fica fora deste sprint**
Lista explícita do que não vai ser feito agora e por quê, para você não se sentir culpado por não fazer tudo de uma vez.
Exemplo de usoentrada e saída de exemplo
Input
- Projeto: Sistema de agendamento online para clínica (React + Node + PostgreSQL)
- Pendências: Login de paciente, cadastro de horários, tela de agendamento, confirmação por e-mail, painel do médico, relatórios
- Horas disponíveis: 30h (1 semana)
- Prazo final: 3 semanas
- O que cliente quer ver: Paciente conseguindo agendar uma consulta
- Bloqueios: Nenhum
Output
1. Backlog Priorizado
| Tarefa | Prioridade | Horas | |---|---|---| | Login e cadastro de paciente | Crítico | 6h | | Cadastro de horários disponíveis (médico) | Crítico | 5h | | Tela de agendamento (paciente escolhe horário) | Crítico | 8h | | Confirmação por e-mail | Importante | 3h | | Painel do médico (ver agenda do dia) | Importante | 5h | | Relatórios | Desejável | 4h |
2. Meta do Sprint Ao final da semana, um paciente consegue se cadastrar, ver horários disponíveis e confirmar um agendamento, e o cliente pode logar e testar esse fluxo de ponta a ponta.
3. Plano Dia a Dia
- Dia 1-2 (12h): Login/cadastro de paciente + cadastro de horários do médico
- Dia 3-4 (10h): Tela de agendamento completa (a peça central da meta do sprint)
- Dia 5 (6h): Confirmação por e-mail + buffer para ajustes encontrados nos dias anteriores
- 2h de margem não alocada para imprevistos
4. Critério de Conclusão (Definition of Done)
- Login/cadastro: paciente novo consegue criar conta e logar sem erros, dados salvos no banco
- Agendamento: paciente vê apenas horários realmente livres e o agendamento aparece refletido para o médico
- "Feito" = testado manualmente pelo próprio desenvolvedor simulando o fluxo do paciente, não só "código escrito"
5. O que fica fora deste sprint Painel do médico e relatórios ficam para o próximo sprint, não são necessários para o cliente validar a experiência principal (agendar uma consulta), e antecipá-los agora atrasaria a entrega do que o cliente mais quer ver primeiro.
Gostou? Tem mais 154 assim no pacote vitalício.
Ver pacote vitalício