Concept Backlog é uma ferramenta criada para conectar conceitos com backlogs de desenvolvimento facilitando a conexão entre as duas fases.
De modo geral, o backlog é uma lista com pedidos ou tarefas a serem realizadas por um time ou por um profissional específico.
Dentro do desenvolvimento de serviços digitais, o backlog – essa lista de pedidos ou tarefas – é escrita pela figura do Product Owner, responsável também por priorizar as tarefas que serão feitas primeiro de acordo com uma série de variáveis como, por exemplo, a estratégia do serviço, a missão da empresa, as necessidades de negócio, as necessidades ou os impedimentos técnicos, o tempo disponível e, principalmente, as necessidades dos clientes.
O backlog normalmente é dividido em duas partes:
Product Backlog – uma lista que contém vários pedidos ou tarefas necessárias para a construção de um serviço novo ou mudanças e melhorias em um serviço existente. Esse backlog pode conter todas as tarefas previstas para a construção do serviço ou apenas as necessárias para o desenvolvimento das primeiras funcionalidades que serão oferecidas ao cliente. Normalmente a segunda abordagem é mais usada por que as funcionalidades do serviço podem mudar de acordo com a interação do cliente com o serviço.
Sprint Backlog – uma lista reduzida, priorizada e ordenada do Product Backlog que serão desenvolvidas pelo time de desenvolvimento em um período de tempo previamente combinado, chamado de Sprint. A quantidade de tarefas que serão realizadas dentro dessa Sprint é decida pelo time de desenvolvimento junto com o Product Owner que as priorizou de acordo com as variáveis mencionadas anteriormente.
Para facilitar a conexão entre a saída das sessões de Design Thinking com o time de desenvolvimento, costumo usar um Concept Backlog como um dos entregáveis dessas sessões.
Ligeiramente diferente do Product Backlog, o Concept Backlog é uma lista de funcionalidades desejadas para o serviço. Essa lista é escrita e priorizada pela equipe envolvida nas sessões de Design Thinking – que inclui o Product Owner e o time de desenvolvimento, além de outros profissionais –, mas, ao invés de detalhar a tarefa especifica necessária para construir a funcionalidade, a lista mostra as funcionalidades em si.
Um exemplo ilustrativo poderia ser:
Funcionalidade do Concept Backlog: “Fazer login usando redes sociais”
Tarefa do Product Backlog: “1. Disponibilizar login via Facebok / 2. Disponibilizar login via Google”
Ou seja, as funcionalidades do Concept Backlog vão ser posteriormente transformadas em pedidos ou tarefas específicas para o time de desenvolvimento. Uma funcionalidade pode, inclusive, ser quebrada em várias tarefas e serem realizadas em Sprints diferentes.
Composição do Concept Backlog
Intenção do cliente: Qual a intenção do cliente que a funcionalidade vai suprir.
Funcionalidade: A funcionalidade em si.
Descrição da funcionalidade: Detalhamento da funcionalidade.
Insights vindo dos clientes: Aprendizados vindo dos clientes durante a sessão de Design Thinking por meio de entrevistas ou testes.
Priorização: Categorização da funcionalidade, que pode ser em quatro dimensões:
- Fundamental: Funcionalidades necessárias para o serviço sem as quais ele não pode acontecer;
- Desempenho: Funcionalidades que tornam o serviço mais eficiente para o cliente;
- Show: Funcionalidades que tornam o serviço mais atrativo e espetacular;
- Secundárias: Funcionalidades incrementais que podem ser inseridas por último no serviço.
Relevância para o cliente: Nota definida pela equipe de quanto a funcionalidade é importante para o cliente (0 a 10).
Valor para o negócio: Nota definida pela equipe de quanto a funcionalidade é importante para a empresa e o negócio (0 a 10).
Facilidade de desenvolvimento: Nota definida pela equipe de quanto a funcionalidade é fácil de ser desenvolvida (0 a 10).
Média: Soma das notas dividida por três para gerar a priorização das funcionalidades.
Para que normalmente é usada
O Concept Backlog é uma ferramenta útil para consolidar os aprendizados de sessões de Design Thinking e conectar os resultados dessas sessões para o time de desenvolvimento que vai realizar o conceito, transformando-o em um serviço utilizável pelo cliente.
Quando normalmente é usada
No final de sessões de Design Thinking, para consolidar os aprendizados e definir os próximos passos.
Exemplo de passo a passo
PASSO 1
Comece escrevendo as intenções do cliente em cada momento da jornada, aprendidas em entrevistas ou em testes com clientes reais.
PASSO 2
Escreva uma ou mais funcionalidades pensadas para suprir essas intenções que foram aprendidas em entrevistas ou em testes com clientes.
PASSO 3
Escreva os insights para cada funcionalidade observados nas entrevistas ou nos testes com clientes.
PASSO 4
Descreva o funcionamento da funcionalidade.
PASSO 5
Defina em qual categoria de priorização a funcionalidade se encaixa.
PASSO 6
Dê notas para de valor para o cliente, valor para o negócio e a facilidade de desenvolvimento e feche a média por funcionalidade.
PASSO 7
Organize as funcionalidades pelas médias e pelos momentos da jornada.
Referências
Desenvolvimento Ágil. Disponível em: <http://www.desenvolvimentoagil.com.br/scrum/sprint_backlog>. Acesso no dia da postagem.
