Modelos de história de usuário gratuitos para baixar

By Kate Eby | 22 de August de 2018 (updated 14 de August de 2024)

As histórias de usuários são uma parte fundamental do desenvolvimento de software com Agile, e você pode usar modelos para ajudar a orientar o desenvolvimento da funcionalidade do seu produto. Neste artigo, você aprenderá sobre os diferentes tipos de modelos de histórias de usuários e encontrará modelos gratuitos disponíveis para baixar.

 

Modelos gratuitos de história de usuário

Os modelos a seguir podem ser usados para uma variedade de propósitos. Você pode escrever, mapear e gerenciar listas de pendências de histórias de usuários, escrever épicos e muito mais. Muitos desses modelos são semelhantes, por isso escolha com base na preferência pessoal ou de acordo com o processo específico da sua empresa (e, portanto, formato).

Os gerentes de produto e projeto podem usar o modelo de lista de pendências para acompanhar as histórias de usuários. Também podem usar os outros modelos para criar ou mapear histórias de usuários. Outros membros da equipe podem usar a história de usuário ou modelos épicos para criar histórias de usuários.

Modelo de história de usuário

 Modelo de história de usuário ágil

As histórias de usuários ajudam as equipes de produto a se concentrarem nas necessidades dos usuários e gerenciarem seu trabalho no desenvolvimento da funcionalidade. Os gerentes de projeto e produto podem usar este modelo para gerenciar o trabalho gerado pelo usuário. Todos os outros membros da equipe podem usá-lo para escrever histórias de usuários.

 

  Baixe o modelo do Excel

Modelo de lista de pendências para história de usuário

 Gráfico Burndown do Modelo de Backlog do Agile Sprint

Use este modelo para gerenciar a lista de pendências da história de usuário durante as iterações de desenvolvimento do produto.

A lista de pendências é criada durante o planejamento de sprint, quando uma equipe seleciona os principais itens da lista de pendências do produto e adiciona-os aos sprints. A lista de pendências inclui todo o trabalho encaminhado para a fase de desenvolvimento e é uma lista de itens que devem ser concluídos na iteração atual. Essa lista deve ser final (ou seja, as tarefas não devem ser adicionadas ou removidas neste momento).

O modelo tem colunas para itens de lista de pendências, pontos de história, responsabilidade, status e estimativas originais. Nas colunas que representam os dias 1-5, os gerentes de produto ou projeto podem adicionar o número de horas extras de desenvolvimento exigidas a cada dia para uma tarefa. A quantidade total de horas extras de desenvolvimento para cada dia para todas as tarefas no sprint é exibida na linha total. O gráfico de burndown representa este excelente trabalho.

 

  Baixar modelo do Excel

Modelo de mapeamento para história de usuário

 

User Story Map Template

Este é um modelo que você pode concluir ou recriar usando post-it ou fichas. O número de caixas pode variar de acordo com as atividades que ocorrem ao usar um determinado sistema.

Os gerentes de projeto e produto podem usar este modelo para sequenciar a ordem das atividades que um usuário experimenta ao utilizar um sistema. O eixo y representa a crescente sofisticação da funcionalidade que está sendo mapeada; o eixo x contém a ordem sequencial de atividades que os usuários experimentam ao utilizar um sistema. A primeira linha contém a funcionalidade mais básica, e as linhas subsequentes se tornam mais complexas.

 

  Baixar modelo do Excel

 

Modelo para épico

 Modelo épico de usuário ágil

 

Um épico é uma parte de trabalho que aborda algumas funcionalidades a serem desenvolvidas. Eles podem ser usados para gerar histórias de usuários. Utilize este modelo para escrever épicos. Em seguida, trace as histórias de usuários geradas a partir de cada épico. Os gerentes de projeto e produto podem usar este modelo para gerenciar o trabalho gerado a partir dos épicos, e todos os outros membros da equipe podem usá-lo para criar épicos.

Baixe o modelo para épico de usuários Agile - Excel

O que é uma história de usuário?

