Explicando a diferença entre o Item do Backlog do Produto e uma Tarefa

Eu já enfrentei esse desafio algumas vezes e espero que alguém possa fornecer algumas referências, treinamento ou conselhos sobre como explicar a diferença entre um Item de Backlog do Produto e uma Tarefa no TFS.

Entendo e expliquei que um Item do Backlog do Produto é o "O quê" e a Tarefa é o "Como". Também expliquei que o PBI é o requisito e a tarefa é como o requisito é atendido.

Sou visto repetidamente com olhares em branco e cabeça coçando quando explico isso. Parece que os engenheiros de software aos quais explico não podem fazer a distinção. É tudo a mesma coisa para eles.

Acredito que meu outro desafio é que não sou capaz de ilustrar efetivamente por que é importante fazer a distinção.

O "Item de lista de pendências do produto" é realmente o quê, a funcionalidade que precisa ser criada. A tarefa descreve as etapas que precisam ser seguidas para chegar lá.

Muitas equipes não são usadas para se decompor em tarefas, apenas constroem o que as especificações dizem. Para essas pessoas, é difícil vê-las como duas coisas separadas.

Talvez uma anedota simples ajude:

Veja os itens do Backlog do produto como os itens da lista de compras para as férias. Talvez uma "barraca", uma "vara de pescar", um "carro preparado para a viagem".

As tarefas do item "barraca" seriam "Descrever os requisitos da barraca", "Comparar barracas on-line", "Obter conselhos de amigos com experiência ao ar livre", "Ir para a loja de rua", "Comprar barraca", "montar barraca no quintal para" verifique se "," empacota a barraca para viajar "

As tarefas para a vara de pesca serão muito semelhantes, mas as tarefas para "preparar o carro para a viagem" provavelmente são muito diferentes: "Verificar requisitos para estados / países na rota desejada", "comprar colete de segurança", "substituir o conteúdo vencido dos primeiros socorros kit "," inspecione o pneu sobressalente "," agende uma consulta com a garagem para verificar o motor "," vá para a garagem para verificar o motor "," vá para a agência estadual para comprar o passe da estrada "," verifique o seguro de carro "

Isso separa claramente a questão do que o proprietário do produto deseja e do que ele precisa fazer. A menos que o proprietário do produto já tenha se decomposto em itens acionáveis ​​no Backlog do Produto, nesse caso, você também precisará conversar com eles.

Como eu disse, para muitos desenvolvedores, eles acham que já têm informações suficientes e sabem o que fazer, não querem decompor as etapas O que fazer em Como, chegarão lá quando chegarem lá. Quando você começar a conversar com eles sobre como acompanhar o progresso do sprint, melhorar as estimativas, acompanhar o trabalho que foi esquecido durante o planejamento do sprint e outros itens relacionados às melhorias profissionais, pergunte a eles como eles e sua equipe saberão onde podem melhorar e como sei que eles realmente terminaram. Quando eles podem criar um sistema que funciona sem criar tarefas e funciona, tudo bem, mas as chances são muito baixas de que eles realmente possam.

Antes de tentar trabalhar com o TFS e as ferramentas ágeis, sua equipe precisará entender como tudo isso funciona. A melhor maneira é fazê-los trabalhar com uma placa de papel, visível a todos no piso de trabalho. Mais tarde, quando o processo for entendido melhor, a mudança para as ferramentas ajudará. Sem o entendimento, as ferramentas não serão muito úteis e encontrarão muita resistência.

Eu acho que Jesse deu uma ótima resposta. Simplesmente vou tentar torná-lo, bem, mais simples (se possível) :) O Item do Backlog do Produto (ou História do Usuário, se você preferir) geralmente é escrito assim:

Como novo cliente, desejo registrar meus dados para ser informado sobre os lançamentos de novos produtos.

Na cabeça de um desenvolvedor, isso pode se traduzir em:

1. Crie um formulário de registro
2. Gravar dados de registro no banco de dados
3. Enviar email para o novo cliente para confirmar seu registro

Esses três itens são as tarefas.

Espero que ajude.

- Torne o mais simples possível, mas não mais simples (Einstein)

Veja como rolamos:

O PBI:

• é o requisito conhecido como "o quê"
• é sobre isso que você fala com um cliente .
• É o que aparece na Atualização diária do projeto (DPU) para o sprint ..... novamente porque a DPU está voltada para o cliente.
• É sobre isso que o cliente falará e se referirá em termos de estimativas e orçamento.
• Pode incluir uma ou mais tarefas.
• É orientado para negócios e descrito em linguagem orientada para negócios / estilo de domínio que o cliente entende.
• É o que é testado e aceito no UAT (User Acceptance Testing)

A tarefa:

• É um trabalho necessário para materializar o PBI (requisito)
• Não é algo que você fala com um cliente
• Não aparece na DPU porque você não fala sobre eles com os clientes
• É estimado, mas tem suas estimativas acumuladas no PBI
• É filho de um e apenas um requisito.
• Pode ser descrito (e geralmente é) usando o jargão técnico
• Testado internamente e assinado por teste
• Não aceito ou testado isoladamente pelo cliente (eles não sabem que existem)

Costumo oferecer isso quando solicitado: -

Um PBI ou uma história é algo que mais do que uma pessoa pode dar a volta.

A Tarefas é algo que apenas uma pessoa pode pegar.