Priorização de Backlog Utilizando PBB
Inicialmente, cabe destacar que, equipes ágeis, assim como é proposto para as StartUps, devem fazer entregas incrementais. Neste sentido, elas precisam priorizar seus itens de trabalho para decidir em que ordem eles serão desenvolvidos. As equipes que seguem o Scrum realizam essa priorização, via planejamento das Sprints.
Neste sentido, tendo como base o Canvas PBB (ver PBB) a equipe de desenvolvimento juntamente com o Dono do Negócio ou Líder da StartUp, realizam a priorização dos itens de trabalho (Product Backlog Items - PBIs). Essa atividade possui como insumo fundamental os PBIs identificados no Canvas PBB. Sendo assim, caso eles ainda não estejam consistentes ou os envolvidos (equipe de desenvolvimento, Dono do Produto, Líder da StartUp) acreditem que eles ainda podem ser melhorados, faça isso, antes de ir em direção a sua priorização.
Em consonância com o método PBB utiliza-se a técnica COORG, a qual é apresentada, a seguir.
Classificar, Ordenar e Organizar - COORG
COORG é uma técnica bastante eficiente para realizar a priorização de backlog em equipes Scrum, visando planejar e alinhar o fluxo do trabalho e/ou as próximas Sprints. A Figura 1, ilustra a aplicação do COORG em um Canvas PBB.
Figura 1. Canvas PBB e COORG (fonte: Aguiar e Caroli, 2021, adaptado).
Classificar o Backlog
A primeira atividade a ser realizada é a definição dos critérios a serem utilizados para a classificação dos PBIs. Para tanto, os envolvidos devem estabelecer critérios que, de fato, façam sentido e sejam relevantes para o produto que está sendo construído. Caso contrário, a priorização poderá ser enganosa, fantasiosa.
A seguir, são apresentados dois exemplos de critérios.
- Frequência de uso: frequência com que o usuário utiliza um PBI (cada PBI é um passo no fluxo de trabalho de uma funcionalidade).
- Valor de negócio: o valor de negócio gerado quando o usuário utiliza o PBI.
Após a definição dos critérios, defina a sua escala de valores, por exemplo:
Nome do Critério: Frequência de Uso
| Nome do Item da Escala | Valor do Item da Escala | Descrição do Item da Escala |
|---|---|---|
| HORA A HORA | 5 | utilizado mais de uma vez no dia. |
| DIÁRIO | 4 | utilizado uma vez ao dia, pelo menos. |
| SEMANAL | 3 | utilizado uma, duas ou três vezes na semana. |
| MENSAL | 2 | utilizado uma vez no mês ou um pouco mais de uma vez. |
| TRIMESTRAL | 1 | utilizado, pelo menos, uma vez a cada três meses. |
Nome do Critério: Valor de Negócio
| Nome do Item da Escala | Valor do Item da Escala | Descrição do Item da Escala |
|---|---|---|
| ALTO | 3 | muito importante, principal, algo com um valor de negócio alto. |
| MÉDIO | 2 | algo que possui relevância, um valor de negócio médio. |
| BAIXO | 1 | algo que faz sentido, mas que não agrega muito valor no momento atual, um valor de negócio baixo. |
Definidos os critérios e suas escalas de valores, cada PBI deverá receber uma classificação, quanto a sua frequência de uso e valor de negócio. A prioridade de cada item será calculada, neste exemplo, como: PRIORIDADE = FREQUÊNCIA DE USO + VALOR DE NEGÓCIO. Essa valoração deve ser registrada diretamente em cada PBI (ver Figura 2).
Figura 2. Priorização de PBIs (fonte: Aguiar e Caroli, 2021, adaptado).
Ordenar o Backlog
A segunda atividade do COORG é a ordenação das funcionalidades em uma sequência lógica, da esquerda para a direita, estruturando-as como em uma narrativa. A ordem lógica de sequenciamento deve ser definida pela equipe de desenvolvimento e Dono do Produto. Fique atento, pois se uma funcionalidade for movida, seus respectivos PBIs também devem ser, mantendo-os abaixo da funcionalidade correspondente (ver Figura 3).
Figura 3. Ordenação das Funcionalidades (fonte: Aguiar e Caroli, 2021).
Organizar o Backlog
Por fim, deve-se organizar cada um dos PBIs (verticalmente, de cima para baixo) em relação a sua funcionalidade correspondente. Neste sentido, coloque na primeira linha os PBIs com maior prioridade. Por exemplo: Se o número 7 for a maior pontuação, todos PBIs com nota 7 ficam na primeira linha. Abaixo dela, a linha dos PBIs com nota 6, depois a linha dos PBIs com nota 5, e assim sucessivamente (ver Figura 4).
Figura 4. Organização dos PBIs (fonte: Aguiar e Caroli, 2021).
Considerações sobre o COORG
O COORG organiza os PBIs no formato de uma matriz. Para convertê-la em uma lista ordenada de trabalho, siga a matriz da esquerda para a direita e de cima para baixo. Comece com os itens da primeira linha, depois da segunda linha, e assim sucessivamente até o final. Os itens que possuem nota baixa, geralmente, não entram no backlog pois, por meio da aplicação do COORG, fica claro o valor reduzido dentro do contexto do produto. Neste sentido, o Product Owner pode usar seu poder de decisão para dizer “não” a esses itens com classificações baixas.
Após aplicar o COORG nas histórias, verifique se há dependência entre elas (às vezes isso acontece, mesmo tendo aplicado o INVEST). Se houver, automaticamente, a história dependente deve receber a mesma pontuação da história a qual ela depende.
Figura 4. COORG, Backlog e Prioridades (fonte: Aguiar e Caroli, 2021).
ATENÇÃO
- Lembre-se que o backlog deve ser sempre atualizado ao longo do ciclo de desenvolvimento do produto.
- A medida que novas funcionalidades e PBIs forem surgindo, não deixe de evoluir do backlog.
- Novos itens não devem interromper o trabalho da Sprint atual pois, o escopo da Sprint, é intocável.
- Novos itens que surgirem devem ser classificados e priorizados no backlog, de maneira que o COORG ajude a definir em qual Sprint subsequente tal item será desenvolvido.
Referências Bibliográficas
- Aguiar, F. e Caroli, P. Product Backlog Building: Um guia prático para a criação e refinamento de backlog para produtos de sucesso. Editora Caroli, RJ. 2021.
- Aguiar, F. Scrum PBB. Disponível em: http://www.productbacklogbuilding.com/slides/ScrumPBB.pdf