Usando planilhas ágeis para estimativa de descoberta

Este artigo inclui uma planilha pré-formatada para ajudá-lo a desenvolver estimativas de descoberta Agile. Ele também inclui informações para ajudá-lo a acompanhar o exemplo em destaque. Você pode fazer uma cópia editável (Arquivo>Fazer uma cópia ou Arquivo>Baixar) do modelo aqui.

Os clientes geralmente me pedem para fornecer estimativas ágeis antes de eu ter uma equipe ou conhecer os requisitos do MVP. Nesse estágio inicial, não tenho acesso a métricas tradicionais como velocidade, número de sprints ou custo da equipe para calcular essas estimativas. Mas os clientes querem respostas. Eles podem lançar um produto hipotético em dois meses ou seis? Será viável para o seu orçamento (geralmente baixo)?

Entre na planilha Agile.

As planilhas são uma escolha adequada, mas muitas vezes esquecida, para uma mentalidade ágil. São ferramentas de baixa tecnologia e alto toque que incentivam a colaboração. Dito isso, seu cliente provavelmente não se importa se suas ferramentas são “aprovadas para o Agile”, desde que o custo e a qualidade do produto atendam aos seus requisitos. O verdadeiro valor das planilhas está em sua acessibilidade a gerentes de projeto e partes interessadas de todos os níveis de experiência.

Muitas ferramentas especializadas de gerenciamento de projetos têm curvas de aprendizado muito íngremes para usuários inexperientes em projetos rápidos. Portanto, quanto mais fácil for para clientes, proprietários de produtos e desenvolvedores atualizarem os requisitos e os custos de mão de obra, mais cedo você chegará a uma estimativa realista. Com uma planilha pré-formatada, os gerentes de projeto podem ajustar valores e parâmetros para demonstrar os efeitos de cada recurso flutuante ou mudança de cronograma.

As planilhas também são uma ótima maneira de compartilhar conhecimento com seus colegas. A planilha que utilizo veio de um colega da Toptal, e desde então fiz uma cópia e modifiquei para atender às minhas necessidades. Eu encorajo você a fazer isso também.

Neste artigo, demonstro como fornecer estimativas de descoberta bem-sucedidas que capacitam clientes e partes interessadas a se alinharem às metas do projeto e prosseguirem com o desenvolvimento. Veja como preencher as lacunas e fornecer uma estimativa inicial que você pode apoiar.

Aborde primeiro a visão do produto e o roteiro

Digamos que seu cliente queira desenvolver um site de namoro com um orçamento fixo, mas os detalhes do produto são confusos. Sem conhecer o custo e a velocidade da equipe, a visão do produto é o melhor ponto de partida, pois exige que as partes interessadas concordem com uma meta de design e promove a transparência em toda a equipe.

Eu gosto do formato de visão do produto Scrum.org por seu estilo narrativo intuitivo. Aqui está o que parece:

Uma vez que a visão do produto esteja definida, você pode adicionar o Product Roadmap em uma nova guia de planilha para dar ao cliente uma noção do cronograma do projeto de longo prazo. O roteiro deve listar metas, recursos principais e prazos para cada versão do roteiro de produto.

As versões de roadmap são edições planejadas, voltadas para o consumidor ou para o cliente, de um produto que orientam sua trajetória no mercado. A primeira versão do roteiro é o produto que você pode estrear no mercado. As versões subsequentes do roteiro representam lançamentos de mercado com novos recursos atraentes que se alinham com a visão do produto.

Para usar a Microsoft como exemplo: o Windows 8 provavelmente era uma versão de roteiro. O Windows 10 foi outra versão do roteiro que apresentava muitos recursos novos e desejáveis.

Assim que a visão do produto e o roteiro estiverem completos, é hora de pedir ao cliente que se comprometa com um MVP.

Negocie recursos de MVP com o gráfico de restrição tripla

Este é o momento de moldar as expectativas do seu cliente em relação ao tempo e às despesas usando o gráfico de restrição tripla:

Em uma abordagem Waterfall, recursos fixos determinam tempo e custo, e o desenvolvimento prossegue de acordo com um plano de projeto detalhado. Por outro lado, os custos fixos e o cronograma do Agile determinam os recursos do produto, e esses recursos são constantemente redefinidos com base na visão mais flexível do projeto.

O gráfico de restrição tripla mostra ao cliente que incluir todos os recursos desejados na primeira versão aumentará o tempo de desenvolvimento e os custos do balão. Em vez disso, trabalhe com o cliente para selecionar apenas os recursos “obrigatórios” para um MVP e apresente os recursos restantes para versões futuras.

