Gerenciando Product Backlog usando o Visual Studio Online (TFS)

Quando começamos a estudar o Scrum Guide logo nos deparamos com o artefato Product Backlog. O framework prescreve que o Product Owner deve manter este artefato com todos os itens necessários ao produto/projeto a ser desenvolvido, de maneira priorizada, atualizada e visível.

No entanto, algo que o framework não prescreve é como fazer isso e a ideia do post de hoje é justamente essa, mostrar uma ideia de como organizar o seu Product Backlog usando a ferramenta Visual Studio Online, o antigo Team Foundation Server da Microsoft (TFS), em sua versão SaaS. Não vou falar aqui de priorização de backlog, coisa que já falei em outros posts, mas de como usar esta ferramenta web para fazê-lo e explicando alguns conceitos importantes que podem ser aplicados independente da ferramenta que você venha a utilizar.

Visual Studio Online

Em idos de 2008 a empresa que eu trabalhava à época, RedeHost, adquiriu licença para instalarmos em um servidor nosso o Team Foundation Server, uma suíte para gerenciamento do ciclo de vida de aplicações (ALM – Application Lifecycle Management). Nela podíamos gerenciar desde as tarefas de um projeto, o versionamento de seu código, automatizar o seu build, issue tracker, etc.

Em 2010 a Microsoft lançou o preview do TFS na nuvem, em versão SaaS, onde era possível ter acesso à mesma suíte sem necessitar de um servidor local e sem se preocupar com a escala do SQL Server, que era um requisito que incomodava bastante nosso pessoal de infra. De lá pra cá a ferramenta web não mudou na minha opinião e, embora não seja uma ferramenta perfeita, é muito útil para gerenciar todo tipo de projeto, independente da tecnologia utilizada, uma vez que oferece suporte a versionamento com Git, diversos plugins, uma API rica e muito mais.

Note que mesmo que você não tenha interesse algum nestas features de Integração Contínua (CI – Continuous Integration), você ainda pode usar a ferramenta para Task Management.

Para poder prosseguir neste tutorial, crie uma conta gratuita em visualstudio.com definindo uma URL para você. A minha é luiztools.visualstudio.com e tenho essa conta há muitos anos, desde a época do preview. Enquanto você tiver até 5 usuários cadastrados na sua conta, você não terá de pagar nada à Microsoft, o que é excelente para pequenos times de desenvolvimento.

Criando um novo projeto

Na tela inicial da ferramenta você tem um botão New Project no canto direito. Use ele e defina um nome para o projeto. Se você tem apenas um time que toca diversos projetos, pode ser interessante colocar o nome do time aqui, ao invés do nome do projeto atual deles, para fins de histórico.

Tela Inicial - New Project
Tela Inicial – New Project

Outras opções na criação do projeto incluem a tecnologia de versionamento (que eu deixo para você decidir) e o template de Work Items dentre os possíveis:

  • CMM: fundamentado no CMMI;
  • Agile: fundamentado no antigo MSF for Agile da Microsoft;
  • Scrum: fundamentado no Scrum;

Usaremos este último neste tutorial e enquanto o primeiro eu nunca usei, os dois últimos são praticamente idênticos, mudando alguns estados e a nomenclatura de alguns Work Items (User Stories do Agile viram Product Backlog Items no Scrum, por exemplo).

New Project - Scrum
New Project – Scrum

Uma vez com o projeto criado, acesse o menu superior Work > Backlogs. É aqui que concentramos os nossos esforços neste artigo.

Organizando o Product Backlog

Nesta área nós temos acesso a um modelo de gerenciamento de backlog prescrito pela ferramenta, uma vez que o framework Scrum não toma partido do método A ou B de gerenciamento de backlog.

Backlog
Backlog

Existem diversos níveis de backlog que auxiliam o Product Owner (principalmente) a se organizar. Para ver todos os níveis, use o pequeno ícone de Settings na extrema direita da tela (uma engrenagem preta), logo acima das colunas do backlog. Dentro das configurações, na aba Backlogs, marque as três opções: Epics, Features e Product Backlog Items.

Settings - Backlog
Settings – Backlog

