Como priorizar as tarefas de um projeto ágil

100 trilhões de dólares do Zimbábue
100 trilhões de dólares do Zimbábue

Trabalho e ensino outros a trabalharem com Scrum desde 2010. Independente das empresas adotarem ou não a metodologia ágil mais utilizada (e com mais cases de sucesso conhecidos) no mundo, sempre há o que aprender com seus métodos inusitados e com a cultura que permeia este mundo ágil em geral. Um dos pontos-chave em qualquer projeto, seja com Scrum ou não, é a priorização de tarefas, tema do post de hoje.

Alguns especialistas que conheço dizem que basta perguntar ao cliente o que ele quer e depois, o que ele quer primeiro.

Pergunte ao seu usuário e/ou cliente tudo o que ele quer no software e você terá uma pilha de documentos com vários centímetros de altura e dezenas (talvez centenas) de páginas. Depois pergunte à ele o que é mais importante e ele vai lhe responder que tudo é importante. Pergunte o que é mais urgente e ele vai te responder que tudo é urgente. Esqueça, isso não funciona. Pelo menos dessa forma tão direta não.

Como fazer então?

Cortando o escopo

Simplesmente nunca teremos tempo hábil (e nem faz sentido) desenvolver tudo o que o cliente acha que precisa no software. Principalmente na primeira versão (já ouviu falar em MVP?) e é o seu dever ensinar isso a ele.

Gerentes de projeto tem de lidar com escopo, custo e prazo nos projetos. Dificilmente conseguimos equilibrar essas três variáveis e, na minha opinião, escopo é a que faz mais sentido cortar. Não apenas porque manter um equilíbrio nessa balança de três pratos é quase utópico mas porque é o mais inteligente a se fazer, pensando no sucesso do projeto como um todo.

Jason Fried fala no seu livro Getting Real que é melhor fazer meio-software do que um software meia boca. E eu concordo com ele.

É no escopo onde temos sempre a maior quantidade de desperdício em um projeto. E desperdício aumenta os custos e estoura os prazos, simples assim. A Toyota passou a GM com seu método Lean focando em apenas uma coisa: reduzir o desperdício.

Mas como reduzir o desperdício de escopo?

Princípio de Pareto

Use o Princípio de Pareto ou a “regra do 80/20”, como muito bem apontada por Tim Ferriss em seu best-seller Trabalhe 4h por semana. Pareto determina uma relação de 80/20 ou simplesmente maioria/minoria que é aplicada há muitas coisas em nosso cotidiano. Por exemplo, 80% do uso de um software se dá em apenas 20% das funcionalidades.

Isso quer dizer que apenas 20% de tudo que for desenvolvido será utilizado realmente. O restante cairá no esquecimento.

Scrum enfatiza o foco na geração de valor para o cliente a cada entrega e a chave para geração de valor é reduzir o desperdício priorizando muito bem o que deve ser DONE em cada Sprint. Ok, dentro do Scrum isso é uma tarefa para o Product Owner, mas se você leu até aqui é porque de alguma forma está envolvido com as decisões de produto também, certo?

Atualmente trabalho em um banco e como todo banco, temos alguns processos e projetos inchados, burocráticos e cheios de desperdícios. Alguns são culpa do Banco Central, outros são culpa nossa mesmo.Algumas vezes parece que Agile e Lean jamais andarão de mãos dadas com a palavra banco, mas essa é a minha função lá e tem sido um trabalho bem interessante.

Cito o case do banco pois lá eu tenho cuidado da priorização de tarefas para os times de desenvolvimento, além das minhas atribuições normais como Scrum Master. Um app de cartão de crédito, por exemplo, é cheio de features, por mais que pareça algo simples como comprar-e-pagar. É troca de senha, de data de vencimento, aviso de viagem, solicitação de mais limite, ajuste do limite atual, etc. Se deixar a equipe de negócio se empolga e quer um Nubank pronto em duas sprints. Quem nunca passou por isso?

Minha estratégia neste projeto foi bem simples: priorização. Não vamos entregar um Nubank em duas sprints, mas consegui priorizar as features baseado no que agregaria mais valor ao cliente o mais rápido possível. Assim, em três sprints teremos um app de cartão funcional com os 20% de features que trazem 80% dos benefícios. E sim, nós vamos entregar, pois falta apenas uma das três sprints e já estamos com boa parte das funcionalidades essenciais prontas.

Conhecendo seu produto

