Qual é o papel responsável pela priorização dos itens do Backlog de produto?

ola, isso mesmo a palavra final é dele

Boa tarde Hugo! Em princípio a afirmação realmente parece forte, mas é isso mesmo. O Scrum Guide é categórico ao afirmar que o PO (Product Owner) é a única pessoa responsável por gerenciar o Backlog do Produto, e cita que esse gerenciamento inclui as seguintes atividades:

Expressar claramente os itens do Backlog do Produto;
Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
Além disso, o Scrum Guide di que o PO pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o PO continua sendo o responsável pelos trabalhos.
O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.
fonte: https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf
Boa sorte nos estudos!

É que do meu ponto de vista, ser responsável e ser o único que pode alterar o backlog são coisas distintas. Eu acredito que pela filosofia da metodologia, qualquer um do time Scrum poderia alterar, mas o Product Owner teria que revisar todas, aprovando, rejeitando ou solicitando retificações, não?

solução!

Hugo você tem razão! De fato ser o responsável e ser o único que pode alterar o Backlog do Produto são coisas distintas. Até porque como visto acima, o Dono do Produto pode delegar esta atividade ao Time de Desenvolvimento e mesmo assim continua a ser o responsável por ela.

Contudo, quando você menciona que acredita que "qualquer um do Time Scrum poder alterar e depois o Dono do Produto vai revisar..." eu entendo que essas alterações (não só do Time mas também dos demais Stakeholders) são levadas ao Dono do Produto para que sejam adicionadas ao Backlog do Produto. Aqui já há uma necessidade de persuasão do Dono do Produto

Scrum Guide: "Para que o Product Owner tenha sucesso, toda a organização deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto."

O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que o Produto deve ter e é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia (em geral, quem mais entende de tecnologia é o Time) podem causar mudanças no Backlog do Produto.

Em que pese haver uma ordenação prévia dos requisitos pelo Dono do Produto (pode contar com a ajuda do Scrum Master), ela não é impositiva. O Dono do Produto não impõe nada ao Time de Desenvolvimento, ele negocia com o Time de Desenvolvimento defendendo a visão do cliente. (Eu sei que você não entrou nesse mérito, mas essa explicação é necessária para entender-mos que existem etapas de refinamento do Backlog do Produto).

Essas novas características são então submetidas a uma priorização pelo próprio Time Scrum no Planejamento da Sprint (por exemplo pelo método MoSCoW) se for a 1ª Sprint do Projeto, ou através de grooming se for nas demais Sprints do Projeto.

Assim, as características que geram mais valor para o cliente provavelmente receberão a classificação Must Have (Deve ter), já as características que não geram nenhum valor receberão a classificação Won't Have (Não deve ter), pulei propositalmente Should e Could Have. Aqui ocorre outra validação, desta vez por todo o Time Scrum

Cabe ressaltar que dentre os valores propagados pelo Scrum Guide consta a coragem para o Time Scrum fazer a coisa certa e trabalhar em problemas difíceis. E o respeito: "Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes."

Como se vê, no Scrum todo o time deve se respeitar e isso inclui desenvolver a capacidade de negociação e empatia com os colegas. Assim, apesar de ser o responsável pelo Backlog do Produto se o Dono do Produto for inflexível demasiadamente descartando arbitrariamente os inputs fornecidos pelo Time provavelmente não obterá sucesso com o projeto. Daí, nota-se também, a importância de uma boa escolha do Dono do Produto para um determinado Projeto.

Veja também: https://cursos.alura.com.br/course/scrum-parte-4/task/22414

Bons estudos! :D

Backlog é um dos tipos de lista de tarefas que, normalmente, é associada ao seguimento de TI, por referir-se ao desenvolvimento de um produto ou um sistema. Quando combinado com uma gestão ágil, ele ajuda a entender melhor o escopo de um projeto, as prioridades e o andamento das sprints.

Veja o que você vai encontrar neste artigo:

