Exemplos de pontos de história: uma escala de referência de 1 a 13
Seis exemplos de backlog para ajudar sua equipe a comparar trabalhos, questionar suposições e escolher suas próprias histórias de referência.
Uma estimativa em pontos de história expressa o tamanho relativo do trabalho para uma equipe, considerando esforço, complexidade e incerteza. Isso torna um item concluído e familiar uma referência útil para discutir o próximo. O guia de estimativa da Atlassian explica essa abordagem relativa.
Por exemplo, uma equipe pode atribuir 2 pontos a uma mudança familiar nas configurações e 5 a um novo fluxo de trabalho de notificações. A pergunta útil é: qual trabalho adicional explica essa diferença?
Os exemplos abaixo pertencem a uma equipe fictícia que está construindo um espaço de trabalho de documentos compartilhados. Eles são pontos de partida para uma conversa, não valores padrão para recursos. Sua equipe pode escolher valores diferentes de forma razoável.
Seis exemplos na escala de uma equipe
Suponha que esta equipe já possua uma biblioteca de componentes, permissões de espaço de trabalho, um serviço de notificações e verificações automatizadas em seus fluxos de trabalho existentes. Cada estimativa inclui implementação, revisão e as verificações necessárias para atender à definição de pronto da equipe.
| Pontos | Item do backlog | Incluído neste exemplo | Por que esta equipe o posiciona aqui |
|---|---|---|---|
| 1 | Explicar um feed de atividades vazio | Texto aprovado e componente de estado vazio existente; nenhum novo comportamento | Uma mudança pequena e familiar com poucos estados afetados |
| 2 | Permitir que administradores do espaço alterem o nome exibido compartilhado | Formulário de configurações existente, API e verificação de permissão de administrador; validação e estados de salvamento/erro | Um caminho familiar com algumas verificações de comportamento; o item de referência da equipe |
| 3 | Filtrar documentos pelo proprietário | Componente de filtro existente e suporte à API; comportamento de reset e resultados vazios | Mais estados interativos na interface que a referência, com um caminho de dados conhecido |
| 5 | Notificar o proprietário do documento quando alguém solicitar acesso | Serviço de entrega existente; verificações de permissão, conteúdo da notificação, tratamento de duplicatas e um link para a solicitação | Várias partes existentes devem funcionar corretamente juntas |
| 8 | Transferir a propriedade do documento dentro de um espaço de trabalho | Nova operação de transferência; alterações de permissão, edições concorrentes e uma entrada de auditoria | Uma transição de estado mais ampla com casos de falha que precisam de acordo cuidadoso |
| 13 | Mover uma pasta e seus documentos para outro espaço de trabalho | Permissões do destino, links, falhas parciais e comportamento de recuperação | Muitas decisões conectadas para esta equipe manter como um único item confortável; discutir divisão |
As suposições sobre a infraestrutura importam. Uma equipe sem serviço de notificações estimaria trabalho adicional no exemplo de 5 pontos. Uma equipe com operação comprovada de transferência de propriedade pode considerar esse item com menor pontuação.
Esses números não são uma fórmula. Contar telas da interface, endpoints ou critérios de aceite não reproduzirá as estimativas de forma confiável.
Como o escopo altera a estimativa
Considere “alterar o nome exibido de um espaço de trabalho”. A tabela assume um administrador editando o rótulo compartilhado exibido nas configurações, com um endpoint de atualização existente e verificação de permissões.
Agora altere as condições de aceite:
| Versão | Escopo | Estimativa ilustrativa |
|---|---|---|
| A | Alterar o rótulo exibido nas configurações do espaço; usar a operação de salvamento existente | 2 |
| B | Também atualizar conteúdo do convite e navegação em cache; manter essas superfícies consistentes se a atualização falhar parcialmente | 5 |
| C | O nome também determina a URL pública do espaço; preservar links antigos e lidar com colisões | Pausar para esclarecer, depois possivelmente 8 ou dividir |
A versão C levanta uma questão de produto antes da questão de dimensionamento: renomear deve alterar a URL? Decidir manter a URL estável pode eliminar grande parte do trabalho adicional.
Se um participante votar 2 enquanto outro votar 8, peça que cada um descreva o comportamento que considerou. Ambos podem estar raciocinando consistentemente sobre versões diferentes. Reescreva as condições de aceite antes de votar novamente.
Escolha histórias de referência que sua equipe lembre
Escolha dois ou três itens concluídos com limites claros. Uma mudança pequena e familiar, um fluxo de trabalho moderado e uma mudança maior, porém compreendida, dão à equipe comparações mais úteis do que um único número abstrato.
Para cada referência, mantenha uma nota curta:
- Qual resultado para o usuário foi entregue?
- Quais sistemas e estados foram alterados?
- Que trabalho de revisão e verificação foi incluído?
- Que suposições tornaram o trabalho simples ou difícil?
Então compare o novo trabalho com a referência mais próxima. “Isso se assemelha à nossa mudança de configurações, mas adiciona dois caminhos de permissão” oferece um ponto concreto para questionamentos.
Se a equipe não tiver histórico compartilhado de entrega, escolha um item bem compreendido como referência provisória. Reavalie-o após a entrega e mantenha as suposições visíveis. Não há necessidade de criar uma escala perfeita antes da equipe aprender em conjunto.
Copie esta nota de estimativa em um item do backlog
Use o seguinte como auxílio para discussão no seu backlog ou nas anotações da equipe:
Resultado para o usuário:
Comportamento incluído:
Explicitamente excluído:
Referência completa mais próxima:
O que torna isso menor ou maior:
Incógnitas que podem alterar o escopo:
Decisão: estimar / dividir / investigar
Estimativa acordada, se estiver pronta:
Próxima clarificação e responsável, se necessário:
Aqui está um exemplo preenchido para o item de notificação de acesso:
Resultado para o usuário: o proprietário do documento é informado quando um membro do espaço solicita acesso e pode abrir a solicitação.
Incluído: uso do serviço de notificações existente, verificação das permissões do destinatário, link para a solicitação pendente e evitação de notificações duplicadas em tentativas de entrega.
Excluído: e-mails de lembrete, digests diários e concessão automática de acesso.
Referência: nossa mudança nas configurações de 2 pontos usa um caminho familiar de salvamento. Este item une os caminhos de solicitação, permissão e entrega, envolvendo mais coordenação e casos de falhas.
Pergunta aberta: o serviço já previne entregas duplicadas? O mantenedor do serviço de notificações confirmará antes de definirmos a estimativa.
No cenário fictício da tabela, essa verificação confirma suporte reutilizável à entrega e a equipe concorda com 5. Sem essa confirmação, a equipe precisa discutir o trabalho adicional antes de usar o mesmo número. A referência explica a comparação; não calcula a resposta.
Para a sequência da reunião, use o guia passo a passo do Planning Poker. Ele cobre votação privada, discussão das diferenças e escolha do resultado para a próxima rodada.
Quando um número ainda não é útil
Retorne para a clarificação quando uma incógnita muda a natureza do trabalho. “Qual texto a notificação deve usar?” é uma incerteza diferente de “O espaço de trabalho de destino permite usuários externos?”
No exemplo de mover pasta, a equipe pode inicialmente concordar com um resultado menor para o usuário: mover um documento entre espaços que o usuário administra. Essa primeira etapa ainda exige permissões claras no destino, regras de acesso preservadas e tratamento seguro de falhas para que uma movimentação interrompida não perca o documento ou o exponha a pessoas erradas. Mover lotes de documentos pode ser um item separado. Reduzir o tamanho do lote limita o trabalho, mas não elimina a necessidade de lidar com falhas.
Após dividir, estime cada item separadamente. Os novos números não precisam somar 13: a equipe mudou o escopo e aprendeu mais sobre o trabalho.
Perguntas frequentes das equipes
Quantas horas tem uma história de 3 pontos?
Não há conversão universal. Os exemplos aqui comparam trabalho dentro de uma equipe fictícia. Se precisar de uma previsão de entrega, use seu próprio histórico de entregas e capacidade atual, e discuta a incerteza separadamente do valor do ponto.
Todo bug é um item de 1 ponto?
Não. Um erro de exibição reproduzível com causa conhecida é diferente de perda de dados intermitente cuja causa ainda é desconhecida. Esclareça o que está estimando: o conserto, uma investigação ou ambos.
Toda equipe deve dividir uma história de 13 pontos?
Não. Aqui, 13 marca um trabalho que esta equipe em particular quer examinar e dividir. O limite da sua equipe depende de suas referências e capacidade de entender e entregar um item.
Traga suas referências para o Planning Poker
Escolha alguns itens futuros, escreva seus limites de aceite e mantenha suas histórias de referência próximas a eles. Use o Agilo Planning Poker para a sessão de estimativa da equipe.
Crie uma sala de Planning Poker quando os itens estiverem prontos para discussão.