Mas como saber o que é mais prioritário dentre centenas de features que aparecem no backlog todos os meses?

O jeito mais óbvio é conhecendo o seu produto, o seu time e entendendo o seu mercado. Óbvio que isto não é algo simples de se alcançar e existem diversos outros fatores que impactam na priorização. Se você está lançando uma versão nova de um produto, olhar o que os usuários realmente usam na sua aplicação pode ajudar bastante a decidir o que deve entrar ou não em uma nova versão. Se está lançando um novo produto, tente entrevistar usuários de produtos concorrentes, vai lhe ajudar a entendê-los e fazer algo superior à concorrência.

Quais são as dores do seu usuário? Priorize o que “dói mais”. Se o que o usuário mais reclama é de não ter um bom limite de crédito nos cartões concorrentes, foque em fazer uma análise de crédito automatizada, eficiente e que forneça um crédito condizente com a realidade (e histórico) de cada cliente. Permitir que ele escolha a cor do seu cartão pode ficar pra depois.

O quê seu usuário mais utiliza no dia-a-dia? Entregue primeiro o que ele espera como “mínimo viável” em produtos do seu nicho. Se o usuário consulta o limite disponível no cartão todos os dias, mas apenas viaja para o exterior anualmente, o que você acha que deve ser feito primeiro: consulta de limite ou aviso de viagem? Se seu usuário troca de senha do cartão apenas uma vez por ano (no máximo), mas paga faturas todos os meses, qual funcionalidade deve ser o foco nas primeiras entregas?

Este tipo de raciocínio, sem muita técnica, ajuda bastante a priorizar o que é realmente importante e deve ser posto na frente em um projeto de software.

Buy a Feature Game
Buy a Feature Game

Buy a Feature Game

Obviamente existem diversas técnicas que podem ser utilizadas pra fugir do “achismo” e até mesmo lidar com conflitos de egos que muitas vezes irrompem em reuniões para priorização de backlog. Vou falar da minha favorita: a técnica Buy a Feature Game,  que é bem simples, lúdica e eficiente.

Primeiro, escreva as histórias ou features do seu projeto em cards e deixe-os todos espalhados em uma mesa. Não traga qualquer feature aqui, apenas aquelas que já estão no roadmap próximo e/ou são minimamente importantes ao projeto. Cada card postado na mesa deve ser lido, com a atenção de todos. O ideal é que cada card possua um “preço” também, que pode ser a estimativa de horas para desenvolvimento ou os story points, mas se não estiver tudo estimado, não invalida a dinâmica, apenas reduz um pouco a sua eficiência.

Para cada um dos envolvidos na priorização (de 4 a 7), geralmente stakeholders ou até mesmo usuários, entregue à eles um maço de notas falsas, tipo Banco Imobiliário. Se todas as tarefas estiverem estimadas e com “preço”, some os preços, divida o valor pelo número de participantes e distribua esta quantia em notas para cada participante (poucas notas grandes, muitas notas pequenas).

O dinheiro da dinâmica pode ser apenas post-its com os valores escritos ou dinheirinho de brinquedo, à venda em bazares. Apenas não permita a fabricação de dinheiro falso ao longo da dinâmica nem injeção ou lavagem de dinheiro aproveitado de outras dinâmicas. 🙂

Já se não estiver tudo estimado mas se você estiver trabalhando com story points ou horas e já souber quanto o seu time entrega por sprint, divida essa quantia entre os participantes em notas, seguindo aquela mesma lógica do Banco Imobiliário (poucas notas grandes, muitas notas pequenas). Você pode jogar o B-a-F Game uma vez para várias sprints, por exemplo, somando a capacidade das sprints na hora de distribuir as notas.

Se suas sprints são de 15 dias e você entrega 30 pontos em cada sprint, você pode priorizar uma vez a cada 30 dias, emitindo 60 pontos de notas para os participantes, por exemplo. Para que os valores não fiquem muito limitados, sugiro multiplicar story points por $10 ou até $100 mesmo, enquanto que horas geralmente não possuem esse problema.

Sem nenhuma regra, cada participante pode depositar o seu dinheiro sobre cada card, representando o seu interesse e/ou o quanto aquela feature vale a pena ser implementada. Aqui, cada um terá a sua própria percepção de prioridade, mas como o dinheiro é limitado, eles serão obrigados a trabalhar com esta limitação na hora de distribuir as notas.

