Scrum: itens técnicos em um backlog que é gerenciado por um PO não técnico? [fechado

Question

Se itens técnicos, como "sever de atualização de V1 para V2" ou "aumentar o desempenho da inicialização" ou "o módulo de login do refattor para reduzir a complexidade do código", entre no backlog do produto e, se sim, como um proprietário de produto não técnico poderá priorizá -los vs outros itens de atraso mais funcionais?

Deveria haver um atraso separado para coisas técnicas? Deveríamos ter um papel de PO conjunto com duas pessoas que poderiam priorizar coisas funcionais e técnicas no backlog do produto?

Answer 1

Eu tive sucesso com a abordagem de backlog duplo:

1. O backlog do produto é de propriedade do proprietário do produto. Ele contém itens (recursos) no nível da história que são estimados pela equipe e depois priorizados pelo proprietário do produto. Esse processo de estimativa divide as histórias em tarefas menores.

2. A equipe de equipes é de propriedade da equipe de desenvolvimento. Ele contém itens de nível de tarefa relativamente pequenos (podem ser concluídos em um sprint). Eles podem estar ligados a histórias, por exemplo, como impedimentos: para concluir a história, as seguintes tarefas técnicas precisam ser concluídas primeiro. Eles também podem ser independentes para que não sejam necessários para nenhuma história em si, mas pagam alguma dívida técnica para permitir uma velocidade mais alta no futuro.

(Em alguns programas grandes e com vários projetos, também tive pedidos de backlogs do programa que contêm itens de nível épico, pertencentes e priorizados por uma equipe de gerenciamento de programas, para ser dividido em histórias em pedidos em atraso de produtos.

Answer 2

Geralmente, no scrum 'baunilha', as tarefas técnicas que você mencionou não serão como histórias separadas.

Para mim, o PO não técnico não deve estar olhando para as histórias como 'atualizar o servidor'. Não é uma história de negócios, não é visível para o usuário final, por isso é difícil priorizar se for formulado dessa maneira. As prioridades devem ser atribuídas de acordo com o valor comercial do trabalho. 'Atualizar' não significa muito. 'Permitir conexões mais simultâneas', 'reduzir o tempo de inatividade' ou até 'melhorar a velocidade da equipe' pode fornecer informações muito mais valiosas a uma pessoa não técnica. Se você não conseguir encontrar uma descrição não técnica, faça uma pergunta sobre a necessidade da atualização :)

A história de 'refatoração' é ainda mais complicada. Você se perguntou por que é uma história? A refatoração pode ser feita como uma tarefa na história, mas raramente é uma história sobre si mesma. Portanto, se você deseja fazer o login funcionar melhor ou fornecer mais recursos, é uma história, mas mexer sob o capô não conta como um. Observe também que a refatoração sem um objetivo comercial pode facilmente levar ao chamado "revestimento de ouro"

Eu sugeriria fazer as histórias de 'atualização' como um pico com o 'desempenho melhorado' e o 're-fator' sendo as tarefas para uma história de negócios relevante.

PS Você pode encontrar uma boa discussão sobre esse tópico (principalmente na parte 3) no excelente livro de Mike Cohn chamado "Histórias de usuário aplicadas: para o desenvolvimento de software ágil".

Answer 3

Eu concordo com a visão de olhar para o benefício comercial de qualquer história técnica e rastreá -la no backlog principal do produto

Eu acho que existem histórias internas relacionadas à velocidade/capacidade da equipe, que às vezes são mais convenientemente gerenciadas, atribuindo alguma capacidade aos desenvolvedores, especialmente quando o proprietário do produto não está interessado em priorizar ou gerenciar essas histórias. Por exemplo, atribua capacidade de 10% para testar o backlog (de regressão herdada), configuração do servidor CI, etc.

Sim, tudo certamente pode ser expresso em termos comerciais, mas alguns deles devem ser considerados "a maneira como precisamos fazer o nosso trabalho", onde há confiança entre o proprietário do produto e a equipe de que a equipe fará o melhor uso da capacidade atribuída para isso .