O que é backlog e quem deve administrá-lo?
Como funciona o backlog?
Como refinar o backlog?
Backlog para quem não é de TI
FAQ sobre Backlog
Uma ferramenta online para auxiliar seu backlog

Você também pode ouvir este conteúdo dando play logo abaixo.

O que é backlog e quem deve administrá-lo?

Como dito anteriormente, backlog, também conhecido como backlog de produto ou “product backlog”, é uma lista de tarefas que contém breves descrições de todas as funcionalidades desejadas para um produto específico ainda não atribuídas a um responsável. Essa lista traz os requisitos para um projeto, priorizados de acordo com o valor entregue para o cliente.

Essas descrições podem se transformar em tarefas, que no futuro serão feitas pela sua equipe de desenvolvimento. Dessa forma, e seguindo o seu fluxo de trabalho, fica mais fácil priorizar o que deve ser feito em cada sprint.

No mundo ideal, ele deve ser gerenciado pelo product owner, que é o gestor de produto que fica responsável por todos os aspectos de um software, desde os objetivos estratégicos até os detalhes de experiência do usuário. Já falamos sobre o product owner neste artigo sobre gerenciamento de conflitos em equipes de TI.

Mas não se trata de uma lista estanque; conforme o projeto avança e à medida que os requisitos são descobertos, o backlog pode e deve ser ampliado. O importante é que contenha informações suficientes para que o time consiga realizar estimativas de desenvolvimento.

Gestão ágil

A gestão ágil surgiu do Manifesto ágil, criado em 2001 por desenvolvedores e profissionais da área de TI, para tornar os processos mais coesos, seguindo alguns princípios fundamentais que vão garantir o sucesso do desenvolvimento do seu produto ou serviço. Os principais pilares são:

1.Indivíduos e interações mais que processos e ferramentas;
2.Software em funcionamento mais que documentação abrangente;
3.Colaboração com o cliente mais que negociação de contratos;
4.Responder a mudanças mais que seguir um plano.

Portanto, metodologias amplamente conhecidas como o Scrum ou o Kanban são considerados frameworks ágeis. Nesse caso, o backlog pode ser aplicado para ambas as metodologias. No Scrum, através do product backlog e/ou do sprint backlog (falaremos mais detalhadamente sobre eles no próximo tópico) e no kanban, como sendo a primeira coluna, contendo todas as tarefas.

Quer saber mais sobre a gestão ágil e como aplicá-la no seu dia a dia? Então assista ao webinar abaixo:

Como funciona o backlog?

Geralmente, o time e o “dono do produto” responsáveis pelo projeto escrevem e priorizam os itens iniciais do backlog de produto. A premissa, aqui, é que tais itens bastem para que a equipe inicie a primeira iteração (sprint) – que é o ato de repetir, de tornar a fazer. Neste momento, teremos o sprint backlog, composto pelas histórias que fazem parte da iteração em questão.

Perceba que temos, assim, dois tipos: o product e o sprint. Mas não confunda: de acordo com este artigo do site OAT Solutions, enquanto o backlog de produto é criado uma vez e atualizado ao longo do projeto, um sprint backlog é criado sempre no início de cada iteração. E enquanto o backlog de produto costuma ser atualizado semanalmente, o sprint é revisado e atualizado diariamente.

Reiteramos que, ao longo de todo o processo, a lista de atividades irá crescer e mudar à medida em que se aprende mais sobre o produto e sobre o cliente a quem é direcionado.

Como refinar o backlog?

Às vezes, obter um processo de backlog refinado pode ser um tremendo desafio. Dificuldades durante o planejamento das iterações (sprint backlogs), um backlog de produto enorme ou muito pequeno, a falta de atendimento durante um sprint… São vários os obstáculos que se impõem para o product owner, ou o gestor.

Este artigo do portal DZone traz dicas imperdíveis para você superar tais desafios. Vamos a eles:

1. Formalize as demandas

