Desenvolver uma visão que possibilite enxergar e compreender o todo por meio da análise das partes que o formam é um grande desafio ao lidar com ambientes de incerteza.

Uma das formas de compreender e analisar o sistema de trabalho de uma equipe ágil se dá através das métricas de processo (há uma coletânea de conteúdo bacana sobre o assunto aqui no blog da Ptec).

Entender o fluxo a partir dos dados é uma maneira pragmática de incorporar uma filosofia de melhoria contínua, sem mudanças abruptas e caóticas e de forma transparente para todos que estão envolvidos no contexto (equipe, stakeholders, área de produtos, gestores, etc.). Parafraseando a comunidade Kanban, medir é uma ferramenta que ajudará a evoluir e não revolucionar um processo já existente.

Pessoalmente, eu gosto de quantificar o processo quando estou mapeando a realidade de uma equipe, pois exponho fatos (dados) para discussão e análise. Na minha experiência com equipes de desenvolvimento de software, venho percebendo que ter esse tipo de conduta ajuda a diminuir uma carga subjetiva que possa existir na equipe e é um jeito de confrontar crenças como “não precisamos melhorar”, “não temos problemas no processo” e “atuamos de forma colaborativa”.

No blog post de hoje, compartilharei uma coleção de métricas que ajudarão você a diagnosticar a saúde do proceso de uma equipe ágil.

Premissas

Antes de qualquer coisa, preciso deixar algumas ressalvas quanto ao uso das métricas.

Métricas devem ser usadas para evoluir o processo e não para gerar cobranças e comparações destrutivas.

Não caia na tentação de comparar equipes e medir o desempenho de um indivíduo. Se você ou a empresa no qual trabalha estão interessados em premiar resultados individuais, formulem um método que proponha avaliar o desempenho da pessoa a partir da opinião dos gestores, pares e clientes que tenham interagido com o resultado do trabalho do indivíduo. No caso de recompensar individualmente as equipes por seu resultado, fuja de métricas que não tenham relação direta com o resultado do negócio (ex: do que adianta a equipe ter entregue um número de funcionalidades no semestre sendo que o produto não teve um aumento de receita?).

Compartilho essa premissa para que você e sua equipe não se comportem de acordo como estão sendo medidos. Afinal, já diria Goldratt: “diga-me como serei avaliado e eu lhe direi como me comporto”.

Números sem contextos são perigosos.

Qualquer análise feita sem compreender as variáveis que compõe um cenário se torna superficial, enviesada e pobre. Se alguém lhe contar que o número de funcionalidades entregues em uma equipe é de 10 itens por semana, é possível concluir algo? Tal métrica é boa ou ruim? Qual o significado de entregue para aquela equipe? É software em produção ou entrega em um ambiente de homologação? Bem, pelos questionamentos anteriores é possível concluir que um número solto nada mais é do que um símbolo privado de qualquer significado.

Procure tendências e fuja da precisão. Dada a complexidade que é criar um produto de software, não busque ser determinístico em um mundo que é receptivo por natureza a uma realidade probabilística.

A lógica por trás da última premissa é: vivemos em um ambiente onde há risco, isto é, existe a probabilidade de insucesso em função de algum acontecimento incerto, cuja ocorrência não depende exclusivamente da vontade da equipe. Portanto, é pouco provável que a equipe saiba ao certo o prazo de entrega de uma demanda ou projeto. Ao invés de nos enganarmos com prazos que ratificam que as entregas acontecerão sempre na mesma data e na mesma forma, passemos a analisar o histórico de dados da equipe para projetarmos a chance de entregarmos algo.

As premissas compartilhadas ajudarão você a utilizar as métricas de forma efetiva. O Lucas Colucci escreveu um texto muito importante que apresenta alguns erros comuns ao utilizar métricas de processo.

Diagnóstico do processo

Dada as premissas compartilhadas acima, vamos ao que de fato interessa. As métricas listadas a seguir servirão para você mapear como está a saúde do processo de uma equipe. Como agilista, considero que as visualizações abaixo compõem o painel de análise (cockpit) de um fluxo de trabalho e devem estar disponíveis para que as equipes utilizem como material para a promoção de melhorias no processo (ex: uso das métricas em retrospectivas, análise do processo em reuniões diárias, etc.).

Trabalho em progresso

Monitorar o trabalho em progresso ajudará a equipe a ter consciência de qual é o montante de trabalho que o processo tem suportado ao longo do tempo. Gosto desse tipo de visualização, pois ela demonstra, por exemplo, se as equipes estão respeitado uma política de limite do trabalho em progresso.

No exemplo acima, temos uma situação onde a equipe estava com a quantidade de itens em progresso próximo de 10 por semana até que em determinado momento houve uma reconfiguração no número de pessoas, o que fez com que a quantidade de trabalho em progresso diminuísse. Um insight aqui é que essa visualização apresenta um histórico interessante da equipe, ajudando a identificar momentos em que ocorreram mudanças na estrutura do time, mudanças de rumo (as famosas pivotadas), impedimentos, etc.