Uma história de usuário é uma descrição curta (uma ou duas frases), simples e específica de uma interação com um produto em desenvolvimento, geralmente um aplicativo ou site. (Naturalmente, também podem ser usadas para o desenvolvimento de outros projetos.) As histórias de usuários são usadas como uma estrutura para orientar desenvolvedores, designers, gerentes de produto e outros envolvidos na criação de um produto.

As histórias de usuários devem definir quem são os usuários e o que farão com o produto ou serviço. Elas também devem incluir um tipo de usuário, a ação desejada pelo usuário e o valor que o usuário recebe quando a ação estiver completa. No entanto, uma história de usuário não deve descrever como implementar ou desenvolver um recurso ou função.

As histórias de usuários são parte essencial da metodologia de desenvolvimento de software Agile . Em comparação com os métodos tradicionais de gerenciamento de projetos (como Waterfall), o Agile é um processo flexível e iterativo. O Agile funciona em ciclos, chamados iterações, que duram de uma a quatro semanas. Em cada iteração, os desenvolvedores trabalham para criar novas funcionalidades ou melhorar a funcionalidade existente. As histórias de usuários são usadas para orientar na criação de funcionalidades. Os modelos gratuitos e disponíveis para baixar abaixo podem ser usados para criar e trabalhar com histórias de usuários em várias fases do processo Agile. Você pode ler mais sobre o Agile e baixar modelos gratuitos de gerenciamento de projetos do Agile aqui.

O que é Scrum?

Scrum é uma variação do método Agile amplamente utilizado. Existem algumas diferenças entre as práticas dos dois métodos: Scrum refere-se a uma reunião de equipe diária e breve para discutir o progresso e os planos. No Scrum, os ciclos são chamados de sprints em vez de iterações, e os critérios de aceitação são referidos como DOD (Definição de Concluído). No entanto, Scrum e Agile compartilham princípios importantes.

Qual é a estrutura de uma história de usuário?

Não há um formato específico para histórias de usuários do Agile, existindo diversas variações (embora elas variem apenas ligeiramente na terminologia). A forma básica de uma história de usuário pega a perspectiva de um usuário específico do produto e descreve o que ele quer fazer com o produto e que valor ele vai obter com o desempenho dessa função: como <um tipo de usuário>, quero <realizar uma tarefa> para que eu consiga <alcançar um objetivo>.

Estes são alguns exemplos de histórias de usuário para software de rastreamento de despesas de negócios:

  • Como pessoa de entrada de dados, quero carregar planilhas, para que eu não tenha que copiar e colar dados;
  • Como representante de vendas itinerante, quero importar imagens de recibos, para não ter que carregá-los por aí;
  • Como gerente financeiro, quero poder fazer alterações nos modelos de relatórios de despesas de ações, para não precisar manipular os relatórios todos os meses.

Embora seja um formato simples, ele é bastante flexível e permite opções quase ilimitadas.

Como as histórias de usuários são criadas?

As histórias de usuários são frequentemente retiradas de épicos, que muitas vezes seguem um formato semelhante ao das histórias de usuários. No entanto, os épicos são mais complexos e cobrem múltiplas funções. (Eles também podem ser declarados como frases curtas.) Épicos são muito amplos para serem concluídos em uma iteração Agile, então eles precisam ser fragmentados. A ideia não é eliminar nada do épico, mas criar histórias de usuários que sejam granulares o suficiente para serem concluídas em uma única iteração. Exemplos épicos para um aplicativo de calendário podem incluir o seguinte:

  • Como usuário, quero gerenciar todos os meus compromissos pelo telefone;
  • Como usuário, quero ver meu calendário familiar e profissional juntos;
  • Como usuário, quero ter funcionalidade completa de lembrete sem abrir o aplicativo.

Inicialmente, pode ser difícil diferenciar entre uma história épica e uma história de usuário, mas torna-se mais fácil com a experiência.

Épicos e histórias de usuários devem ser baseados nas necessidades dos usuários, em vez de especulação —  entrevistas com usuários ou potenciais usuários garantem que as histórias serão baseadas na realidade.

