Incorporando o trabalho UX no Backlog do Produto

Quando o assunto é Backlog do Produto, além dos conhecimentos e habilidades necessárias com relação à Priorização, Gerenciamento e Maximização do Valor, um outro desafio do Product Owner é ter a habilidade e competência para Incorporar outros itens de diferentes categorias na lista, a exemplo do UX Backlog.

Navegando pelo site da Nielsen Norman Group, visualizei um artigo bastante interessante sobre este assunto fiz questão de compartilhar essa versão traduzida e reformatada com vocês.

Backlogs no Ágil

Por definição:

O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto… O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões.

Na maioria das equipes ágeis, o planejamento das funcionalidades é documentado na forma de Histórias de Usuários. Cada User Story recebe critérios de aceitação e um esforço estimado necessário para completá-las, e essa lista de funcionalidades é então priorizada com base nas necessidades das partes interessadas, negócios e equipe de desenvolvimento.

A priorização é uma tarefa importante de qualquer equipe ágil, pois determina quais histórias de usuário serão concluídas em uma determinado Sprint. Dependendo de quanto seus stakeholders acreditam no valor da UX, as histórias de usuários que representam o trabalho de UX podem ser despriorizadas em favor dos itens focados no desenvolvimento.

Estrutura do Backlog

O Product Owner pode se deparar com um dilema: deve usar um backlog único que inclua também trabalho de UX ou usar um outro Backlog paralelo com o trabalho de UX apartado da equipe de desenvolvimento?

Não há um livro de regras definitivo quando se trata de backlogs ágeis – cada PO pode estruturar seu backlog de maneira diferente. Apesar do Guia Oficial do Scrum dizer que o Produto só deve ter Backlog, ele também não trata esse cenário. Portanto, nossa intentação não é informar qual a melhor e mais correta forma de se trabalhar.

Ambos os métodos: seguir um backlog unificado ou manter vários backlogs podem ser bem sucedido, a depender das nuances de como são implementados. A chave é entender como sua equipe trabalha em conjunto e quanta influência seus stakeholders têm no backlog. Vejamos alguns prós e contras desses diferentes modelos.

Backlog unificado: Itens de UX itens de desenvolvimento no mesmo backlog

O mesmo Backlog unifica todo o trabalho a ser feito no produto, incluindo histórias de UX e Desenvolvimento:

Exemplo de Backlog Unificado com UX

Neste modelode backlog, a Sprint é composta de 4 itens de backlog, cada um com sua estimativa de pontos de história correspondente. O item destacado, Protótipo: Melhorias de Filtragem, é um item específico da User Experience que se refere à construção e teste de um protótipo.

 

Com itens específicos de UX explícitos incluídos no backlog unificado, o trabalho de UX é priorizado e estimado como qualquer outra coisa no backlog. A dica aqui é diferenciar os itens da lista utilizando tags, rótulos ou categorizações em seu software de gerenciamento de produto.

Prós

• Este método torna o trabalho UX visível para a equipe e seus stakeholders. Todos podem olhar o backlog e visualizar o atrabalho de UX a ser feito. O uso de tags em seu software de gerenciamento de produto tornará os itens UX fáceis de filtrar.
• Os itens pendentes relacionados à UX costumam ser tarefas grandes e gerais, em vez de tarefas pequenas e específicas. Como as atividade de UX podem consumir um certo tempo de elaboração, os profissionais podem visualizar um fluxo de trabalho completo e do tamanho necessário para sua conclusão dentro de uma ou duas Sprints.

Contras

• Os itens de UX podem ser despriorizados pelas partes interessadas em favor de novos recursos. Especialmente se eles não virem valor na pesquisa de UX. Se você achar que seus stakeholders estão consistentemente despriorizando itens de backlog relacionados à UX, você desejará tentar uma das outras duas técnicas de backlog explicadas posteriormente neste artigo.
• Pode ser mais difícil controlar as dependências. Certos itens específicos de UX podem afetar outros itens do backlog, o que significa que você precisará determinar o que precisa ser concluído primeiro. Se você usar tags ou categorias em seu software de gerenciamento de produto, pode ser fácil escapar desta situação. No entanto, preste atenção às dependências e ordem de execução do trabalho a ser feito.

 

Backlog unificado com base em tarefas: trabalho baseado em funções expresso como tarefas dentro dos itens do backlog

O segundo método de organizar seu backlog é ter itens que se dividam em um conjunto de subtarefas para diferentes competências da equipe (por exemplo, tarefas de UX, tarefas de desenvolvimento).

Backlog Unificado com UX baseado em tarefas

Neste exemplo, as “Melhorias de Filtragem” se dividem em 4 subtarefas – algumas para UX, algumas para desenvolvimento e algumas para teste de qualidade. Quando todas essas sub-tarefas são concluídas, o item do backlog é considerado concluído.