Visando estabilizar o processo a partir da capacidade produtiva, é importante que o número de itens em WIP não entre em uma tendência de crescimento. Caso isso esteja acontecendo, é bem provável que a equipe precise de otimizações para que o WIP passe a diminuir. Como agilista, monitorar o WIP apoiará você a reverberar o seguinte mantra com a equipe: “vamos parar de começar e comecemos a terminar”.

Uma outra análise de WIP que tenho começando a fazer diz respeito ao tempo de vida dos itens que estão em WIP dentro de uma determinada semana. Essencialmente, a visualização leva em consideração os itens que estão em progresso naquela semana e contabiliza há quanto tempo eles se encontram dentro do fluxo de trabalho. Para facilitar a leitura do gráfico, faço um agrupamento por categoria onde considero as seguintes faixas: (1) 1 dia em WIP; (2) até uma semana em WIP; (3) de 1 à 2 semanas em WIP; (4) de 2 à 3 semanas em WIP; (5) de 3 à 4 semanas em WIP; (6) acima de 4 semanas em WIP.

Ainda sobre a estrutura da visualização, para as semanas que já passaram, é feita a contabilização e a classificação dos itens que estão em WIP no final do período. Já para a semana corrente, é realizada uma análise dos itens que estão em WIP no momento.

Aplicando em um exemplo, é possível perceber que, na quinta semana de monitoramento do tempo de vida do WIP da equipe acima, existiam dois itens que estavam há mais de um mês dentro do fluxo. Se a equipe, ao acompanhar sistematicamente seu fluxo de trabalho, perceber que as categorias de mais idade estão crescendo é bem provável que um gargalo esteja se formando em alguma etapa do processo e uma intervenção será necessária.

Tenha em mente que WIP representa esforço e energia que ainda não foram validados e quanto mais tempo a equipe passar carregando-o, menos feedback será recebido, mais lento será o processo de validação das hipóteses por detrás das iniciativas que originaram o trabalho e maior será o risco da empresa estar perdendo uma oportunidade de mercado.

Caso queira saber mais sobre WIP, não deixe de ler post Um estudo mais profundo sobre Limites WIP

Tempo de entrega

O lead time é uma métrica importante para que as equipes desenvolvam a capacidade de entender quanto tempo elas têm levado para concluir um item de trabalho. Além disso, equipes que desenvolvem a habilidade de analisar tal métrica conseguem identificar situações que geraram variabilidade no processo (ex: problemas em ambientes, saída de membros da equipe, falta de critérios de aceite claros nas demandas).

A primeira visualização que recomendo estar disponível para a equipe é o gráfico de dispersão do lead time. Ele oferecerá uma ideia se o tempo para que os itens sejam entregues está diminuindo ou não ao longo do tempo.

Conforme ilustrado no gráfico acima, gosto de combinar nessa visualização as seguintes informações: itens finalizados (representados no gráfico pelos pontos em azul) e em progresso (representados no gráfico pelos pontos em vermelho); a média móvel que leva em consideração os últimos 5 itens entregues (esse é um parâmetro totalmente arbitrário); e as informações de percentil 50 (mediana), percentil 75 e percentil 95.

Tais medidas de referência são úteis, pois, a partir do exemplo, trazem a tona constatações como:

• A média móvel tem variado ao longo do tempo.
• Baseado no histórico de itens concluídos, 50% deles foram finalizados em até 10 dias, 75% levaram até 16 dias para serem finalizados e 95% foram concluídos em até 34 dias.

Além disso, o gráfico de dispersão pode gerar respostas para questionamentos como:

• O que a equipe está fazendo para tratar os itens em progresso que estão se tornando casos extremos de lead time?
• O que é possível melhorar no processo para que haja uma diminuição no lead time?

Outra visualização benéfica para entender o tempo de entrega é o gráfico de histograma, pois, ao considerar cada lead time como uma categoria, o mesmo apresenta os dados de uma maneira mais concisa e que permite extrair informação sobre o comportamento da distribuição.

Conforme ilustrado no exemplo acima, o histograma permite que a equipe tenha resposta para indagações do tipo:

• Qual tem sido o lead time mais frequente?
• Os casos extremos de lead time são muito frequentes?
• Qual o formato da distribuição? Há uma concentração do lead time a esquerda ou a direita da distribuição? Existe mais do que uma moda? Geralmente distribuições bimodais representam fluxos de equipes que lidam com mais de um tipo de demanda em seu processo, pois apresentam concentrações semelhantes em diferentes categorias de lead time.

Ritmo das entregas

Medir e visualizar o throughput (vazão) é importante para que a equipe compreenda qual tem sido o montante de trabalho entregue em um período de tempo (exemplo: semana, quinzena, mês), bem como para que ela identifique se há a criação de uma tendência de aumento no número de entregas. Ao perceber que o throughput está em queda, a equipe pode buscar entender quais fatores estão afetando a vazão do processo.