Esta limitação de dinheiro ilustra bem as limitações reais de um projeto como a verba, as horas-homem, etc. Ajuda os stakeholders a “sofrerem” com as decisões difíceis que o gerenciamento de um projeto exige. Caso seus cards possuam outras limitações, como precedência, crie combos de produtos do tipo “para comprar esse, tem de comprar o outro primeiro”.

Quando todos terminam sem dinheiro (deixe que discutam e troquem as notas de lugar até o final da dinâmica), basta somar quanto cada card recebeu e os que receberam mais dinheiro são os mais prioritários. Opcionalmente, se estiver trabalhando com as estimativas, uma feature só vira de fato prioridade se ela recebeu um valor mínimo equivalente ao valor necessário para sua compra.

Se uma feature exige 100h de desenvolvimento, ela não entrará na próxima sprint se não alcançar $100 de ‘doações’ dos stakeholders, por exemplo.

Permita uma pequena discussão sobre o resultado da distribuição de notas logo após exibir os cards que se mostraram mais prioritário (i.e. que receberam mais $). Isso tende a gerar algumas movimentações de capital, o que é perfeitamente normal, mas ao término da sessão, o que ficou definido é o que será utilizado como prioridade do backlog e orientará os times nas próximas semanas.

Obviamente que nenhum método é perfeito, mas assim como o Planning Poker, este método baseia sua eficácia no consenso entre os envolvidos no projeto e o conhecimento que cada um tem do produto e do mercado para priorizar de uma maneira caótica, mas organizada.

E aí, o que achou desta técnica? Conhece alguma outra? Compartilhe nos comentários!

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

Dicas para um Sprint Planning de sucesso

A Sprint Planning ou Reunião de Planejamento de Sprint é uma cerimônia simples dentro do processo ágil Scrum. Se você investir algum tempo prévio refinando o Product Backlog (tarefa principal do Product Owner) você conseguirá fazer uma Planning produtiva sem sombra de dúvida. Ajuda também evitar algumas más práticas que vou citar no artigo de hoje, que tem como objetivo enriquecer as informações sobre Sprint Planning existentes no Scrum Guide.

O propósito da Sprint Planning

Antes de começar a dizer o que fazer e o que não fazer quando o assunto é Sprint Planning, vale a pena relembrarmos qual o real propósito dela: alinhar o time de desenvolvimento e o Product Owner. Ambos precisam concordar no que será entregue como incremento de produto na próxima sprint e o time deve apresentar um plano de como irá trabalhar para que este incremento seja possível.

Se o Time Scrum possui um Product Backlog refinado e priorizado, o Time de Desenvolvimento será capaz de, juntos, ajustar o escopo da sprint à sua capacidade de produzir código, incluindo nessa previsão as ausências e impedimentos já previstos como férias de colegas, idas ao médico, etc. Geralmente essa conversa inicial para mensurar um escopo exequível e demais assuntos preparatórios dura entre cinco a dez minutos da etapa inicial da Planning, deixando todos alinhados e preparados para quebrar as tarefas macro em sub-tarefas que fiquem mais fáceis de mensurar na etapa seguinte (geralmente usando User Stories).

O Time de Desenvolvimento na Planning

Em primeiro lugar, é imprescindível que todo o time de desenvolvedores esteja disponível para participar da Sprint Planning. Ausências não eximem os ausentes da responsabilidade do que for acordado nesta reunião.

Além disso, é importante que todos os desenvolvedores sejam capazes de dizer o quão disponíveis estarão para a próxima sprint. Jamais considere que 100% dos membros do time estarão disponíveis 100% do tempo e não esqueça de novos membros que possam estar entrando no time e que demoram a se adaptar. Em geral, assumir uma capacidade de produção de 80% do total de horas trabalhadas é uma prática aceitável para cobrir possíveis ausências não previstas (doença, atrasos diversos, detalhes não previstos, bugs urgentes, etc).

Alguns times assumem uma postura confiante de que são 100% produtivos o tempo todo e isso leva-os a uma armadilha do ego que diminui a qualidade do trabalho, de vida e das relações entre os membros do time, que ficam cada vez mais reféns de metas impossíveis e inalcançáveis.