Após salvar, a tela deve se atualizar e você vai ver na esquerda três níveis de Backlog: Epics, Features e Product Backlog Items, à saber:

  • Epics: épicos são histórias de usuário muito grandes e pouco detalhadas, geralmente levando várias sprints para ser concluído (pense na grandeza de meses de trabalho). Você pode criar épicos pensando em marcos/milestones/grandes versões do seu produto/projeto, como “MVP do Produto X” ou como grandes entregas do seu time, como “Entrega de Março”. Ou ainda falando de um módulo específico, que seja muito grande.
  • Features: funcionalidades são incrementos de software dentro de um épico, simbolizando partes coerentes do produto que geram valor ao usuário de uma maneira completa. Dentro de um épico como “MVP do Produto X”, cada funcionalidade que não deve faltar ao MVP é uma feature dentro do épico. O mesmo vale para o épico “Entrega de Março”, onde cada feature é um dos pedaços desta entrega.
  • Product Backlog Items: os famosos itens de backlog do produto são citados no Scrum Guide como sendo a unidade de trabalho do Product Backlog. Um PBI gera valor ao usuário por si só e entregar um ou mais deles pronto (DONE) atinge ao grau máximo de sucesso de uma sprint, o chamando “incremento de software potencialmente entregável”. Embora o Scrum não prescreva uma fórmula para escrever esses itens, o mais comum é que se use o formato de User Stories aqui.

O formato recomendado de escrita é partir do Work Item Type menos granular (Epic) até o mais granular (Product Backlog Item), usando o próprio recurso de “Add Feature”que fica à disposição à esquerda do Epic e “Add Product Backlog Item” que fica à esquerda das Features, sempre com um ícone de adição (+). Sendo assim, acesse o nível Epic do seu Product Backlog e comece criando os seus épicos com apenas títulos. Mais tarde você pode adicionar mais detalhes a cada um deles (mas não muito, eles são apenas visões) clicando no título dos mesmos.

Backlog Preenchido
Backlog Preenchido

Após adicionar os seus épicos, adicione features dentro de cada um deles, de acordo com o que você sabe hoje sobre os épicos. Faça isso na mesma visão organizacional de Epics, para ir vendo os desdobramentos e hierarquia dos mesmos. Para este exercício, pegue um projeto real do seu time ou então um problema fictício como um cadastro de cliente. O épico seria fazer a v1 do cadastro, sendo que as features poderiam ser “Adicionar novo cliente”, “Excluir cliente”, etc.

Conforme você for adicionando as features dentro do épico você já pode ir quebrando seus Product Backlog Items (PBIs). Se você atendeu à minha sugestão de usar User Stories, pense em todos as histórias de usuário que puder lembrar para cada uma das features. Algumas features simples talvez tenham apenas uma história, enquanto outras mais complicadas podem ter várias. Não esqueça de, além de escrever o título e descrição da história (usando o formato padrão da User Story), escreva também os critérios de aceite no campo adequado (Acceptance Criteria).

Product Backlog Item
Product Backlog Item

É importante ter em mente que o Product Owner tem total liberdade neste momento. Crie, edite e exclua seus Work Items livremente. É comum escrevermos algumas histórias que mais tarde descobrimos serem épicos. É comum épicos serem quebrados em mais épicos para que o sistema não vire um mero waterfall-iterativo. Questões relacionadas a prioridades de itens podem ser feitas usando o campo Priority ou a própria ordenação visual (drag-n-drop com o mouse). Embora o time tenha acesso ao Product Backlog como um todo, não é a partir dele que eles se orientarão no dia-a-dia, como falarei mais adiante.

Organizando as sprints

A visão de backlog que usamos até o momento são de foco do Product Owner. O Time de Desenvolvimento trabalha usando a visão da sprint atual (current sprint) dentro do Visual Studio Online. A visão das sprints fica à esquerda da tela.

Sprints
Sprints

Durante a Sprint Planning o Product Owner explica quais são as prioridades do Product Backlog. Sobre cada história prioritária, o time deve detalhar quais as tarefas serão necessárias para que seja possível estimar o esforço (campo Effort) de entrega daquele Product Backlog Item.

