O que é uma reunião de planejamento de sprint?
As equipes de desenvolvimento de software contam com sprints que os ajudam a acompanhar o ritmo do lançamento de novas versões de software, chamadas iterações. Com demandas que competem para serem incluídas em uma iteração, as equipes de desenvolvimento precisam saber, com clareza, em quais devem se concentrar durante um sprint. Por exemplo, será que algumas correções de bugs devem vir antes da implementação de novos recursos? Ou vice-versa?
O Agile também se tornou popular em outras áreas e setores, pois essa abordagem focada pode aumentar a eficácia, a produtividade e a qualidade.
Antes de um sprint começar, a equipe do projeto participa de uma sessão de planejamento, que chega a duas decisões importantes:
Meta de sprint: se refere aos produtos resultantes durante o sprint.
Listas de pendências do sprint: a lista de tarefas a serem concluídas durante o sprint para alcançar o objetivo.
O planejamento de Sprint é um exercício limitado por tempo, que geralmente dura uma hora semanal durante cerca de oito semanas.
O planejamento de sprint se ajusta ao Scrum e outros métodos Agile
O planejamento de sprint desempenha um papel importante no universo das metodologias de desenvolvimento Agile que priorizam a capacidade de reação, flexibilidade e melhoria contínua, e buscam ajudar as organizações a se destacarem no gerenciamento do trabalho em um mundo em que prioridades e mercados estão mudando rapidamente. À medida que os requisitos do cliente e a concorrência evoluem, o planejamento de sprint determina o que deve ser feito em seguida.
Falando sobre softwares, o planejamento de sprint determina quais mudanças ou recursos do produto podem ser entregues e como fazer a implementação deles de forma mais eficiente na próxima iteração. Esse processo de planejamento garante que a equipe aborde um volume de trabalho realista e comece pela tarefa mais importante. Afinal, existe um limite do que pode ser feito durante um sprint sem comprometer a qualidade.
O planejamento de sprint também é usado para métodos Agile híbridos, como Scrumban, uma combinação de Scrum e Kanban, sistema de trabalho com estratégia pull associado à Toyota. O Scrumban combina iterações de tamanho fixo com um processo de entrega padronizado, o que significa que mais de uma equipe especializada pode trabalhar em um único item de trabalho.
Para entender como o planejamento de sprint funciona com o Scrum: primeiro, ele ajuda a analisar as principais funções e processos do método. Durante o planejamento de sprint, a equipe do projeto trabalhará com o proprietário do produto (a principal parte interessada pelo produto na empresa) e será conduzido por um Scrum Master (o indivíduo que atua como um servidor-líder, garantindo que o processo flua, treinando a equipe e ajudando todos a se comunicarem e a entenderem a missão).
Esses participantes criam um backlog de sprint, uma série de recursos ou alterações extraídos da lista de pendências do produto e que será desenvolvida e implantada no final do sprint. A lista de pendências é determinada pela meta de sprint, ou seja, os produtos resultantes dele.
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
“Um hábito supersimples, mas muito útil, é: não use siglas ao anotar as metas de sprint, roteiros e definição de conclusão. Nunca pressuponha que todos as conhecem bem, especialmente quando há recém-chegados na equipe. Evite o excesso de explicações e retrabalho. Quando as siglas são escritas por extenso, você também se obriga a reavaliar se alguns conceitos antigos se mantêm atuais. Você (e sua equipe) se lembram de tudo que deve acontecer ao longo do fluxo de ponta a ponta?”, pergunta ela.
Quer uma abordagem mais ágil para gerenciar projetos?
Saiba tudo sobre o gerenciamento de projetos ágeis e dicas para ajudá-lo a começar a implementar as práticas recomendadas ágeis PM.
Obtenha o e-book gratuito para implementar as práticas recomendadas do método Agile
Qual é a duração de uma reunião de planejamento de sprint?
Especialistas em Scrum geralmente recomendam gastar cerca de uma hora por semana em planejamento de sprint, ou seja, um total de até oito horas. Projetos altamente complexos podem exigir mais tempo, e podem levar quase o dobro do tempo, dependendo da maturidade da equipe Scrum.
Para saber por que o tempo desde a formação de uma equipe é um fator tão significativo para determinar a duração de um sprint, vamos analisar o trabalho do psicólogo Bruce Tuckman, que, em 1965, propôs a ideia de que o desenvolvimento de um grupo passa por estágios definidos:
Formação: quando uma nova equipe se reúne ou novos membros são incorporados a ela
Ataque: quando começam as discussões sobre a forma de trabalhar
Normatização: quando os membros da equipe chegam a um acordo sobre as funções e relacionamentos de cada um
Execução: quando uma equipe começa a manter um ritmo, maximizando a produtividade e minimizando atritos entre colegas de equipe
Portanto, não é uma surpresa que as equipes que ainda estão nos estágios iniciais do desenvolvimento precisem de mais tempo de planejamento para criar consenso do que os times que já trabalham juntos há mais tempo.
Esse fator de aclimatação pode explicar por que o planejamento de sprint é visto por alguns críticos como uma perda de tempo. Em contrapartida, especialistas em Scrum dizem que o planejamento de sprint é um precursor vital para um sprint. Por um lado, o planejamento melhora a eficiência de um sprint e impede que os desenvolvedores acabem dando um passo maior que a perna. O processo também cria um consenso com o proprietário do projeto sobre os produtos do sprint. Além disso, os desenvolvedores do método Agile sentem que têm autoridade sobre o trabalho e que não precisam estar constantemente conciliando demandas que competem com sua capacidade de trabalho.
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
Definir a meta de sprint é crucial para o sucesso
Especialistas dizem que o esforço para definir a meta de sprint gera retornos, pois ajuda a equipe a garantir que o sprint forneça o valor máximo para a empresa e seus clientes.
A equipe determina a meta de sprint em colaboração com o proprietário do produto, e a declaração de meta deve ser curta (apenas algumas frases).
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
Como outros objetivos em geral, uma boa meta de sprint é SMART (específica, mensurável, alcançável, realista e limitada ao tempo). Por exemplo, uma boa meta de sprint para uma equipe freelancer de desenvolvimento de plataformas on-line pode ser: “Criar um gerador de relatório de receitas que faça a verificação da renda de um freelancer obtida durante um ano fiscal” ou “Criar uma interface multimídia de mensagens dentro da plataforma para os freelancers e clientes não dependerem de serviços de terceiros”. Objetivos claros facilitam a comunicação de metas e evolução com quem não está diretamente envolvido no sprint.
É necessário levar alguns itens em consideração ao elaborar uma meta de sprint. Por exemplo, como as metas de nível inferior, projetadas para serem alcançadas dentro de um único sprint, se alinham com objetivos estratégicos de alto nível ou com a visão de longo prazo de um produto? Quais tarefas na lista de pendências do produto são relevantes para a meta de sprint e devem ser incluídas na lista de pendências do sprint? E as metas de sprint são alcançáveis e realistas com base no número de recursos e desenvolvedores disponíveis? Lembre-se de considerar feriados, férias dos membros da equipe e eventos da empresa ao analisar o tempo disponível.
A meta de sprint não é uma mera formalidade a ser concluída e que, em seguida, é deixada de lado quando o sprint começa. Além de definir a direção de tudo que deve ser concluído durante o sprint, a meta também é o padrão de avaliação do êxito na revisão pós-sprint. Então, vale a pena ter uma meta que a equipe possa cumprir de acordo com seus recursos.
Definir o backlog de sprint determina o plano de trabalho da equipe
O backlog de sprint compreende uma série de tarefas a serem concluídas durante um sprint e é elaborada de forma colaborativa pela equipe Scrum e pelo proprietário do produto. No entanto, o proprietário geralmente não se envolve no processo de planejamento granular de sprint. As equipes Scrum, por definição, são auto-organizadas, para que seus membros conduzam o processo. Muitas vezes, o proprietário do produto não tem como saber como a equipe deve realizar as tarefas. Na verdade, o envolvimento muito próximo do proprietário nessa parte do planejamento pode até ser contraproducente.
Em vez disso, a função do proprietário do produto geralmente é especificar a meta de sprint, preparar os itens candidatos ao backlog de sprint, determinar os requisitos para esses itens e negociar com a equipe de desenvolvedores a composição dessa lista até que todos cheguem a um consenso.
É claro que o proprietário do produto tem direito de fazer perguntas sobre o backlog de sprint, a ordem dos itens e a forma como devem ser realizados. A equipe Scrum preparará uma lista de itens de backlog que se comprometem a entregar e outra de tarefas e subtarefas necessárias para isso. No processo, a equipe também estima o esforço necessário para concluir cada item de backlog, geralmente usando termos curtos, como tamanhos de camisa ou pontos de história.
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
O volume de trabalho para cada sprint deve ser gerenciável, normalmente incorporando uma margem de tempo extra. É comum alocar 20% da capacidade de sprint como “tempo de folga”. Para isso, as equipes usam uma métrica chamada velocidade de sprint, que é o volume de trabalho, em pontos de história, concluído durante um único sprint. Normalmente usamos os valores do sprint mais recente, uma prática chamada de “tempo de ontem”, já que se acredita que a velocidade do sprint anterior é a forma mais precisa de prever o próximo. A velocidade do sprint é ajustada com base na disponibilidade dos membros da equipe e na criação da equipe Scrum.
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
O planejamento de sprint pode ser dividido em duas fases: a reunião do O QUE e a reunião do COMO. Durante a reunião do O QUE, definimos a meta de sprint, criamos a lista de pendências e determinamos a capacidade da equipe. Já na reunião do COMO, a equipe Scrum lista as tarefas necessárias para completar cada item de backlog. No setor de software, essas tarefas geralmente abrangem o desenvolvimento, a implementação, os testes e a documentação. Cada uma deve levar apenas alguns dias para ser concluída. Se uma tarefa demorar mais do que isso, é um indicativo de que os itens da lista de pendências são muito grandes para o trabalho de sprint e talvez precisem ser divididos.
Em seguida, a equipe Scrum estima a quantidade de trabalho em horas de pessoas necessárias para concluir itens de backlog e calcula a provável duração total das atividades do sprint. Com base na capacidade da equipe Scrum, os membros podem solicitar um ajuste de iteração para aumentar ou diminuir o escopo de trabalho se sentirem que podem enfrentar um volume maior (ou menor) durante um sprint.
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
Quem participa das reuniões de sprint?
Uma sessão de planejamento de sprint inclui informações vindas de três partes interessadas principais: a equipe Scrum, o Scrum master e o proprietário do produto.
A equipe Scrum é composta pelos desenvolvedores que assumem a parte prática do projeto. Durante a reunião de planejamento de sprint, é função da equipe estimar e discutir o que pode e deve ser assumido durante um único sprint. A equipe Scrum então se comprometerá a cumprir as metas de sprint, trabalhando no projeto e garantindo a entrega de uma nova iteração que atenda aos requisitos expostos durante o planejamento de sprint.
O Scrum master atua como facilitador, articulador e treinador da equipe Scrum. Geralmente são desenvolvedores mais velhos e experientes que entendem como o trabalho da equipe se desenvolve em objetivos estratégicos abrangentes, metas de longo prazo e relacionamento com o cliente. O Scrum master gerencia os relacionamentos externos da equipe (incluindo com o proprietário do produto) e garante que a equipe siga os princípios do desenvolvimento ágil. Na sessão de planejamento de sprint, o Scrum master orienta a equipe a definir objetivos adequados para cada sprint, agindo como negociador entre desenvolvedores e o proprietário do produto.
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
O proprietário do produto é a principal parte interessada, o indivíduo ou grupo para quem o projeto está sendo desenvolvido. O tanto que o proprietário do produto se envolve no planejamento de sprint varia, mas ele tende a não interferir no planejamento de tarefas de nível inferior. Em vez disso, sua autoridade se destina a determinar a meta de sprint, selecionar e priorizar itens na lista de pendências e estipular requisitos de aceitação para cada item.
Qual é o objetivo da reunião de revisão de sprint?
Ironicamente, o planejamento de sprint começa com o fim do sprint anterior. Ao término de cada sprint, organize uma reunião de revisão, na qual a equipe Scrum analisa o que realizou e demonstra o funcionamento de novos recursos e funções.
Geralmente, a equipe Scrum, o proprietário do produto, o Scrum master, outros desenvolvedores da empresa, a gerência e outras partes interessadas participam da revisão de sprint. Mantenha um clima informal e uma conversa fluida.
Durante a sessão, avalie o trabalho da equipe em relação à meta de sprint definida durante a reunião de planejamento. A equipe realizou cada item do backlog de sprint? Você cumpriu a meta abrangente de sprint? Quais lições podem ser aplicadas no próximo sprint?
Como se preparar para uma reunião de planejamento de sprint
Antes de uma reunião de sprint, vale a pena verificar o roteiro de produto, um documento estratégico que descreve a evolução de um produto ao longo de uma extensa série de sprints e iterações. Os itens que eventualmente aparecem no backlog de sprint devem estar alinhados com o roteiro do produto, por isso, vale a pena ter o roteiro fresco em mente. Se os itens de backlog do sprint não estiverem alinhados com o roteiro do produto, o produto pode perder a direção.
Também é necessário realizar uma reunião de pré-planejamento com representantes da equipe Scrum, o Scrum master e o proprietário do projeto. Essa reunião deve ser conduzida alguns dias antes da reunião principal de planejamento de sprint e dá a todos a chance de preparar a lista de pendências (backlog), ou seja, o processo de priorizar, estimar, detalhar e determinar critérios de aceitação para itens de backlog. Esse processo acelera a sessão de planejamento e permite maior produtividade durante um sprint, combinando com maior precisão o volume de trabalho necessário e a capacidade disponível.
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
“Recomendo adicionar um ponto de controle no meio do sprint ou atividade de preparação para reunir a equipe com o proprietário do produto e revisar as histórias adicionadas ao próximo backlog de sprint, fazer perguntas e obter esclarecimentos bem antes da próxima reunião de planejamento de sprint. Isso tornará seu planejamento muito mais eficiente e pode até mesmo reduzir o tempo pela metade”, diz ela.
Baixe o modelo de lista de pendências de produto – Excel
Baixe o modelo de backlog de sprint – Excel
Outras partes interessadas importantes podem se beneficiar de uma reunião de pré-planejamento, pois todos têm a chance de garantir que estejam satisfeitos com a priorização dos itens na lista de pendências. Também é um bom momento para integrar o designer de UX para começar a pensar em possíveis alterações necessárias para itens de backlog concluídos.
Quando se trata de técnicas para determinar a priorização de itens de backlog, correções de bugs e reparos de falhas geralmente estão no topo do backlog de sprint. Outra prática comum é usar a priorização de negócios. Com ela, analisamos quais itens da lista de pendências oferecem maior benefício para a empresa e, assim, atribuímos a maior prioridade a eles. Alguns fatores possíveis devem ser considerados, como o risco envolvido ou mitigado pelo item de backlog e o valor comercial que esse elemento deve gerar. Se essas métricas estiverem faltando, o método MoSCoW, que prioriza cada item como “precisa ter”, “deveria ter”, “poderia ter” ou “não terá”, também pode ser uma técnica útil. E, claro, você deve aproveitar a experiência do Scrum master na priorização das listas de pendências; afinal, esse profissional atua como conselheiro da equipe.
Uma reunião de pré-planejamento desse tipo também ajuda o proprietário do produto a garantir que os itens da lista atendam à definição de conclusão da equipe, ou seja, algo que possa ser executado imediatamente. Como os sprints não permitem muito desperdício de tempo, as equipes de desenvolvimento terão um conjunto de critérios para itens de backlog que indicam se os itens estão prontos para o trabalho.
Geralmente, preparamos primeiro os itens de backlog com os maiores valores de preparação. Para uma equipe típica trabalhando em tarefas típicas, a definição de pronto pode incluir qualquer ou todos os seguintes: atribuição de valores de ponto da história; remoção das dependências; criação de exemplos testáveis; e definição de critérios de aceitação. Uma sigla simples para explicar uma definição sólida de concluído é INVEST (independente, negociável, valioso, estimado, pequeno e testável). As histórias validadas usando o INVEST estão prontas para passar para o backlog de sprint.
Da mesma maneira, o proprietário do produto pode economizar tempo durante a reunião de planejamento estabelecendo critérios de aceitação para itens de backlog. Uma descrição simples e objetiva do que uma implementação de item de backlog deve e pode alcançar agiliza as discussões sobre os critérios de aceitação durante toda a reunião de planejamento.
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
As etapas de uma reunião de planejamento sprint
Estas são as etapas de uma reunião típica de planejamento de sprint:
Anuncie a visão geral: antes da reunião começar, o Scrum master lembra a equipe sobre os objetivos que querem alcançar e como isso se encaixa nas metas estratégicas ou no roteiro de um produto. Também é útil se o proprietário do produto falar sobre dois itens que têm potencial para se tornar sprints, a fim de contextualizar a direção do produto a médio prazo.
Forneça todas as informações necessárias: agora é a hora de trocar informações que os envolvidos com o próximo sprint devem saber, como adições recentes à lista de pendências, alterações na disponibilidade dos membros da equipe ou novas partes interessadas.
Apresente a velocidade alvo para o próximo sprint: a velocidade é o número total de histórias de usuários concluídas durante um sprint. Geralmente, esse valor é derivado do último sprint concluído (o princípio do tempo de ontem). Se os membros – não os números – da equipe Scrum mudaram desde então, use uma velocidade média dos três últimos sprints. Se for o primeiro sprint de sua equipe, oito pontos de história por desenvolvedor por sprint é um valor aproximado adequado, e você pode ajustar depois sempre que precisar.
Confirme a capacidade da equipe: a capacidade da equipe é calculada como o número total de horas de trabalho do sprint. Então, para uma equipe Scrum de dez pessoas trabalhando dez horas por dia em um projeto de dez dias, a capacidade será de 1.000 horas. No entanto, as equipes geralmente deduzem de 20 a 40% da capacidade máxima para ter um valor mais realista que leve em conta o tempo de inatividade, a sobrecarga e as horas de trabalho perdidas. Além disso, dadas as dependências inevitáveis entre itens de backlog, a capacidade prática pode ser ainda mais reduzida por uma espécie de efeito dominó, no qual as tarefas atrasadas atrasam as próximas. Se for previsto algum fator que afete a velocidade do sprint ou a capacidade da equipe, ele deve ser registrado nesta fase.
Revise a definição de concluído: essa definição é uma visão resumida da iteração resultante no final do sprint. É importante que aqueles que realizam o trabalho e aqueles que o inspecionam concordem com uma definição de concluído antes do sprint começar.
Decida quais itens de backlog do produto incluir no backlog de sprint: nesta fase, a equipe Scrum também decidirá se algum item de backlog é grande demais para ser concluído em um único sprint e precisa ser adiado.
Determine as necessidades de recursos, delineie quem fará o quê e estime o trabalho a ser feito: se houver trabalho demais para a equipe Scrum, ficará evidente para o Scrum master neste momento. Atribua o trabalho e garanta que as atribuições dos indivíduos correspondam à capacidade de cada um.
Defina os critérios de aceitação: os critérios de aceitação são padrões mensuráveis para saber se um item de backlog foi concluído com êxito. A especificação deles é prerrogativa do proprietário do projeto, mas a equipe Scrum pode ter alguma margem de negociação através do Scrum master.
Confirme e registre hipóteses, novos problemas ou dependências identificados durante o planejamento: essas informações devem ser integradas à lista de pendências do produto.
Estabeleça o consenso: essa é uma prerrogativa do Scrum master. Ao mesmo tempo, a equipe Scrum e o proprietário do produto indicarão se é o melhor plano possível para o sprint.
Explique as tarefas envolvidas: se a equipe Scrum precisar de mais informações, principalmente sobre as especificidades dos itens no backlog de sprint, faça outras perguntas necessárias neste momento, para transformar histórias de usuários em tarefas detalhadas.
Como organizar e conduzir uma reunião de planejamento de sprint
Pode ser sua primeira reunião de planejamento de sprint ou talvez você queira deixar suas reuniões mais produtivas. É essencial saber o que precisa ser abordado e, além disso, ter certeza de que a logística é perfeita e os suprimentos estão à mão.
Para um sprint de um mês, é necessário orçar cerca de quatro horas de reunião – uma para cada semana de sprint. O ideal é uma reunião presencial, mas se alguns membros da equipe estiverem trabalhando remotamente, certifique-se de que sua tecnologia de conferência funcione bem.
Quem for participar presencialmente precisará de uma área de trabalho grande o suficiente para acomodar todo mundo. Tenha um sistema visual, como notas adesivas, um quadro branco ou uma ferramenta eletrônica (forneça algumas notas adesivas de cores diferentes para representar itens de backlog). E, já que a equipe vai ficar naquele espaço por um tempo, vai precisar de lanches e café para espantar o mau-humor.
Baixe a pauta da reunião de planejamento de sprint
Antes da reunião começar, pendure a meta e a velocidade do sprint na sala de reunião, para que todos possam consultá-la.
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
Use notas adesivas para documentar itens de backlog: cada cor de nota se refere a um item diferente. Você precisará de pelo menos três cores: uma para histórias de usuários, uma para tarefas e outra para bugs. As notas adesivas são, então, fixadas na parede ou quadro em ordem de prioridade. Você pode recriar essa lista de pendências visual para os membros remotos da equipe.
Quando estiver tudo pronto, inicie a reunião comemorando o que a equipe conseguiu alcançar no último sprint para começar o processo com o pé direito. Em seguida, o Scrum master ou proprietário do produto apresentará as histórias potenciais para o backlog de sprint, incluindo aquelas que ficaram de fora do último sprint. Se isso não aconteceu no pré-planejamento, as histórias terão que ser dimensionadas. Existem diferentes maneiras de se fazer isso. Algumas equipes usam o tamanho da camiseta (XP, P, M, M+, G, XG, XXG, XXXG), enquanto outras atribuem pontos de história usando a sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21).
Não importa qual sistema você usa, os valores relativos são mais importantes do que brutos. Comece com duas histórias, decida qual é maior e as coloque em ordem. Em seguida, pegue uma terceira história e decida o tamanho dela em comparação com as outras duas, adicione-a ao ranking e assim por diante. A soma dos pontos da história deve ser menor do que a velocidade da equipe. Todos os itens da lista de pendências de produto que vão para as pendências de sprint também precisam ser validados se estão prontos para serem trabalhados.
Para a equipe Scrum, analisar a história de cada usuário pode levar muito tempo. Além disso, existem várias etapas a serem consideradas. Por exemplo, a história está atualizada? Sua definição mudou? Há novas informações a serem consideradas? As previsões sobre a história ainda são válidas?
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
Uma vez fixada a definição da história, é necessário dividi-la em tarefas (algumas delas se tornarão histórias de usuários por conta própria). A equipe decidirá os conjuntos de habilidades especializadas, se houver, necessários para encarar essas tarefas e também perguntará como testar a história.
Assim como nos pontos e velocidade da história, a duração estimada das tarefas deve ser menor do que a capacidade da equipe para o sprint. Tarefas e histórias de usuário que são movidas para o backlog de sprint receberão prazos, levando em conta os dias úteis e se algum membro da equipe vai sair de férias ou trabalhará na equipe Scrum durante meio período.
Lembre-se: não são apenas as histórias de usuários e suas tarefas relacionadas que tomam espaço na lista de pendências; correções de bugs também. Ou seja, elas assumem parte da capacidade da equipe Scrum. Mas como se decide quanto espaço cada item de backlog receberá? Uma maneira é alocar uma proporção fixa de capacidade (digamos, uns 20%) para correção de bugs. Outra é conectar essa etapa a histórias de usuários e depois dimensioná-las e priorizá-las como novas histórias de usuários.
Por fim, a equipe Scrum, o Scrum master e o proprietário do produto criarão uma definição de concluído, incluindo uma métrica de teste para ajudar a garantir a qualidade da nova iteração.
O ideal é que a sessão de planejamento de sprint seja concluída após alcançar alguns resultados desejados, como: deixar a equipe Scrum à vontade com o objetivo e, por sua vez, alinhar o objetivo com a visão estratégica e o roteiro do produto; documentar adequadamente o plano de sprint; criar um gráfico de burndown (que plota o trabalho que ainda falta em relação ao tempo restante) para mostrar o progresso planejado; e garantir que todos os desenvolvedores na equipe Scrum saibam exatamente no que vão trabalhar quando o sprint começar.
Com a lista de pendências em ordem e o objetivo em mente, o sprint está pronto para começar.
Planejamento de sprint para o marketing ágil
Os desenvolvedores de software são profissionais do método Agile por essência, mas não são os únicos. Muitas equipes de marketing também estão abraçando com entusiasmo o Agile.
Obviamente, os profissionais de marketing não têm iterações fixas de software para lançar, e sim projetos contínuos (muitas vezes de longo prazo) que abrangem uma variedade de atividades. Assim, precisam constantemente conciliar prioridades em prazos curtos e médios, muitas vezes tendo um objetivo claro para cada novo conjunto de esforços.
Então, para os profissionais de marketing, adotar métodos ágeis é uma maneira de reagir de forma coordenada às mudanças nas condições do mercado, além de maximizar a eficiência e seguir em direção a uma meta claramente determinada.
Na maioria das vezes, os sprints e o planejamento de sprint para o marketing e o desenvolvimento de software são muito semelhantes. No entanto, há algumas diferenças significativas.
Por um lado, a duração dos sprints de marketing tende a ser mais curta do que os do desenvolvimento de software. O sprint de marketing típico não leva mais do que duas semanas. Já no desenvolvimento de software, é comum encontrar sprints que duram um ou dois meses.
Em segundo lugar, as mudanças na lista de pendências durante o sprint são mais comuns no marketing do que no desenvolvimento de software. Essa diferença se refere a restrições mais rígidas impostas pelas tarefas técnicas do desenvolvimento de software. Já o marketing permite mais fluidez.
Em terceiro lugar, é provável haver especializações mais abrangentes em uma equipe Scrum de marketing do que em uma de desenvolvimento de software, já que o primeiro time engloba mais disciplinas.
Práticas recomendadas para o planejamento de sprint
Especialistas sugerem algumas práticas recomendadas para aproveitar ao máximo sua reunião de planejamento de sprint.
Ao enviar o convite para a reunião, inclua a pauta. Você também pode adicionar um link às histórias de usuários candidatas a partir da lista de pendências de produto, para que os desenvolvedores tenham tempo para analisá-los antes da reunião de sprint.
Quando o proprietário do produto for preparar uma lista de histórias de usuários candidatas a partir do backlog do produto, deve escolher aquelas que totalizam valores maiores do que a capacidade da equipe Scrum. Isso porque o Scrum master e a equipe provavelmente rejeitarão algumas ou as incluirão em um sprint posterior. Se o proprietário do produto tiver escolhido histórias abaixo da capacidade total da equipe, as rejeitadas resultarão em desperdício durante o sprint.
Lembre-se que, durante a reunião de planejamento de sprint, quem assume o comando é o Scrum master, e não o proprietário do produto. Assim como a equipe Scrum, o proprietário do produto atua mais como colaborador da reunião: responde a todas as perguntas dos desenvolvedores, explica histórias de usuários e negocia critérios de aceitação sob a mediação do Scrum master.
Também vale lembrar como cada um pode contribuir de forma mais eficaz e o que se deve ou não esperar de outros participantes. O proprietário do produto, por exemplo, assume a liderança na criação da meta de sprint e é responsável por definir o escopo do sprint, detalhando a fundo cada história de usuário (finalizada com uma definição de concluído) e priorizando o backlog do produto.
O Scrum master organiza a logística da reunião e negocia métricas importantes, como a velocidade de sprint e a capacidade prática da equipe. Ele também assume a liderança na finalização do backlog de sprint e negociações moderadas entre o proprietário do produto e a equipe Scrum.
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
A equipe Scrum reúne todas as informações necessárias para o próximo sprint e se compromete com um backlog de sprint que é capaz de entregar de maneira adequada. Também é dever da equipe informar o Scrum master se ela não estará disponível em algum momento do sprint.
Uma fonte comum de disfunção no planejamento de sprint, comenta o treinador ágil, Kevin Brunner, é a pessoa responsável pela lista de pendências. Se ela não se preparar para a reunião ou não confiar que a equipe seja capaz de tomar suas próprias decisões, a mentalidade do time passa a ser resistente em vez de comprometida. Os desenvolvedores, em particular, podem reclamar que a reunião é uma perda de tempo, já que as histórias de usuários não foram esmiuçadas ou porque a presença deles não é necessária, uma vez que o Scrum master e o proprietário do produto tomarão todas as decisões unilateralmente.
Para promover uma dinâmica de equipe saudável, Brunner diz que o Scrum master pode seguir três princípios:
Visualizar: imagine-se no fim de um sprint com uma iteração concluída com êxito e trabalhe de trás para frente para negociar critérios de aceitação e extrair as informações necessárias para a entrega dessa iteração. A visualização dá à equipe um produto final concreto em torno do qual seus esforços se unirão.
Cultivar: é o hábito de tomar decisões em equipe por consenso e de ouvir e respeitar a opinião de cada membro. O cultivo também fornece à equipe o tempo necessário para tomar decisões e garante a aquisição dos principais aspectos do sprint, como escopo e estimativa de tempo.
Refletir: é olhar para trás após o fim de um sprint, a fim de perguntar o que deu certo ou não e como as coisas podem ser melhoradas.
Uma dinâmica de equipe saudável, afirma o treinador ágil Tony Solomita, é definida por três hábitos: preparar a lista de pendências antes da reunião de planejamento, ouvir o que todos têm a dizer no processo de gerar previsões e de finalizar o backlog de sprint, e respeitar a autoridade do proprietário do produto sobre a necessidade de um recurso específico e a dos desenvolvedores sobre a forma como esse recurso será entregue.
Perguntas frequentes sobre planejamento de sprint
Confira, a seguir, as perguntas mais frequentes sobre planejamento de sprint:
Qual é a melhor maneira de lidar com as dependências entre tarefas? Existem várias maneiras de mitigar os possíveis efeitos do desperdício de tempo das dependências de tarefas. Primeiro, o planejamento das tarefas durante a reunião de planejamento de sprint pode minimizar ou eliminar ativamente as dependências complexas à medida que as histórias de usuários são divididas em tarefas. Em segundo lugar, você pode determinar uma margem de tempo entre tarefas dependentes sempre que possível. Terceiro, o uso de designs e técnicas de desenvolvimento vagamente unidos e adaptáveis, como objetos simulados, pode ajudar os desenvolvedores a lidar com os efeitos das dependências. E, por último, ter desenvolvedores trabalhando próximos uns dos outros facilita a comunicação e pode antecipar problemas relacionados à dependência.
Com qual volume de trabalho cada membro da equipe deve se comprometer? Usando o princípio do tempo de ontem, cada membro da equipe deve se comprometer a encarar no máximo a mesma quantidade de pontos atingidos na história do último sprint.
Como as iterações são planejadas se o tamanho da equipe varia? Embora as mudanças recorrentes no tamanho da equipe não sejam o ideal, às vezes, são inevitáveis. Se o tamanho de uma equipe mudar, calcule a média de pontos de história atingidos por cada desenvolvedor no último sprint e a multiplique pelo número de desenvolvedores que participarão do próximo sprint para obter um valor aproximado da velocidade de sprint. Você pode ter que ajustar ainda mais esse número com base nos indivíduos que deixam a equipe e nos que se juntam a ela.
Como as despesas gerais (por exemplo, o tempo gasto em reuniões ou escrevendo e-mails) são contabilizadas? Não há uma regra geral para calcular essas despesas, uma vez que variam de equipe para equipe. A maioria dos times simplesmente pressupõe que se gasta um tempo constante em despesas gerais para cada sprint e que a velocidade dos sprints anteriores reflete com precisão o período alocado com esses gastos.
Como contabilizar a correção de bugs? Há algumas maneiras de abordar esse tema. Uma delas é tratar os bugs como histórias de usuários, estimando a quantidade de trabalho envolvido e outros itens no backlog de sprint. Outra abordagem mais arriscada é não atribuir pontos de história a bugs, o que reduz a velocidade da equipe. O risco dessa abordagem é que só funciona se você o mesmo volume de trabalho for dispendido na correção de bugs em cada iteração. Se esse volume varia, a velocidade mudará drasticamente a cada sprint, tornando o planejamento de sprints futuros muito mais difícil.
Por que as iterações devem ter sempre a mesma duração? A resposta, em poucas palavras, é ritmo e consistência. A sequência de um sprint progride muito mais suavemente se seguir um ciclo regular e fácil de prever, simplificando bastante o planejamento de sprint.
Como contabilizar o tempo gasto em testes e documentação? A maneira mais fácil é incluir o tempo gasto em testes e documentação como uma tarefa separada para cada história de usuário. Uma alternativa é criar um item separado no backlog de sprint para esses dois processos.
As estimativas de recursos devem ser revistas durante o planejamento de iteração? Apenas se a estimativa original for extremamente imprecisa.
As estimativas de tarefas devem ser revisadas durante uma iteração? Não. Depois de concluir o planejamento de iteração, não mexa nas estimativas de tarefas. É claro que o Scrum master provavelmente anotará por que a equipe optou por mudar uma tarefa, para poder refletir essas informações no planejamento futuro de sprint.
Todas as equipes devem seguir o mesmo cronograma de iteração? Isso depende do número de equipes Scrum trabalhando em conjunto e da disponibilidade de pessoal de apoio. Se não houvesse restrição em ter várias equipes começando e finalizando iterações ao mesmo tempo, a sincronização resultante seria um grande benefício para a gestão. Isso reduziria o risco de o trabalho de uma equipe acabar obrigando outra a fazer alterações no backlog de sprint, já que os times poderiam coordenar o planejamento de sprint entre eles. Na prática, no entanto, as equipes Scrum não trabalham isoladamente. Também há um número limitado de indivíduos que assumem cargos de apoio em várias equipes Scrum ao mesmo tempo e que preferem iterações com datas de início e término escalonadas.
Erros comuns de planejamento de sprint e sinais de alerta
Um Scrum master experiente conhece os sinais de alerta que indicam que o planejamento de sprint não está indo tão bem quanto deveria. Fique de olho nestes itens.
Se uma equipe não consegue, repetidamente, concluir o backlog de sprint ( se, com frequência, deixam histórias de usuários para o próximo sprint), é um sinal de que o grupo está superestimando sua própria velocidade e se sobrecarregando. Para garantir que o planejamento seja preciso (e útil de verdade), o Scrum master precisa diminuir a velocidade da equipe.
Se, no entanto, os mesmos recursos estiverem sendo jogados repetidamente para o próximo sprint, é provável que o time esteja evitando lidar com certas histórias de usuário ou correções de bugs deliberadamente. É importante analisar bem essa situação para saber se há problemas nessas histórias de usuários ou bugs que não foram considerados durante o planejamento de sprint.
Uma falha na conclusão do backlog de sprint também pode apontar para um design exagerado, ou seja, os desenvolvedores estão indo muito além de seu trabalho e fazendo mais do que o necessário. Isso exigiria uma revisão dos requisitos dos recursos solicitados para garantir que a equipe não esteja gerando esforço desnecessário.
O que não fazer: erros comuns no planejamento de sprint
Uma sessão de planejamento de sprint pode ser sabotada por algumas armadilhas comuns:
O proprietário do produto cria um backlog de sprint por conta própria sem a participação dos desenvolvedores: isso prende a equipe Scrum a uma lista de pendências sobre a qual não puderam opinar. Essa armadilha reduz o envolvimento do time com o processo de planejamento e a probabilidade de o sprint cumprir sua meta declarada.
O Scrum master apresenta as histórias de usuários candidatas pela primeira vez para os desenvolvedores durante a reunião de planejamento de sprint: uma perda desnecessária de tempo, pois faz com que as reuniões de planejamento se arrastem por muito mais tempo do que deveriam. Desde que você tenha preparado o backlog, é muito simples incluir as histórias de usuários candidatas na pauta da reunião. A presença de histórias de usuários que não atendam aos critérios INVEST causará problemas semelhantes.
A equipe não entra em consenso sobre uma definição de concluído: quando isso acontece, a equipe entrega um produto incompleto no final da iteração. Um sinal de que esse problema pode ocorrer é não dividir todos os itens do backlog de sprint em uma série de tarefas gerenciáveis.
Subtarefas não são devidamente estimadas: você pode detectar esse problema quando as tarefas não parecem ser estimadas com precisão em relação umas às outras (uma tarefa muito complexa não é um múltiplo grande o suficiente de uma tarefa simples).
O Scrum master leva muito tempo para inserir o backlog de sprint em uma ferramenta eletrônica: isso pode significar que a equipe Scrum trabalhará às cegas nos primeiros dias do sprint, incapaz de enxergar seu progresso real.
As histórias de usuários candidatas não são discutidas com outras partes interessadas antes de serem adicionadas ao backlog de sprint: novamente, esse tipo de erro faz com que as partes interessadas insatisfeitas solicitem a alteração do backlog após o início do sprint. Alguns proprietários do produto podem fazer isso também, mesmo depois de concordarem com o backlog de sprint original, o que pode ser muito frustrante. Para algumas equipes Scrum, uma alteração na lista pode ser praticamente inevitável. Se for o caso, há uma série de possíveis soluções. Uma delas é aumentar a duração do sprint ou subestimar de maneira intencional a capacidade para ter mais margem de negociação caso precise acrescentar mais trabalho. Para equipes cujo trabalho é frequentemente interrompido, a melhor solução pode ser seguir adiante e reduzir a quantidade de tempo gasto no planejamento de sprint, já que a atividade não vai atender à finalidade proposta.
A equipe Scrum não detalha tarefas e subtarefas adequadamente: isso geralmente é um sinal de que a equipe está entediada com o planejamento e quer seguir adiante. O detalhamento inadequado corre o risco de desequilibrar as estimativas assim que os desenvolvedores descobrirem que as tarefas tomarão mais tempo do que o previsto.
Os membros da equipe relutam em discutir etapas: essa armadilha faz com que uma parte do time não tenha a oportunidade de aprender.
A equipe não tem um Scrum master para assumir o comando do planejamento: sem um Scrum master para controlar o ritmo da sessão de planejamento, os participantes tentarão economizar o máximo de tempo possível, o que pode resultar em uma sessão de planejamento frustrantemente ineficaz ou na falta de detalhes importantes.
Aprimore o planejamento de sprint com o Smartsheet for Project Management
Do gerenciamento de tarefas simples e planejamento de projetos à gestão de portfólio e recursos complexos, o Smartsheet ajuda a melhorar a colaboração e acelerar a velocidade do trabalho — aumentando sua produtividade. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período. Experimente o Smartsheet gratuitamente hoje mesmo.