Scrum: como o framework funciona e quando ele faz sentido na TI

Autor: Pedro Tebaldi PM do KeepGreen

Publicado dez/2014Atualizado ago/2026

Duas equipes da mesma empresa adotam Scrum no mesmo trimestre. A de desenvolvimento de produto ganha previsibilidade em dois meses. A de infraestrutura abandona o quadro na quarta rodada, depois de três sprints seguidas estouradas por chamado urgente.

A diferença não está na disciplina de nenhuma das duas. Está no tipo de demanda que cada uma recebe. O framework foi desenhado para trabalho que pode ser comprometido com antecedência, o que descreve mal a rotina de quem atende incidente.

Este guia cobre o framework como ele está definido hoje: responsabilidades, eventos, artefatos. Depois entrega o que falta na maior parte do material em português. Ou seja, o critério para decidir se ele cabe no seu time, com a alternativa nomeada quando não cabe.

O que é Scrum e como o framework funciona

Scrum é um framework leve para trabalho complexo, organizado em ciclos curtos de duração fixa chamados sprints. Ele define três responsabilidades, cinco eventos e três artefatos, cada um com um compromisso associado.

O framework não determina como executar a tarefa. Ele fixa os pontos de inspeção e adaptação, deixando a técnica por conta do time. Essa distinção explica por que duas empresas rodam o mesmo framework com resultados opostos.

A definição vem do guia oficial mantido por Ken Schwaber e Jeff Sutherland, revisado em 2020. Ele é curto o bastante para ser lido em uma tarde, além de encerrar boa parte das discussões internas sobre o que é obrigatório.

Vale separar dois níveis que costumam se confundir. Os quatro valores declarados no manifesto ágil orientam a intenção, enquanto o framework dá forma prática a ela. O panorama completo dos modelos está no guia de gerenciamento de projetos ágil.

Três responsabilidades, sem gerente de projeto

O Product Owner responde por maximizar o valor do produto, o que inclui definir a ordem do backlog. O Scrum Master responde pela eficácia do time, removendo impedimento e sustentando a prática. Os Developers respondem por transformar itens do backlog em incremento pronto.

Repare no que falta nessa lista: gerente de projeto. A edição de 2020 trocou a palavra papéis por responsabilidades exatamente para reduzir a leitura de cargo. Em empresa com estrutura matricial, essa distinção evita o atrito mais comum da adoção.

Uma armadilha específica de TI aparece nesse ponto. Empresas costumam nomear o gerente de infraestrutura como Scrum Master do próprio time, acumulando as duas funções. O resultado é previsível: quando o impedimento é a prioridade do próprio gestor, ninguém remove nada.

Separe as duas funções, ainda que a segunda fique com alguém de outro time. Um Scrum Master sem autoridade hierárquica sobre o grupo costuma funcionar melhor do que um chefe acumulando o papel.

Cinco eventos, um contêiner

A sprint é o contêiner que abriga os outros quatro eventos: planejamento, reunião diária, revisão e retrospectiva. A duração é fixa, sem prorrogação. Quando o trabalho não cabe, o que sobra volta para o backlog em vez de esticar o ciclo.

O erro mais frequente é tratar a reunião diária como relatório de status para o gestor. Ela existe para os Developers ajustarem o plano do dia rumo à meta da sprint. Quando vira prestação de contas, o time passa a otimizar a narrativa em vez do resultado.

A duração do ciclo é decisão do time, com um teto de um mês. Na prática, duas semanas equilibram previsibilidade e capacidade de correção. Ciclo de quatro semanas atrasa o aprendizado, enquanto ciclo de uma semana gasta tempo demais em cerimônia para o trabalho que cabe dentro dele.

Três artefatos, três compromissos

Cada artefato carrega um compromisso, que é o que impede o item de virar lista solta. O backlog do produto tem a meta do produto. O backlog da sprint tem a meta da sprint. O incremento tem a definição de pronto.

A definição de pronto merece atenção redobrada em TI. Sem ela escrita, “pronto” significa coisas diferentes para quem desenvolve e para quem sustenta em produção. Inclua ali o que a operação precisa: monitoramento configurado, runbook atualizado, alerta com dono declarado.

Escreva essa lista junto de quem opera, nunca depois. Um item que sobe para produção sem alerta configurado gera chamado na semana seguinte. Esse chamado volta como trabalho não planejado para o mesmo time. O ciclo se retroalimenta até alguém quebrá-lo na definição de pronto.

Onde o Scrum entrega e onde ele quebra em times de TI

O framework entrega quando três condições se sustentam ao mesmo tempo. A demanda pode ser priorizada com antecedência. O time tem autonomia para escolher como executar. Existe alguém com autoridade real sobre a ordem do backlog.

Projetos com escopo definido se encaixam bem nesse desenho. Migração de datacenter, implantação de ferramenta, construção de integração, evolução de produto interno: todos têm backlog possível e entrega incremental verificável.

A quebra aparece em três cenários conhecidos. Time de sustentação com fila de chamado, onde a prioridade muda por severidade e não por valor. Operação com plantão, onde metade da capacidade some sem aviso. Estrutura em que o Product Owner não decide nada, porque a ordem vem pronta de fora.

Nesses casos a adoção vira teatro. A cerimônia acontece, o quadro existe, o compromisso da sprint nunca fecha. O time conclui que ágil não funciona, embora o diagnóstico correto seja outro: o framework não combinava com o tipo de demanda. Escolher método por moda está entre os erros mais comuns na gestão de projetos de TI.

Existe um teste rápido antes de decidir. Pergunte quem pode dizer não a uma demanda que chega no meio do ciclo. Quando a resposta é “ninguém”, o compromisso da sprint já nasce decorativo.