Recomendo sempre que possível a quebra da visualização do throughput por tipo de demanda. Dessa forma, fica explícito para todos se a equipe está conseguindo:

• Equilibrar o número de entregas de valor (ex: funcionalidades) com demandas de falha (ex: bugs).
• Lidar com o urgente de forma sustentável. Volta e meia me deparo com equipes que classificam todo tipo de demanda que entra no fluxo de trabalho como urgente e atuam em cima delas, deixando de lado itens que serão importantes para o negócio no médio prazo.

No exemplo acima a equipe conseguiu equilibrar em grande parte das semanas entregas de história do usuário com correções de bug. Na semanas sinalizadas com as setas em vermelho, a equipe precisou atuar e entregar problemas críticos que estavam afetando a operação da empresa e por isso entregou apenas correções de bugs.

Análise da taxa de entrada e saída do fluxo

Além do uso do gráfico de CFD (escrevi um blog post completo para falar sobre essa visualização), gostaria de apresentar uma análise que não tenho visto muitos agilistas fazerem: relação entre as taxas de entrada e saída do fluxo de trabalho. Basicamente essa visualização compara a quantidade de itens que a equipe se comprometeu entregar com o número de itens entregues ao longo do tempo.

O que esse tipo de visualização pode trazer de insight? Vamos analisar um exemplo.

Baseado na imagem acima é possível fazer algumas deduções:

• Das 27 semanas analisadas, 10 delas tiveram uma taxa de entrada (itens que a equipe se comprometeu) maior do que a quantidade de itens entregues.
• Na semana 17 a equipe teve um pico de itens comprometidos para serem entregues. Isso ocorreu pelo fato da pessoa que era PO da equipe estar em vias de entrar de férias. Falando em estoques, sugiro a leitura do blog post do Guilherme Fré sobre o assunto.

Analisar a taxa de entrada e saída do processo apoiará a equipe no entendimento de se o ritmo de entrega está acompanhando a quantidade de itens comprometidos. Tenho visto equipes assumindo mais do que sua real capacidade. Tal tipo de comportamento gera desconfiança dos stakeholders pelo fato da equipe entregar menos do que é pedido e frustação da equipe por nunca conseguir entregar “tudo”.

Em um sistema perfeitamente estável, a taxa de entrada e saída deveria ser a mesma. Se você e sua equipe conseguirem desenvolver um processo onde na maior parte das semanas as taxas forem equivalentes (ex: para cada 4 semanas, 3 tiveram as taxas de entrada e saída iguais), isso demonstrará maturidade do fluxo de trabalho e representará um contexto altamente previsível.

Conclusão

Incorporar uma cultura que traga dados para sua equipe fará com que você monitore um processo que possui uma natureza essencialmente complexa (software) trazendo visibilidade do progresso para quaisquer interessados no que está sendo construído ou mantido.

Além disso, propor melhorias e evoluções baseadas em dados é um excelente caminho para a remoção de análises subjetivas e, até certo ponto, vazias. No fundo, espero que com esse blog post você, agilista, estimule que as pessoas utilizem menos o recurso do feeling quando estiverem analisando o comportamento do fluxo de trabalho de uma equipe.

Se você busca um material avançado em métricas, recomendo o livro que escrevi sobre o assunto Métricas Ágeis – Obtenha melhores resultados em sua equipe. Aproveite para dar uma olhada nas revisões feitas por quem já leu 

E você? Quais métricas tem utilizado para acompanhar a saúde do processo? Deixe suas experiências nos comentários abaixo!

jQuery( document ).ready(function() {
new RDStationForms(‘nurturing-agile-blog-post-guia-de-um-agilista-analisando-saude-do-processo-1d8b67d69ba6b19eaca3-html’, ‘UA-8268430-1’).createForm();
});

The post Guia de um Agilista: Analisando a saúde do Processo first appeared on Plataformatec Blog.

É comum no ambiente de equipes que trabalham com a construção ou evolução de produtos a necessidade da definição de objetivos, a projeção de resultados esperados e o planejamento de entregas. Se você convive com tais desafios, confira a seguir uma dinâmica na qual obtive ótimos resultados no processo de concepção de OKRs.

O que é OKR e para o que serve

Bom, antes de escrever sobre o assunto, vale a pena definir o termo OKR.

Segundo definição do pessoal da Lean Performance, OKR — do inglês Objectives and Key Results –, utilizado no Silicon Valley por empresas como Google, Facebook, Linkedin, Intel etc, é um framework para definir metas. Trata-se de um sistema simples para criar alinhamento e engajamento em torno de metas mensuráveis e dinâmicas, tipicamente definidas trimestralmente.

OKRs são uma ótima forma das organizações criarem e comunicarem objetivos e resultados. Seu maior propósito é promover conexão entre os objetivos da empresa, do time e dos indivíduos a partir de resultados mensuráveis, fazendo com que todos se movam na mesma direção.

Em resumo, utilizar OKRs adequadamente auxilia no aumento do alinhamento e do engajamento entre as pessoas, e torna o processo de planejamento estratégico mais ágil, com maior cadência de revisão, adaptação e participação de toda a equipe.