Uma técnica muito comum utilizada para estas estimativas é a de Planning Poker, já citada aqui no blog. Caso o Time de Desenvolvimento julgue útil, eles podem “quebrar” os Product Backlog Items em Tasks dentro da própria ferramenta usando o botão de + (Add Task) à esquerda do PBI, na mesma visão que o Product Owner usa para gerenciar o backlog.

Quebrando Tasks
Quebrando Tasks

Existe um campo Work Remaining dentro das Tasks que permite adicionar a estimativa de tempo para realização de cada tarefa. Se você optar por quebrar e/ou estimar as tarefas é uma decisão do time, mas essa atividade é auxiliar para descobrir o esforço da história. Entende-se que somente a entrega completa da história agrega valor ao cliente e consequentemente nos permite dar uma sprint como bem sucedida.

Após descobrir o esforço de cada um dos PBIs prioritários do P.O., o time decide qual o volume de PBIs que cabem na sprint usando o somatório de seus campos Effort. Se esse time já rodou sprints anteriores usando a mecânica de pontos eles já devem ter algum histórico de velocidade. Caso contrário terão de chutar mesmo, posteriormente analisando na Sprint Retrospective o quão próximo estavam da realidade.

Uma vez definido o escopo da próxima sprint, cada uma das Tasks e PBIs que farão parte da mesma devem ter seu campo Iteration ajustado para a sprint correta, como mostra a imagem abaixo.

Iteration - Sprint 1
Iteration – Sprint 1

O Time de Desenvolvimento irá trabalhar somente olhando o backlog da sprint que, via de regra, não deve ser mudado durante o desenvolvimento da mesma. Na aba Board o time tem um Kanban virtual que apesar de não ser tão bom de usar quanto o Trello, é bem útil e completamente personalizável, o que pode ser assunto para outro post.

Kanban Virtual
Kanban Virtual

Boas Práticas

Algumas boas práticas para quem está começando a usar o Visual Studio Online agora e até mesmo está começando com Scrum:

  • Como Product Owner, refine o seu backlog quase que diariamente, detalhando as histórias mais importantes, consultando o time sobre o impacto de cada uma delas, consultando os stakeholders, analisando o mercado, etc. O seu backlog sempre deve estar atualizado, priorizado e visível quando uma Sprint Planning for começar.
  • Cada história pode estar associada a um membro do time (campo Assigned To). Converse com seu time para que ninguém associe mais de uma história a si mesmo para evitar problemas.
  • Como Product Owner, use os três níveis de backlog, isso ajuda a deixar tudo mais organizado e ao time entender para onde o projeto está caminhando.
  • Priorize visualmente o seu backlog, deixando o que é mais prioritário no topo. Apesar de existir um campo Priority, ele é facilmente negligenciado por não ser muito visual.
  • Use o padrão de User Stories em seus PBIs para focar na entrega de valor para o usuário final e facilitar o entendimento dos requisitos por parte do Time de Desenvolvimento.
  • Estime em Story Points as suas histórias e não em horas. Isso tem uma série de benefícios mas principalmente descola alguns conceitos de chão de fábrica como produtividade em horas.
  • use Tags (tem um campo pra isso) nos seus PBIs para facilitar consultas, relatórios e dashboards mais tarde (aba Queries e Dashboards). Use a imaginação, tags podem ser qualquer coisa.
  • não se preocupe em usar tudo que a ferramenta oferece, aprenda o básico que faz sentido pra você e depois vá usando o restante conforme for necessitando. Uso o TFS desde 2008 e até hoje tem coisas lá que nunca precisei.

Espero que tenham gostado do post e até a próxima!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Falhas comuns no refinamento de Product Backlog

Dentre as tarefas principais do papel de Product Owner, dentro do Scrum, está o refinamento do product backlog. O Product Backlog, ou Backlog de Produto, é o artefato ágil para gerenciar os requisitos de um determinado produto. Este artefato é de domínio exclusivo do Product Owner, que refina-o constantemente para que os itens mantenham-se priorizados (usando diversas técnicas), detalhados e que façam sentido com a estratégia de mercado em cima deste produto.