Muitas organizações também usam personas ao criar histórias de usuários. Uma persona é uma pequena biografia de um usuário fictício que ajuda designers e desenvolvedores a se concentrarem em um tipo de usuário específico em vez de um usuário geral e imaginário.

Algumas organizações dividem histórias de usuários em histórias infantis (também chamadas de sub-histórias) que se encaixam no trabalho necessário em uma única iteração. No entanto, alguns acreditam que se uma história de usuário pode ser dividida ou não se encaixa em uma iteração, ela é um épico.

Quem escreve histórias de usuários?

Qualquer pessoa em um projeto pode escrever histórias de usuários durante o projeto. Geralmente, uma sessão de escrita de histórias acontece antes da primeira iteração, o que dá à equipe de produtos uma lista de pendências de histórias para resolver. Leia mais sobre o processo de escrita de histórias de usuários aqui.

Existem algumas estruturas que ajudam a escrever histórias de usuários relevantes. Uma das estruturas mais conhecidas é um mnemônico chamado INVEST, criado pelo consultor e desenvolvedor Bill Wake:

  • Independente: deve ser independente (ou seja, não depende de outra história de usuário);
  • Negociável: deve haver espaço para discussão;
  • Valiosa: a história deve fornecer valor às partes interessadas;
  • Estimável: a quantidade de esforço para implementar a funcionalidade da história pode ser estimada;
  • Pequena: deve poder ser concluída em um único sprint;
  • Testável: a história deve incluir detalhes suficientes para permitir a criação de testes que verifiquem a funcionalidade abordada na narrativa.

Quais são alguns benefícios das histórias de usuários?

As histórias de usuários se tornaram populares no Agile e em outras metodologias porque fornecem valor e ajudam as equipes de desenvolvimento de produto a trabalhar em direção ao objetivo de criar funcionalidades que atendam às necessidades do usuário. Aqui estão alguns dos benefícios das histórias de usuários:

  • É uma maneira simples de ver quais novos recursos e capacidades são necessários;
  • Elas esclarecem a funcionalidade necessária para resolver problemas do cliente;
  • Elas são fáceis de entender e lembrar;
  • Elas se concentram no valor de negócio e nas necessidades dos clientes;
  • Elas facilitam a priorização;
  • Elas se concentram no modo como os clientes potenciais usarão o produto;
  • Elas podem economizar tempo, pois há menos erros iniciais;
  • Elas podem ser usadas para rastrear a história do produto, rastreando quais componentes foram adicionados em cada iteração;
  • Elas mudam o foco de escrever requisitos para falar sobre eles;
  • Elas podem ter diferentes níveis de detalhes;
  • Com a divisão do trabalho em partes, elas fornecem flexibilidade na implementação;
  • As especificações técnicas são deixadas para os desenvolvedores;
  • Elas incentivam a colaboração e soluções criativas;
  • Elas melhoram o retorno sobre o investimento e a motivação da equipe.

Quais são alguns desafios das histórias de usuários?

Embora as histórias de usuários sejam úteis, como qualquer ferramenta de negócios ou processo, elas não são perfeitas. Veja alguns dos desafios associados:

  • Elas não abordam jornadas do usuário, design visual ou requisitos técnicos;
  • A oração final das histórias de usuários é muitas vezes negligenciada pelos escritores, embora seja a parte mais importante do processo;
  • Se os escritores não tiverem os dados certos ou não examinarem os dados que têm para retirar as necessidades dos usuários, as histórias de usuários serão fracas;
  • Não entender totalmente os usuários resultará em histórias que não abordam suas reais necessidades;
  • Se as equipes de produto não tiverem o conhecimento adequado, as histórias de usuários não serão eficazes para atender às necessidades dos usuários.

Como as histórias de usuários são implementadas?

As histórias de usuários são um ponto de partida para uma discussão em equipe. Essa discussão deve gerar mais detalhes e algumas ideias específicas sobre como implementar a função descrita para que ela seja valiosa para o usuário. Se você criou personas, você pode usá-las durante essas discussões para manter o foco centrado no usuário.