Nesse método, as tarefas de UX são adicionadas a qualquer item do backlog que requeira seu trabalho. Essas atividades podem incluir pesquisa, design ou teste de usabilidade.

Prós

• Esse método funciona melhor quando o UX e o desenvolvimento podem ser concluídos em uma única sprint. Normalmente, esse é o caso quando as equipes estão trabalhando com um domínio bem conhecido e problemas de design pequenos ou focados. Como todos os membros da equipe estão concluindo o trabalho ao mesmo tempo, a equipe precisa garantir que o trabalho de UX não impeça o restante da equipe de concluir a história.
• É fácil ver uma lista de atividades necessárias para cada item do backlog. Cada função na equipe tem tarefas associadas aos itens do backlog; portanto, as dependências entre diferentes tipos de trabalho serão mais fáceis de identificar do que com uma carteira unificada de itens misturados. Também será possível rastrear melhor o que ainda não foi concluído.

Contras

• As equipes precisam ser habilidosas para estimar os itens do backlog. Visto que você terá várias funções trabalhando no mesmo item de carteira, a estimativa pode ficar confusa. Algumas equipes gostam de usar o Planning Poker ou a sequência de Fibonacci para itens de desenvolvimento, enquanto usam os tamanhos de camisetas para trabalhos de experiência do usuário.
• Há uma chance de que você carregue itens do backlog de sprint para sprint a depender do progresso das tarefas. Por exemplo, se incorporar feedback do usuário é uma tarefa UX que não acontece até o final de um sprint, a tarefa de desenvolvimento correspondente pode passar para o próximo sprint, o que carregaria todo o item do backlog também.

Múltiplos Backlogs

O último modelo é manter vários backlogs, ou seja, um para cada competência. Por exemplo, um backlog de UX e um backlog principal de desenvolvimento. Geralmente, recomendo este modelo somente depois de tentar os outros dois, pois é preciso muita disciplina e comunicação para manter vários backlogs. Este método também é ideal para equipes UX isoladas ou equipes com várias especialidades UX.

Neste exemplo, a lista de pendências do produto e a lista de pendências de UX são independentes. A lista de pendências de UX é composta de tarefas relacionadas à UX que são criadas com base em itens de lista de pendências da lista de pendências do produto.

Ainda haverá um backlog principal do produto com todos os seus novos recursos, comentários, bugs e assim por diante. Seu backlog de UX separado incluirá todas as suas diferentes atividades de UX. Caberá ao Dono do Produtos garantir que estão trabalhando nas coisas certas no momento certo. Às vezes, a User Experience pode precisar trabalhar em uma tarefa bem antes do resto da equipe para permitir que o desenvolvimento prossiga com uma solução sólida.

Prós

• A Experiência do Usuário é totalmente responsável por seu próprio backlog. A equipe de UX está tomando decisões sobre o que precisa ser feito e como, e pode planejar os próximos itens do backlog junto ao Product Owner. Além disso, como a UX trabalha antes do desenvolvimento, haverá menos risco de atrasar os desenvolvedores em um sprint.
• Backlogs separados de UX podem ser escalados com várias equipes de engenharia e especialidades de UX. Se sua organização possui uma grande equipe de experiência do usuário com várias especialidades, cada pessoa pode trabalhar em tarefas que sejam relevantes para sua especialidade. Além disso, se sua organização tiver várias equipes de engenharia trabalhando no mesmo produto – iOS, Android e equipes da web, por exemplo – todas as tarefas de UX podem trabalhar em um backlog para ajudar a manter a consistência em todas as equipes.

Contras

• É difícil medir a velocidade geral da equipe. Como a UX funciona a partir de um backlog separado, sua velocidade não é combinada com a da equipe de desenvolvimento. (Algumas equipes não consideram a UX como parte da velocidade de sua equipe, então este aspecto pode não ser um embaraço para você.)
• Há risco de trabalhar muito à frente. Quando você está planejando com antecedência para os itens do backlog do produto, recomendamos focar a maior parte do seu esforço nos itens que estão no sprint atual e no próximo. Se sua equipe estiver trabalhando mais à frente em algo diferente da pesquisa inicial, há um grande risco de perder o trabalho caso os itens sejam despriorizados.

Conclusão

Sua estrutura de backlog pode mudar de equipe para equipe e projeto para projeto. A melhor coisa sobre as pendências é que você pode e precisa ser flexível. Não tenha medo de misturar e combinar métodos diferentes até encontrar algo que funcione para sua equipe.

Esse artigo foi publicado originalmente no Site Oficial do Nielsen Norman Group em: https://www.nngroup.com/articles/ux-agile-backlog/