Sprint no desenvolvimento móvel: essência, duração e planejamento

O que é um sprint no desenvolvimento?

Sprint é um timebox de duração fixa ao final do qual a equipe entrega um incremento do produto pronto para uso. O conceito de sprint é a base do Scrum, mas também é usado em outros frameworks Agile. No desenvolvimento móvel, um incremento é um build do aplicativo que pode ser instalado em um dispositivo, testado e mostrado aos stakeholders. Um sprint não pode ser estendido — se as tarefas não forem concluídas, elas são movidas para o próximo sprint.

A característica principal de um sprint é a duração fixa. A equipe não altera o objetivo do sprint após a aprovação. Isso proporciona previsibilidade: os stakeholders sabem quando receberão o resultado. Dentro do sprint, a equipe decide como distribuir o trabalho. O Scrum Master protege a equipe de interferências externas — novas tarefas não são adicionadas ao sprint atual. De acordo com o Scrum Guide 2025, esta é a única maneira de manter um ritmo de desenvolvimento sustentável.

Um sprint consiste em quatro eventos obrigatórios: Sprint Planning, Daily Scrum (sincronização diária), Sprint Review (demonstração do resultado), Sprint Retrospective (análise do processo). Entre eles está o trabalho principal: implementação de tarefas, testes, code review. Duração de cada evento é diretamente proporcional ao comprimento do sprint: para um sprint de 2 semanas, Planning dura 4 horas, Review 2 horas, Retro 1.5 horas, Daily 15 minutos. No total, os rituais ocupam cerca de 8 horas por sprint — 10% do tempo de trabalho da equipe.

Rituais Scrum do sprint

Rituais Scrum (cerimônias/eventos) são reuniões estruturadas da equipe dentro do sprint. Sprint Planning no início, Daily Scrum todos os dias, Sprint Review e Retrospective no final. Todos os eventos têm um timebox. O Scrum Master garante o cumprimento do timebox e do foco. Toda a equipe Scrum participa de cada ritual: Product Owner, Scrum Master, desenvolvedores. A exceção é o Daily Scrum (apenas desenvolvedores participam, PO e SM são opcionais).

A conexão dos rituais com as etapas do sprint: Planning define a direção (o que e como fazemos), Daily sincroniza (quem está fazendo o quê, quais bloqueadores existem), Review mostra o resultado (o que foi feito, o que não foi), Retrospective melhora o processo (como tornar o próximo sprint melhor). Pular a retrospectiva é o erro mais comum da equipe: quando os prazos são apertados, Retro é sacrificado primeiro. Isso leva à estagnação dos processos e à repetição dos mesmos erros. A pesquisa da Scrum.org (2025) mostra que equipes que realizam Retro a cada 2 semanas melhoram a velocidade 35% mais rápido.

Sprint Planning: planejamento da iteração

Sprint Planning é uma reunião da equipe no início do sprint onde é determinado o que será feito e como. O Product Owner apresenta as tarefas prioritárias do Product Backlog. A equipe estima a capacidade (tempo disponível considerando férias, reuniões, dívida técnica) e seleciona as tarefas que pode concluir durante o sprint. O resultado do Planning é o Sprint Goal (objetivo do sprint) e o Sprint Backlog (lista de tarefas). O Sprint Goal é formulado como uma frase curta: “Implementar a tela de pedido e a integração de pagamento via SBP.”

Velocity é a velocidade da equipe medida em story points por sprint. Média dos últimos 3-5 sprints. De acordo com a Scrum.org (2025), uma equipe de 5 desenvolvedores móveis (3 Android + 2 iOS) tem uma velocity de 25-40 SP por sprint de 2 semanas. O Planning usa a velocity como limite superior — eles pegam 10-15% a menos para considerar tarefas imprevistas (code review, incidentes, ajuda a outras equipes). Capacity vs Velocity: capacity são “horas-pessoa”, velocity são “story points”. Capacity considera férias, licenças médicas, reuniões. A taxa de perda típica é de 25-30% do tempo de trabalho gasto em atividades não relacionadas a código.

O Planning é dividido em duas partes: “o quê” (PO descreve as tarefas, a equipe esclarece) — 2 horas, e “como” (a equipe decompõe e estima) — 2 horas. Para projetos móveis, em “como” é discutido: compatibilidade com versões Android/iOS, necessidade de feature flags, impacto no tamanho do APK/IPA, novas permissões. Técnica Planning Poker é usada para estimativa: cada desenvolvedor dá sua estimativa em story points (1, 2, 3, 5, 8, 13). Uma discrepância de mais de 2 unidades desencadeia discussão das razões. Isso revela riscos ocultos na fase de planejamento, não no meio do sprint.

Execução do sprint: Daily Standup e acompanhamento

Daily Scrum (Standup) é uma reunião diária de 15 minutos para sincronização da equipe. Cada participante responde a três perguntas: “O que foi feito ontem?”, “O que planejo fazer hoje?”, “Quais bloqueadores tenho?” O Daily não é um relatório de status para o gerente, mas uma ferramenta de auto-organização da equipe. Se durante o Daily dois desenvolvedores estiverem trabalhando na mesma tarefa — é um sinal de reorganização. Importante: O Daily não resolve problemas, mas os identifica — para resolvê-los, uma reunião separada é convocada após o Daily.

