O que é uma sprint? O guia do fundador não-técnico

A sprint é o relógio do seu projeto de software. Se você entende como ele funciona, controla o build sem virar gerente de tecnologia. Se não entende, descobre tarde demais que pagou por duas semanas que não renderam nada.

Um fundador que a gente conhece mandou uma mensagem no sábado à noite, na terceira semana de projeto: “o time disse que vai entregar na próxima sprint, mas ninguém me explicou o que isso significa e eu já paguei metade do orçamento”. Ele não era burro. Era ex-consultor e sabia ler um balanço. Só que ninguém tinha traduzido “sprint” para a língua que importava para ele: a do dinheiro e do controle.

Uma sprint é um ciclo curto e fixo de trabalho, normalmente de duas semanas, no qual um time de desenvolvimento se compromete a entregar um pedaço funcional do seu software. No fim da sprint, existe algo que roda, você testa, e o time começa o ciclo seguinte. É a unidade básica de tempo do desenvolvimento moderno e o coração da metodologia Scrum. Essa é a definição de dicionário. A parte útil, a que ninguém escreve para quem paga a conta, vem agora.

A sprint não é uma cerimônia técnica. É o seu ponto de controle.

Quase todo artigo sobre sprint foi escrito para o time de dentro: o scrum master, os devs, a pessoa que roda a daily. Eles explicam ritual. Você não precisa de ritual. Você precisa saber uma coisa: a sprint é o intervalo mais curto no qual você consegue responder a pergunta “o dinheiro que entrou virou software que funciona?”.

Fora do software, você já opera assim. Um restaurante fecha o caixa todo dia. Um time comercial olha o pipeline toda semana. A sprint é o fechamento de caixa do seu build. A cada duas semanas, o projeto para de ser uma promessa e vira uma coisa que você pode abrir no navegador e testar. Sem esse ponto de parada, o desenvolvimento vira uma caixa-preta de três meses onde você assina cheques e reza.

É por isso que a duração é fixa e curta. Se a sprint durasse três meses, você descobriria um problema de rumo tarde demais para corrigir barato. Com duas semanas, o pior caso é você perder duas semanas. Caro, mas recuperável. A sprint transforma um risco grande e opaco em uma série de riscos pequenos e visíveis.

Quanto tempo dura uma sprint (e por que quase sempre são duas semanas)

O Scrum permite sprints de uma a quatro semanas. Na prática, o padrão de mercado para produtos em estágio inicial é duas semanas, e há uma razão de operação por trás disso.

Uma semana é curta demais: metade do tempo vai embora em planejamento e review, sobra pouco para construir. Quatro semanas é longo demais: você volta a perder visibilidade e um erro de rumo custa um mês. Duas semanas é o ponto onde o time tem tempo suficiente para entregar algo real e você tem frequência suficiente para não perder o controle.

Se um fornecedor te propõe sprints de quatro semanas ou, pior, “a gente não trabalha com sprint, entrega tudo no final”, trate como um sinal. Não é necessariamente fraude. Mas é menos visibilidade para você, e a visibilidade é justamente o que você está comprando quando terceiriza um build sem ter um CTO para vigiar.

O que acontece dentro de uma sprint, do seu ponto de vista

Uma sprint tem quatro momentos. A literatura técnica trata os quatro como rituais do time. Aqui está o que cada um significa para você, a pessoa que paga.

Sprint planning (o começo). O time decide o que vai construir nas próximas duas semanas, puxando itens do backlog, a lista priorizada de tudo que o produto precisa. Seu papel aqui é curto e decisivo: garantir que o que entrou na sprint é o que mais importa para o negócio agora, não o que é mais divertido de programar. Você não decide como. Você defende o o quê.

Daily (o meio). Uma conversa curta, diária, onde o time se alinha. Você quase nunca precisa estar nela. Se um fornecedor exige sua presença na daily todo dia, algo está errado: ou eles não sabem se organizar, ou estão tentando te transformar no gerente de projeto que você contratou justamente para não ser.

Sprint review (o fim, e a parte que você não pula). No último dia, o time te mostra o que construiu, funcionando. Não slides. Não “está 80% pronto”. Software rodando. Esta é a reunião mais importante do seu mês. É onde você verifica se o dinheiro virou produto, testa com as próprias mãos, e diz o que está bom e o que voltou errado. Se você só puder participar de uma coisa no projeto inteiro, participe da review.

Retrospective (a manutenção do motor). O time conversa sobre como melhorar o próprio processo. É interno. Você não precisa estar, mas vale perguntar, de vez em quando, o que saiu dela. Um time que nunca muda nada na retrospective é um time que não está aprendendo.

Como a sprint protege o seu orçamento

Aqui está o motivo real de você se importar com isso. A sprint é a melhor defesa que existe contra as duas formas mais comuns de um projeto de software queimar dinheiro: o scope creep e o build que se afasta do negócio.

