O que são as Histórias de Usuário no PMBOK 8?
As Histórias de Usuário — chamadas de User Stories no PMBOK Guide, Eighth Edition — são descrições breves e informais de funcionalidades do produto escritas da perspectiva do usuário final, expressando o que o usuário precisa e por que. No PMBOK 8, aparecem como saídas das abordagens adaptativas, representando a unidade básica de valor no Product Backlog.
O PMBOK Guide, Eighth Edition descreve as Histórias de Usuário no contexto adaptativo:
Cadastre-se para navegar sem anúncios e participar do Project Together →
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability. User stories typically follow the format: As a [type of user], I want [some goal] so that [some reason]. User stories are used in adaptive approaches to capture requirements in a lightweight format.”
— Mike Cohn, User Stories Applied: For Agile Software Development (Addison-Wesley, 2004) — referência clássica adotada pelo Scrum Alliance
O PMBOK Guide, Eighth Edition define Histórias de Usuário da seguinte forma:
“A user story is a brief, textual description of an outcome from a specific stakeholder perspective, and is a promise for a conversation to clarify details. User stories clarify details or required functionality in a conversational manner, which is a clear and concise representation of a requirement written from the end user perspective. A typical user story should describe the user or stakeholder role, who benefits from the feature (role), what the stakeholder needs to accomplish (goal), and the benefit to the stakeholder (motivation).”
— PMBOK Guide, Eighth Edition, Section 4
As Histórias de Usuário não são especificações técnicas — são conversas. Elas capturam a intenção e o valor esperado pelo usuário, deixando os detalhes de implementação para a colaboração entre o time de desenvolvimento e o Product Owner durante o refinamento e o desenvolvimento.
O formato padrão de uma História de Usuário
O formato canônico das Histórias de Usuário é:
Como [tipo de usuario ou papel], quero [ação ou funcionalidade], para [beneficio ou objetivo de negocio].
| Componente | Descrição | Exemplo |
|---|---|---|
| Como [usuario] | Quem se beneficia — persona ou papel específico, não um grupo genérico | “Como gerente de projeto”, “Como cliente externo”, “Como analista financeiro” |
| Quero [ação] | O que o usuário quer fazer — o que o sistema deve permitir ou realizar | “quero visualizar o cronograma do projeto em formato Gantt”, “quero exportar o relatório em PDF” |
| Para [beneficio] | Por que o usuário precisa disso — o valor de negócio ou objetivo a ser alcançado | “para apresentar o progresso nas reuniões de status”, “para enviar ao cliente sem acesso ao sistema” |
Critérios de Aceite — O complemento essencial da História
Os Critérios de Aceite definem as condições específicas que devem ser atendidas para que a História de Usuário seja considerada concluída:
| Aspecto | Descrição |
|---|---|
| O que são | Condições específicas e verificáveis que a implementação deve satisfazer — o “contrato” entre o time e o Product Owner |
| Formato típico | Lista de cenários “Dado/Quando/Entao” (Given/When/Then) ou lista de condições booleanas |
| Responsável por definir | Product Owner — com colaboração do time de desenvolvimento durante o refinamento |
| Quando são verificados | Na Sprint Review — o Product Owner verifica se os critérios foram atendidos antes de aceitar a história |
Exemplo completo:
História: “Como gerente de projeto, quero visualizar o cronograma em formato Gantt, para apresentar o progresso nas reuniões de status.”
Critérios de aceite: (1) O Gantt exibe todas as atividades do projeto com datas de início e fim. (2) O caminho crítico é destacado em vermelho. (3) O progresso de cada atividade é exibido em percentual. (4) O Gantt pode ser exportado em PDF ou PNG.
Critérios INVEST para Histórias de Usuário de qualidade
| Letra | Critério | O que significa |
|---|---|---|
| I | Independent (Independente) | A história pode ser desenvolvida e entregue sem depender de outra história não concluída |
| N | Negotiable (Negociável) | Os detalhes de implementação são discutidos e acordados — não são fixos na escrita da história |
| V | Valuable (Valiosa) | Entrega valor real ao usuário ou ao negócio — não é apenas trabalho técnico sem valor visível |
| E | Estimable (Estimável) | O time consegue estimar o esforço — está suficientemente detalhada sem ser uma especificação completa |
| S | Small (Pequena) | Pode ser concluída em um sprint — histórias grandes (épicos) devem ser divididas |
| T | Testable (Testável) | Tem critérios de aceite claros que permitem verificar objetivamente se foi concluída |
Histórias de Usuário em abordagens preditivas, adaptativas e híbridas
Abordagem adaptativa (ágil)
As Histórias de Usuário são o artefato central de definição de requisitos em projetos ágeis. Constituem o Product Backlog com épicos, features e histórias. O refinamento do backlog detalha as histórias prioritárias antes do Sprint Planning. A Sprint Review é o momento em que o Product Owner verifica se os critérios de aceite foram atendidos.
Abordagem preditiva (cascata)
Em projetos preditivos, as Histórias de Usuário podem ser usadas como técnica de elicitação de requisitos — capturando necessidades dos usuários em formato narrativo antes de formaliza-las na Documentação dos Requisitos. Não são o artefato principal de escopo em abordagens preditivas, mas podem coexistir com especificações formais.
Abordagem híbrida
Em projetos híbridos, as Histórias de Usuário definem as funcionalidades a serem desenvolvidas nas fases ágeis. Os marcos, entregáveis formais e documentação de arquitetura das fases preditivas coexistem com o backlog de histórias. O gerente do projeto mapeia as histórias concluídas para os entregáveis formais da EAP.
5 erros comuns nas Histórias de Usuário
- Escrever histórias técnicas em vez de histórias de usuário: “Como desenvolvedor, quero refatorar o módulo de autenticação para usar JWT” não é uma História de Usuário — é uma task técnica. Histórias devem ser escritas da perspectiva do usuário de negócio e expressar valor. A dívida técnica e o trabalho de infraestrutura podem entrar no backlog como itens técnicos, mas não devem ser disfarcos de Histórias de Usuário.
- Omitir o “para” — o benefício de negócio: “Como gerente, quero exportar o relatório” é uma história incompleta. Sem o benefício (“para enviar ao cliente sem acesso ao sistema”), o time não entende o contexto que guia as decisões de implementação. O “para” é o que transforma um pedido em uma necessidade compreendida.
- Histórias sem critérios de aceite: uma história sem critérios de aceite é uma história que nunca vai ser aceita na primeira tentativa. Os critérios de aceite devem ser escritos antes do desenvolvimento começar — são o contrato entre o Product Owner e o time. Sem eles, “pronto” significa coisas diferentes para o time e para o PO.
- Histórias grandes demais (épicos não divididos): uma história que leva mais de um sprint para ser concluída é um épico, não uma história. Épicos devem ser divididos em histórias menores antes de entrar no Sprint Planning. Histórias grandes demais geram sprints que terminam com histórias parcialmente concluídas — sem valor entregável ao usuário.
- Product Owner escrevendo histórias sem input dos usuários reais: histórias escritas exclusivamente pela equipe de negócio ou TI sem validação com usuários reais capturam pressupostos, não necessidades. Técnicas como entrevistas com usuários, observação de campo e testes de usabilidade devem alimentar a escrita das histórias para garantir que capturem o que os usuários realmente precisam.
Checklist das Histórias de Usuário
| Item | Verificação |
|---|---|
| História escrita no formato “Como / Quero / Para” com todos os três componentes? | [ ] |
| História atende ao critério INVEST (Independente, Negociável, Valiosa, Estimável, Pequena, Testável)? | [ ] |
| Critérios de aceite específicos e verificáveis definidos? | [ ] |
| História estimada em story points pelo time de desenvolvimento? | [ ] |
| História baseada em necessidade real de usuário (validada com usuários, não apenas pressupostos)? | [ ] |
| Histórias grandes divididas em histórias menores antes do Sprint Planning? | [ ] |
| História priorizada no backlog conforme valor de negócio? | [ ] |
Template e Exemplo de Histórias de Usuário — PMBOK 8
Para facilitar a escrita e gerenciamento das Histórias de Usuário em seus projetos, disponibilizamos dois recursos gratuitos para download:
Template oficial PMBOK 8
Kit de Histórias de Usuário — template de história individual (Como/Quero/Para + critérios de aceite + story points), guia de critérios INVEST para avaliação de qualidade, exemplos de divisão de épico em histórias, template de mapa de histórias (Story Map) e planilha de Product Backlog com hierarquia épico-feature-história.
Exemplo real — Projeto de Desenvolvimento de Software (ProjectAdm)
Histórias de Usuário do projeto ProjectAdm — 187 histórias em 3 épicos e 12 features. Inclui exemplos de histórias bem escritas e mal escritas com análise INVEST, 42 histórias com critérios de aceite no formato Dado/Quando/Entao, 3 épicos divididos em histórias e histórico de refinamento do backlog ao longo de 12 sprints.
Quer se aprofundar no PMBOK 8?
O PMBOK Guide — Eighth Edition é a referência essencial para entender as Histórias de Usuário e as abordagens adaptativas de gerenciamento de projetos. Adquira agora:
Adquirir o PMBOK Guide — Eighth Edition na Amazon →
Teste seus conhecimentos sobre Histórias de Usuário
Você sabe o que diferencia uma boa História de Usuário de uma especificação técnica no PMBOK 8? E o que são os critérios INVEST e como avaliar a qualidade de uma história? Coloque seu conhecimento a prova:
Cadastre-se para navegar sem anúncios e participar do Project Together →
Iniciar Etapa 1 do Quiz Project Together →
QUIZ
Quer testar o que aprendeu neste artigo?
Uma pergunta de múltipla escolha + uma reflexão prática. Ganhe pontos no Project Together!
Como Associado da Amazon, a escritoriodeprojetos.com.br recebe por compras qualificadas. Os links para a Amazon nesta página são links de afiliado; o preço que você paga não muda.