As planilhas facilitam o agrupamento e reatribuição de recursos a diferentes versões, lançamentos e prioridades com base nas necessidades de mudança do cliente e exibem instantaneamente os custos dessas alterações.

Ao identificar os recursos do MVP, peça ajuda aos especialistas no assunto (SMEs) para listar as etapas do projeto com base em projetos semelhantes em que trabalharam. Você usará estas etapas para criar épicos mais tarde. Depois de ter essas entradas prontas, você pode começar a construir uma estimativa.

Comece com o tamanho da camiseta

Para iniciar o primeiro backlog, peça ao proprietário do produto uma descrição detalhada dos recursos do produto e, em seguida, atribua um tamanho de camiseta para cada recurso com base em seu nível de dificuldade.

O dimensionamento da camiseta mostrará a complexidade relativa e a duração de cada tarefa de desenvolvimento antes que você tenha quaisquer valores absolutos. À medida que avançamos no planejamento do projeto, converteremos esses tamanhos relativos em pontos de história e horas de trabalho.

Por exemplo, se o seu cliente quiser que você desenvolva uma série de pop-ups no site de namoro, isso seria demorado, mas direto. Você pode caracterizar essa complexidade de tarefa como “Pequena”, mas o esforço seria “Médio”. Você pode abreviar isso como "SM". Por outro lado, desenvolver uma conexão de back-end para uma nova API seria uma tarefa mais complexa devido a toda a documentação e testes necessários. A habilidade e a atenção necessárias para isso podem torná-lo um “Grande” tanto no esforço quanto no nível de habilidade: “LL”.

Depois de terminar o dimensionamento da camiseta, você terá uma noção da carga de trabalho relativa e dos requisitos de habilidade para cada futuro membro da equipe. Um especialista técnico da equipe de desenvolvimento pode ajudá-lo a correlacionar o tamanho da sua camiseta com intervalos de horas e pontos de história.

Defina seus parâmetros

Agora você está pronto para colocar sua planilha para trabalhar e calcular sua estimativa. Comece criando uma guia Parâmetros. Isso servirá como chave para seus cálculos, e os valores inseridos aqui alimentarão as fórmulas usadas nas guias Backlog/User Stories e Estimate Summary by Release.

Aqui está tudo o que você precisa na guia Parâmetros:

Moeda. É aqui que você insere as conversões de moeda. Por exemplo, se o orçamento do cliente estiver em reais, você pode inserir a taxa de conversão atual para dólares ou euros.

Data de início. A data de início de desenvolvimento esperada será usada para criar uma linha do tempo do projeto. Em cada exemplo, nossa data de início é 25 de outubro.

Orçamento inicial. O orçamento fornece restrições que mostram se todos os recursos do MVP caberão nele.

Tamanho da camiseta. Insira os tamanhos de suas camisetas como uma tabela e atribua pontos de história e um intervalo de horas para cada combinação de tamanhos. Neste exemplo, usamos uma a duas horas para um SS e 33 a 48 horas para um LL.

Lembre-se de que a duração do seu sprint limitará as horas do tamanho máximo da sua camiseta. Se o sprint for de apenas uma semana, o maior tamanho não pode exceder 40 horas. É por isso que consultar um SME é tão importante ao atribuir tamanhos de camisetas a tarefas .

Tarifas por hora. Use esta tabela para documentar as taxas de pagamento para cada função. Se seus desenvolvedores de back-end tiverem taxas diferentes, use a média das duas.

A sobrecarga. Distribua uma porcentagem do esforço total do projeto para tarefas administrativas, como reuniões de status, sessões de feedback e revisões do projeto. Dez por cento (ou quatro horas da semana de trabalho de cada participante) é um bom ponto de partida, mas a sobrecarga pode ser maior para projetos mais complexos.

Contingência. Isso indica a variação potencial em sua estimativa. Começar com uma contingência de 0% mostrará o melhor caso (ou seja, improvável) orçamento e cronograma, considerando os valores que você inseriu na planilha. Mais adiante, em nosso exemplo, aumentaremos a contingência para uma variação aproximada de ordem de magnitude (ROM) de 50% para mostrar o potencial alto de custos e a duração do projeto. A contingência diminuirá à medida que você obtiver números mais precisos.

Dimensione cada lançamento com épicos