Scrum Board (quadro do sprint) é uma visualização do Sprint Backlog. Colunas: To Do / In Progress / In Review / Done. Cada tarefa se move pelo quadro. Burndown Chart é um gráfico do trabalho restante por dia do sprint. O burndown ideal é uma linha reta do SP total até 0. O burndown real é um gráfico escalonado refletindo o fechamento de tarefas. Um burndown abaixo da linha ideal significa que estamos atrasados. Sinal de problema: se menos de 30% das tarefas forem concluídas até o meio do sprint — é necessário ajuste. Os riscos podem não ter sido considerados ou as tarefas foram superestimadas.

Para o desenvolvimento móvel, o acompanhamento do sprint é afetado por fatores específicos: tempo de compilação (o build do Android no CI pode levar 30+ minutos), espera pela moderação da App Store / Google Play (se for necessário lançar um build para testers via TestFlight), compatibilidade com diferentes dispositivos (testar em 10+ modelos leva tempo). Dica: reserve 1 dia de buffer no final do sprint para testes finais e montagem do build de lançamento. Isso reduz o risco de um sprint incompleto em 40% de acordo com a Mind the Product (2025).

Sprint Review e Retrospective

Sprint Review é uma demonstração do incremento para os stakeholders. A equipe mostra um build funcional do aplicativo, não slides. A duração é de 2 horas para um sprint de 2 semanas. O Product Owner verifica a conformidade com os Acceptance Criteria. Os stakeholders fornecem feedback que pode afetar o Product Backlog. Review não é um relatório, mas um diálogo: os stakeholders podem fazer perguntas e sugerir mudanças. Regra chave: Sprint Review é sobre o produto, não sobre o processo. Mostre o que foi alcançado, não como foi feito.

Sprint Retrospective é uma reunião interna da equipe para analisar o sprint passado. Formato: Start Doing (o que começar a fazer), Stop Doing (o que parar de fazer), Continue Doing (o que continuar fazendo). A duração é de 1.5 horas para um sprint de 2 semanas. Retrospective é um espaço seguro para discutir problemas. Regra: no Retro não são discutidos detalhes técnicos (para isso existem reuniões técnicas). Apenas processo, comunicação, ferramentas, cultura. O Scrum Master facilita a reunião e garante que cada participante fale.

O resultado da Retrospective são 1-3 melhorias para o próximo sprint. Se a equipe identificou o problema “O code review demora muito” — action item: “Definir SLA para revisão — 4 horas. Se a revisão não for feita a tempo — o desenvolvedor lembra no Slack.” Action Items devem ser específicos, mensuráveis e atribuídos a uma pessoa específica. De acordo com a Atlassian (2025), equipes que cumprem seus action items do Retro melhoram a velocidade em 15-25% em 3-4 sprints. Aquelas que não cumprem — ficam estagnadas.

Como escolher a duração do sprint

2 semanas é o padrão para desenvolvimento móvel. O equilíbrio ideal entre previsibilidade e flexibilidade. Tempo suficiente para: planejar, implementar 3-5 funcionalidades médias, testar, mostrar resultados. 1 semana é para equipes com alta maturidade de processos e CI/CD. Requer decisões rápidas, burocracia mínima. Adequado para startups em estágio inicial que precisam experimentar rapidamente. Desvantagem: alta sobrecarga de rituais (Planning + Review + Retro a cada semana = 7.5 horas).

3-4 semanas são para projetos complexos que envolvem integração com hardware (wearables, IoT, dispositivos BLE), moderação longa das lojas ou migrações importantes (por exemplo, transição de RxJava para Coroutines). Sprints longos fornecem mais tempo para testes, mas aumentam o risco do “efeito cascata” — a equipe perde flexibilidade Agile. Recomendação do Scrum Guide: não exceda 1 mês. Se o sprint for mais longo, haverá muito contexto no Review e os stakeholders não poderão dar feedback de qualidade.

Problemas típicos dos sprints

Problema 1: Scope Creep. No meio do sprint, o Product Owner adiciona uma nova tarefa “urgente e importante”. A equipe concorda — e o sprint falha. Solução: o Sprint Goal é um contrato. Qualquer mudança requer revisão do Sprint Goal, o que só é possível em casos de emergência. A nova tarefa vai para o Product Backlog e para o próximo sprint. Se a tarefa for realmente crítica — o Sprint Goal antigo é cancelado, o sprint é replanejado, mas isso é uma exceção, não uma prática. A frequência de scope creep superior a uma vez a cada 3 sprints é sinal de um Product Owner fraco.

Problema 2: Tarefas incompletas. No final do sprint, 50% das tarefas estão In Progress, 20% In Review, apenas 30% Done. Razões: capacidade superestimada, complexidade subestimada, bugs não planejados. Solução: analise a razão no Retro. Se sistematicamente não conseguir cumprir — não aumente a quantidade de tarefas no Planning, diminua-as. Equipes que pegam 20% menos tarefas mostram uma taxa de conclusão maior (80%+ contra 50-60%). Lista de verificação para Planning: para cada tarefa, verificar Acceptance Criteria, Definition of Ready e dependência com outras tarefas.

Problema 3: Retro formal. A equipe realiza Retro apenas por formalidade — 15 minutos, frases genéricas, sem action items. Solução: mude o formato de cada Retro. Métodos: Sailboat (o que atrasa, o que acelera), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Atribua action items com prazos e responsáveis. No início do próximo Retro, verifique o cumprimento dos action items anteriores. De acordo com a Atlassian (2025), equipes que usam diferentes formatos de Retro geram 50% mais insights úteis.