De acordo com o texto, não há um jeito certo de incorporar o refinamento de um backlog de produto em uma iteração. Mas uma coisa é certa: formalizar as atividades de refinamento que ocorram numa cadência regular dentro de cada iteração é essencial. Assim sendo, aproveite esses eventos para inspecionar e adaptar o backlog durante as retrospectivas, e descubra o que funciona melhor para seu time.

2. Atribua somente os responsáveis por cada tarefa

Em equipes de desenvolvimento, é comum que todos estejam alinhados em todas as etapas, porém nem sempre alguém que foi mencionado irá atuar de forma prática naquele momento.

Quando envolvemos colaboradores que não deveriam ser envolvidos nessas atividades, tempo e recursos são desperdiçados. Então, procure sempre conversar com sua equipe para estabelecer quem deve comparecer a uma sessão de refinamento.

Mas isso não significa que o resto do time não deve ser informado de mudanças; pelo contrário, todo mundo deve estar a par de quaisquer novidades que venham por aí. Nesses momentos, metodologias como a gestão à vista ou o KPI dashboard podem ser extremamente úteis.

3. Defina o que “Pronto” significa para seu time

Esse ponto é fundamental. Você deve estabelecer com todo cuidado possível o que “Pronto” significa; por “Pronto”, entenda um pequeno checklist de itens que seu time deve realizar antes que um item do backlog de produto seja trazido para uma iteração. A prática é de grande auxílio para estabelecer alguns limites ao redor daquilo que seu time de desenvolvimento precisará fazer para que um item seja feito.

4. Não se antecipe demais

Se você estiver refinando itens do backlog de produto que serão trabalhados pelo seu time de desenvolvimento com muitos meses de antecedência, pare. Será uma perda do seu tempo. Porque os requisitos são, com frequência, um dos aspectos mais instáveis do desenvolvimento de software (leia sobre análise de requisitos aqui).

É muito difícil captar, com precisão, as exigências de um cliente sem considerar o formato que você estará usando ou a quantidade de esforço que você colocará nele.

Um backlog de produto com itens “caducos” significa que você perdeu tempo utilizando requisitos que não são mais relevantes. Assim sendo, mantenha-se com um ou dois que possam ser definidos como “Prontos” para o sprint backlog.

Da mesma forma, não assuma que todo aspecto de um item do backlog de produto deva ser explicitamente definido. Abra espaço para conversas e para a criatividade de sua equipe durante uma iteração.

Backlog para quem não é de TI

O backlog nasceu na área de TI, mas é um conceito que pode ser aplicado em qualquer área. Confira a seguir alguns exemplos de como o modelo pode ser aplicado na sua rotina de organização e atribuição de tarefas, usando o Runrun.it como ferramenta.

Backlog criativo

Imagine que todos os departamentos de uma empresa executem suas tarefas de sustentação, que são aquelas do dia a dia e já enraizadas em seu cotidiano. Por outro lado, as lideranças gostariam de fazer testes, implementar novas ideias, realizar novos projetos… E onde ficam guardados todos esses desejos? No backlog!

Confira os passos abaixo para organizar o backlog criativo da sua equipe:

1. Brainstorm

Faça um brainstorm com a equipe para listar ideias que poderiam deixar os processos da área mais eficientes, ou tornar a equipe mais produtiva, ou ainda, aumentar os resultados de alguma forma. Seja criativo.

2. Conte a história e guarde

Selecione as ideias com maior potencial e que merecem ser levadas adiante. Para cada uma, faça um briefing, como se contasse uma história do porquê e como a ideia deve ser executada. Use um checklist, se for mais fácil. Avalie quanto tempo e pessoas devem trabalhar na ideia. Por fim, guarde todas as selecionadas no backlog.

A cada período, 1 semana ou 15 dias, de acordo com seus recursos, priorize junto à equipe uma nova ideia para ser executada. Atenção: ela não deve demorar muito para ser finalizada, deve estar dentro dessa janela escolhida. A escolha deve ser feita em conjunto e todos devem opinar. É uma decisão coletiva e todos devem participar da execução.

3. Execute