Começamos com um dimensionamento aproximado do produto completo para garantir que não desperdiçamos tempo ou dinheiro do cliente. Dependendo da proximidade do dimensionamento com o orçamento e prazo propostos, o cliente pode decidir abandonar o projeto ou investir em orçamentos mais detalhados. Como não temos muitos detalhes neste momento, inserimos os principais recursos como épicos na guia Backlog/User Stories. Em seguida, para cada épico, inserimos o número de horas que as PMEs e os líderes de desenvolvimento sugeriram para cada pilha de desenvolvimento com base na tabela de tamanhos de camisetas na guia Parâmetros.

Primeiro, selecione a coluna “EPIC?” e certifique-se de que apenas “Epic” esteja selecionado.

Em seguida, escreva a descrição épica e insira o número de horas para cada coluna da pilha de desenvolvimento. Por exemplo, o épico “Conexão e login seguros” levará cerca de oito horas de desenvolvimento de interface do usuário, 40 para o back-end e assim por diante.

Observe que, na maioria dos casos, as células na coluna "Ponto" exibem "34*". Se você retornar à guia Parâmetros, verá que 34 pontos correspondem a um intervalo horário entre 33 e 48 horas. Esse número de horas é muito grande se a duração do nosso sprint for de apenas uma semana.

Assim que tivermos mais detalhes, essas horas precisarão ser reduzidas, ou os épicos devem ser divididos em histórias mais gerenciáveis. Por uma questão de tempo, no entanto, vamos ignorar a coluna Pontos e continuar com a estimativa aproximada.

Agora vá para a guia Estimate Summary by Release. Na parte superior da planilha, você verá os valores "Overhead" e "Contingency" conforme definidos na guia Parameters. Há também um botão que você pode selecionar para mostrar estimativas por épicos ou histórias de usuários.

Como ainda não temos histórias de usuários para exibir, verifique o botão "Modo Épico".

Agora você pode ver o custo aproximado e os prazos para o MVP e os recursos e atualizações menos urgentes em versões futuras (R3 e R4). Neste exemplo, a segunda versão (R2) está vazia porque o cliente solicitou que todos os épicos do MVP fossem lançados na primeira versão.

Agora você pode ver o custo agregado mais otimista: US$ 28.810. Este valor é a soma do custo de cada lançamento do MVP até o R4.

Também temos uma estimativa do prazo mais curto para entrega do produto, que corresponde à última data de conclusão da pilha de desenvolvimento R4. Os gerentes de projeto chamam essas pilhas de desenvolvimento mais lentas de “caminhos críticos” porque ditam a velocidade de todo o lançamento.

Nesse caso, o caminho crítico é o desenvolvimento front-end, com data de conclusão em 31 de janeiro.

Agora é hora de ajustar os parâmetros para simular o orçamento do pior caso e o cronograma mais longo.

Ajuste a contingência para 50%

Ainda sabemos relativamente pouco sobre os requisitos de esforço e experiência para o produto, então adicionaremos uma contingência de ROM de 50% na guia Parâmetros. A contingência diminuirá à medida que soubermos mais detalhes sobre o projeto.

Novamente, aqui está a estimativa total do projeto com 0% de contingência.

E aqui está com 50% de contingência.

Isso significa que a estimativa de ROM para todo o projeto está entre US$ 28.810 e US$ 41.860. Nos melhores e piores casos, o orçamento de US$ 20.000 do cliente não será suficiente para incluir todos os recursos em sua lista de desejos.

A data de conclusão completa do projeto com contingência de 50% agora cai em 14 de março, seis semanas depois da data de conclusão de contingência de 0%.

Enquanto isso, o MVP estará pronto em 10 de janeiro.

Em vez de abandonar o projeto, o cliente solicita uma estimativa mais detalhada para ver se pode chegar mais perto de seu orçamento-alvo em um prazo mais curto.

Repriorize para cumprir os prazos

Suponha que o cliente defina uma data-alvo de 25 de dezembro para o MVP, dois meses a partir do início de 25 de outubro.

Para adiantar a data atual de conclusão do MVP em 10 de janeiro, o cliente concordou em adiar dois épicos do MVP até o próximo lançamento (R2).

A planilha calcula o efeito cascata desse ajuste. Nesse caso, a linha do tempo do MVP é reduzida para 27 de dezembro. O desenvolvimento de front-end e back-end são os caminhos críticos nesta simulação porque levarão mais tempo para serem concluídos.

Com base nessas informações, você pode decidir adicionar outros dois desenvolvedores para alinhar as datas de conclusão de front-end e back-end com as outras pilhas de desenvolvimento. Para fazer isso, aumente as horas de 40 para 80 na linha MVP “Horas por semana”.