O alinhamento e engajamento entre as pessoas aumentam, pois o time passa a fazer parte do direcionamento do produto, gerando maior senso de pertencimento em cada um.

Certa vez, no projeto de um dos nossos clientes, após a equipe definir os OKRs, fui informado pelo QA que o bug que estava ocorrendo no ambiente de produção iria impactar diretamente um dos OKRs, se não fosse corrigido imediatamente. Esse fato me deixou realmente surpreso, pois jamais veria uma ação assim se não compartilhassemos a responsabilidade com todo o time.

Com a aplicação de OKRs, ganhamos mais uma ferramenta na priorização do backlog e, mais importante, temos o escopo direcionado para um objetivo comum.

Ao aplicar dinâmicas de OKRs, espera-se que a empresa, equipe ou pessoa tenha em mãos:

1. Objetivos: Possuem, por essência, característica qualitativa, inspiracional, com prazo definido e apontem para metas, ou seja, dizem para onde se deve ir.
2. Key results: Quantificam toda a ideia inspiracional. Devem ser atingíveis, mensuráveis e realistas. Em outras palavras, indicam como será possível atingir os objetivos.

Beleza Raphael, entendi os conceitos e percebi que isso pode ser útil, mas você pode dar um exemplo?

Objetivo: Aumentar o número de clientes a partir de melhor experiência de uso do aplicativo.

Período: Primeiro trimestre de 2017.

Key results:

• Aumentar a taxa de conversão mobile global de 5% (último trimestre de 2016) para 10%.
• Aumentar o volume de sessões entrantes de 161 mil (último trimestre de 2016) para 240 mil.
• Vender 10.000 mil licenças básicas.
• Vender 500 licenças premium.

De onde vamos tirar esses indicadores?

Aqui vai um ponto importante: para definir bons key results, que sejam mensuráveis e reflitam a situação real, é essencial que a organização seja orientada a dados e indicadores. Basicamente, a empresa deve possuir métricas de produto que assegurem uma tomada de decisão assertiva, dando a real noção de direção e esforço; e não somente baseada em intuições e experiências. Esses dados ajudam a definir as estratégias do próximo período com maior segurança e a otimizar os recursos empreendidos.

Os dados devem direcionar as seguintes questões:

• Quais desafios temos à frente? Quais indicadores estão ruins? O que devemos fazer para melhorar tal indicador? Ex: Diminuir o churn, aumentar prospects e leads, melhorar os processos operacionais etc.
• Qual frente do produto precisamos melhorar para atingir o objetivo X da organização?
• Quais riscos esses dados evidenciam e onde devemos manter a atenção?

Feita essa introdução, vamos para a dinâmica de definição dos OKRs para que você possa aplicá-la e aprimorá-la.

Parte 1 – Compreendendo o negócio

O primeiro tópico a ser discutido diz respeito a revisão ou criação do modelo de negócios do produto.

Baseado nas personas, a equipe poderá analisar os canais, formatos de relacionamento com o cliente, fontes de receita, atividades chave, recursos chave, parceiros chave e estrutura de custo.

Para levantar tais informações, sugiro que você leve as seguintes perguntas:

• Personas: qual o perfil de clientes que utilizam o produto?
• Canais: como os clientes chegam ao produto, geralmente?
• Formatos de relacionamento: como ocorre o relacionamento dos usuários com o produto atualmente?
• Fontes de receita: quais são as fontes de receita atuais?
• Atividades chave: quais as principais atividades que precisam ser realizadas no dia a dia da operação para que o produto possa entregar o valor que se propõe?
• Recursos chave: o que o produto possui de diferencial competitivo?
• Parceiros chave: quais parceiros ajudam a empresa a viabilizar/alavancar o produto?
• Custos: qual a estrutura necessária para tornar a operação do produto viável?

Assim, a equipe terá maior clareza sobre o estágio atual do produto. Caso o produto não possua um modelo de negócios, não deixe de desenvolver um. Uma dica de leitura para que você possa construir um é o livro Business Model Generation.

Após a revisão do modelo de negócio, o próximo passo será analisar as principais métricas do produto. Cada pessoa da equipe poderá explorar o produto a partir de:

• Informações financeiras: churn, ticket médio, custo de aquisição do cliente etc;
• Comportamento de acesso: número de acessos, taxa de saída, tempo despendido nas páginas do fluxo de venda, origem do tráfego, dispositivo utilizado para acessar o fluxo de venda etc;
• Perfil do cliente: dados demográficos, nível de serviço contratado, faixa etária etc.

A partir das métricas de produto, cada membro da equipe deverá identificar pontos de melhoria e pontos onde o produto aparenta estar bem.

Parte 2 – Definindo os OKRs

Feita a análise das métricas de negócio e do modelo de negócio, levante com a equipe os potenciais objetivos que serão trabalhados no período de tempo (exemplo: próximo trimestre).