Outro sintoma útil aparece no histórico. Conte quantos itens entraram na sprint depois do planejamento nas últimas quatro rodadas. Se a média passar de um quarto do escopo, o time replaneja toda semana. A sprint virou relatório do que aconteceu, não compromisso do que vai acontecer.

Scrum ou Kanban para times de infraestrutura

A decisão não é ideológica, é sobre origem da demanda. A tabela abaixo separa as duas opções pelas dimensões que importam para quem opera.

Nada impede combinar os dois. O arranjo que costuma funcionar em TI reserva a sprint para o trabalho planejado. Uma faixa de capacidade fica protegida para a demanda que chega sem aviso, com rodízio de plantonista fora do ciclo.

Duas armadilhas fecham essa escolha. A primeira é adotar Kanban mantendo o quadro sem limite de trabalho em andamento, o que devolve a fila infinita com nome novo. A segunda é chamar de híbrido o arranjo em que a sprint existe no calendário, embora qualquer chamado entre nela sem negociação.

O trabalho não planejado é o que mata a sprint

Antes de escolher o método, meça. Some as horas gastas com chamado, plantão e pedido de última hora nas últimas quatro semanas. Depois divida pela capacidade total do time. Esse número decide mais do que qualquer preferência de quadro.

Com pouca interrupção, o framework se sustenta reservando folga explícita de capacidade no planejamento. Na faixa intermediária, o modelo híbrido resolve. Quando a interrupção domina a agenda, o time não é de projeto, é de fluxo, então insistir na sprint só produz relatório de fracasso.

Proteger capacidade tem forma concreta. Reserve uma fração fixa do ciclo para o não planejado, mantenha um plantonista fora do compromisso da sprint, faça rodízio a cada rodada. Quem está de plantão não recebe item com meta, porque plantão e entrega previsível não convivem na mesma agenda.

Esse desenho traz um efeito colateral bom: torna o custo da interrupção visível. Quando a diretoria enxerga quanta capacidade some em demanda não planejada, reduzir ruído de alerta deixa de ser assunto interno do time técnico.

Existe ainda o caminho que quase ninguém aponta: reduzir a interrupção em vez de acomodá-la. Alerta cru chegando direto ao time é falha de triagem, resolvida por gestão de incidentes estruturada. Enquanto isso não acontece, nenhum quadro segura o compromisso do ciclo.

Como medir se o Scrum está funcionando

Velocidade é a métrica mais distorcida do tema. Ela mede estimativa cumprida, não valor entregue, então sobe com facilidade quando o time infla a pontuação. Use como referência interna de capacidade, nunca como indicador de desempenho comparável entre times.

Três sinais dizem bem mais. A proporção de sprints que atingiram a meta mostra se o compromisso é realista. A quantidade de itens que atravessam mais de dois ciclos revela fatiamento ruim. O tempo entre “pronto” e “em produção” expõe gargalo fora do time.

Para quem entrega software, vale cruzar isso com as métricas de equipes de desenvolvimento, em especial as quatro chaves consolidadas pelo programa DORA. Elas medem fluxo de entrega, o que a cerimônia sozinha não enxerga.

Um quarto sinal costuma passar despercebido: o destino das ações da retrospectiva. Time que sai da reunião com três ações e chega à seguinte sem ter feito nenhuma está rodando cerimônia, não melhoria contínua. Registre cada ação com dono e prazo, no mesmo backlog do trabalho técnico.

Quando o gargalo aparece na fronteira entre desenvolvimento e operação, o problema deixa de ser de framework. Passa a ser de pipeline e de responsabilidade compartilhada, terreno de práticas DevOps.

Por onde começar a implantação

Comece por um time só. Adotar o framework na área inteira de uma vez tira a chance de corrigir o desenho. Nenhum erro fica isolado o bastante para ser lido.

Defina antes de tudo quem responde pela ordem do backlog. Sem essa pessoa nomeada, com autoridade real para dizer não, o resto da estrutura não para em pé. Só depois escreva a definição de pronto, com a operação na sala.

As duas primeiras rodadas servem para calibrar, nunca para entregar volume. Use ciclo de duas semanas, meta única e escopo deliberadamente pequeno. O que você quer descobrir ali é quanta capacidade some em trabalho não planejado, o número que decide todo o resto.

A reunião diária cabe em 15 minutos. A edição de 2020 do guia deixou de prescrever as três perguntas clássicas, então o formato virou escolha do time. O requisito é sair de lá com o plano do dia ajustado à meta da sprint, não com um relatório pronto.

Estimativa, velocidade e escala ficam para depois do terceiro ou quarto ciclo. Times que começam por essa parte gastam a energia inicial discutindo pontuação, em vez de gastar em fechar o primeiro compromisso de verdade.

O que decidir antes da próxima sprint

A pergunta útil não é se o Scrum é bom. É se a sua demanda cabe em um compromisso de duas semanas. Times de projeto quase sempre cabem. Times de sustentação quase nunca cabem, por mais madura que seja a prática.

Comece pela medição do trabalho não planejado, escolha o método a partir desse número, escreva a definição de pronto com a operação junto. Se o time estiver montando o portfólio inteiro, o guia de gerenciamento de projetos de TI cobre o que vem antes dessa escolha.

Vale lembrar que método nenhum compensa time sobrecarregado ou prioridade que muda toda semana. Estruturar a rotina de gestão de equipes de TI vem antes de escolher quadro. Se quiser discutir como reduzir a interrupção que chega ao seu time hoje, converse com um especialista da OpServices.