Guia Scrum | 19. Histórias de Usuário – o que são?

A User Story é uma breve descrição de uma nova funcionalidade do Produto ou de sua melhoria. Não contém uma solução técnica, mas aborda questões relacionadas à funcionalidade: Quem é o usuário? O que o Produto faz? E qual é o seu propósito? A User Story descreve o produto em linguagem cotidiana ou de negócios, embora também aponte para as tarefas da Equipe Scrum que visam melhorar o desempenho da Equipe.

O que são User Stories? – índice:

1. Introdução
2. User Story. De quem é a história?
3. Como usar User Stories?
4. Critérios de Aceitação
5. Resumo

Introdução

User Story é a forma mais comum de formular as tarefas realizadas pela Equipe Scrum. Uma única User Story define uma pequena funcionalidade do Produto. Ela descreve o menor objetivo parcial significativo do Produto. Por essa razão, as User Stories são muito breves.

User Stories são criadas durante todo o tempo de trabalho no Produto. Elas são criadas continuamente, desde o momento em que a decisão de começar o trabalho é tomada, até a realização do Objetivo do Produto.

Criar User Stories é uma tarefa do Product Owner. Com base em uma conversa com um Cliente, ele formula respostas a perguntas que permitem criar a User Story e as insere no Product Backlog. No entanto, as User Stories refletem não apenas as necessidades do cliente.

User Story. De quem é a história?

A Equipe Scrum cria uma User Story para definir as necessidades do Usuário, e é por isso que é redigida em linguagem de negócios. Em outras palavras, indica os benefícios que sua implementação trará para o usuário do produto. No entanto, no Product Backlog, também podem existir User Stories que descrevem as necessidades da Equipe de Desenvolvimento, por exemplo, melhorar o fluxo de trabalho entre os Desenvolvedores, ou descrever as necessidades do Product Owner, por exemplo, organizar o Product Backlog. Em tais casos, o Usuário na User Story é o Desenvolvedor e o Product Owner.

Você pode descrever uma User Story respondendo às perguntas 3W:

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

A User Story é então contida em uma fórmula:

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

Exemplos de User Stories sobre a funcionalidade de uma loja online escritas nesta forma estão ilustrados na tabela abaixo:

Essa fórmula permite não apenas formular uma User Story, mas também traduzir relativamente fácil a linguagem técnica em linguagem de negócios e vice-versa. Como resultado, tanto os Desenvolvedores quanto os Stakeholders veem claramente o Objetivo e as etapas de seu progresso. Também abordaremos a criação de boas User Stories usando o método INVEST em um artigo separado na série do Guia Scrum.

Como usar User Stories?

Criar uma User Story esquemática é apenas o começo. Elas são sinais e pontos de partida para discussões sobre problemas e suas soluções. A discussão das User Stories ocorre durante o Planejamento do Sprint para resolver quais questões técnicas 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, quadros brancos digitais, compartilhados pela Equipe Scrum, funcionam melhor.

Salvar User Stories dessa forma tem várias vantagens porque:

• Destaca a autonomia de cada User Story – cada uma tem um quadro separado e pode ser executada independentemente das outras
• Enfatiza a dinâmica das User Stories – a ordem de sua realização é renegociada pela Equipe Scrum e a ordem atual de realização é visível no quadro graças à disposição física dos cartões com User Stories
• Serve como um lembrete – graças à representação visual das User Stories, a Equipe Scrum tem um sinalizador à vista para lembrá-los do objetivo ao criar soluções detalhadas.

A Equipe de Desenvolvimento estima o esforço necessário para completar uma User Story em dias, horas-homem ou Story Points.

Critérios de Aceitação

Uma User Story 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 User Story pode ser considerado concluído.

Dessa forma, tanto o cliente quanto os desenvolvedores sabem como seu trabalho se traduzirá em valor de negócios. Normalmente, uma User Story é considerada concluída quando o usuário especificado nela pode realizar a ação descrita. Usando o exemplo acima, veja esta User Story com o conteúdo:

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

Ela é concluída quando um botão “Comprar Agora” funcional aparece na página da loja online, que utiliza as informações de pagamento e envio padrão para o usuário logado.

Resumo

Uma User Story é uma descrição concisa de uma nova funcionalidade ou melhoria do Produto. Ela serve como o menor Objetivo expresso em linguagem de negócios, ou seja, do ponto de vista do valor de negócios e do usuário. Ajuda a definir claramente a tarefa a ser realizada, 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.