Tabela modelo para o Backlog do Produto
Quero mostrar uma forma bem simples de apresentar User Stories em um Product Backlog em formato de tabela. A ideia surgiu quando encontrei um dos meus antigos Product Backlogs de nove anos atrás e pensei: "Uau, comparado com o que faço hoje, isso está bem ultrapassado." Por isso, vou mostrar aqui um modelo de Product Backlog em formato de tabela (por exemplo, Excel).
Como você provavelmente já sabe, sou grande fã de escrever o Backlog usando User Stories e estruturar essas User Stories da seguinte forma:
"Como ______ quero ______, para que ________."
Isso poderia ser assim: "Como viajante frequente, quero poder acessar a internet durante o voo, para poder atualizar meu blog também durante a viagem, em vez de apenas salvar um documento de texto para atualizar o blog mais tarde." (Consegue adivinhar onde escrevi isso?)
Ao trabalhar com uma planilha Excel, acho mais fácil usar os elementos de texto das User Stories como títulos de coluna. Dessa forma, obtemos os títulos "Como", "quero" e "para que" ou "pois". A mensagem central de cada Story fica bem visível. Também é possível adicionar mais colunas, por exemplo, para numeração, observações, status, etc. No exemplo a seguir, também adicionei uma coluna para o tema principal de cada Story.
| ID | Tema | Como… | quero… | para que… | Observações | Prioridade | Status |
| 2 | Jogo | Moderador | criar um novo jogo, inserindo um nome e uma descrição opcional | eu possa convidar outras pessoas para fazer estimativas | Se não for possível salvar jogos e retornar a eles, a descrição não é necessária | obrigatório | done |
| 2 | Jogo | Moderador | convidar outras pessoas para fazer estimativas, fornecendo uma URL para participarem do jogo | possamos começar o jogo | A URL deve ser formatada de forma que seja fácil compartilhá-la por telefone | done | |
| 5 | Jogo | Estimador (pessoa que fará uma estimativa) | participar de um jogo, inserindo meu nome na página para a qual recebi a URL | eu possa participar do jogo | done | ||
| 6 | Jogo | Moderador | iniciar uma rodada, inserindo um item em um campo de texto de múltiplas linhas | possamos estimá-lo | done | ||
| 8 | Jogo | Estimador | ver o item que será estimado | eu saiba para o que estou dando uma estimativa | done | ||
| 40 | Jogo | Participante | ter as cartas sempre na mesma ordem ao puxá-las várias vezes | seja mais fácil comparar as estimativas | Substituído por A08, para que a story não fale sobre "a mesma ordem", pois isso pode ser um detalhe de UI | done | |
| 35 | não funcional | Usuário | que a aplicação responda rapidamente às minhas ações | eu não fique entediado | done | ||
| 36 | não funcional | Usuário | boas páginas de erro quando algo der errado | eu possa confiar no sistema e nos seus desenvolvedores | done | ||
| A11 | não funcional | Pesquisador | que os resultados sejam armazenados de forma não identificável | eu possa estudar dados, como por exemplo se as estimativas são semelhantes à primeira opinião dada pelo "Estimador A" | Não devem ser armazenados nomes nem textos, mas sim cada carta, quem a jogou e a estimativa final | ||
| A05 | Jogo | Moderador | modificar um dos itens a serem estimados | ele reflita melhor o entendimento do time sobre o item | |||
| 22 | Arquivo | Moderador | exportar os dados de um jogo como arquivo CSV | eu possa continuar trabalhando nas stories e estimativas | O arquivo exportado deve ser diretamente importável de volta ao sistema | done |