Em segundo lugar, para que a sprint seja minimamente bem sucedida, os desenvolvedores jamais devem superestimar sua capacidade de produzir. Para cada tarefa a ser estimada (seja com Planning Poker ou qualquer outra técnica), cada detalhe que possa afetar a capacidade do time de entregar aquela tarefa deve ser analisado. Ter uma Definição de Pronto bem definida aqui ajuda bastante, pois dá uma noção mais clara de todas etapas que cada tarefa deverá percorrer para ser entregue de fato.

Uma falha comum na definição do escopo e comprometimento com tarefas é ignorar o débito técnico. O time de desenvolvimento tem de estar ciente de que em torno de 25% do seu tempo estará fazendo correções, ajustes e refatorando código existente. Se o time ignorar o débito técnico, seja não deixando esta margem ou qualquer outra, mais cedo ou mais tarde terá problemas técnicos severos e sua produção cairá em sprints futuras.

Outra falha comum é na definição de tarefas. Quer você use User Stories ou não, jamais detalhe com uma granularidade muito fina o que terá de ser feito. Como a responsabilidade dos detalhes de implementação cabe aos desenvolvedores, não há porque discutir e especificar isso abertamente dentro da Sprint Planning. Nada impede, no entanto, que os desenvolvedores se reúnam após a Planning para uma reunião técnica de detalhamento. Planejar demais com antecedência gera desperdício.

E por fim, uma armadilha recorrente é subestimar a importância desse planejamento colaborativo e democrático. Alguns times nomeiam um líder para tomar as decisões por todos, desconsiderando a importância de suas opiniões individuais no processo de planejamento. Isso leva a uma série de problemas, desde estimativas não condizentes com a realidade até problemas de comprometimento de quem se sentir lesado posteriormente com as decisões tomadas nesta ocasião.

O Product Owner na Planning

O papel do Product Owner dentro da Sprint Planning é trazer um Product Backlog refinado, priorizado e um objetivo muito claro. Assim como para manter um exército motivado para uma batalha, todos precisam saber pelo quê estão “lutando”. Esse objetivo cabe ao Product Owner definir e ele deve ser alcançável e mensurável. O P.O. deve ser “firme” na sua decisão de objetivo e ser capaz de responder as dúvidas de negócio relacionados ao incremento combinado.

Com isso em mente, entende-se que o Product Owner deve fazer o “dever de casa” antes de começar a Sprint Planning, para poder definir o objetivo da sprint, a prioridade das tarefas e se cercar do conhecimento necessário sobre o produto a ser desenvolvido do ponto de vista do business. E dentro desse dever de casa, uma falha comum que P.O.s cometem é o de assumir que todo o trabalho não entregue da sprint passada caberá nesse sprint além das novas tarefas que ele priorizou.

Não é porque algumas tarefas haviam sido aceitas na sprint anterior que você pode considerá-las como automaticamente aceitas nesta sprint. Além disso, elas consomem tempo e por não terem sido entregues na última sprint devem ser alvo de uma investigação para entender os motivos do ocorrido.

Outro ponto de atenção são as famosas “mudanças de última hora”. O P.O. jamais deve tentar empurrar tarefas que apareceram de última hora na Sprint Planning e menos ainda após ela. Cabe ao Scrum Master não permitir esse comportamento que pode arruinar a sprint. Se isso acontece com frequência, é sinal de que o Product Owner não está fazendo o seu trabalho direito.

Lembre-se: o foco do P.O. não é delegar as tarefas ao time, mas priorizá-las de modo a garantir o ROI e a entrega de valor ao cliente. Focar em quantidade nunca é a melhor solução.

Anti-padrões

O anti-padrão mais comum em Times Scrum são as sprints irregulares e elas já nascem assim em Sprint Plannings mal conduzidas. Um dos motivos disso acontecer são tarefas mal dimensionadas que não cabem dentro da Sprint e acabam arrastando seu término. Nenhuma tarefa deve entrar na sprint com duração maior do que alguns dias, pior ainda quando insistem em colocar tarefas com o mesmo tamanho da sprint. É problema na certa! Sempre quebre tarefas grandes em pequenas tarefas.

Outro anti-padrão comum de acontecer em Sprint Plannings mal sucedidos é o “over-commitment” ou excesso de comprometimento. Seja porque o time acaba pegando tarefas demais para si, seja por que ele sempre coloca todo o trabalho não finalizado da sprint anterior na sprint atual. Se sobraram tarefas da sprint anterior, é porque as tarefas foram mal estimadas em relação à capacidade do time. Isso deve ser discutido na Retrospectiva e não ser algo recorrente.