Se você estiver facilitando a discussão, tenha em mãos as seguintes dicas antes da equipe determinar os objetivos:

• Tenha poucos objetivos (de 3 a 4). Motivo? O trimestre, por exemplo, é curto para se assumir muitos objetivos.
• Relacione os objetivos do produto com os objetivos da empresa.
• Relacione os objetivos com problemas e necessidades reais.
• Utilize as métricas de negócio para definir os objetivos.

Caso os objetivos levantados sejam complexos ou grandes, vale a pena fomentar discussões para que a equipe simplifique. O mantra que deve ser pensado aqui é: pequenos incrementos que geram valor econômico para o negócio.

Para medir os objetivos, a equipe deverá elencar quais serão os key results que serão acompanhados ao longo do período. Para que a equipe tenha um norte:

• Defina poucos key results (de 3 à 4). Motivo? Se o objetivo precisa de muitos itens para ser medido é provável que ele seja complexo demais.
• Os key results devem ser expressos através de números.
• Quais resultados garantirão que alcancemos nossos objetivos?

Parte 3 – Definindo um roadmap

Dado que os objetivos e os key results estão definidos, a equipe pode se questionar: bom, e agora, o que vamos fazer para atingir nossos OKRs?

Sugiro como última parte da dinâmica o desenvolvimento de um roadmap, a fim de identificar entregáveis macro e quando eles deverão ser entregues ao longo do período (ex: trimestre).

Técnicas de brainstorming e story mapping ajudam a ter uma ideia de cronologia e dependência entre as possíveis funcionalidades que serão construídas para alcançar os OKRs.

Antes que alguém me crucifique dizendo que não estou sendo lean, gostaria de deixar algo claro. O roadmap criado será uma referência que COM CERTEZA (repita, C-O-M C-E-R-T-E-Z-A) sofrerá alterações ao longo do tempo por conta das mudanças e experimentações que acontecerão para atingir os objetivos e key results definidos.

Conclusão

A estrutura de OKR pode ser replicada no nível empresa, equipe e, até mesmo, indivíduo. Uma dica que sempre compartilho é: comece com poucos objetivos e trace em torno de 3 à 4 key results. O motivo? Foco. Quanto mais direcionado, mensurável e acionável for a sua estrutura de OKR, maiores serão as chances de alcançar o planejamento desenvolvido.

Lembre-se que os OKRs devem ser revistos com frequência para que o time possa tê-los sempre em mente e, juntos, decidirem onde despender esforços para caminharem na direção correta.

É essencial que a empresa possua uma cultura questionadora, desapegada de ferramentas e soluções revolucionárias e tenha um ambiente que promova aprendizado com as falhas, pois certamente haverão erros no início.

A dinâmica que apresentei teve como objetivo conectar negócio, resultados atuais e futuro (OKRs + funcionalidades).

E você, como tem aplicado dinâmicas de OKR? Compartilhe os resultados e desafios.

Até próximo dilema

Algumas referências:

• Metas Ágeis com OKR
• The Art of the OKR
• OKRs
• The Basics of OKR – Google’s Secret Sauce

The post Dilemas de PO: como definir OKRs em equipes ágeis first appeared on Plataformatec Blog.

Then, suddenly, the P.O. discovers that the features D and E were developed by a competitor and that you are losing users because of that. Therefore, the P.O. decides to deprioritize story C. This is only an example of why a card might be deprioritized in the middle of its development. But now that it was deprioritized, what happens to story C?

Well, to answer that, let me make a parallel with an alcohol-based perfume company.

In the backlog column, the company has the bottle ready to be filled but no fluid yet. When the bottle starts to be filled, the card goes to “in progress”. When the bottle is totally filled, the bottle is closed and the card goes to done.

So what happens if another perfume suddenly receives a priority greater than the priority of the bottle being filled? Well, as we all know, alcohol-based fluids are volatile and, with time, they will completely evaporate, requiring them to be refilled.

The same happens with the story and its code. With time, the code that is inside the story gets obsolete and unnecessary, losing its value. What to do with the story depends on the following rationales:

• How long will the story C stay in the same stage?
  • If the story stays too long in the same stage, some part of the work may get useless, therefore, you could just remove it from the board and put it back on backlog, since some refining might be needed when this story is chosen gain.
  • If the story will stay there for a short time, you may want to leave it there and, when it can be worked on, you may still use what was already developed.
• What is the value story C will generate after being done?
  Let’s say that the return on the development of that feature is small. Is it worth to pause its development and run the risk of investing even more money on the development later? Will the return on its development be greater than the development time?

For this to be true, the following needs to happen (visualized in the chart below):

• $ spent with initial development + $ spent with rest of the development < story C $ return
  • The amount spent with rest of the development will increase with time, since the initial development starts to lose value.
• If the amount spent is greater than the return, it is better to ignore the functionality. However, this math is not as easy as it seems… You need to account for risks, increased revenue, increase the number of users of your product, etc. So be careful!

Therefore, based on those, you can possibly do four things:

