O que é Incremento?

Ken Schwaber e Jeff Sutherland desenvolveram Scrum desde a década de 1990 e publicaram a primeira versão do Scrum Guide em 2010. O Incremento faz parte dos artefatos do framework. A versão oficial de 2020 o descreve como um passo concreto em direção à Meta do Produto, utilizável, aditivo aos incrementos anteriores e completamente verificado com eles.

Em 2020, a Definition of Done passou a ser apresentada como o compromisso do Incremento. O guia afirma que vários Incrementos podem ser criados numa Sprint e que eles podem ser entregues antes de sua conclusão. A Sprint Review serve para inspecionar o resultado, não como portão de liberação.

Pense em ampliar uma casa que já está em uso: uma nova parte só ajuda se for segura, acessível e funcionar com a estrutura existente. No Scrum, o Incremento amplia ou melhora o produto de forma utilizável. Não basta uma funcionalidade isolada parecer pronta na máquina de uma pessoa. Ela precisa cumprir o padrão de qualidade do produto e funcionar junto com o que já existe. A Definition of Done torna esse padrão transparente.

Relação com o Product Backlog. O Product Backlog reúne trabalho futuro do produto. Quando um item atende à Definition of Done, nasce uma parte do Incremento. O item não entra por porcentagem de conclusão nem por avaliação informal de alguém. Se não cumpre o padrão, não pode ser apresentado como pronto. A transparência permite que o time e pessoas interessadas saibam o que realmente está disponível para uso.

Integração com o produto. O Scrum Guide 2020 diz que cada Incremento é aditivo aos anteriores e verificado para funcionar em conjunto. Uma mudança que opera sozinha, mas quebra um fluxo existente, ainda não atende a esse princípio. Testes, revisão, integração e outras verificações dependem da qualidade exigida pelo produto. Não há uma lista universal de tarefas técnicas no guia; o time e a organização definem o padrão adequado na DoD.

Utilizável não é necessariamente liberado. Um Incremento deve estar em condição de uso. A decisão de expor a mudança pode depender de estratégia de lançamento, comunicação ou outras condições de negócio. Essa distinção não autoriza chamar de utilizável algo que ainda precisa passar por testes essenciais. Uma feature flag pode controlar exposição, mas não apaga defeitos nem substitui a DoD. A possibilidade de liberar deve ser real, não apenas teórica.

Mais de um por Sprint. A Sprint não é um lote obrigatório que só gera resultado no último dia. Um time pode concluir um recorte na primeira semana e outro depois. Se cada um cumprir a DoD e se integrar ao produto, ambos são Incrementos. Isso reduz o tamanho das mudanças e pode acelerar feedback. Também pode haver apenas um Incremento numa Sprint, desde que o time alcance um resultado utilizável. Frequência de liberação ao cliente depende do produto e não é uma competição entre equipes.

Relação com a Meta do Produto. O Incremento deve representar um passo rumo à Meta do Produto, o objetivo de longo prazo presente no Product Backlog. Uma entrega tecnicamente pronta pode não gerar o resultado de negócio esperado; por isso, a equipe precisa observar uso e aprender. Porém, falta de resultado não torna retroativamente a parte não pronta. Qualidade de construção e valor percebido são perguntas diferentes que o time examina em momentos apropriados.

Na Sprint Review. O Time Scrum apresenta e discute o resultado da Sprint com pessoas interessadas para inspecionar progresso e adaptar o Product Backlog. Incrementos podem ter sido liberados antes da reunião. A Review não é uma aprovação formal que transforma trabalho incompleto em pronto, nem um portão pelo qual toda mudança deve passar antes de chegar ao usuário. O feedback obtido pode alterar prioridades e os próximos recortes.

Quem faz o quê. Os Desenvolvedores são responsáveis por incutir qualidade ao aderir à Definition of Done. O Product Owner é responsável por maximizar o valor do produto e pela gestão eficaz do Product Backlog. O Scrum Master ajuda o time a focar Incrementos de alto valor que atendam à DoD. O Scrum Guide não cria uma etapa em que o PO certifica, no fim da Sprint, se os Desenvolvedores fizeram algo pronto.

Exemplo fora de software. Scrum pode ser aplicado a produtos e serviços não digitais. Uma melhoria de atendimento, por exemplo, só é utilizável se orientações, pessoas e canais necessários estão preparados conforme o padrão acordado. Um documento ainda não aprovado ou um piloto sem acesso ao cliente pode ser aprendizado útil, mas não deve ser confundido com um Incremento pronto do serviço. O time precisa adaptar a DoD ao produto real.

O Incremento é a evidência de progresso concreto. Estimativas, histórias iniciadas e apresentações de slides podem ajudar a planejar ou explicar trabalho, mas não substituem uma parte utilizável. Quando o time mantém essa distinção, consegue inspecionar resultado com honestidade e decidir melhor o que fazer depois.

Imagine um time hipotético que melhora um sistema de agendamentos. A Sprint dura duas semanas e a Meta é reduzir erros de confirmação. Antes, o time mostra oito itens na Sprint Review. Cinco estão em ambiente de teste, dois precisam de revisão de segurança e um depende de integração. Nenhum cumpre integralmente a DoD. Os números são ilustrativos. A demonstração parece movimentada, mas não há Incremento utilizável.

Na Sprint seguinte, o time divide a mudança em recortes menores. Primeiro, melhora a mensagem de confirmação para todos os agendamentos e verifica acessibilidade, testes e operação conforme a DoD. Essa parte se integra ao produto e pode ser liberada no quarto dia. Depois, acrescenta uma confirmação por outro canal, também integrada e verificada. O time pode apresentar ambos na Review e discutir o efeito observado nas dúvidas de usuários.

O número de itens ditos "prontos" pode cair de oito para dois, mas a informação fica mais confiável. Se o segundo recorte ainda depender de uma autorização externa, ele não entra no Incremento até cumprir o padrão. O time torna o impedimento visível e adapta seu plano sem mascarar o estado do trabalho.

Em um serviço presencial, o recorte poderia ser uma nova orientação de recepção implantada em uma unidade piloto com pessoas treinadas, material acessível e um modo de observar erros. Uma apresentação da proposta, por si só, não seria a melhoria utilizável. O contexto determina o que compõe o Incremento e como verificar que funciona com o serviço existente.

Cursos K21 recomendados