Imagine que quando um novo produto está sendo criado temos uma vaga ideia do que queremos que ele se torne. Dentre tudo o que gostaríamos de ter no produto (o roadmap), o Product Owner deve priorizar o que é mais urgente, trará maior valor aos clientes ou trará o ROI mais rapidamente. Estes itens mais prioritários são então detalhados (em User Stories, por exemplo) para que sejam entregues ao time de desenvolvimento trabalhar durante a próxima iteração. Enquanto o time trabalha no desenvolvimento destes itens (o Sprint Backlog), o P.O. trabalha no refinamento dos itens da sprint seguinte, para que tenhamos itens priorizados e detalhados para a Sprint Planning seguinte.

Parte desse processo de refinamento, limitado em até 10% da capacidade de trabalho do time de desenvolvimento, pode ser compartilhado com o time de desenvolvimento, em sessões de Product Backlog Refinement, também chamadas de Grooming Sessions. Nestas sessões, o Product Owner faz uma prévia do que ele planeja para a Sprint Planning seguinte, o time já faz questionamentos, já agenda spikes e/ou POCs e já dá um overview de riscos e preocupações que eles possuem em cima do que está sendo planejado.

Futuramente, usa-se o feedback recebido nas Sprint Reviews e do próprio mercado (quando as primeiras versões do produto estão em produção) para ajudar neste processo de refinamento, criando um ciclo virtuoso de melhoria contínua.

Até aí tudo bem, mas o que pode dar errado no processo de refinamento do Product Backlog?

Muitas coisas!

Priorização e refinamento externo

Quem prioriza o Product Backlog é o PO. Ponto. Qualquer outra opinião ou feedback externo é bem vindo, mas a decisão final das prioridades de requisitos a serem entregues pro time de desenvolver é do PO. Obviamente que o mesmo deve estar alinhado com a estratégia da empresa para não criar um produto que não ajude a organização a atingir a sua visão, mas jamais o PO deve ser alguém que “apenas” repassa as prioridades da empresa para o time de desenvolvimento. Tire esse poder do Product Owner e teremos um Waterfall 2.0.

Outra falha é muitas vezes o P.O. copiar-e-colar os itens de backlog de algum documento dos stakeholders. A construção do product backlog é um trabalho criativo, iterativo e incremental. Não é uma conversão de um modelo tradicional para um modelo ágil para que o time se sinta melhor dizendo que trabalha ágil.

Product Backlog Completo

Jamais o P.O. deve querer refinar completamente o Product Backlog de uma vez só, no início do projeto. Se o seu escopo é fechado e o seu produto final já está delimitado, qual o sentido de rodar Scrum ou qualquer outro método ágil? Qual a chance de você estar certo hoje sobre as features que serão necessárias no seu produto daqui a 6 meses? Onde entra a inovação neste processo?

O refinamento do Product Backlog deve ser iterativo e incremental, assim como o Scrum e o Lean Startup pregam. Mantenha um estoque de itens priorizados e detalhados para até um mês à frente, no máximo. Mais do que isso e a chance de você jogar muito trabalho fora é enorme.

Isso é uma verdade ainda maior no que tange estimativas de tempo de projeto. Jamais deixe que o time de desenvolvimento estime mais do que uma sprint e meia. A chance de estimativas “perderem a validade” nestes casos é muito grande em virtude de mudanças de arquitetura, dependências, prioridades, etc é muito grande e com isso perdemos o tempo que se levou estimando.

Parking Lot misturado com backlog

Features que não são debatidas, priorizadas ou detalhadas há mais de um mês devem sair do Product Backlog para não atrapalhar refinamentos posteriores. A sugestão é criar um backlog separado, chamado de Parking Lot ou Icebox. Abordagens mais drásticas como a do Getting Real dizem que estas features deveriam simplesmente ser excluídas. Se elas realmente forem importantes, voltarão a aparecer.

Histórias incompletas

As histórias devem sempre buscar entregar valor ao usuário final, de uma ponta a outra, o chamado “fatiamento vertical de features”. Histórias que entregam cenários pela metade, os famosos componentes (fatiamento horizontal), devem ser evitadas ao máximo pois causam um acúmulo de itens com pendências que não podem subir para produção.