• Leave it on the column and restart it when its priority arrives
  The pause will be fast and will not harm the development of the card. In this case, it is important to flag the story somehow so that the whole team can see that the story is “blocked” by the P.O. due to its prioritization.

• Take it back to the backlog, and restart it when its priority arrives
  The pause will be long and the card will need more refinement.

• Finish it first, before getting another card
  The card is almost done, and if you stop it, it will not generate value anymore.

• Cancel the card
  The card is a long way from being finished, and its value is too small to pay for the time it will be paused.

It is also important to notice that this should NOT be a common thing in your process. If it is happening too often, you may need to work on your prioritizations!

What are your thoughts on the topic? Leave your comments below

The post The user story in development was deprioritized, what now? first appeared on Plataformatec Blog.

Então, no meio do seu sprint, o P.O. descobre que as features D e E foram lançadas por um concorrente e que vocês estão perdendo usuários por isso. Pensando nisso, a P.O. decide despriorizar a história C. Isso seria apenas um exemplo de como um card pode ser despriorizado no meio do seu desenvolvimento. Mas, e agora, o que acontece com a história C?

Para responder isso, deixe-me fazer um paralelo com uma companhia de perfumes a base de álcool.

Na coluna de backlog, a companhia tem a garrafa pronta mas sem fluído algum. Quando a garrafa começa a ser enchida, o card é passado para “in progress”. Após a garrafa estar cheia, ela é lacrada e o card vai para “done”.

O que acontece então se outro perfume tem sua prioridade elevada a um nível maior do que o que está sendo abastecido? Bom, como sabemos, fluídos com base em álcool são voláteis e, com o tempo, evamporam totalmente, sendo necessário que se reabasteça o recipiente.

O mesmo acontece com uma história e seu código. Com o tempo, o código que compõe tal história se torna obsoleto e desnecessário, perdendo o valor que tinha outrora. Neste caso, o que fazer com a história despriorizada depende dos seguintes pontos:

• Quanto tempo a história C continuará no mesmo estágio?
  • Se a história permanece muito tempo no mesmo estágio, alguma parte do trabalho já feito pode se tornar desnecessário, portanto, você poderia apenas removê-la da coluna e colocá-la de volta ao backlog, já que algum refinamento pode ser necessário para que essa história seja desenvolvida novamente.
  • Se a história vai ficar por um curto período de tempo em tal coluna, você pode optar por deixá-la lá e, quando sua hora chegar, pode continuar aproveitando o que já havia sido desenvolvido.
• Qual o valor que a história C vai gerar quando pronta?
  Digamos que o retorno gerado pelo desenvolvimento de tal feature seja pequeno. Será que vale a pena pausar seu desenvolvimento e ter o risco de investir ainda mais dinheiro no seu desenvolvimento em outro momento? O retorno gerado será maior do que o tempo total de desenvolvimento gasto?

Para que isso seja verdade, o seguinte precisa acontecer (observado na imagem abaixo):

• $ gasto com o desenvolvimento inicial + $ gasto com o resto do desenvolvimento < retorno da história C
  • A quantia gasta com o resto do desenvolvimento aumentará com o tempo, já que o desenvolvimento feito anteriormente vai perdendo valor.
• Caso o retorno seja menor do que o gasto, é melhor ignorar a funcionalidade. No entanto estes cálculos não são tão simples como parecem… Você precisa levar em conta riscos, aumento na receita, aumento no número de usuários, etc… Então tenha cuidado com essa ação.

Portanto, baseado no que já foi dito, você pode ter as seguintes ações a respeito do card C:

• Mantenha-o na coluna “in progress” e recomece o trabalho quando sua prioridade for retomada
  Essa pausa será rápida e não afetará o desenvolvimento da feature. Neste caso é importante deixar visível de alguma forma no quadro que essa história está “bloqueada” por motivos de priorização.

• Ponha-o na coluna de backlog novamente, e recomece quando necessário
  A pausa será longa e o card precisará de um novo refinamento.

• Termine-o primeiro, antes de começar outra história
  O card está quase pronto e, caso você pare seu desenvolvimento, quando pronto, seu valor será menor do que o gasto no seu desenvolvimento.

• Cancele o seu desenvolvimento
  A história está muito longe de ser terminada, e seu valor final é muito pequeno para pagar o tempo que ela ficará pausada.

É importante também notar que isso NÃO deve ser algo comum em seu processo. Se coisas como essa estão acontecendo frequentemente, você pode precisar melhorar suas priorizações!

O que acha do que foi discutido aqui? Deixe seus comentários abaixo!

The post A user story em desenvolvimento foi despriorizada, e agora? first appeared on Plataformatec Blog.

• Como priorizá-las?
• Quando elas serão entregues?

Neste blog post, teremos a oportunidade de discutir algumas abordagens que poderão ajudar você a responder tais questionamentos (neste ano, falarei mais sobre o assunto aqui no blog).