Ignorar a Definição de Pronto nas estimativas também é um erro recorrente nos times. Conforme o time vai amadurecendo, é comum que a Definição de Pronto vá ficando mais complexa e que tome mais tempo para que cada tarefa satisfaça-a. Tempo este que não pode ser ignorado sob hipótese alguma.

Concluindo, a Sprint Planning é uma cerimônia simples, mas requer algum investimento de tempo prévio por parte do Product Owner e uma condução assertiva por parte do Scrum Master para que o time inteiro não caia em alguma das armadilhas supracitadas.

Conhece alguma outra dica para a sprint planning ou armadilha que deva ser evitada? Coloque nos comentários!

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

User Stories – Descrição de requisitos que humanos entendem

Dentro da Engenharia de Software temos um sub-campo que é a Engenharia de Requisitos. A Engenharia de Requisitos é a “ciência” que estuda todas as formas de elicitar, analisar, validar, especificar e documentar requisitos, visando gerar insumos para a fase de projeto do software, coordenada por arquitetos de software ou analistas de sistemas, dependendo da empresa.

É nesta “fase de requisitos” que exploramos o quê, como e para quem iremos desenvolver as próximas funcionalidades do sistema. E no Scrum não é muito diferente disso, essa fase existe, embora distribuída em “pedaços”, no início de cada sprint, sendo executada durante a Sprint Planning.

Mas uma coisa que o Scrum não nos diz é: como organizar e/ou documentar as tarefas que devem ser realizadas a cada Sprint? Uma ideia é fazê-lo com User Stories ou Histórias do Usuário: um artefato ágil para especificar requisitos.

Histórias do Usuário

Vamos partir aqui de algumas premissas básicas: toda funcionalidade que vamos desenvolver vai impactar a vida de no mínimo uma pessoa. Se não impacta a vida de ninguém, não deveria existir. O impacto pode ser grande ou pequeno, desde um botão que vai economizar 15 minutos de tarefas repetitivas ou um formulário que vai atender a uma norma legal do governo que poderia fechar a empresa.

Então sempre começamos com um “quem”.

Toda user story, como o próprio nome sugere, começa com um usuário. Este usuário é o ator principal da história, uma persona que todos no time conhecem e entendem como pensa, como age, quais são as “dores”, etc. É importante mapear essas personas que serão utilizadas antes de escrever user stories com elas.

A descrição de uma persona, e isso não faz parte da user story em si, pode ser como abaixo (exemplo da Umbler):

“Luiz é um desenvolvedor e também um empreendedor. Ele cria diversos projetos usando tecnologias como ASP.NET e Node.js e gosta de publicá-los em ambientes confiáveis e com preços razoáveis. O Luiz ocasionalmente tem amigos que o ajudam nestes projetos e quase sempre bola maneiras de rentabilizar os projetos. O Luiz prefere fazer deploy via Git ao invés de FTP por ser mais rápido e confiável, além de gostar de pagar apenas pelos recursos que consome no servidor ao invés de um fixo mensal.”

Eu poderia continuar escrevendo sobre essa persona, mas acho que você já deve ter entendido a ideia.

Assim, quando uma user story começa com “Enquanto Luiz…”, todo o time, que já conhece aquela persona (os mesmos podem ser apresentados antes da leitura de cada história) e já entende as motivações dela, tornando mais fácil tomar decisões futuras. Sempre que o desenvolvedor que estiver implementando uma funcionalidade que é “para o Luiz” estiver em dúvida sobre algo, ele sempre deve se projetar (através de empatia, jovem gafanhoto!) e pensar “se eu fosse o Luiz, como eu gostaria que isso funcionasse?”.

Ponto de vista do usuário

Depois de definirmos para quem estamos desenvolvendo uma nova funcionalidade, devemos definir o que será desenvolvido.

Note que quem escreve as histórias do usuário é quem gerencia o produto: o Product Owner. Como alguém não-técnico e centrado no produto, cabe ao P.O. especificar “o quê” deve ser feito e “para quem”, mas não “o como”. A funcionalidade deve ser descrita a nível de usuário e a nível de negócio, jamais a nível de programação.

Um bom exemplo seria:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web.”

Um mau exemplo seria:

“Enquanto Luiz, eu gostaria de ter um formulário em React para criação de banco MongoDB, com os campos nome do banco, usuário e senha, que quando preenchidos iniciassem uma tarefa de criação de instância no datacenter 03 da Umbler e me retornasse os dados de acesso por email quando estivesse pronto.”

