Como o Scrum transforma o trabalho do Product Backlog em progresso utilizável, integrado e verificado em direção ao Product Goal - e por que Increments Done podem ser criados e entregues ao longo de uma Sprint, sem esperar pela Sprint Review.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o que é um , como ele representa valor e progresso, por que precisa ser utilizável e integrado a todos os Increments anteriores, como vários Increments podem ser criados em uma única , por que a entrega pode ocorrer antes da , como o se relaciona ao e como a protege a qualidade e a transparência.
Introdução: no , o progresso precisa se tornar algo real
O não mede o progresso principalmente por quanto trabalho foi iniciado, por quão ocupadas as pessoas estão ou por quantas tarefas estão quase concluídas. O progresso ganha significado quando o trabalho se transforma em um utilizável.
A ideia de desenvolvimento incremental de produtos é anterior ao . Engenheiros e equipes de produto aprenderam que grandes sistemas se tornam mais seguros para evoluir quando o progresso é criado em pequenos passos integrados, em vez de ser montado apenas ao final de um projeto longo. O adotou essa lógica e a tornou central para o desenvolvimento empírico de produtos: durante cada , o transforma o trabalho selecionado do em um de valor.
Isso é mais exigente do que simplesmente concluir tarefas. Um não é uma coleção de componentes parcialmente concluídos, branches isoladas, documentos desconectados ou funcionalidades que ainda exigem uma fase separada de estabilização. O Scrum Guide atual o define como um passo concreto em direção ao . Cada é aditivo a todos os Increments anteriores e é minuciosamente verificado para assegurar que funcionem em conjunto. Para fornecer valor, ele deve ser utilizável.
Essa definição conecta, de uma só vez, várias ideias fundamentais do . O fornece direção de longo prazo. Os Items expressam possibilidades de trabalho no produto. Os transformam o trabalho selecionado em um estado utilizável do produto. A define as medidas de qualidade que tornam a conclusão transparente. Em seguida, a oferece uma oportunidade formal de inspecionar o resultado com os stakeholders - mas o próprio não precisa esperar pela Review para ser entregue.
Esse último ponto é uma das distinções práticas e de prova mais importantes. O não define a como um gate de release. Vários Increments podem ser criados durante uma , e um pode ser entregue aos stakeholders antes do fim da . Isso permite que equipes de produto encurtem os ciclos de feedback ainda mais do que a cadência da quando o contexto do produto favorece entregas frequentes.
O também impede que uma organização esconda trabalho inacabado atrás de relatórios de percentual concluído. Um contribui para um Done e utilizável, ou não contribui. Trabalho que não atende à não pode ser contabilizado como parte do nem apresentado na como trabalho de produto concluído.
Para candidatos à , o modelo mental mais útil é simples: o é evidência. É evidência de que o trabalho do produto atingiu um estado de qualidade utilizável, evidência de progresso em direção ao e evidência que os stakeholders podem inspecionar. Este capítulo explora por que essa evidência é tão importante e como ela muda a forma como os times pensam sobre valor, integração, qualidade, releases e progresso.
O conceito oficial de
O Scrum Guide define um como um passo concreto em direção ao . Trata-se de progresso real do produto que pode ser inspecionado e utilizado como base para decisões futuras.
A palavra concreto é importante. Um plano não é um . Uma estimativa não é um . Um design que ainda não pode ser utilizado como parte do produto não é automaticamente um . O exige que o progresso do produto se torne tangível o suficiente para que o time e os stakeholders possam inspecionar o que de fato existe.
A expressão passo em direção ao conecta a entrega de curto prazo à direção de longo prazo do produto. Um deve fazer o produto avançar de uma maneira que possa apoiar aprendizado, valor, capacidade, redução de risco ou outra melhoria significativa do produto.
Um pode assumir formas diferentes conforme o produto. Em software, pode ser uma versão integrada e utilizável de uma aplicação ou serviço. Em um produto físico, pode ser uma configuração funcional aprimorada. Em pesquisa, pode ser um resultado de pesquisa integrado e utilizável. O não se limita a software; portanto, deve ser entendido como um estado utilizável do produto, e não como um pacote de release de software.
Âncora para a
Um é um passo concreto em direção ao . Ele deve estar utilizável, integrado, verificado e Done.
Valor: o existe para apoiar o progresso do produto
A definição do afirma que, para fornecer valor, o precisa ser utilizável. Isso não significa que todo tenha de gerar receita imediata ou encantar um cliente por si só. O valor pode assumir várias formas, conforme o contexto do produto.
Um pode melhorar resultados para o cliente, reduzir riscos, aumentar a confiabilidade, habilitar capacidades futuras, proporcionar , atender a uma regulamentação, reduzir custos operacionais, melhorar a acessibilidade ou tornar o produto mais seguro e mais fácil de evoluir.
O ponto central é que o trabalho passe a fazer parte de um estado coerente do produto, em vez de permanecer como esforço especulativo e inacabado. Uma ideia de alto valor que existe apenas em uma branch incompleta ainda não pode ser inspecionada nem utilizada da mesma maneira que um Done.
O valor também permanece empírico. O pode acreditar que um criará valor, mas o feedback dos stakeholders ou o uso real pode demonstrar o contrário. É por isso que o favorece a inspeção: o time pode comparar as hipóteses sobre o produto com as evidências.
Essa distinção é importante para o . Output pergunta quanto foi construído. Valor incremental pergunta qual progresso utilizável do produto existe agora e o que esse progresso nos ensina.
Usabilidade: Done significa que o produto pode realmente ser utilizado
O deve ser utilizável. No , usabilidade não significa necessariamente que a organização tenha escolhido fazer uma release pública, mas significa que o estado do produto é capaz de ser utilizado de acordo com a .
Isso impede que os times declarem sucesso enquanto trabalho crítico de finalização permanece em outro lugar. Se integração, testes, validação de segurança, documentação, verificação de performance ou preparação para deployment fizerem parte da , um item que não os concluiu não contribui para o .
Um time que afirma "o desenvolvimento terminou; os testes acontecerão na próxima " não está criando um Done se os testes forem exigidos para a qualidade do produto. Da mesma forma, um componente que funciona apenas isoladamente, mas quebra o produto integrado, não é um utilizável.
A usabilidade cria opcionalidade econômica. Quando o está utilizável, o e a organização podem decidir se fazem a release com base em valor, momento de mercado, risco, conformidade ou outras considerações de produto. Quando o não está utilizável, não existe uma verdadeira decisão de release - existe apenas trabalho inacabado.
Utilizável não significa liberado
Um Done deve ser utilizável, mas o não exige que todo utilizável seja liberado imediatamente. Ele precisa estar em um estado no qual a release seja uma decisão de produto, e não uma operação de resgate de qualidade.
Aditivo a todos os Increments anteriores
Todo é aditivo a todos os Increments anteriores. Isso significa que o produto não recomeça do zero a cada . Novo valor de produto é acrescentado ao estado integrado já existente.
Aditivo não significa necessariamente "mais funcionalidades". Um pode remover uma capacidade obsoleta, simplificar um fluxo, substituir um componente frágil ou reduzir complexidade técnica. O ponto importante é que o estado resultante do produto incorpore o novo trabalho e preserve um todo coerente e utilizável.
É por isso que o trabalho individual de não pode simplesmente ser chamado de Increments independentes e separados se essas partes não estiverem integradas. Uma alteração de frontend, uma alteração de API e uma migração de banco de dados podem estar localmente concluídas, mas o do produto só existe quando o estado do produto funciona em conjunto, de acordo com a .
A integração, portanto, é uma responsabilidade contínua, e não uma fase de fim de . Quanto mais tempo os times deixam trabalhos individuais separados, maior é o risco de problemas de integração surgirem tarde, reduzirem a transparência e ameaçarem o .
Para produtos apoiados por vários Teams, a mesma lógica se aplica no nível do produto. O trabalho deve se integrar em um único produto coerente que atenda à compartilhada.
Minuciosamente verificado: a qualidade não pode ser presumida
O Scrum Guide afirma que cada é minuciosamente verificado, assegurando que todos os Increments funcionem em conjunto. A verificação fornece confiança empírica de que o estado atual do produto é realmente utilizável.
As técnicas específicas de verificação dependem do domínio. Software pode exigir testes automatizados, controles de segurança, verificações de performance, testes de integração, validação de acessibilidade, , observabilidade ou prontidão operacional. Produtos físicos podem exigir testes de segurança ou performance. Produtos de pesquisa podem exigir reprodutibilidade ou verificações de qualidade.
O deliberadamente não prescreve essas técnicas. Em vez disso, a torna explícito o estado de qualidade exigido para o produto.
A verificação não deve ser adiada para a . A é um evento de inspeção do produto e colaboração com stakeholders, e não um gate de qualidade. O trabalho já deve atender à antes de ser considerado parte do .
Isso protege a transparência. Stakeholders que inspecionam um não deveriam precisar adivinhar quais partes estão realmente concluídas e quais ainda dependem de testes ou integração ocultos.
Vários Increments durante uma única
O Scrum Guide afirma explicitamente que vários Increments podem ser criados dentro de uma . Esse é um lembrete importante de que o não define um único grande em "big bang" que aparece somente no final da .
No momento em que um atende à , nasce um . Mais tarde, durante a , trabalho adicional Done pode ser integrado, criando novo progresso do produto. A soma dos Increments é inspecionada na .
Na prática, pode ser útil pensar neles como estados utilizáveis sucessivos do produto. A capacidade Done de segunda-feira passa a fazer parte do produto. O trabalho adicional Done de quarta-feira estende esse estado do produto. O trabalho adicional de sexta-feira o amplia novamente. Cada passo deve continuar integrado e utilizável.
Esse modelo favorece o fluxo. Os não precisam esperar até o último dia da para atingir Done. Conclusões frequentes reduzem , expõem problemas de integração mais cedo e criam mais oportunidades de liberar valor e aprender.
A existência de vários Increments não justifica fragmentos independentes e incompatíveis. Cada deve ser aditivo aos anteriores e minuciosamente verificado para que o produto continue funcionando como um todo coerente.
Nuance importante
Vários Increments podem ser criados durante uma , mas cada novo estado do produto deve permanecer integrado e aditivo ao produto existente.
Entrega antes da
Um pode ser entregue aos stakeholders antes do fim da . A nunca deve ser considerada um gate para liberar valor.
Essa regra é um dos exemplos mais claros de como o separa a cadência de inspeção da cadência de release. A oferece uma oportunidade formal e recorrente para inspecionar resultados do produto e adaptar a direção futura. A release pode ocorrer sempre que houver um Done e o contexto do produto permitir.
Um time pode fazer várias releases durante uma de duas semanas, uma release por ou liberar com menor frequência por causa de restrições legítimas do produto. O não prescreve frequência de release. O que ele exige é que o esteja utilizável e Done.
Esperar pela apenas porque "o diz que releases acontecem na Review" é, portanto, incorreto. Isso atrasa o feedback e transforma a Review em um gate de aprovação que o nunca definiu.
O uso real antes da pode tornar a Review mais forte. Em vez de discutir apenas o que os stakeholders acham que pode acontecer, o pode levar evidências sobre uso real, performance, conversão, comportamento do cliente ou impacto operacional.
Fato para a prova
A não é um gate de release. Um Done pode ser entregue antes do fim da .
O e o
O descreve um estado futuro do produto e é o objetivo de longo prazo do . O é o progresso concreto do produto que ajuda o time a avançar em direção a esse objetivo.
Essa relação protege o de se transformar em uma "". Um time pode criar muitos Increments Done, mas, se esses Increments não se acumularem em progresso em direção a um significativo, output não estará necessariamente se convertendo em valor estratégico.
Os Goals criam foco de prazo mais curto dentro dessa jornada. Os selecionam Items e criam Increments durante uma em busca do , enquanto a sequência de Sprints e seus Increments deve contribuir para o .
A torna essa conexão visível ao discutir o progresso em direção ao . O e os stakeholders inspecionam o que o revela e decidem qual adaptação do produto deve ocorrer em seguida.
Um também pode revelar que o próprio é fraco ou deixou de ser valioso. O permite que o utilize evidências para questionar a direção, e não apenas a implementação.
A : o compromisso associado ao
A é o compromisso associado ao . Trata-se de uma descrição formal do estado do quando ele atende às medidas de qualidade exigidas para o produto.
No momento em que um atende à , nasce um . Se o item não atender à , não poderá ser considerado parte do .
A cria transparência ao oferecer a todos um entendimento compartilhado do trabalho concluído. Sem ela, dois poderiam usar significados diferentes para "Done", stakeholders poderiam interpretar incorretamente o estado do produto e Product Owners poderiam tomar decisões com base em trabalho inacabado oculto.
Se um não atender à , ele não poderá ser liberado nem apresentado na como trabalho concluído do . Ele retorna ao para consideração futura.
Se a organização possuir um padrão de , os Teams devem segui-lo como mínimo. Se não houver padrão organizacional, o cria uma apropriada para o produto. Quando vários Teams trabalham em um mesmo produto, eles devem definir mutuamente e cumprir a mesma .
Artefato + compromisso
-> . A cria transparência sobre qual estado de qualidade qualifica o trabalho como parte do .
Qualidade: por que "quase Done" é economicamente perigoso
O não cria um artefato formal chamado "quase ". O trabalho ou faz parte do porque atende à , ou permanece inacabado.
Essa transparência binária é economicamente importante. Times que carregam grandes quantidades de trabalho quase concluído acumulam risco oculto. Testes permanecem pendentes, a integração é incerta, podem existir defeitos, o esforço de release é desconhecido e os relatórios de progresso se transformam em estimativas otimistas.
Uma forte incorpora o trabalho importante de qualidade ao processo normal de criação. Isso pode reduzir a quantidade aparente de escopo concluído no curto prazo, mas melhora a transparência do produto e reduz retrabalho futuro.
Durante a , a qualidade não diminui. Se os descobrirem que não conseguem concluir todo o escopo previsto no nível de qualidade exigido, o escopo pode ser adaptado com o enquanto o é protegido. Reduzir a apenas para alegar maior output enfraqueceria o .
A qualidade, portanto, passa a fazer parte do planejamento, do refinamento, do e do trabalho diário - e não de uma etapa final de inspeção.
vs. release vs. deployment
Os times frequentemente usam as palavras , release e deployment como se significassem a mesma coisa. O não exige essa equivalência.
Um é um estado utilizável e Done do produto. Deployment é o ato técnico ou operacional de disponibilizar algo em um ambiente. Release é uma decisão de produto ou de negócio de disponibilizar valor a usuários ou stakeholders. Esses conceitos podem coincidir, mas não precisam coincidir.
Por exemplo, um time de software pode criar um Done e fazer deployment dele atrás de uma feature flag enquanto aguarda um lançamento coordenado do produto. O permanece utilizável e integrado, mesmo que a capacidade ainda não tenha sido amplamente liberada.
Em outro contexto, um time pode criar e liberar vários Increments Done durante uma utilizando . A então inspeciona os resultados acumulados e as evidências do mundo real.
Essa distinção ajuda candidatos à a evitar a falsa suposição de que todo deve ser liberado exatamente na .
O que não conta como ?
Estado do trabalho
Interpretação como
Código concluído, mas não testado
Se os testes exigidos pela estiverem ausentes, o trabalho não faz parte do .
Um mockup de design para uma funcionalidade de software
Pode ser um trabalho valioso, mas não é automaticamente o utilizável do produto, a menos que o próprio produto seja o artefato de design e a seja atendida.
Uma branch de frontend separada
Não é um se não estiver integrada ao produto e verificada.
Um PBI 90% concluído
Percentual concluído não cria um .
Um ambiente de demo que ignora controles de qualidade exigidos
Um artefato de apresentação não é o estado Done do produto.
Uma funcionalidade aguardando aprovação de segurança exigida pela
Permanece inacabada até que o requisito de qualidade seja atendido.
Trabalho integrado e utilizável que atende à
Sim - isso faz parte do .
Exemplo prático - Vários Increments em uma de autenticação de pagamentos
Imagine um responsável por um produto de autenticação de pagamentos móveis. O é reduzir o abandono de pagamentos legítimos mantendo forte proteção contra fraude. O atual é melhorar a resiliência da autenticação para clientes recorrentes em dispositivos confiáveis.
Na , os selecionam vários Items: melhorar o caching de confiança do dispositivo, adicionar observabilidade de retries, otimizar uma consulta de dependência e atualizar a mensagem de retry voltada ao cliente. A inclui testes automatizados, validação de segurança, verificações de performance, prontidão integrada para deployment e observabilidade em produção.
No terceiro dia, a melhoria de caching passa por todas as medidas da e é integrada ao produto atual. Existe um novo estado utilizável do produto: o time criou um . Como o considera a melhoria segura e valiosa, a organização a libera imediatamente para um pequeno grupo de produção. O time não espera pela .
No sexto dia, a observabilidade de retry é concluída, integrada, verificada e atende à . O produto agora contém tanto a melhoria anterior de caching quanto a nova capacidade de observabilidade. Outro foi criado durante a mesma .
No oitavo dia, os descobrem que a otimização de dependência planejada é maior do que o esperado. Em vez de reduzir a qualidade ou criar uma solução parcialmente integrada, eles colaboram com o para reduzir o escopo preservando o . Uma otimização menor é concluída e atinge Done.
O item referente à mensagem de retry voltada ao cliente permanece inacabado quando a termina porque a validação de acessibilidade exigida pela não foi concluída. O time não o chama de "90% de um ", não o libera e não o apresenta na como trabalho concluído. Ele retorna ao para consideração futura.
Na , o e os stakeholders inspecionam a soma do progresso Done do produto criado durante a . Como alguns Increments já foram liberados, podem inspecionar evidências reais de produção: a latência melhorou, o abandono diminuiu para um segmento de clientes e os diagnósticos de retry se tornaram mais úteis para operações.
A discussão altera o . Um amplo redesenho de UI planejado desce na ordem porque as evidências sugerem que a confiabilidade da dependência tem impacto maior. Um novo experimento é adicionado para um segmento de clientes ainda não resolvido.
Esse exemplo demonstra o modelo de de ponta a ponta: o fornece direção, o fornece foco de curto prazo, os criam progresso integrado e Done, vários Increments podem surgir durante a , a release pode acontecer antes da , trabalho inacabado permanece fora do e a inspeção dos stakeholders gera novo aprendizado sobre o produto.
Anti-patterns comuns relacionados ao
Anti-pattern
Por que enfraquece o
Um único apenas no último dia da
Incentiva trabalho em grandes lotes e atrasa integração, verificação e aprendizado.
Sugere que Sprints anteriores não produziram Increments Done e utilizáveis.
Release somente após a
Transforma a Review em um gate e atrasa valor potencial.
Increments separados por time que não se integram
Viola a exigência de que os Increments funcionem em conjunto.
Testes depois da
Cria trabalho inacabado se os testes fizerem parte da .
Chamar trabalho 90% concluído de
Enfraquece a transparência; trabalho inacabado não faz parte do .
DoDs diferentes para times no mesmo produto
Pode produzir estados de qualidade incompatíveis; times que trabalham no mesmo produto precisam da mesma .
Reduzir qualidade para aumentar escopo
Conflita com a regra do de que a qualidade não diminui durante a .
Demo equivale a
Uma demonstração pode mostrar um , mas a apresentação não define Done.
significa funcionalidade
Um pode incluir qualquer melhoria integrada do produto que atenda à e apoie valor.
Armadilhas comuns da sobre o
Armadilha
Interpretação correta no
Exatamente um deve ser criado por .
Falso. Vários Increments podem ser criados dentro de uma .
O só pode ser liberado após a .
Falso. Um Done pode ser entregue antes do fim da .
A aprova o para release.
Falso. A não é um gate de release.
Um pode conter PBIs inacabados se a maior parte do trabalho estiver concluída.
Falso. Trabalho não faz parte de um se não atender à .
Cada Developer pode criar um independente que não precise ser integrado.
Falso. Increments devem ser aditivos, verificados e funcionar em conjunto.
O deve incluir uma nova funcionalidade voltada ao cliente.
Falso. Valor de produto pode incluir confiabilidade, redução de risco, aprendizado, conformidade e outras melhorias utilizáveis.
Um item liberado que depois se mostrou de baixo valor não era um .
Falso. O status de diz respeito a um estado Done e utilizável do produto; o valor permanece empiricamente inspecionável.
O determina se o trabalho atende à .
Falso. Os precisam cumprir a ; ela é um padrão compartilhado de qualidade.
Um pode ser mostrado na mesmo sem atender à .
Falso. O Guide afirma que ele não pode ser apresentado como parte do .
Vários Teams podem usar Definitions of Done incompatíveis no mesmo produto.
Falso. Eles precisam definir mutuamente e cumprir a mesma .
e release são sinônimos.
Falso. Um Done é utilizável; o momento da release é uma decisão de produto.
A qualidade pode ser reduzida temporariamente para concluir o .
Falso. A qualidade não diminui durante a .
Um framework de raciocínio para questões de na
Utilizável: o estado do produto está realmente utilizável de acordo com a ?
Done: cada parte contabilizada como atende à ?
Integrado: o novo trabalho funciona em conjunto com todos os Increments anteriores?
: o fornece um passo concreto em direção ao progresso do produto?
Vários Increments: a resposta permite vários estados Done do produto durante uma ?
Release: a resposta permite entrega antes da em vez de tratar a Review como um gate?
Transparência: os stakeholders conseguem compreender o que está genuinamente concluído?
Qualidade: a resposta preserva a e a regra de que a qualidade não diminui?
Trabalho inacabado: trabalho que não atende à permanece fora do e retorna à consideração no ?
Vários times: um produto preserva uma compartilhada para que os Increments permaneçam integrados?
Atalho rápido para a prova
Se não está Done, utilizável, integrado e verificado, não o chame de parte do .
Conclusão: o é onde as promessas do encontram a realidade
O é o artefato que transforma o de um framework de planejamento em um sistema empírico de produto. Product Goals, Goals, Product Backlogs e Backlogs orientam decisões, mas o mostra qual progresso real do produto foi de fato alcançado.
Um válido é um passo concreto em direção ao . Ele é aditivo aos Increments anteriores, minuciosamente verificado e utilizável. Esses requisitos criam um estado coerente do produto em vez de uma coleção de fragmentos concluídos apenas localmente.
A fornece ao sua fronteira de qualidade. No momento em que um atende a esse padrão, nasce um . Trabalho que não atende à permanece inacabado, independentemente de quanto esforço já tenha sido gasto.
O também favorece fluxo em vez de trabalho em grandes lotes. Vários Increments podem ser criados durante uma , e um Done pode ser entregue antes da . A cadência de release e a cadência da são, portanto, distintas. A Review inspeciona resultados e adaptações futuras; ela não autoriza a existência de trabalho Done.
A relação com o confere significado estratégico ao . Um time não deve otimizar apenas para produzir mais itens concluídos. A pergunta é se estados sucessivos e utilizáveis do produto criam evidências e progresso em direção a um futuro significativo para o produto.
A qualidade torna esse progresso confiável. Integração, verificação e uma compartilhada impedem que a organização trate esforço inacabado como valor. Essa transparência torna a inspeção confiável, e uma inspeção confiável torna a adaptação possível.
Na minha visão, o é uma das disciplinas mais importantes do porque obriga os times a substituir relatórios otimistas por evidência do produto. "Quase Done" pode soar tranquilizador; um utilizável é realidade inspecionável. Em trabalho complexo, essa diferença é o que permite às organizações aprender antes que a incerteza se torne cara.
Principais conclusões
Um é um passo concreto em direção ao .
Cada é aditivo a todos os Increments anteriores.
Os Increments devem ser minuciosamente verificados para que o produto funcione em conjunto como um todo coerente.
Para fornecer valor, um deve ser utilizável.
Todo o é accountable por criar um valioso e útil a cada .
Os estão comprometidos em criar qualquer aspecto de um utilizável a cada .
Vários Increments podem ser criados em uma única .
A soma dos Increments é inspecionada na .
Um Done pode ser entregue aos stakeholders antes do fim da .
A nunca é um gate para liberar valor.
O trabalho não faz parte do se não atender à .
A é o compromisso associado ao .
No momento em que um atende à , nasce um .
Trabalho inacabado não pode ser liberado nem apresentado na como parte do .
Quando vários Teams trabalham em um produto, devem cumprir a mesma .
não significa funcionalidade, deployment ou release; significa um estado Done e utilizável do produto.
Increments sucessivos devem criar progresso inspecionável e aprendizado em direção ao .
