Anteriormente, vimos neste blogpost do Felipe Gimenes, o passo a passo de como criar um Story Mapping desde o levantamento ou criação do seu fluxo de valor até o fatiamento dos itens de trabalho identificados em entregas objetivas, as chamadas Releases. Parece que o trabalho acabou não é? Será mesmo? E se ainda assim te perguntassem: “Bonito, mas afinal, quando vocês entregam?”

Neste blogpost vou mostrar a vocês como gerar previsibilidade para o Story Mapping a partir das métricas. Bora lá?

Recapitulando o Burnup

Primeiro, vamos falar brevemente sobre o gráfico de Burnup, a métrica que iremos utilizar como ferramenta.
O Burnup permite acompanhar o progresso e o montante de trabalho concluído versus o tamanho total de um escopo de trabalho, fazendo uma projeção linear baseada no histórico de produtividade do time. Através dele, podemos ter uma noção do quão próximo ou distante estamos de atingir um objetivo, ou seja, o popular “quanto falta para terminar o projeto”.

A leitura deste gráfico é feita da seguinte forma:

• No eixo vertical temos duas representações gráficas, sendo a primeira a quantidade de novos itens inseridos no backlog do projeto/produto, representado pela área colorida (neste caso, em amarelo), e a segunda a quantidade de itens deste backlog que foram finalizadas pelo time, representado pelas barras verticais sequenciais;
• E no eixo horizontal temos uma escala de tempo para visualizar o crescimento dos valores descritos no eixo vertical (neste caso medido em semanas).

Ou seja, conseguimos aqui acompanhar tanto o crescimento do backlog semana a semana quanto o valor de throughputs acumulados que o time vem entregando.

Dados estes valores, podemos projetar três diferentes cenários:

• O Pessimista: projetar a performance futura da equipe com base no menor Throughput histórico;
• O Mais provável: considerar que a equipe terá no futuro um comportamento semelhante ao Throughput “médio” performado;
• O Otimista: considerar que a equipe performará nas próximas semanas igual ao valor de maior Throughput histórico ja registrado pelo time.

Caso queira se aprofundar um pouco mais sobre Throughput e Burnup, recomendo a leitura deste blogpost do Raphael Albino. Agora vamos unir os assuntos!

E o que o story mapping tem a ver com isso?

Uma das etapas finais do story mapping, é fatiar o backlog levantado em objetivos menores e que em um curto prazo já podem entregar valor ao usuário final ou persona cujo problema estamos tentando resolver. Segue um exemplo onde foram definidos os três primeiros objetivos e abaixo o backlog não priorizado (imagem desfocada para preservar a confidencialidade dos dados).

Dado que nós já temos as fatias de entregas mapeadas, e se ao invés de incluirmos o backlog levantado como uma única stack dentro do nosso Burnup, utilizarmos do mesmo artifício de fatiamento e criarmos as visões de entrega de cada release?
Basicamente nós temos a seguinte visão:

Cada fatia entra individualmente como uma porção de backlog isolada. Como a leitura deste gráfico é feita de baixo para cima, logo, a primeira fatia do Story Mapping (a que está no topo e representa o primeiro objetivo de entrega), virá acima do objetivo atual do time (representado pela porção azul do Burnup), e assim sucessivamente, conforme a indicação das setas.
Podemos observar que é possível obter hipóteses de data de entrega, pessimista, provável e otimista, para cada uma das fatias do nosso Burnup, esteja o time já trabalhando nelas ou não. Com isso, torna-se possível setar ou controlar expectativas com pessoas que têm interesse no projeto ou em uma entrega, tanto de forma interna (para o próprio time) como externa (ex: Um patrocinador do projeto).

Munindo o time com estas informações, a equipe será capaz de assumir estratégias melhor direcionadas de acordo com a necessidade. Ex: Negociar escopo caso seja necessário cumprir uma data de entrega específica ou alinhar estratégias de lançamento de um produto dadas as perspectivas de finalização do trabalho que está em vista.
Porém, existem alguns pontos que devemos ter atenção quando utilizamos o burnup como ferramenta de previsibilidade, vamos ver a seguir.

Premissas que impactam diretamente as estimativas/previsibilidade

• As datas de projeção consideram o tamanho atual do backlog e a vazão do time dentro de uma linearidade. À medida que estes valores avançam, estas datas também sofrerão alteração (Ex: um crescimento no backlog ou uma mudança drástica no padrão de entregas do time);
• Mantenha os valores de throughput utilizados para a projeção sempre atualizados. É sempre importante considerar a realidade do time em relação à cadência de entregas para se ter previsibilidade. Afinal, não faz muito sentido eu projetar estimativas de entrega considerando um padrão de comportamento que não condiz mais com a realidade do time, certo?
• Se o time ainda não possuir um histórico de throughput relacionado ao projeto, o ideal seria coletar esta métrica durante algumas semanas para utilizar estes dados como insumo antes de criar-se a expectativa com datas e prazos. Caso seja de fato necessário ter esta ideia de prazo para pelo menos se ter uma perspectiva do quando a entrega seria feita, pode-se utilizar do histórico de outros projetos que o time ja trabalhou. Porém, é preciso levar em consideração diversas variáveis que impactam diretamente na assertividade em utilizar estes valores passados (tais como tamanho da equipe, se a composição do time é a mesma, tecnologias utilizadas, experiências que o time tem neste tipo de projeto, etc.
• Sinalize corretamente a qual releases cada tarefa pertence. É muito importante que cada uma das tarefas do backlog esteja enquadrada dentro do objetivo ao qual ela pertence, não só para as tarefas que foram originadas no story mapping mas também para todas as demais que podem surgir ao longo do caminho devido a processos como o Refining ou task splitting;

Como as datas de projeção/previsibilidade de entrega são extremamente sensíveis, conforme vimos nas premissas acima, minha dica final é fuja de utilizar estas datas como prazos determinantes e utilize como probabilidades de cenários (Ex: Se tudo der certo e nada diferente do habitual acontecer, temos boas chances de entregar por volta do dia DD/MM, mas é esperado que seja perto de DD/MM (de acordo com as linhas de projeção).
Desta forma, caso algo inesperado ou emergencial aconteça, o time consegue responder de forma adequada sem comprometer fortemente as expectativas geradas sobre as entregas.

Resumindo

Utilizando estas duas ferramentas em conjunto, conseguimos ter de forma mais concreta um cenário de previsibilidade que pode ajudar o time a setar expectativas com quaisquer stakeholders que estejam dependentes destas entregas ou possuem algum tipo de interesse sobre elas. Além disso, as próprias pessoas do time terão uma maior sensação de progresso em relação aos objetivos que elas mesmas mapearam e isso os ajudará a tomar melhores decisões ao longo do tempo.
Esta é apenas uma das formas de obtermos melhor previsibilidade das entregas do time. Existem diversas outras ferramentas que podem ajudar também, como o Reality Check 🙂

O que achou desta abordagem? Deixe aqui seu comentário sobre como você trata previsibilidade de entregas dentro do seu time ou nos escreva enviando para contagil@plataformatec.com.br. Caso queira começar a utilizar o Burnup, nós disponibilizamos uma versão gratuitamente através da Planilha de métricas da Plataformatec. 🙂

Abraços e até a próxima!