Só geramos valor com o produto quando o usuário passa a gerar valor com ele. Até então, temos investimento ou desperdício, mas nunca geração de valor.

Além disso, um item do product backlog somente deveria ser dado como refinado quando os seus critérios de aceitação estão claros. Apenas escrever a história (ou pior ainda, apenas ter um título) não é o bastante. Um artefato que ajuda o Product Owner a ter certeza que sua história está pronta para entrar na próxima sprint é a Definição de Preparado (Definition of Ready).

Basicamente uma Definição de Preparado é um checklist (assim como a Definição de Pronto) que deve ser repassado para garantir que cada história realmente está ‘preparada’ para entrar em desenvolvimento. Obviamente isto pode variar de time para time mas coisas como critérios de aceite, o modelo a ser seguido de user story, um screenshot da UI desenhada, etc são coisas que você pode ter. Nenhuma história deveria ser discutida em uma Sprint Planning sem antes ter sido preparada em groomings.

Histórias ‘completas’ demais

O papel do P.O. é definir para ‘quem’ criamos ‘algo’ e ‘porquê’, mas jamais ‘como’ o time deve fazer isso. A multidisciplinaridade de um time de desenvolvimento deve garantir, por exemplo, que tenhamos profissionais de UX para criar as melhores experiências e interfaces gráficas, que tenhamos profissionais de QA para garantir a qualidade da entrega, profissionais de sistemas para garantir a melhor técnica de programação e assim por diante. Deve haver confiança de que cada pessoa é capaz de executar a sua atribuição da melhor maneira possível e que a soma de todos é que constrói o melhor produto, e não o ego de uma pessoa apenas.

Se o PO define como os programadores devem escrever o código, como os designers devem criar as telas e como os testers devem testá-las, porque temos um time? Não é mais fácil terceirizar tudo pela Internet? E qual a chance dele ser bom de fato em todas estas skills, além da skill de negócio que é a mandatória do papel?

Detalhe as histórias até o ponto que o time de desenvolvimento tenha as informações necessárias para aplicar as suas skills da melhor forma que eles entenderem, sem jamais restringir a sua capacidade criativa e intelectual impondo requisitos técnicos demais que fogem ao escopo de negócio. Mesmo no âmbito de negócio, o P.O. deveria consultar os stakeholders para garantir sempre o alto alinhamento com a empresa.

Itens de backlog soltos

Todo item de backlog deve fazer parte de uma hierarquia que faça sentido dentro da estratégia do produto, para que seja possível entender porque ele é importante ou onde ele se encaixa.

Itens de backlog soltos geram software desenvolvido que não se encaixa em lugar nenhum, telas que não “conversam” com as demais telas do sistema, regras de negócio e de experiência que não são uniformes, etc. Quer você opte por apenas dois níveis (épicos e histórias) ou mais níveis (no TFS temos épicos, features, histórias e tarefas, por exemplo), é importante que cada história faça parte de algo maior.

A composição total dos épicos é o que chamamos de roadmap e o ideal é que ele seja público (transparente) e que não seja mais longo do que 3 meses para produtos inovadores e complexos. Além disso, ele deve ser minimamente possível de se realizar dentro do time-to-market pelo time existente, mesmo sem um estudo detalhado e estimativas minunciosas.

Achismos

Ok, o Product Owner tem a palavra final sobre o Product Backlog, mas ele sempre deve ter argumentos para explicar a sua priorização e detalhamento. Itens obscuros devem ser estudados, itens complexos devem ter spikes e POCs, itens que dividem opiniões devem ter dados de mercado e assim por diante.

Forçar sua opinião para definir uma história sem argumento é o primeiro passo para quebrar a confiança com seu time ou pior ainda, quebrar a cara com seu produto.

P.O. Parcial

A função de Product Owner é uma demanda de tempo integral que não se ajusta bem a mais responsabilidades. Refinar o product backlog apenas uma vez por semana antes da próxima Sprint Planning não é o bastante, esse refinamento deve ser diário, de acordo com a evolução do projeto nas mãos do time.