Durante a discussão, as histórias de usuários podem ser exibidas em uma tela de produto, juntamente com personas, épicos e outros itens relacionados, em uma ferramenta como StoriesOnBoard ou FeatureMap. Algumas equipes também criarão maquetes de baixa resolução para que possam percorrer pela funcionalidade que fornecerá uma solução para o problema abordado na história de usuário.

Quando as histórias de usuários são criadas e discutidas, elas precisam ser mapeadas.O mapeamento é um processo de definição de uma grade das histórias de usuários em grupos lógicos relacionados a um recurso ou uma função ou tarefas que os usuários completam. Cada grupo pode ser chamado de tema. Existem muitas maneiras de mapear histórias de usuários: você pode escrevê-las em notas autoadesivas e colocá-las em uma parede ou ter uma caixa cheia de fichas e espalhá-las em uma mesa. Leia mais sobre o mapeamento de histórias de usuários aqui.

Como mencionado anteriormente, as histórias de usuários são coletadas em uma lista de pendências. A lista de pendências é uma lista priorizada da funcionalidade que será criada para o produto. O proprietário do produto é responsável por garantir que haja histórias suficientes de usuários na lista de pendências para cada iteração. Embora algumas organizações usem outros itens na lista de pendências, as histórias de usuários são o item mais popular.

No gerenciamento de projetos Waterfall, um documento de requisitos descreve quais características e funções serão incluídas no produto final. Embora as histórias dos usuários não sejam requisitos reais, no gerenciamento de projetos Agile, a lista de pendências serve a um propósito semelhante ao do documento de requisitos.

Devido à sua estrutura, uma lista de pendências no Agile é muito mais fluido do que o de um documento de exigências Waterfall. As histórias na lista de pendências devem ganhar identificadores exclusivos para facilitar a rastreabilidade da origem da história (por exemplo, um relatório de bugs, entrevistas de usuários, um ticket de suporte ou sugestão de um desenvolvedor) por meio de seu desenvolvimento, testes e lançamento. Ferramentas comuns para rastrear histórias no lançamento incluem JIRA, GitHub, FogBugz ou até uma planilha do Excel.

Depois que uma equipe concorda com as histórias iniciais, eles devem se reunir para complementar o restante das informações necessárias para o desenvolvimento, testes e outras etapas do processo. Eles também devem priorizar qual funcionalidade descrita nas histórias de usuários será desenvolvida primeiro. Devido à estrutura do Agile, a priorização é fluida e mudará em resposta às novas necessidades do usuário, novas histórias de usuários e novas pressões competitivas.

Como saber quando uma história de usuário está pronta?

Para toda história, você precisa de uma maneira de verificar se a funcionalidade desejada foi implementada com sucesso. Há algumas frases usadas para descrever isso, ou seja, critérios de aceitação e condições de satisfação. Alguns especialistas afirmam que esses dois termos são sinônimos; outros acreditam que as condições de satisfação são mais importantes do que os critérios de aceitação, e que os detalhes nos critérios de aceitação são utilizados para verificar se as condições de satisfação são atendidas.

Quem usa as histórias de usuários?

Uma equipe inteira do Agile pode usar histórias de usuários para seu trabalho em um projeto, mas veja uma lista dos principais membros da equipe:

  • Proprietários de produtos: garante a entrega de um produto que atenda às necessidades do usuário;
  • Desenvolvedores: orientam o trabalho da equipe;
  • Testadores: verificam se o produto funciona como esperado;
  • Escritores técnicos: garantem que os materiais de suporte abrangem casos de uso importantes.

Com exceção dos desenvolvedores, cada uma dessas pessoas pode atuar como um representante do cliente, colocando-se no papel de um cliente ou usuário.

Melhore a escrita de histórias de usuários para desenvolvimento de software com o Smartsheet

Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.

 

Descubra por que mais de 90% das empresas da Fortune 100 confiam no Smartsheet para realizarem seu trabalho.

Experimente o Smartsheet gratuitamente Get a Free Smartsheet Demo