Tenho observado um movimento de gestão de produtos que vem concretizando os princípios por trás do Lean Startup que diziam: construa, meça e aprenda. A partir da ótica de medir e aprender, é perceptível que gestoras e gestores de produto começam a levantar hipóteses de negócio a partir de métricas como taxa de conversão, recorrência mensal, taxa de evasão, análise da interação dos usuários nos fluxos críticos da aplicação, etc.

Voltando para a primeira pergunta que abriu o texto, nos deparamos com atributos quantitativos que nos permitem priorizar o que precisamos construir. Tal ferramental sustenta a ideia de que estamos interessados em melhorar os resultados do produto a partir de números.

Antes que alguém me crucifique, nem só baseados em números devem ser os fatores para a priorização de novas features dos produtos que trabalhamos. Caso você tenha a possibilidade de se aproximar do seu usuário para perguntá-lo o que ele deseja, você também estará aumentando a probabilidade de construir algo que traga valor para ele. Dados qualitativos podem ser coletados através de questionários online, pesquisas de campo, análises de interação a partir de protótipos, etc.

Ao priorizarmos uma funcionalidade, estamos em busca de gerarmos uma solução que traga valor para nossos usuários, clientes, acionistas e empresa. Em outras palavras, podemos dizer que estamos em busca de encontrarmos uma relação positiva na equação de valor que nada mais é do que a diferença entre o valor criado pela solução menos o preço pago por ela #maisvalorporfavor.

Quadro de abordagens quali e quantitativa

Dado que priorizamos aquilo que é mais importante para a saúde do produto e para os usuários, um segundo questionamento que por vezes fica na cabeça é: quanto tempo levaremos para entregar essa nova feature?

Partindo do pressuposto que vivemos em um contexto incerto (sim, acredite, desenvolver software não é algo determinístico), trabalhar com cenários de entrega passa a ser uma abordagem mais confiável. Ao utilizar projeções você passa a calcular ou predizer um evento futuro a partir da análise dos dados disponíveis (passado).

Para que isso seja possível, sugiro que você e a sua equipe passem a monitorar uma métrica de processo: lead time (número de dias entre o início e o fim do processo de entrega de uma história do usuário, um bug, etc.).

Em outras oportunidades tivemos a chance de discutir formas de analisar o lead time (“Looking at Lead Time in a different way” e “Why we love metrics? Learning with Lead time”), porém, gostaria de compartilhar como o percentil pode ser uma referência útil para desenhar cenários futuros a partir de referências do passado.

Se você não conhece, percentil é uma medida que divide a amostra ordenada (por ordem crescente dos dados) em 100 partes, cada uma com uma percentagem de dados aproximadamente igual. Traduzindo e relacionando com uma distribuição de lead time, é como se analisássemos o lead time das demandas que foram entregues e discutíssemos qual o percentual de chances de um determinado valor ser atingido a partir do percentil.

Em um projeto recente utilizamos a informação de percentil para projetar possíveis prazos de entrega de uma demanda de negócio que havia sido priorizada pelo Product Owner (PO) da célula em que trabalhamos.

Histograma de lead time

A equipe utilizou o histograma acima e passou a seguinte análise do cenário ao PO:

• 50% das demandas levaram até 6 dias para serem concluídas (mediana).
• 75% das demandas levaram até 12 dias para serem concluídas ou seja apenas 25% levaram mais do que tal limite para serem concluídas (percentil 75).
• 95% das demandas levaram até 18 dias para serem concluídas, o que nos leva a afirmar que apenas 5% delas levaram mais tempo do que isso para serem finalizadas (percentil 95).

A partir dos dados acima, o time demonstrou confiança de entregar a demanda entre 6 e 12 dias. Com tal informação em mãos, o PO traçou o plano de comunicação e promoção do novo recurso do produto. Se você ficou curioso em saber, a demanda foi entregue em 8 dias.

Ao utilizar tal abordagem de projeção, o time e o PO se sentiram mais confortáveis e confiantes. Caso o PO tivesse imposto para o time que a nova demanda deveria ser entregue em 3 dias, com posse das informações de percentil, o time teria insumos para dizer que seria muito difícil entregá-la pelo simples fato de que apenas 25% das demandas entregues foram concluídas no prazo determinado (percentil 25).

Fecho esse texto com algumas sugestões:

1. Crie hipóteses através de fatos que podem ser originados por dados quanti ou qualitativos.
2. Projete cenários de entrega a partir de uma referência (histórico do time).
3. Desenvolva pequenas entregas de valor, pois elas permitirão que você mude de direção mais rápido.
4. Não acredite que métrica de produto ou processo é algo burocrático, pois elas servem como uma base para você construir um futuro melhor.

E você? Como tem priorizado e projetado suas entregas? Quais métricas e abordagens tem utilizado? Compartilhe sua opinião nos comentários abaixo. Estou curioso para aprender com o seu exemplo.

Se está interessado saber mais como lidar com prazos de projetos de software não deixe de conferir nosso e-book gratuito sobre o assunto.

The post Dilemas de PO: priorizar features e projetar entregas first appeared on Plataformatec Blog.