Porque a sprint tem escopo fixo, ela cria uma fronteira. Aquela ideia genial que te ocorreu na quarta-feira não entra no meio da sprint atual e bagunça o que já foi combinado. Ela vai para o backlog e entra na próxima sprint, quando você e o time reavaliam prioridades com a cabeça fria. A fronteira da sprint é o que impede que todo lampejo seu vire uma emergência para o time e uma conta maior para você.

E porque toda sprint termina em software que roda, você nunca fica mais de duas semanas longe da verdade. Um projeto de três meses sem sprints pode estar 100% errado no dia 89 e você só descobre no dia 90. Com sprints, você tem seis pontos de correção no caminho. Cada review é uma chance de dizer “não era isso” enquanto ainda é barato mudar.

Um jeito prático de usar isso: no fim de cada sprint, faça uma conta de padeiro. Você pagou X por duas semanas. O que entrou de valor real para o negócio nessas duas semanas vale X? Não precisa ser exato. Depois de três ou quatro sprints, você vai sentir se o ritmo está justo ou se está pagando caro por pouco. Essa sensação, calibrada a cada duas semanas, vale mais do que qualquer relatório.

Sprint, Scrum e design sprint não são a mesma coisa

Três palavras parecidas que confundem todo mundo, então vale separar rápido.

Scrum é a metodologia inteira: papéis, cerimônias, artefatos. A sprint é uma parte do Scrum, o ciclo de tempo. É como a diferença entre “futebol” e “tempo de jogo”. Você não precisa dominar o Scrum. Precisa entender a sprint.

Design sprint é outra coisa: um processo de cinco dias criado no Google para testar uma ideia rápido, antes de construir. Apesar do nome, tem pouco a ver com a sprint de desenvolvimento. Se alguém te oferece um “design sprint”, está falando de validar conceito em uma semana, não de construir software em ciclos.

E, não, a sprint do software não tem relação com a corrida de velocidade. A palavra foi emprestada do atletismo pela ideia de esforço curto e concentrado. Só isso.

O erro que fundadores não-técnicos cometem com sprints

O mais comum não é ignorar a sprint. É usá-la ao contrário. O fundador entende que existe um ciclo, então trata cada sprint como uma promessa de entrega e cobra o time como se fosse uma linha de produção: “por que essa funcionalidade não ficou pronta nesta sprint?”.

O problema é que a sprint não é uma garantia de entrega. É um compromisso de tentativa dentro de uma caixa de tempo fixa. Às vezes o time descobre no meio que a tarefa era mais complexa do que parecia. Uma sprint que termina com “isso é mais difícil do que a gente achou, aqui está o que aprendemos” não é uma sprint fracassada. É a sprint fazendo o trabalho dela: te dando a má notícia em duas semanas, e não em dois meses.

A pergunta certa na review nunca é “por que não ficou pronto”. É “o que a gente aprendeu, e o que isso muda na próxima sprint”. Fundador que trata sprint como esteira de fábrica quebra a confiança do time e, ironicamente, atrasa o projeto. O ciclo funciona quando você o usa como instrumento de visão, não como chicote.

Se você está montando a lógica do seu produto do zero, a sprint é a batida do relógio que mantém o roadmap conectado à realidade. O roadmap diz para onde. A sprint entrega os próximos dois passos e mostra se o terreno é o que você imaginava.

Perguntas frequentes

O que é uma sprint, em uma frase?

Um ciclo fixo de trabalho, normalmente de duas semanas, no qual um time de desenvolvimento entrega um pedaço funcional do software que você pode testar no fim.

Qual a diferença entre sprint e backlog?

O backlog é a lista completa e priorizada de tudo que o produto precisa. A sprint é o recorte dessa lista que o time se compromete a construir agora. O backlog é o cardápio; a sprint é o que você pediu nesta rodada. Detalhamos o backlog neste guia.

Quantas sprints leva para construir um produto?

Depende do escopo, mas um primeiro produto sério costuma levar de 4 a 10 sprints, ou seja, de dois a cinco meses. Desconfie de quem promete “uma sprint” para algo que você mesmo levaria meses para descrever.

Preciso participar de todas as reuniões da sprint?

Não. Você precisa estar na sprint review, no fim de cada ciclo, e ser ouvido no planning. A daily é do time. Um fornecedor que exige sua presença diária provavelmente está mal organizado.

O que é uma sprint no Scrum?

É exatamente a mesma coisa. “Sprint no Scrum” só deixa explícito que o ciclo faz parte da metodologia Scrum, onde ela nasceu. Não existe uma sprint “diferente” dentro do Scrum.

Sprint tem a ver com a corrida de velocidade?

Só no nome. A palavra foi emprestada do atletismo pela imagem de esforço curto e intenso. No software, descreve o ciclo de trabalho, não uma corrida.

A sprint é o instrumento mais simples que você tem para transformar um build terceirizado em algo que você controla sem precisar entender de código. Duas semanas, uma entrega que roda, uma pergunta honesta: valeu? Faça essa pergunta seis vezes seguidas e você terá conduzido um projeto de software inteiro sem nunca ter aberto um editor de código.