Quem deve ter permissão para adicionar histórias ao backlog do produto?

Qual é a melhor prática para evitar que o backlog se torne uma bagunça, mas também mantendo a produtividade do desenvolvedor

Quem devemos permitir adicionar histórias ao backlog do produto? E como você garante que essas histórias atendam a certos requisitos?

Por exemplo, encontro alguns pequenos erros de CSS durante o desenvolvimento do Recurso X. Devo então, como desenvolvedor, adicionar uma história descrevendo os erros na parte inferior da lista de pendências? Ou devo discuti-lo com o proprietário do produto?

Ter todas as idéias / erros percorridos pelo proprietário do produto parece um possível gargalo.

A abordagem usual é que qualquer pessoa pode adicionar histórias à lista de pendências. O proprietário do produto as prioriza e a equipe as estima. As questões de qualidade da história geralmente são resolvidas de uma maneira ou de outra no planejamento de reuniões ou retrospectivas.

Isso significa que o proprietário do produto não é um gargalo, desde que você esteja satisfeito com as prioridades que ele está atribuindo. Caso contrário, faça o seu caso.

Onde quer que eu tenha trabalhado no desenvolvimento de software, sempre houve um equivalente a um backlog, sempre uma lista de relatórios de bugs e sempre alguém responsável pelas prioridades (o equivalente a um PO), então sua pergunta, embora use termos do Scrum, é IMHO longe de ser restrito ao Scrum.

Uma rápida pesquisa no Google por "erros de backlog do scrum" revelou que algumas equipes separam bugs / problemas de histórias de "novos recursos", outras não. Às vezes, são usados ​​rastreadores de problemas, às vezes um Wiki, às vezes tudo vai diretamente para a lista de pendências, etc., e não há consenso "o que é melhor". Então a primeira coisa que você deve esclarecer em sua equipe como você deseja lidar com isso, o que faz sua equipe quer ver no backlog eo que não, e o que sua equipe acha que vai funcionar melhor para o seu caso.

Se você fez a experiência de que se todos puderem adicionar algo à lista de pendências estragam tudo, provavelmente será melhor separar histórias de usuários de bugs. Os requisitos de aparência de um bom relatório de bug provavelmente são diferentes dos requisitos de aparência de uma boa história de usuário para um novo recurso, o que também pode ser outro motivo. No entanto, ambos acabarão em tarefas para os desenvolvedores, o que pode ser um motivo para mantê-los em um só lugar.

No entanto, para a maioria dos produtos, faz sentido quando os relatórios de erros podem ser fornecidos por qualquer pessoa (usuários, testadores, desenvolvedores, pessoal de marketing, quem percebe um problema em potencial). Provavelmente, os "novos recursos" devem ser discutidos com o OP como parte do processo ao adicioná-los ao backlog. O seu OP deve decidir se ele deseja colocar as histórias nele sozinho para fazer algum trabalho editorial com antecedência, ou se alguém pode colocar as histórias na lista de pendências e ele faz o trabalho editorial depois. Mas para erros, especialmente aqueles que parecem severos para o repórter, não deve haver discussão necessária para adicioná-los ao rastreador de problemas, ao documento de lista de pendências ou lista de erros ou aonde quer que você os mantenha. "Nenhuma discussão" não significa colocar o relatório de erro em qualquer lugar silenciosamente, pelo contrário. Quando um relatório de bug é adicionado,

Como observação final: para tomar a decisão certa para sua equipe de como gerenciar isso, faz bastante diferença o tamanho do seu produto, quantas pessoas vão reportar bugs e novas histórias e, se você receber apenas um, por semana , uma dúzia ou várias centenas.

Permitimos a publicação de bugs na parte inferior da lista de pendências de produtos para todos da equipe. O item deve corresponder a certas regras (por exemplo, condições de reprodução, qual é o comportamento correto, etc.) Novos recursos, no entanto, são adicionados à lista separada 'Idéias', da qual o PO os puxa para o Backlog (e obviamente os transforma em um PBI com mais informações, se necessário)

Normalmente, fazemos o seguinte: o gerente de produtos adiciona histórias com descrições ao backlog do produto. Nosso scrum master (que também é líder de equipe) revisa essas histórias e solicita feedback adicional para histórias que não são definidas com clareza suficiente. Durante a semana de planejamento, a equipe divide cada uma das histórias em tarefas. Se houver erros, o líder da nossa equipe os colocará em lista de pendências, com prioridade atribuída também a cada um deles.