Como os Product Backlog Items ganham clareza comportamental específica por meio de critérios de aceitação, exemplos e Given/When/Then - e por que as expectativas no nível do item devem permanecer distintas do padrão de qualidade de todo o produto estabelecido pela Definition of Done
Tempo estimado de leitura: 20 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o que são , como eles se relacionam com Items individuais, como exemplos melhoram o entendimento compartilhado, como Given/When/Then expressa cenários de contexto-ação-resultado, por que são práticas complementares e opcionais, e não , e como distinguir requisitos específicos de um item do limite global de qualidade estabelecido pela .
Introdução: um precisa de significado compartilhado, não apenas de um título
Um curto pode criar foco, mas, sem expectativas compartilhadas, pessoas diferentes ainda podem imaginar produtos diferentes.
Imagine um intitulado 'Permitir que clientes redefinam a senha'. O pode imaginar um link enviado por e-mail que expira após trinta minutos. Um Developer pode presumir o uso de um código de uso único. A área de segurança pode exigir a revogação das sessões anteriores. O suporte pode esperar que o usuário consiga recuperar o acesso mesmo se o endereço de e-mail tiver sido alterado. Todos acreditam que o item está claro até que a implementação exponha as diferenças.
Os existem para tornar essas expectativas específicas do item mais transparentes antes ou durante a implementação. Eles descrevem condições, exemplos, regras ou comportamentos observáveis que ajudam o a compreender como é o sucesso para um determinado .
A prática está fortemente associada a User Stories e ao trabalho de requisitos em ambientes . As primeiras práticas de enfatizavam a conversa em vez de documentação exaustiva, mas os times ainda precisavam de uma forma de confirmar o significado da conversa. Os 'Three Cs', de Ron Jeffries, descrevem isso como Confirmation: exemplos ou verificações que ajudam a confirmar o comportamento pretendido. Mais tarde, o () popularizou exemplos estruturados com Given, When e Then.
Essa evolução é importante porque os não devem se transformar em outro documento extenso de requisitos. Seu valor está na precisão onde a precisão importa: o comportamento único do item atual. Eles complementam a conversa, o e o desenvolvimento, em vez de substituí-los.
O , por si só, não define . O Scrum Guide define os Items e permite que seus atributos variem conforme o domínio. Portanto, são uma técnica complementar. Um pode utilizá-los quando aumentarem a transparência e pode omiti-los quando outra técnica funcionar melhor.
A distinção mais importante é em relação à . descrevem o que um item específico deve fazer. A descreve o estado recorrente de qualidade exigido para o . Um é local e específico ao comportamento; o outro é global e orientado à qualidade. Um pode atender a todos os e ainda não estar Done se integração, segurança, testes, acessibilidade, desempenho ou outras medidas da permanecerem incompletas.
Para a preparação para a , essa distinção evita vários erros comuns. não são um artefato do , não são um compromisso do , não são um gate obrigatório de aprovação e não substituem a . São simplesmente uma forma útil de tornar o comportamento esperado de um mais fácil de compreender e verificar.
O que são ?
são condições ou exemplos específicos de um item que descrevem como determinado deve se comportar ou o que precisa ser verdadeiro para que a necessidade pretendida seja satisfeita.
Eles podem expressar regras de negócio, comportamento visível ao usuário, condições de contorno, regras de validação, tratamento de erros, permissões, cálculos, requisitos de dados ou outras características próprias daquele item.
Por exemplo, um pode dizer: 'Como titular de um cartão, quero bloqueá-lo temporariamente para protegê-lo enquanto procuro por ele.' Os podem esclarecer que novas autorizações de compra são recusadas imediatamente, que o usuário pode desbloquear o cartão posteriormente e que o aplicativo diferencia claramente o bloqueio temporário da comunicação de cartão roubado.
não precisam ser escritos como frases iniciadas por 'O sistema deverá'. Eles podem ser bullet points concisos, exemplos concretos, tabelas de decisão, cenários Given/When/Then, diagramas, regras ou outra forma que melhore o entendimento compartilhado.
O objetivo não é produzir papelada. O objetivo é reduzir a ambiguidade no nível de uma necessidade específica do produto.
Definição central
descrevem comportamento esperado ou condições específicas para um . Eles são uma prática complementar, não um elemento obrigatório do .
e Items
O define o como uma lista emergente e ordenada do que é necessário para melhorar o produto. Items próximos de serem selecionados normalmente precisam de transparência suficiente para que e tomem decisões úteis durante a .
podem contribuir para essa transparência. Eles podem revelar regras ocultas, esclarecer exemplos, expor casos de borda e reduzir interpretações diferentes para o mesmo item.
Entretanto, nem todo precisa do mesmo nível ou formato de . Um defeito pequeno e evidente pode precisar de apenas um exemplo reproduzível. Uma regra regulatória complexa pode exigir vários cenários. Um PBI técnico de redução de risco pode ser melhor expresso por uma hipótese experimental ou por um resultado técnico mensurável.
É por isso que o deixa os atributos dos Items em aberto. A forma deve seguir a decisão que precisa ser tomada, e não um template universal.
Os também evoluem. Durante o ou a , a conversa pode revelar novos casos ou tornar critérios existentes desnecessários. O é emergente, e o entendimento no nível do item também pode emergir.
são um apoio à conversa, não um contrato de handoff
Um anti-padrão comum é uma pessoa escrever exaustivos e entregá-los aos como se a conversa estivesse encerrada.
Essa abordagem recria o handoff tradicional de requisitos dentro de uma ferramenta com aparência . O ou analista torna-se o autor da verdade, enquanto os passam a ser implementadores de uma especificação que não ajudaram a compreender.
Uma prática mais forte utiliza de forma colaborativa. O traz a necessidade do usuário e o valor. Os expõem viabilidade, casos de borda, dependências e opções de implementação. Testers ou especialistas de qualidade contribuem com exemplos. Designers esclarecem o comportamento de interação. Especialistas de domínio revelam regras.
Os critérios tornam-se o resultado visível de uma conversa, e não um substituto dela.
Essa distinção também protege a negociabilidade. Se novas informações surgirem durante a implementação, o pode discutir se o comportamento esperado deve se adaptar, em vez de tratar cada linha como um contrato imutável.
Boa prática
Escreva para preservar o entendimento compartilhado, não para eliminar a necessidade de as pessoas conversarem.
Bons : específicos, observáveis e relevantes
úteis possuem algumas qualidades práticas. São específicos o suficiente para reduzir a ambiguidade, observáveis o suficiente para serem verificados, focados no comportamento ou na regra que realmente importa e concisos o bastante para permanecerem legíveis.
Critérios fracos costumam empregar palavras como rápido, intuitivo, seguro, fácil, apropriado ou amigável sem definir evidências observáveis. Também podem especificar em excesso detalhes de implementação que não pertencem ao requisito.
Exemplos de fracos e melhores
Qualidade
Exemplo
Por quê
Fraco
O login deve ser seguro.
Seguro é amplo demais; o critério não identifica o comportamento relevante.
Melhor
Após cinco tentativas de login malsucedidas em até dez minutos, a conta fica temporariamente bloqueada por quinze minutos.
A condição e o comportamento esperado são observáveis.
Fraco
O relatório deve carregar rapidamente.
Rapidamente é ambíguo.
Melhor
Para relatórios com até 10.000 linhas, a primeira página de resultados é exibida em até dois segundos sob condições normais de operação.
O limite de desempenho esperado está explícito.
Fraco
Mostrar um erro amigável.
Amigável é subjetivo.
Melhor
Se o provedor de pagamento estiver indisponível, o usuário vê que o pagamento não foi enviado e pode tentar novamente sem criar um pagamento duplicado.
O resultado visível ao usuário e o comportamento de segurança estão claros.
Given / When / Then: transformando regras em exemplos
Given/When/Then é uma forma estruturada de descrever comportamento por meio de exemplos. É amplamente associado ao e à linguagem Gherkin utilizada pelo Cucumber.
O padrão expressa três partes diferentes de um cenário:
Estrutura Given / When / Then
Palavra-chave
Finalidade
Exemplo
Given (Dado)
O contexto ou estado inicial antes de o comportamento ocorrer.
Dado que o cartão está ativo e o cliente está autenticado
When (Quando)
O evento ou ação que dispara o comportamento.
Quando o cliente bloqueia temporariamente o cartão
Then (Então)
O resultado observável esperado.
Então novas autorizações de compra para o cartão são recusadas
Given estabelece o cenário. Ele deve descrever pré-condições relevantes, e não detalhes de implementação. When descreve uma ação ou evento. Then descreve um resultado observável, evitando, quando possível, o estado interno do banco de dados.
A referência oficial do Gherkin, do Cucumber, recomenda descrever o contexto inicial com Given, um evento com When e um resultado esperado com Then. Etapas adicionais com And ou But podem melhorar a legibilidade quando vários contextos ou resultados são necessários.
Given/When/Then pode ser extremamente útil porque exemplos revelam ambiguidade mais rapidamente do que regras abstratas. Uma afirmação como 'usuários bloqueados não conseguem fazer login' parece clara até o time perguntar: e se o bloqueio expirar durante a autenticação? E se o usuário já tiver uma sessão ativa? Qual mensagem será exibida? Cenários concretos expõem essas perguntas.
Importante
Given/When/Then é uma técnica opcional de specification by example. O não exige Gherkin, Cucumber, ou testes de aceitação automatizados.
Um exemplo completo de Given / When / Then
Considere um para bloqueio de cartão:
Como titular de um cartão, quero bloqueá-lo temporariamente para proteger minha conta enquanto procuro um cartão extraviado.
Um cenário de aceitação poderia ser:
Dado que o cartão do cliente está ativo
E o cliente está autenticado no aplicativo móvel
Quando o cliente bloqueia temporariamente o cartão
Então novas autorizações de compra para esse cartão são recusadas
E o aplicativo exibe o cartão como temporariamente bloqueado
E o cliente pode posteriormente escolher desbloqueá-lo
Outro cenário poderia esclarecer a diferença entre bloqueio temporário e comunicação de cartão roubado. Um terceiro poderia descrever o que acontece se o serviço de autorização estiver indisponível. A quantidade exata de cenários deve ser determinada pelo comportamento que realmente agrega clareza, e não por uma regra que obrigue todo PBI a ter um número fixo.
O valor desses cenários não está em parecerem técnicos. Seu valor é tornar o comportamento de negócio concreto o suficiente para que conversas de produto, desenvolvimento e qualidade convirjam.
Given / When / Then não é um script de teste
Cenários Gherkin podem tornar-se especificações executáveis quando conectados ao Cucumber ou a ferramentas semelhantes, mas não precisam ser testes automatizados.
Um erro comum é escrever instruções de UI de baixo nível, como 'Dado que clico no botão X e digito texto no campo Y...'. Isso acopla a especificação a detalhes da interface e dificulta a compreensão da regra de negócio.
A orientação do Cucumber recomenda ocultar detalhes de implementação e descrever resultados observáveis. O cenário deve comunicar comportamento na linguagem do domínio do produto.
A automação pode ser valiosa, mas a conversa e a especificação devem permanecer compreensíveis até mesmo para pessoas que não leem o código de teste subjacente.
vs.
e costumam ser confundidos porque ambos influenciam a percepção de conclusão do trabalho. Porém, seu escopo e sua finalidade são diferentes.
vs.
Dimensão
Escopo
Um específico
O / estado de qualidade de todo o produto
Pergunta principal
Este item se comporta como pretendido?
O atingiu o estado de qualidade exigido?
Conteúdo
Regras, exemplos, comportamentos e casos de borda específicos do item
Medidas recorrentes de qualidade, como integração, testes, segurança, desempenho, conformidade, documentação etc.
Exigência do ?
Não - técnica complementar
Sim - compromisso formal do
Frequência
Pode variar de PBI para PBI
Aplica-se consistentemente a todo trabalho relevante do
Exemplo
O link para redefinição de senha expira após 30 minutos
Testes de regressão exigidos, security scanning, integração e prontidão operacional estão concluídos
Memorize a distinção
= requisito específico para um PBI. = padrão global e recorrente de qualidade para o .
Um PBI pode atender aos e ainda não estar Done
Suponha que uma funcionalidade de redefinição de senha atenda a todas as condições específicas do item. O usuário recebe o e-mail de redefinição, o link expira corretamente e a nova senha funciona.
Entretanto, o security scan obrigatório ainda não foi concluído, os testes de regressão estão incompletos e o monitoramento em produção não foi configurado. Se essas atividades fizerem parte da , o trabalho não faz parte do .
Os confirmam o comportamento solicitado. A confirma o estado de qualidade exigido para o produto.
Essa distinção impede que Product Owners ou stakeholders 'aceitem' um item que ainda viola o limite de qualidade do produto. O não define uma cerimônia de aceitação do capaz de sobrepor-se à .
Requisito específico vs. padrão global de qualidade
A forma mais fácil de separar da é perguntar se a regra é exclusiva daquele item ou se deveria se aplicar repetidamente ao produto.
Uma regra como 'o limite de transferência é de US$ 5.000 para este tipo de conta' pertence ao item ou ao comportamento do produto. Uma regra como 'todas as alterações devem passar pelo security scanning exigido' pertence a um padrão recorrente de qualidade quando se aplica de forma ampla.
Manter a qualidade global na evita repetir os mesmos critérios em todo PBI. Manter o comportamento específico junto ao PBI evita que a se torne um enorme catálogo de todas as regras de funcionalidades do produto.
Requisito específico vs. padrão global de qualidade
Escopo
Exemplo
Melhor enquadramento
Específico
Uma transferência acima de US$ 5.000 exige confirmação adicional.
Critério de aceitação / regra de produto no nível do item
Específico
O link de redefinição de senha expira após 30 minutos.
Critério de aceitação
Global
Todos os testes automatizados de regressão relevantes são aprovados.
Global
O vulnerability scanning exigido é concluído sem findings críticos não resolvidos.
Global
O está integrado ao produto atual e pode ser implantado de acordo com os padrões do produto.
Quem cria os ?
Como o não prescreve , ele não os atribui a uma accountability formal do .
O é accountable por criar e comunicar claramente os Items e por garantir que o seja compreendido. Os são responsáveis por dimensionar o trabalho e por criar o . Na prática, os costumam ser mais fortes quando essas perspectivas colaboram.
Um pode começar com regras de negócio ou exemplos. podem revelar casos de borda. Testers ou especialistas de qualidade podem propor cenários. Designers podem esclarecer o comportamento de interação. Usuários ou stakeholders podem revelar exceções.
O não deve se tornar o único autor dos requisitos, e os não devem tratar os critérios como instruções imutáveis. O entendimento compartilhado é mais importante do que a autoria.
durante o
O é um lugar natural para que emerjam, pois o refinement aumenta a transparência e a precisão dos PBIs.
Uma ampla pode inicialmente conter apenas a necessidade do usuário. Durante o refinement, o explora regras de negócio, exemplos, casos de borda, dependências e trade-offs. Algumas dessas descobertas podem ser preservadas como .
Nem todo caso de borda precisa estar documentado antes da . Critérios em excesso podem criar especificação prematura e desperdício. O time deve registrar os detalhes que melhoram de forma material a próxima decisão ou reduzem uma ambiguidade perigosa.
também podem revelar que uma story é grande demais. Se um PBI exige dezenas de cenários não relacionados, dividi-lo em stories menores e valiosas pode melhorar clareza, ordenação, estimativa e feedback.
Exemplo prático - para limite de pagamento digital
Imagine um responsável por um produto de pagamentos para empresas. O é:
Como administrador de uma empresa, quero definir um limite diário de pagamento para cada operador, para reduzir o risco financeiro enquanto delego o trabalho de pagamentos.
Durante o refinement, o explica a intenção de negócio. Os perguntam como o limite interage com pagamentos pendentes, múltiplas moedas e administradores que alteram suas próprias permissões. Um especialista de compliance esclarece que administradores não podem aumentar o próprio limite acima do máximo definido pela organização.
O registra vários específicos do item:
O administrador pode definir um limite diário para um operador de zero até o máximo configurado pela organização.
O operador não pode enviar um novo pagamento quando a soma dos pagamentos já executados com o novo pagamento excederia o limite diário.
Pagamentos pendentes não consomem o limite diário até serem executados.
Se o administrador reduzir o limite para um valor inferior ao já utilizado naquele dia, os pagamentos já executados permanecem válidos e novos pagamentos ficam bloqueados até o próximo período de limite.
Um administrador não pode aumentar seu próprio limite pessoal acima do máximo definido para toda a organização.
Em seguida, o time transforma as regras mais importantes em exemplos concretos de Given/When/Then.
Dado que a operadora Ana possui limite diário de pagamento de US$ 10.000
E Ana já executou US$ 8.000 em pagamentos hoje
Quando Ana tenta enviar um novo pagamento de US$ 3.000
Então o pagamento não é enviado
E Ana é informada de que o limite diário de pagamento seria excedido
Esses critérios não definem o padrão completo de qualidade. A ainda exige testes de integração, security scanning, audit logging, verificações de acessibilidade, monitoramento operacional e outros padrões de todo o produto.
Durante a implementação, os descobrem que o momento da conversão de moedas torna uma regra ambígua. O e os discutem se o limite deve usar a cotação atual ou a cotação no momento da execução. Os são atualizados para refletir a decisão.
Quando a implementação é concluída, os cenários passam. Entretanto, uma validação de audit log exigida pela falha. O PBI atende aos seus , mas ainda não está Done e, portanto, não faz parte do .
Esse exemplo mostra a relação completa: esclarecem comportamento específico do item; Given/When/Then torna regras importantes concretas; a colaboração pode alterar os critérios à medida que o entendimento melhora; e a permanece como o limite final e recorrente de qualidade para o .
Anti-padrões comuns de
Anti-padrões comuns de
Anti-padrão
Por que enfraquece a transparência
Critérios como especificação completa
Páginas de critérios substituem a conversa e congelam detalhes cedo demais.
Todo PBI deve usar Given/When/Then
Uma técnica opcional torna-se uma regra obrigatória de formatação.
Scripts de cliques na UI
Os cenários descrevem passos de baixo nível da interface em vez do comportamento do produto.
Critérios copiados da
Padrões globais de qualidade são duplicados em todos os itens.
substituída por
Comportamento específico do item é confundido com a qualidade completa do .
Gate de aprovação do
Os critérios tornam-se uma cerimônia formal de aceitação que sobrepõe o limite de Done do .
Adjetivos ambíguos
Palavras como rápido, seguro, intuitivo ou fácil aparecem sem evidência observável.
Ausência de cenários negativos
Somente o happy path é discutido mesmo quando exceções importantes afetam valor ou risco.
Cenários demais para uma única story
Pode indicar que o PBI é grande demais e deveria ser dividido.
Critérios nunca evoluem
Novo aprendizado durante refinement ou implementação é ignorado para preservar a redação original.
Armadilhas comuns da sobre
Armadilhas comuns da sobre
Armadilha
Interpretação correta
são obrigatórios no .
Falso. São uma técnica complementar e não aparecem como elemento obrigatório do .
são um artefato do .
Falso. Os são , e .
são um compromisso do .
Falso. Os compromissos são , e .
Given/When/Then é obrigatório para todo PBI.
Falso. É um formato opcional de specification by example.
e são sinônimos.
Falso. Um é específico do item; o outro é o padrão recorrente de qualidade do .
Atender aos significa que o PBI está automaticamente Done.
Falso. Ele também deve satisfazer a .
O pode aceitar trabalho incompleto porque todos os passaram.
Falso. Trabalho que não atende à não faz parte do .
Somente o pode escrever .
Falso. O não prescreve autoria; criação colaborativa pode melhorar o entendimento.
não podem mudar depois da .
Falso. O aprendizado pode esclarecer o comportamento, enquanto mudanças de escopo ainda precisam respeitar o e as accountabilities do .
devem ser testes automatizados.
Falso. Podem ser exemplos, regras, verificações manuais, cenários ou outra representação útil.
Um critério que se aplica a todo PBI deve constar em toda story.
Geralmente é má prática. Padrões recorrentes de qualidade pertencem à quando apropriado.
substituem o .
Falso. Podem ser um resultado do refinement, mas não substituem o refinement colaborativo.
Um framework de raciocínio para questões da sobre
Exigência do : a resposta evita tornar os obrigatórios?
Escopo: os critérios são específicos de um PBI, e não regras globais de qualidade do produto?
Transparência: os critérios reduzem a ambiguidade sobre o comportamento esperado?
Colaboração: eles são tratados como apoio à conversa, e não como contrato de handoff?
Given/When/Then: o formato é opcional e orientado ao comportamento?
Distinção da : a resposta preserva a como compromisso global de qualidade do ?
Done: um PBI pode atender aos e ainda assim permanecer incompleto porque a não foi atendida?
Refinement: os critérios podem emergir e evoluir conforme o entendimento do melhora?
Autoria: a resposta permite criação colaborativa em vez de atribuir os critérios exclusivamente a uma accountability do ?
Específico vs. global: um padrão recorrente vai para a , enquanto um comportamento único permanece com o PBI?
Heurística rápida para a prova
respondem: 'O que este item deve fazer?' A responde: 'Qual estado de qualidade o deve atingir antes de este trabalho contar como Done?'
Conclusão: comportamento específico e qualidade global precisam de limites diferentes
são úteis porque Items costumam ser intencionalmente leves. Uma descrição curta cria foco, mas exemplos e regras podem tornar o comportamento esperado preciso o suficiente para que conversas de produto, desenvolvimento e qualidade convirjam.
Eles são melhor compreendidos como transparência no nível do item. Um PBI pode precisar de várias regras de negócio; outro pode precisar de um único exemplo; outro pode não precisar de formais. O deixa essa flexibilidade porque diferentes domínios de produto exigem diferentes formas de representação.
Given/When/Then é uma das técnicas mais úteis para expressar critérios porque separa contexto, ação e resultado esperado. Exemplos concretos expõem ambiguidades e podem, posteriormente, sustentar especificações executáveis, mas Gherkin e continuam sendo práticas complementares e opcionais.
A atua em outro nível. Ela descreve o estado de qualidade exigido para o . podem confirmar que a funcionalidade se comporta corretamente, enquanto a confirma que o trabalho integrado do produto satisfaz medidas recorrentes de qualidade, como testes, segurança, desempenho, documentação, acessibilidade ou prontidão operacional.
Isso significa que passar pelos não torna automaticamente um Done. O item passa a fazer parte do somente quando a é satisfeita.
Manter os dois conceitos separados também reduz duplicação. Comportamento de negócio exclusivo permanece com o item. Qualidade global recorrente permanece na . O pode então inspecionar tanto a correção do produto quanto sua qualidade sem misturar as finalidades.
Na minha visão, bons não impressionam por serem longos ou formais. Eles são valiosos quando tornam um comportamento importante inequivocamente claro e provocam a conversa certa. O melhor critério muitas vezes parece simples porque o pensamento difícil ocorreu antes de ele ser escrito.
Principais pontos
descrevem comportamento esperado específico ou condições para um individual.
O não exige ; eles são uma prática complementar.
podem ser bullet points, exemplos, regras, tabelas de decisão, cenários Given/When/Then ou outra representação útil.
Sua principal finalidade é reduzir ambiguidade e melhorar o entendimento compartilhado.
devem apoiar a conversa, e não se transformar em uma especificação de handoff.
Given descreve o contexto inicial, When descreve uma ação ou evento e Then descreve o resultado observável esperado.
Given/When/Then está associado a e Gherkin, mas não é exigido pelo .
são específicos do item; a é o padrão global e recorrente de qualidade para o .
Um PBI pode atender a todos os e ainda não estar Done se não atender à .
Medidas recorrentes de qualidade pertencem à quando se aplicam amplamente.
Regras específicas de negócio e comportamento permanecem com o PBI relevante.
podem emergir e evoluir durante o e o desenvolvimento.
O não atribui autoria exclusiva dos ao nem a outra accountability.
Items com quantidade excessiva de critérios não relacionados podem precisar ser divididos em itens menores.