Time submisso

O time deve contribuir com o product backlog durante o refinamento e principalmente durante a Planning. Um time submisso que apenas executa o que o Product Owner decide acaba se metendo em confusão rapidamente.

Dificilmente o Product Owner irá se atentar ou mesmo priorizar débito técnico. Cabe ao time levantar esta bandeira quando necessário. Poucos P.O.s tem capacidade, principalmente em início de projeto, de entender se um time está se sobrecarregando ou não em uma Sprint Planning, o próprio time tem de ter esse discernimento e dizer ‘chega’ quando acreditarem que já se comprometeram com itens suficientes para a sprint. E os incidentes? Se o produto já está em produção, podem acontecer incidentes e é importante o time manter o P.O. a par do volume de chamados que costumam entrar ao longo do período da sprint.

Estes são alguns problemas que costumo perceber auxiliando Product Owners e até mesmo atuando nesta função em diversas ocasiões. Concorda? Discorda? Tem algum ponto a acrescentar? Deixe nos comentários!

Caso queira conhecer uma ferramenta útil e gratuita para gerenciar o Product Backlog, sugiro o Visual Studio Online (antigo TFS).

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Criando um roadmap de produto de maneira ágil

Quando estamos iniciando um novo produto ou até mesmo evoluindo um produto já existente é muito importante um mínimo de organização para que saibamos onde queremos chegar, o que queremos ter no produto, etc. Mesmo em casos onde a mudança seja constante, ter um roadmap ajuda a tomar decisões de escopo, de priorização e principalmente, de ter uma ideia do quão longe estamos de chegar aonde queremos.

Existem diversas técnicas para criação de roadmaps de produtos. Dentre as técnicas mais ágeis e que não tentam ser lá muito precisas, até porque tentar prever o futuro é algo bem impreciso na minha opinião, temos a Futurespective e a Matriz Valor x Complexidade. E é delas que falarei hoje, embora outra dinâmica complementar seja a Buy a Feature Game que já falei antes.

Matriz Valor x Complexidade

A matriz de valor x complexidade é um artefato ágil para dimensionar o tamanho de um projeto ou roadmap, além de ajudar na priorização do mesmo e definição dos épicos e features de um produto.

Você pode fazer esta dinâmica com folhas A3, quadros brancos ou ainda flip-charts. Ela não é uma dinâmica muito boa de aplicar em times grandes, o ideal é que não passe de 5 pessoas e, por se tratar de uma dinâmica focada no negócio, o ideal é não ter a presença de membros que não possuam (ou não gostem) a visão de negócio do produto.

Desenhe uma matriz bi-dimensional com dois eixos, tipo um plano cartesiano. No eixo vertical, escreva Complexidade e no eixo horizontal, escreva Valor. Cada eixo deve ter duas ou mais partes, como Baixo, Médio e Alto Valor, ou Baixa, Média e Alta Complexidade, como mostra o exemplo abaixo, que dividiu em 5 níveis e 4 quadrantes (esqueça, faça primeiro, faça depois e vitória fácil).

Matriz Valor x Complexidade
Matriz Valor x Complexidade

Em post its escreva as features ou épicos do seu produto e posicione um-a-um os posts its nos quadrantes apropriados, considerando o quanto valor eles irão agregar para os clientes e/ou para a empresa e o quanto de complexidade eles possuem (entenda complexidade como risco também).

Considere Valor como não sendo algo meramente financeiro. Valor pode ser engajamento, pode ser marketing boca-a-boca, pode ser algo que gere mais NPS, pode ser algo que reduza o churn, que aumente a conversão, etc. Embora tudo isso de uma forma ou de outra se traduza em dinheiro, não precisa se apegar a valores financeiros diretos neste momento. Essa definição mais abrangente de valor é algo a ser levada a sério, pois até mesmo aparece na prova da certificação de PSPO.

Considere Complexidade como qualquer coisa que torne mais arriscado pegar esta feature ou épico para implementar. Pode ser muito esforço necessário, muito custo, desconhecimento dos detalhes, falta de tecnologia ou de pessoal especializado para tocar a tarefa. Pode ser um prazo muito justo ou uma complexidade muito alta de desenvolvimento. Tudo isso representam riscos para que tenhamos sucesso na empreitada deste épico.

