Guia Scrum | 19. User Stories – o que são?

Publicados: 2022-05-20

A História do Usuário é uma breve descrição de uma nova funcionalidade do Produto ou seu aprimoramento. Ele não contém uma solução técnica, mas aborda questões relativas à funcionalidade: Quem é o usuário? O que o Produto faz? E qual é o seu propósito? A História do Usuário descreve o produto em linguagem cotidiana ou de negócios, embora também aponte para as tarefas do Time Scrum que visam melhorar o desempenho do Time.

O que são histórias de usuários? - índice:

  1. Introdução
  2. História do usuário. De quem é a história?
  3. Como usar histórias de usuário?
  4. Critérios de Aceitação
  5. Resumo

Introdução

User Story é a forma mais comum de formular as tarefas executadas pelo Time Scrum. Uma única História de Usuário define uma pequena funcionalidade do Produto. Ele descreve a menor meta de produto significativa e parcial. Por esse motivo, as User Stories são muito breves.

As Histórias de Usuário são criadas durante todo o tempo de trabalho no Produto. Eles são criados continuamente, desde o momento em que a decisão de iniciar o trabalho é tomada, até a realização do Objetivo do Produto.

Criar histórias de usuário é tarefa do Product Owner. A partir de uma conversa com um Cliente, formula respostas a perguntas que permitem criar User Story e as insere no Product Backlog. No entanto, as histórias de usuário refletem não apenas as necessidades do cliente.

user stories

História do usuário. De quem é a história?

O Time Scrum cria uma história de usuário para definir as necessidades do usuário, e é por isso que ela é colocada em linguagem de negócios. Em outras palavras, indica os benefícios que sua implementação trará ao usuário do produto. No entanto, no Product Backlog, também pode haver User Stories que descrevam as necessidades do Time de Desenvolvimento, por exemplo, melhorando o fluxo de trabalho entre Desenvolvedores, ou descrevendo as necessidades do Product Owner, por exemplo, organizando o Product Backlog. Nesses casos, o usuário na história do usuário é o desenvolvedor e o proprietário do produto.

Você pode descrever uma história de usuário respondendo às perguntas 3W :

  • Quem?
  • Está fazendo o quê?
  • Por quê?

A história do usuário é então contida em uma fórmula:

Como um [tipo de usuário], eu quero [fazer o quê?] Porque [por quê? Por quê?].

Exemplos de histórias de usuário sobre a funcionalidade de uma loja online escritas neste formulário são ilustrados na tabela abaixo:

What are User Stories? - table

Essa fórmula permite não apenas formular uma história de usuário, mas também traduzir com relativa facilidade a linguagem técnica em negócios e vice-versa . Como resultado, tanto os Desenvolvedores quanto os Stakeholders veem claramente a Meta e os estágios de seu progresso. Também abordaremos a criação de boas histórias de usuário usando o método INVEST em um artigo separado na série Guia do Scrum.

Como usar histórias de usuário?

Criar uma história de usuário esquemática é apenas o começo. São sinais e pontos de partida para discussões sobre problemas e suas soluções. A discussão de histórias de usuários ocorre durante o planejamento do Sprint para definir quais problemas técnicos a equipe de desenvolvimento adicionará ao Sprint Backlog.

Normalmente, no espaço físico, as User Stories são escritas em pequenos cartões coloridos fixados no local de trabalho. No entanto, no espaço digital, as lousas digitais, compartilhadas pelo Time Scrum, funcionam melhor.

Salvar histórias de usuário dessa maneira tem várias vantagens porque:

  • Enfatiza a autonomia de cada User Story – cada uma tem uma estrutura separada e pode ser executada independentemente das outras
  • Enfatiza a dinâmica das Estórias de Usuário – a ordem de sua realização é renegociada pelo Time Scrum e a ordem atual de realização é visível no quadro graças ao arranjo físico de cartões com Estórias de Usuário
  • Serve como um lembrete – graças à representação visual das User Stories, o Time Scrum tem um poste de sinalização à vista para lembrá-los do objetivo ao criar soluções detalhadas.

A equipe de desenvolvimento estima o esforço necessário para concluir uma história de usuário com dias, horas de trabalho ou pontos de história.

Critérios de Aceitação

Uma história de usuário deve ter certos critérios de aceitação no momento em que é aceita para desenvolvimento pela equipe de desenvolvimento. Os critérios de aceitação determinam em que ponto o trabalho em uma história de usuário pode ser considerado concluído.

Dessa forma, tanto o cliente quanto os desenvolvedores sabem como seu trabalho se traduzirá em valor comercial. Normalmente, uma história de usuário é considerada concluída quando o usuário especificado nela pode executar a ação descrita. Usando o exemplo acima, dê uma olhada nesta história de usuário com o conteúdo:

Um cliente pode comprar uma varinha mágica com um único clique.

Ele é concluído quando um botão "Comprar agora" aparece na página da loja online, que usa as informações padrão de pagamento e envio para o usuário conectado.

Resumo

Uma história de usuário é uma descrição concisa de uma nova funcionalidade ou aprimoramento do produto. Ele serve como o menor Objetivo expresso em linguagem de negócios, ou seja, na perspectiva do valor do negócio e do usuário. Ajuda a definir claramente a tarefa a ser executada, bem como os critérios para sua conclusão.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 19. User Stories - what they are? caroline becker avatar 1background

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Guia do Scrum:

  1. Glossário de termos básicos, funções e noções
  2. O que é Scrum?
  3. Valores do Scrum
  4. Como implementar o Scrum na sua empresa?
  5. Time Scrum - o que é e como funciona?
  6. Quem é um Product Owner?
  7. Os erros mais comuns do Product Owner
  8. Quem é o Scrum Master?
  9. Características de um bom Scrum Master
  10. Os erros mais comuns do Scrum Master
  11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
  12. Cooperação entre Product Owner e Scrum Master
  13. Equipe de Desenvolvimento em Scrum
  14. Os erros mais comuns dos desenvolvedores
  15. Artefatos do Scrum
  16. Escalando Scrum
  17. Backlog da Sprint
  18. O que é o Backlog do Produto?
  19. O que são histórias de usuários?
  20. Criando a melhor história de usuário com INVEST
  21. Os erros mais comuns da história do usuário
  22. Critérios de aceitação da história do usuário
  23. Estimativa e pontos de história no Scrum
  24. Poker de Planejamento
  25. Jogo de estimativa de equipe
  26. Definindo Incremento
  27. Eventos Scrum
  28. O que é Sprint no Scrum?
  29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
  30. O que é um gráfico Burndown?
  31. Como criar e interpretar um gráfico de burndown?
  32. Vantagens e desvantagens do gráfico de burndown
  33. Quadros Kanban em Scrum e Scrumban
  34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
  35. Reunião diária
  36. Planejamento de Sprint
  37. Revisão da Sprint
  38. O que é uma Sprint Retrospective?
  39. Erros comuns durante uma Sprint Retrospective
  40. Nutrição do Backlog do Produto