As pilhas de desenvolvimento de front-end e back-end agora terminam em novembro, e o controle de qualidade se torna o novo caminho crítico (com data de conclusão em 20 de dezembro). Observe que o custo não muda. Isso porque o total de horas de trabalho em cada pilha permanece o mesmo. Em vez de um desenvolvedor trabalhando por duas semanas (80 horas), dois desenvolvedores estão trabalhando por uma semana (80 horas).

A planilha também leva em conta as diferenças entre o trabalho em tempo integral e parcial. Vamos supor que o desenvolvedor da interface do usuário esteja trabalhando meio período. Podemos alterar a interface do usuário “Design Hours per week” para 20 para simular o atraso na entrega.

Em uma programação de tempo integral, o UX/UI será concluído em 29 de novembro.

Em um horário de meio período, o UX/UI será concluído em 27 de dezembro.

Mais uma vez, o custo não muda, mas UX/UI se torna o novo caminho crítico, estendendo o cronograma do MVP até 27 de dezembro.

Você pode continuar essa abordagem de tentativa e erro até chegar a um caminho crítico aceitável, considerando seus recursos e o prazo do cliente. Uma vez estabelecido um prazo adequado, é hora de começar a ajustar sua estimativa.

Refine sua estimativa com histórias de usuários

Como a estimativa de contingência de 50% ficou fora do orçamento do cliente, vale a pena refinar suas variáveis ​​para que você possa diminuir a contingência e obter uma estimativa mais realista.

Para fazer isso, trabalhe com seus desenvolvedores e PMEs para dividir seus épicos em histórias de usuários detalhadas. As histórias são mais bem definidas do que os épicos, para que possamos dimensioná-las com mais precisão.

Em seguida, ajuste os valores na guia Parâmetros com base em qualquer nova informação. Por exemplo, sua PME e equipe de desenvolvimento podem ter um conjunto de taxas mais preciso para cada função e também podem querer ajustar os tamanhos das camisetas e as atribuições de pontos. Com esses novos parâmetros, você pode ter mais confiança em seus cálculos e reduzir a contingência para 25%.

Vejamos como dividimos os épicos em histórias de usuários menores e mais detalhadas:

Ao contrário da estimativa épica que exigia inserir manualmente as horas estimadas para cada pilha, a estimativa de história usa o tamanho da camiseta como um atalho. É aqui que os tamanhos de camiseta que você inseriu na guia Parâmetros são úteis.

Em “T-shirt Sizing” na guia Backlog/User Stories, insira a combinação de tamanho que seus desenvolvedores e PMEs atribuíram às suas pilhas para cada história. A partir daí, a fórmula da planilha preencherá automaticamente as horas correspondentes na guia Parâmetros. Lembre-se de que o tamanho maior, LL, deve permanecer abaixo de 34 pontos para garantir que possa ser concluído dentro da duração do sprint acordada. Todas as histórias que ainda pontuarem 34 pontos ou mais precisarão ser subdivididas.

Depois de garantir que menos de 34 pontos sejam atribuídos a todas as histórias, desmarque o botão "Modo épico" na guia Resumo da estimativa por versão para visualizar apenas "História".

Agora você verá um novo conjunto de números:

Depois de detalhar todas as tarefas e manter apenas os recursos do MVP, o cronograma e o custo agora correspondem aos requisitos do cliente. Como o saldo está dentro do orçamento, o cliente decide prosseguir com o MVP e testá-lo antes de se comprometer com lançamentos adicionais.

Faça-o seu

As planilhas são simples de usar e, com algum conhecimento básico de fórmulas (sem necessidade de macros), você pode adaptá-las a praticamente qualquer necessidade. Se o seu conhecimento do Excel estiver enferrujado, os cursos on-line da Udemy e do edX ajudarão você a aprimorar essas habilidades.

Este artigo abordou a estimativa de descoberta, mas você pode usar a mesma planilha para produzir gráficos de burnup/burndown, ajustar cronogramas e calcular estimativas com base na velocidade e sprints para estágios posteriores. Eu uso minhas planilhas personalizadas para complementar aplicativos, como Jira, Asana e Trello, e mantenho que elas são uma ferramenta poderosa no meu kit de gerenciamento de projetos. Espero que eles se mostrem igualmente úteis e versáteis para você.

Você prefere planilhas personalizadas a ferramentas de gerenciamento de projetos prontas para uso? Diga-nos porque ou porque não nos comentários.