O que são as Historias de Usuario no PMBOK 8?
As Historias de Usuario — chamadas de User Stories no PMBOK Guide, Eighth Edition — são descricoes breves e informais de funcionalidades do produto escritas da perspectiva do usuario final, expressando o que o usuario precisa e por que. No PMBOK 8, aparecem como saidas das abordagens adaptativas, representando a unidade basica de valor no Product Backlog.
O PMBOK Guide, Eighth Edition descreve as Historias de Usuario 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 Historias de Usuario não são especificacoes tecnicas — são conversas. Elas capturam a intencao e o valor esperado pelo usuario, deixando os detalhes de implementacao para a colaboracao entre o time de desenvolvimento e o Product Owner durante o refinamento e o desenvolvimento.
O formato padrao de uma Historia de Usuario
O formato canonico das Historias de Usuario e:
Como [tipo de usuario ou papel], quero [ação ou funcionalidade], para [beneficio ou objetivo de negocio].
| Componente | Descricao | Exemplo |
|---|---|---|
| Como [usuario] | Quem se beneficia — persona ou papel especifico, não um grupo generico | “Como gerente de projeto”, “Como cliente externo”, “Como analista financeiro” |
| Quero [ação] | O que o usuario quer fazer — o que o sistema deve permitir ou realizar | “quero visualizar o cronograma do projeto em formato Gantt”, “quero exportar o relatorio em PDF” |
| Para [beneficio] | Por que o usuario precisa disso — o valor de negocio ou objetivo a ser alcancado | “para apresentar o progresso nas reunioes de status”, “para enviar ao cliente sem acesso ao sistema” |
Criterios de Aceite — O complemento essencial da Historia
Os Criterios de Aceite definem as condicoes especificas que devem ser atendidas para que a Historia de Usuario seja considerada concluida:
| Aspecto | Descricao |
|---|---|
| O que são | Condicoes especificas e verificaveis que a implementacao deve satisfazer — o “contrato” entre o time e o Product Owner |
| Formato tipico | Lista de cenarios “Dado/Quando/Entao” (Given/When/Then) ou lista de condicoes booleanas |
| Responsavel por definir | Product Owner — com colaboracao do time de desenvolvimento durante o refinamento |
| Quando são verificados | Na Sprint Review — o Product Owner verifica se os criterios foram atendidos antes de aceitar a historia |
Exemplo completo:
Historia: “Como gerente de projeto, quero visualizar o cronograma em formato Gantt, para apresentar o progresso nas reunioes de status.”
Criterios de aceite: (1) O Gantt exibe todas as atividades do projeto com datas de inicio e fim. (2) O caminho critico e destacado em vermelho. (3) O progresso de cada atividade e exibido em percentual. (4) O Gantt pode ser exportado em PDF ou PNG.
Criterios INVEST para Historias de Usuario de qualidade
| Letra | Criterio | O que significa |
|---|---|---|
| I | Independent (Independente) | A historia pode ser desenvolvida e entregue sem depender de outra historia não concluida |
| N | Negotiable (Negociavel) | Os detalhes de implementacao são discutidos e acordados — não são fixos na escrita da historia |
| V | Valuable (Valiosa) | Entrega valor real ao usuario ou ao negocio — não e apenas trabalho tecnico sem valor visivel |
| E | Estimable (Estimavel) | O time consegue estimar o esforco — esta suficientemente detalhada sem ser uma especificacao completa |
| S | Small (Pequena) | Pode ser concluida em um sprint — historias grandes (epicos) devem ser divididas |
| T | Testable (Testavel) | Tem criterios de aceite claros que permitem verificar objetivamente se foi concluida |
Historias de Usuario em abordagens preditivas, adaptativas e hibridas
Abordagem adaptativa (agil)
As Historias de Usuario são o artefato central de definicao de requisitos em projetos ageis. Constituem o Product Backlog com epicos, features e historias. O refinamento do backlog detalha as historias prioritarias antes do Sprint Planning. A Sprint Review e o momento em que o Product Owner verifica se os criterios de aceite foram atendidos.
Abordagem preditiva (cascata)
Em projetos preditivos, as Historias de Usuario podem ser usadas como tecnica de elicitacao de requisitos — capturando necessidades dos usuarios em formato narrativo antes de formaliza-las na Documentacao dos Requisitos. Não são o artefato principal de escopo em abordagens preditivas, mas podem coexistir com especificacoes formais.
Abordagem hibrida
Em projetos hibridos, as Historias de Usuario definem as funcionalidades a serem desenvolvidas nas fases ageis. Os marcos, entregaveis formais e documentacao de arquitetura das fases preditivas coexistem com o backlog de historias. O gerente do projeto mapeia as historias concluidas para os entregaveis formais da EAP.
5 erros comuns nas Historias de Usuario
- Escrever historias tecnicas em vez de historias de usuario: “Como desenvolvedor, quero refatorar o modulo de autenticacao para usar JWT” não e uma Historia de Usuario — e uma task tecnica. Historias devem ser escritas da perspectiva do usuario de negocio e expressar valor. A divida tecnica e o trabalho de infraestrutura podem entrar no backlog como itens tecnicos, mas não devem ser disfarcos de Historias de Usuario.
- Omitir o “para” — o beneficio de negocio: “Como gerente, quero exportar o relatorio” e uma historia incompleta. Sem o beneficio (“para enviar ao cliente sem acesso ao sistema”), o time não entende o contexto que guia as decisoes de implementacao. O “para” e o que transforma um pedido em uma necessidade compreendida.
- Historias sem criterios de aceite: uma historia sem criterios de aceite e uma historia que nunca vai ser aceita na primeira tentativa. Os criterios de aceite devem ser escritos antes do desenvolvimento comecar — são o contrato entre o Product Owner e o time. Sem eles, “pronto” significa coisas diferentes para o time e para o PO.
- Historias grandes demais (epicos não divididos): uma historia que leva mais de um sprint para ser concluida e um epico, não uma historia. Epicos devem ser divididos em historias menores antes de entrar no Sprint Planning. Historias grandes demais geram sprints que terminam com historias parcialmente concluidas — sem valor entregavel ao usuario.
- Product Owner escrevendo historias sem input dos usuarios reais: historias escritas exclusivamente pela equipe de negocio ou TI sem validacao com usuarios reais capturam pressupostos, não necessidades. Tecnicas como entrevistas com usuarios, observacao de campo e testes de usabilidade devem alimentar a escrita das historias para garantir que capturem o que os usuarios realmente precisam.
Checklist das Historias de Usuario
| Item | Verificacao |
|---|---|
| Historia escrita no formato “Como / Quero / Para” com todos os tres componentes? | [ ] |
| Historia atende ao criterio INVEST (Independente, Negociavel, Valiosa, Estimavel, Pequena, Testavel)? | [ ] |
| Criterios de aceite especificos e verificaveis definidos? | [ ] |
| Historia estimada em story points pelo time de desenvolvimento? | [ ] |
| Historia baseada em necessidade real de usuario (validada com usuarios, não apenas pressupostos)? | [ ] |
| Historias grandes divididas em historias menores antes do Sprint Planning? | [ ] |
| Historia priorizada no backlog conforme valor de negocio? | [ ] |
Template e Exemplo de Historias de Usuario — PMBOK 8
Para facilitar a escrita e gerenciamento das Historias de Usuario em seus projetos, disponibilizamos dois recursos gratuitos para download:
Template oficial PMBOK 8
Kit de Historias de Usuario — template de historia individual (Como/Quero/Para + criterios de aceite + story points), guia de criterios INVEST para avaliacao de qualidade, exemplos de divisao de epico em historias, template de mapa de historias (Story Map) e planilha de Product Backlog com hierarquia epico-feature-historia.
Exemplo real — Projeto de Desenvolvimento de Software (ProjectAdm)
Historias de Usuario do projeto ProjectAdm — 187 historias em 3 epicos e 12 features. Inclui exemplos de historias bem escritas e mal escritas com analise INVEST, 42 historias com criterios de aceite no formato Dado/Quando/Entao, 3 epicos divididos em historias e historico de refinamento do backlog ao longo de 12 sprints.
Quer se aprofundar no PMBOK 8?
O PMBOK Guide — Eighth Edition e a referencia essencial para entender as Historias de Usuario e as abordagens adaptativas de gerenciamento de projetos. Adquira agora:
Adquirir o PMBOK Guide — Eighth Edition na Amazon →
Teste seus conhecimentos sobre Historias de Usuario
Você sabe o que diferencia uma boa Historia de Usuario de uma especificacao tecnica no PMBOK 8? E o que são os criterios INVEST e como avaliar a qualidade de uma historia? 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.