Muitas dessas dúvidas talvez surjam por conta dos conceitos que temos desde o “lançamento” do ágil. O conceito de “história do usuário”, algo que deve ser escrito pelo usuário, indicando na visão dele, uma necessidade para o produto ou projeto. Segundo Mike Cohn argumenta em “User Stories”, uma US deve ser pequena, com descrição simples de uma funcionalidade contada a partir da perspectiva da pessoa que solicitou, geralmente um usuário ou cliente do sistema. Por conta disso nos prendemos muito ao “usuário final”, o cliente, o carinha que está na outra ponta da feature, sem levar em conta todas as outras pessoas que também utilizarão a feature (time de suporte, time de operações, os próprios devs, por exemplo).

Alguns já devem ter lido ou ouvido “User Stories devem ser INVEST”, e pra quem não leu/ouviu, é um acronimo criado por Bill Wake em seu artigo “INVEST in Good Stories, and SMART Tasks” e reproduzido também por Mike Cohn em seu livro “User stories applied”.

São livros e artigos bem interessantes, e em um TL:DR, o que ele diz é que boas user stories possuem alguns atributos desejáveis. São eles: Independent, Negotiable, Valuable, Estimable, Small e Testable. Aqui, o que gostaria de chamar atenção são para 3 itens: Valuable, Estimable e Small. Lembramos sempre do “Valor”, mas esquecemos do Estimável e Pequena. Não uma estimativa mais apurada de esforço, pontos ou dias, mas algo que possa ajudar um Product Owner, por exemplo, a priorizar um backlog sabendo de uma duração próxima que o card terá. E principalmente, pequena, de forma a ser entregue em poucos dias entregando valor mais cedo.

Nos prendemos ao contexto de valor gerado pro usuário final, mas esquecemos que o valor é relativo. Além de ser algo que deve ser benéfico para outras pessoas dentro do processo, como o time de desenvolvimento, por exemplo. No caso de um card que vai gerar uma API que poderá ser utilizada por outros times, isso não gera um valor para o projeto como um todo? User stories técnicas não são user stories? Não devem entrar no backlog? Se formos pensar somente no “card escrito pelo usuário”, uma criação de API não entraria no backlog.

Então, vamos pensar no seguinte caso: o time X está trabalhando num projeto novo, o lançamento de um e-commerce e precisa desenvolver uma feature que deverá receber um pagamento via cartão de crédito, e após confirmado o pagamento envie por e-mail um documento em pdf listando os itens da compra realizada. Algo como “Eu como cliente gostaria de usar meu cartão para pagar a conta, e ao final quero receber no meu e-mail um pdf listando todos os itens comprados.”. Se formos pensar nesse card, o “valor” geral só será entregue quando o pdf chegar no e-mail do cliente, certo?

Essa US por si só, teria um tamanho considerável, levando em conta que: será necessária uma integração com algum gateway de pagamento, para processar a compra no cartão de crédito, uma API de mensagens que faça a rotina de disparos de e-mail, e uma API geradora de docs capaz de gerar o arquivo PDF que o cliente espera. E também é provável que uma PoC, caso o time não tenha mexido com gateways de pagamento antes. Se formos pensar no tamanho dessa user story, ela poderia levar semanas para ser desenvolvida por completo, se considerarmos o “valor” esperado pelo cliente, o PDF no e-mail, dessa forma não se encaixaria no Estimable e nem no Small. Mas uma API de envio de mensagens pode ser usada pelo time de marketing, por exemplo. O gateway de pagamento também já pode ser utilizado por outros times. Da mesma maneira o gerador de PDF já tem valor para outras equipes dentro do projeto. Além de que uma PoC também serve para validar uma hipótese, nos ajudando a mudar de rumo mais rápido, caso o conceito não seja provado. O que também, se formos pensar, é valor.

Dessa forma, esse “épico”, poderia ser quebrado como descrito acima, criando cerca de 4 US, que também geram valor sozinhas. Valor que provavelmente não será entregue somente ao cliente final, mas sim aos times de operações, marketing e suporte. Pensar no cliente externo é muito bom, mas devemos também pensar no cliente interno, aqueles envolvidos que quase sempre são esquecidos.

O conceito de valor é interpretativo demais, além de ser volátil e perecível. Tendo isso em vista, devemos ter bastante cuidado ao deixar de quebrar uma user story por achar que ela não está gerando o devido benefício, é importante lembrar que outras pessoas dentro do fluxo podem se beneficiar de um card quebrado. Dessa forma, se levamos semanas para entrega de uma user story, estamos depreciando o que poderia ter sido entregue, por conta da volatilidade. Fatiar cards, entregando histórias mais rápido auxilia numa geração de valor acelerada com risco reduzido da solução perecer.

E você? Como lida quando o assunto é a quebra de user stories dentro do seu time? Deixe sua opinião aí nos comentários

The post User Stories. Quebrar ou não quebrar? Eis a questão. first appeared on Plataformatec Blog.