Após terminar de colocar os post its nos lugares certos cabe ao time decidir a sua estratégia de priorização do roadmap. Não há uma única estratégia válida aqui  pois cada empresa tem a sua realidade, mas uma análise comum destes quadrantes incluem:

  • alto valor e alta complexidade (topo á direita): geralmente o que possui alta complexidade e alto valor são as que realmente darão um retorno altíssimo para a empresa. O fator complexidade deve ser mitigado o mais rápido possível para que não sejamos surpreendidos no futuro por algo que acabe minando o projeto como um todo. Atacar a alta complexidade/alto valor primeiro é uma estratégia segura a longo prazo;
  • alto valor e baixa complexidade (embaixo á direita): uma estratégia de curto prazo, boa quando se está com a corda no pescoço e precisam-se de ações rápidas e que gerem valor. Em outras situações, ataque estas após as alto risco/alto valor ou quando precisar mostrar resultado rapidamente.
  • baixo valor e baixa complexidade (embaixo à esquerda): não é uma boa estratégia, geralmente só devem ser priorizadas em casos de ociosidade ou em períodos “entressafras”;
  • baixo valor e alta complexidade (topo à esquerda): jamais faça elas, não valem a pena.

Ao definir sua regra de priorização, você terá o seu roadmap definido e priorizado. Se precisar de alguma estimativa de alto nível, convém jogar um Planning Poker sobre o menor épico que valha a pena desenvolver (alto valor e baixo risco?) e, após estimá-lo, projetá-lo sobre os demais post its para ter uma ideia total do roadmap.

Por exemplo, se o menor épico ganhar um 3 e você decidir que ele demora em média 2 meses, some os demais pontos e divida por 3 para saber o número de meses do seu roadmap. Mantenha uma escala exponencial como a de Fibonacci para pontuar tarefas baseadas em seu risco, para não cometer o erro de estimar um roadmap muito “no detalhe”.

Futurespective

Essa dinâmica pode ser complementar à Matrix Valor x Complexidade ou mesmo substitui-la. Sua abordagem é ainda menos precisa e muito mais ágil, quando estamos em uma de duas situações:

  1. você quer ver se o seu time está alinhado com a visão estratégica da empresa em relação ao(s) produto(s) que estão desenvolvendo;
  2. você quer construir um roadmap do produto de maneira colaborativa, com o seu time, para dar uma visão comum a todos;

Seja qual for o seu objetivo, esta dinâmica é bem interessante e pode render bons frutos, apenas não se preocupe em gerar um plano de ação detalhado com ela, pois isso não irá acontecer. Conheci ela durante um workshop do Daniel Wildt e achei bacana reproduzir aqui.

Separe o seu time em grupos de até 3-5 integrantes. Evite grupos muito grandes para evitar discussões desnecessárias. Essa não é uma dinâmica que trará precisão no seu roadmap, mas um alinhamento geral muito bom, então não tem necessidade de discutir nos mínimos detalhes os prazos e prioridades das coisas.

Estabeleça que cada participante vai escrever 10 post-its com épicos ou features que ele acredite ser importante para o produto e que ainda não foram desenvolvidas.

Após todos escreverem,  cada membro deve apresentar aos demais o que ele escreveu. Juntos, devem definir quais x itens devem ser prioridade para os próximos 3 meses (desconsiderando repetidos), sendo que x deve ser o número de integrantes da equipe que está fazendo a dinâmica. Depois, quais os próximos x que devem ser prioridade para os 3 meses posteriores e assim por diante, até os itens terminarem.

Para tomarem a decisão de prioridade, pode ser usada a Matriz Valor x Risco, a Buy a Feature Game ou qualquer outra dinâmica que você conheça. O resultado dessa dinâmica será um roadmap de alto nível que garante uma visão comum entre os membros do time.

Eventualmente este roadmap irá ser alterado, mas não tem problema, como diz no Manifesto Ágil: mais vale responder às mudanças do que seguir um plano.

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.