Guia Scrum | 19. User Stories – o que são?
Publicados: 2022-05-20A 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:
- Introdução
- História do usuário. De quem é a história?
- Como usar histórias de usuário?
- Critérios de Aceitação
- 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.
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:
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.
Guia do Scrum:
- Glossário de termos básicos, funções e noções
- O que é Scrum?
- Valores do Scrum
- Como implementar o Scrum na sua empresa?
- Time Scrum - o que é e como funciona?
- Quem é um Product Owner?
- Os erros mais comuns do Product Owner
- Quem é o Scrum Master?
- Características de um bom Scrum Master
- Os erros mais comuns do Scrum Master
- Quais estatísticas e métricas o Scrum Master deve acompanhar?
- Cooperação entre Product Owner e Scrum Master
- Equipe de Desenvolvimento em Scrum
- Os erros mais comuns dos desenvolvedores
- Artefatos do Scrum
- Escalando Scrum
- Backlog da Sprint
- O que é o Backlog do Produto?
- O que são histórias de usuários?
- Criando a melhor história de usuário com INVEST
- Os erros mais comuns da história do usuário
- Critérios de aceitação da história do usuário
- Estimativa e pontos de história no Scrum
- Poker de Planejamento
- Jogo de estimativa de equipe
- Definindo Incremento
- Eventos Scrum
- O que é Sprint no Scrum?
- Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
- O que é um gráfico Burndown?
- Como criar e interpretar um gráfico de burndown?
- Vantagens e desvantagens do gráfico de burndown
- Quadros Kanban em Scrum e Scrumban
- Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
- Reunião diária
- Planejamento de Sprint
- Revisão da Sprint
- O que é uma Sprint Retrospective?
- Erros comuns durante uma Sprint Retrospective
- Nutrição do Backlog do Produto