Depois de realizada, reunia-se com todos para analisar os pontos positivos e negativos do processo, e sugerir melhorias para a execução das próximas histórias.

4. Crie o hábito

Comece outra vez! Você pode tanto fazer novos brainstorms, como consumir o backlog atual. O importante é manter o ritual de escolher uma nova história a cada período. Além de motivar a equipe (eles farão coisas diferentes, vão sair da rotina), você pode ter resultados surpreendentes.

Backlog para distribuir tarefas

Outra forma de usar o backlog é com equipes cujos membros realizam os mesmos tipos de tarefa. Por exemplo, uma equipe de designers, ou uma equipe de helpdesk, ou ainda, uma equipe de redatores. Não importa a tarefa que entre na fila, qualquer um está habilitado a pegar para si e realizar.

É como se fosse uma despensa com tarefas: assim que o profissional fica livre, ele vai até a despensa e pega a demanda que estiver no topo. Fácil, né? Em um fluxo de trabalho, o backlog seria a primeira etapa, ou coluna.

FAQ sobre Backlog

O que é backlog?

Backlog é uma lista que contém breves descrições de todas as funcionalidades desejadas para um produto específico.

Quem deve administrar o backlog?

O backlog deve ser gerenciado pelo product owner, que é o gestor de produto que fica responsável por todos os aspectos de um software, desde os objetivos estratégicos até os detalhes de experiência do usuário.

Como funciona o backlog?

O time e o “dono do produto” responsáveis pelo projeto escrevem e priorizam os itens iniciais para que a equipe inicie a primeira iteração (sprint). Daí, teremos o sprint backlog, composto pelas histórias que fazem parte da iteração em questão.

Como refinar o backlog?

Faça reuniões regulares de refinamento, envolvendo somente as pessoas necessárias, para inspecionar e adaptar o backlog, descobrindo o que funciona melhor para seu time. Mas tente não se antecipar muito, pois os requisitos são, com frequência, um dos aspectos mais instáveis do desenvolvimento de software.

Como usar o backlog no Scrum?

No framework ágil Scrum, as tarefas são reunidas em um backlog, e o projeto é dividido em blocos fixos de tempo com suas próprias tarefas e metas, ou seja, os Sprints.

Uma ferramenta online para auxiliar seu backlog

Utilizando um software de gestão do trabalho como o Runrun.it, você pode definir diversas etapas que compõem o seu fluxo de trabalho. Uma delas pode ser a etapa Backlog. Nela, você pode listar todas as tarefas que ainda não tem ninguém responsável. Dessa maneira, qualquer um na equipe pode acessar essa etapa e se alocar em tarefas conforme sua disponibilidade.

No kanban, define-se etapas pelas quais as tarefas devem passar até serem entregues. Isso torna o fluxo mais enxuto e ágil

Na plataforma, você também consegue ter uma visão do todo e monitorar as atividades de sua equipe bem de perto, acompanhando a realização de cada item disposto na etapa de backlog. Sem bagunças, desperdício de esforços, de forma organizada e priorizando as tarefas automaticamente. Faça um teste grátis hoje mesmo: http://runrun.it

Artigos que você também vai querer ler:

Priorizar é preciso: dicas para você organizar a gestão e se dedicar ao que realmente importa
O que é kanban e como ele pode ajudar na organização da rotina de trabalho
Metodologia ágil: um presente da indústria de software para todo o universo da gestão

Quem é o responsável por priorizar os itens no Backlog do produto?

O Backlog do Produto é gerenciado pelo Product Owner e contêm os itens ordenados que serão desenvolvidos pelo Time de Desenvolvimento para o produto. Esses itens de trabalho são expressos na forma de necessidades do usuário, objetivos de negócios dos clientes e demais partes interessadas ou funcionalidades do produto.

O que deve ser considerado na priorização do Backlog do produto?

Idealmente, o backlog do seu produto deve ser uma lista de todas as tarefas relacionadas ao produto que sua equipe precisa concluir a seguir e tudo o que elas podem e devem se concentrar (dentro de um prazo definido) depois disso.