Um dos “mandamentos” é que o time deve se auto-gerenciar, eles devem decidir como cada funcionalidade deve ser desenvolvida. O P.O. sabe que MongoDB é uma demanda do mercado e que devemos ter isso em nosso catálogo de produtos pois temos muitos “Luizes” como clientes, mas se isso deve ser implementado com React, se deve ser assíncrono, em qual datacenter vai ficar, etc é com a galera técnica.

Sendo assim, sua história de usuário deve ser:

  1. sem detalhes de implementação;
  2. focada no que o usuário quer fazer;
  3. explicada do ponto de vista do usuário;
  4. curta e objetiva;

A motivação

O último elemento de uma user story é a motivação. Por que o usuário quer essa funcionalidade? Para quê ela vai servir exatamente (do ponto de vista de ‘entrega de valor’)? O que isso vai impactar na vida dele?

Estas e outras perguntas devem ser respondidas na motivação, que é a terceira e última parte da user story.

Muitas vezes quando estamos desenvolvendo não entendemos porque estamos desenvolvendo aquela feature. E quando isso acontece, geralmente não tomamos as melhores decisões sobre dúvidas que temos. Esta listagem deve ter uma busca no topo ou uma paginação? Esta tarefa deve ser síncrona ou assíncrona? Essa informação será buscada com texto-livre ou através de opções fixas?

A motivação costuma deixar isso tudo muito mais claro e ajudar a criar features que realmente entregam valor ao usuário. Como no exemplo abaixo:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web porque usando serviços de terceiros sai mais caro e a latência é alta.”

Aqui deixamos explícito que o usuário quer ‘MongoDB na Umbler’ porque isso seria mais barato e mais rápido para seus projetos web. Sendo assim, no momento da implementação desta funcionalidade (que confesso pode ser quebrada em tarefas menores, mas é apenas um exemplo), podemos inferir que nossa solução:

  1. não pode ser resolvida através de integrações (add-ons);
  2. tem de ter uma baixa latência (no mesmo datacenter que o projeto dele);
  3. deve ser cobrado na mesma moeda do país dele (as soluções atuais são em dólar);

Essa informação ajuda a nortear as decisões, bem como se aliarmos às informações da persona do Luiz, veremos que se ele gosta de Git, é provável que goste de fazer deploy do seu banco MongoDB via linha de comando também.

Alguns autores defendem que a motivação, o “por quê” da user story, é opcional. Embora eu entenda que em alguns casos até possa ser verdade, eu encorajo a você sempre tentar deixar isso o mais explícito possível, usando aquela “máxima” de “o óbvio sempre precisa ser dito”.

User Stories na prática

O jeito mais tradicional de usar user stories é usar o Product Backlog como insumo e escrevê-las em post its, uma por post it. Algumas equipes costumam imprimir cards já com o esqueleto da user story nele, para não esquecerem nenhuma das três informações centrais e até mesmo com outros campos como o número de pontos daquela tarefa, por exemplo.

Segue um exemplo bem elaborado, que pode servir de inspiração:

User Story Card
User Story Card

Esses cards são muito práticos e podem facilmente ser combinados com técnicas como Kanban (incluindo com Trello), para organizá-los e Planning Poker, para estimá-los (um conceito chamado de Story Points). Uma ressalva aqui é quanto ao “tamanho” da história.

Algumas histórias ficam tão abrangentes que costumamos chamá-las de épicos. Devemos sempre quebrar épicos em histórias de maneiras que elas possam ser “digeridas” pelo time que vai implementá-la. Não existe uma regra clara que diferencia um épico de uma história, mas o bom senso ajuda bastante. Algumas dicas nesse sentido são:

  • se não cabe em uma sprint, é um épico;
  • se consigo quebrar em dois ou mais story cards, é um épico;
  • se no Planning Poker gerou muita divergência de pontuações é um épico;

E um último ponto digno de nota é: não subestime a utilidade de artefatos mais tradicionais da engenharia de requisitos. Vão ter projetos, em que um story card não vai ser o suficiente e você terá de ter um artefato de apoio como um mockup, um diagrama UML ou até um caso de uso. Enquanto que para muitos times e projetos user stories se encaixam como uma luva, para outros, você precisará de técnicas complementares ou até substituir essa técnica por uma mais tradicional. Então fique atendo, Scrum não é bala de prata!

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