Imagem 1: Apresentação TDC – OKRs.

Há algum tempo os temas OKRs, MoSCoW e WSJF chamam minha atenção.

Em parceria com alguns amigos – Agilistas – decidimos realizar experimentações para colocar estes conceitos em prática.

Buscamos pontos de sinergia entre os temas e a partir disso elaboramos um modelo composto de três grandes etapas que permite conectar de forma simples e objetiva estratégica de negócio com o produto, chegando até o nível de Feature e User Story.

Os resultados foram bastante satisfatórios e o experimento acabou virando tema de uma palestra da trilha de Análise de negócios no TDC Porto Alegre 2020.

Como funciona o modelo na prática?

 1.0 – Definição de OKRs

              Imagem2: Estrutura  de OKRs.

Definir os Objetivos e Resultados-Chave é o ponto de partida para a construção da estratégia. Os Objetivos e Resultados permitem duas conexões importantíssimas:

•           Alinhamento dos drivers estratégicos ou OKRs corporativos com os objetivos dos times, relacionados ao produto. Este elo é fundamental para manter o foco entre desenvolvimento do produto com a estratégia da empresa.
• Conexão dos objetivos e resultados-chave com os épicos e features. O alinhamento entre estas duas partes permite estabelecer um vínculo entre desenvolvimento do produto com as ações necessárias para alcançar os objetivos de negócio. Este “chaveamento” proporciona a conexão entre produto e estratégia.

Com esta estrutura bem definida, ficará bem mais simples visualizar e acompanhar os resultados e as evoluções das entregas.

A imagem abaixo, ilustra a aplicabilidade dos OKRs com o framework SCRUM em times ágeis.

Imagem 3: OKRs + SCRUM.

2.0 – Utilizando MoSCoW como “Primeira Setorização”

Imagem 4: MoSCoW.

O termo MoSCoW é um acrônimo em inglês derivado da primeira letra de cada uma das quatro categorias com os “Os” no meio para fazer a palavra ser pronunciável.

Onde:

• Must Have (Tenho que Fazer): referem-se aos itens que “tenho que fazer”. Classificados como críticos e que devem ser tratados com maior nível de prioridade.
• Should Have (Devo Fazer): itens importantes mas não são tão necessários do ponto de vista estratégico para entrega neste momento.
• Could Have (Poderia fazer): itens classificados como  desejáveis, mas não necessários do ponto de vista estratégico.

 Won’t Have (Não vou fazer): são itens menos críticos, com menor retorno sobre investimento ou não adequados para serem realizados durante algum período de tempo. Geralmente são itens que ficam no Parking Lot aguardando para serem priorizados com baixa prioridade nas Sprints.

Em nosso modelo o utilizamos esta técnica como uma segunda etapa para separar o “joio do trigo”, elencando os requisitos de negócio e priorizando-os através das seguintes ações:

1. Normalmente as iniciativas consistem em grandes temas. Então, quando estamos trabalhando o Discovery já os transformamos em épicos.
2. Para estes épicos realizamos uma “primeira setorização” para classificá-los com MoSCoW.
3. Trazemos para o backlog para fazer build, normalmente somente o que for Must Have e Should Have.
4. Feito isso, realizamos todo o entendimento detalhado destes épicos e os quebramos em features. Aqui, já é possível algumas vezes entrar na granularidade de User Stories. Mas normalmente quebramos em features.

Concluída esta etapa aplicamos WSJF, detalhado a seguir.

3.0 – WSJF: Priorização Baseada em Valor