Criando boas User Stories

Marcos Garrido, Sócio-fundador e Trainer na K21

Este post não tem tags.

Compartilhe:

Bill Wake, autor do livro “Extreme Programming Explored”, descreveu em seu blog quais seriam as características de boas User Stories. Ele formou o acrônimo INVEST (“investir”, em inglês) com a primeira letra de cada uma dessas características, afirmando que devemos “investir em boas User Stories” (Wake, 2003).

De acordo com Wake, uma User Story deve ser:

  • independente: User Stories devem ser o mais independentes ou desacopladas possível umas das outras, ou seja, User Stories com grande número de dependências em outras User Stories devem ser evitadas. Essa independência visa ser viável alterar livremente a ordem que serão desenvolvidas e, ao fazê-lo, não ser necessário alterar suas estimativas.
    Cabe adicionar que uma User Story se traduzirá sempre em uma funcionalidade de ponta a ponta, que representa valor para o usuário. Além disso, deve ser possível entender uma User Story sem ser necessário ler quaisquer outras;
  • negociável e negociada: seus detalhes serão discutidos, negociados e definidos entre as pessoas de negócios (com o Product Owner, entre elas) e o Time de Desenvolvimento. São as “Conversas”, dos três C’s;
  • valiosa: devem representar valor de negócio para os clientes do projeto. Ao dividir-se uma User Story, o resultado dessa divisão deve ser User Stories menores que também representem funcionalidades de ponta a ponta, e não partes de trabalho técnico;
  • estimável: o Time de Desenvolvimento deve possuir detalhes suficientes — tanto técnicos quanto de negócios — para estimar o trabalho de se transformar a User Story em parte do produto, de forma que o Product Owner possa ordená-la apropriadamente.
    Assim, conversas suficientes devem ser realizadas entre as pessoas de negócios e os membros do Time de Desenvolvimento para se obter os detalhes de negócios da User Story a ser desenvolvida. Os membros do Time de Desenvolvimento devem discutir possíveis soluções e executar pequenos experimentos, caso necessário, para reduzir os riscos técnicos da User Story. É claro que o nível de detalhes necessário depende de quão próxima a User Story está de ser colocada em desenvolvimento.
    Estimativas fornecem o custo de desenvolvimento de uma User Story. Mesmo caso não se utilizem estimativas, os detalhes são necessários para dividir as User Stories de forma que fiquem pequenas o suficiente para serem desenvolvidas;
  • pequena (“small”, em inglês) ou dimensionada apropriadamente: apenas User Stories pequenas e com um bom nível de detalhes podem ser colocadas em desenvolvimento. Quanto mais para baixo no Product Backlog a User Story estiver, maior ela será, a princípio.
    User Stories pequenas próximas a seu desenvolvimento têm maior precisão em suas estimativas, permitem um melhor ordenamento do Product Backlog e representam um menor risco ao possibilitarem que mais itens façam parte de um Sprint;
  • testável — deve ser possível verificar e confirmar que a User Story está pronta, ou seja, que foi transformada em parte do produto e está funcionando conforme esperado. A verificação é realizada por meio dos Critérios e Testes de Aceitação. É a “Confirmação”, dos três C’s.
Marcos Garrido, Sócio-fundador e Trainer na K21

Sobre o autor(a)

Co-fundador, Consultor na Nower e Trainer na K21

Marcos Garrido, co-fundador da K21, é Certified Enterprise Coach (CEC), Certified Scrum Trainer (CST) e Certified Team Coach (CTC), fazendo parte do seleto grupo no mundo que possuem as três certificações mais importantes da Scrum Alliance. Com grande atuação internacional, possui larga experiência em Transformação Digital e Gestão de Produtos.

No headers found for the table of contents.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…