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.