Arquivo para Tag: sprint planning

A reunião de Sprint Planning efetiva

No início de cada Sprint, a equipe Scrum e o Product Owner negociam o escopo do Sprint em uma reunião com tempo limitado para discutir e concordar com o backlog da Sprint, mas como realizar uma Sprint Planning efetiva?

O Product Owner quer que a funcionalidade seja implementada adequadamente e que seja investido o dinheiro do cliente com sabedoria no desenvolvimento, a equipe quer uma missão que consiga cumprir, e claro,  todo mundo quer que a reunião de Sprint Planning termine na hora!

Sprint Planning template

Vou deixar aqui pra você um template de agenda da Sprint Planning, para que seu planejamento de sprint seja bem-sucedido. 

A finalidade da Reunião de Planejamento da Sprint (Sprint Planning) é que o Product Owner e a equipe negociem o que deve ser realizado durante a Sprint, ou, como prefiro chamar, o contrato de Sprint.

Embora valorizemos as interações do cliente em relação aos contratos formais, os contratos ainda podem ser úteis e eu gosto de falar sobre um “contrato de Sprint“.

É simplesmente um acordo entre o Product Owner, que concorda em não mudar o combinado antes do final do Sprint, e a equipe, que se compromete a entregar um conjunto definido de funcionalidades até aquele momento.

Parâmetros Básicos do Contrato de Sprint

Um dos segredos mais bem guardados do Scrum é que um projeto consiste em uma série de mini-projetos de tempo fixo, qualidade fixa e escopo fixo, onde cada mini-projeto tem um teto de custo.

Sendo assim basta somar os resultados de todos os mini-projetos juntos e você tem o valor do seu lançamento.

Como o comprimento do Sprint, o tamanho da equipe e a definição do feito são definidos e fixados para a duração do sprint, apenas o escopo pode variar e, mesmo aqui, a equipe se esforça para definir e cumprir o compromisso.

Da mesma forma o custo depende principalmente das horas trabalhadas, o limite superior é conhecido, mas desde que as coisas acontecem.

Bem como ser chamado para ajudar outro projeto ou a visita de um médico inesperado.

Nestes casos o limite raramente é alcançado. Então você tem um teto de custo.

Enquanto a qualidade é expressa através da definição de feito e só deve mudar ocasionalmente. Como todos os parâmetros são fixos para a duração do Sprint, a única coisa a se concordar é o escopo.

Embora não seja um parâmetro do contrato, a velocidade esperada ajuda a definir a expectativa de quanto pode ser realizado dentro da Sprint.

Permanecendo dentro do time-box

O Scrum Master modera a reunião de Sprint planning, mas o Product Owner vem com a agenda, afinal ele quer que a funcionalidade seja entregue e que o projeto geral esteja no caminho certo.

Independentemente da duração do sprint ou do tamanho da sua equipe, a preparação é a chave para terminar a tempo.

Se você está despreparado, a reunião pode realmente se arrastar!

Antes de começar, a equipe de implementação deve ter visto, entendido e avaliado as histórias – As histórias devem ser pequenas o suficiente para serem implementadas em uma sprint – Os critérios de aceitação deveriam ter sido definidos.

Isso aumenta muito suas chances de o Product Owner aceitar a implementação ja na primeira tentativa.

A equipe deve saber quanta capacidade eles têm disponível. Isto é: as férias, treinamentos, eventos da empresa e outros compromissos devem ser conhecidos e contabilizados antes do início da sprint.

Alguns eventos são imprevisíveis, caso em que você apenas faz uma estimativa razoável de quanto vai consumir, concorda com as prioridades do Product Owner e aceita algumas histórias como “condicionais” – aquelas que você fará se tiver tempo.

Uma reunião de planejamento simples da sprint

Eu usei essa estrutura em vários contextos, incluindo um caso em que o Product Owner  pagou pela equipe por hora e outro com equipes distribuídas em dois ambientes (sites) diferentes.

O quanto você precisa ser formal dependerá de muitas coisas, incluindo o tamanho do projeto, quão bem o projeto está indo, a relação comercial entre o proprietário do produto e a equipe, como as partes cooperam, etc.

Quanto mais desafiador o projeto, mais você precisa pontilhar você e cruzar seu t.

Revise os parâmetros básicos – Data de início e término, hora e local da reunião de revisão do sprint, disponibilidade da equipe e definição de pronto;

Apresentar e discutir cada história – Uma caixa de tempo para cada um pode ser útil para manter toda a reunião no caminho certo, manter uma reserva no final desta seção para histórias difíceis geralmente torna mais fácil seguir em frente se a discussão estiver ficando presa em uma história;

Comprometa-se com as histórias – Percorra a lista, uma de cada vez e por ordem de prioridade, faça com que a equipe se comprometa com cada uma até que ninguém se comprometa mais;

Realize o Acordo – Confirme a lista de histórias confirmadas com o Product Owner.

Como Scrum Master, achei útil confirmar o contrato da Sprint com um e-mail para o Product Owner, nele enviei uma imagem do quadro de tarefas, um pdf da planilha, um dump de tela da página wiki, ou até mesmo o próprio chamado na ferramenta que utilizamos (com os anexos nele) pode ser uma maneira eficaz de capturar o contrato.

Todos ficam sabendo exatamente sobre o que deve ser feito e tanto o Product Owner quanto a equipe têm uma base sólida para examinar o sucesso da sprint e o estado geral do projeto na revisão do sprint.

Conclusão

Em suma, não é porque priorizamos software funcionando em detrimento de documentação que você não “pode” ou “deve” parar de trabalhar em seus documentos, você pode utilizar esse template numa reunião de Sprint Planning e conseguir “fechar” o contrato com sua equipe e seu Product Owner de uma forma simples e transparente.

Em breve enviarei mais notícias das minhas jornadas ágeis e conforme for aprendendo eu acabo compartilhando com você. Um grande abraço e até semana que vem.

 

Criando boas metas de Sprint

Se temos um Sprint Backlog, essencialmente o plano para o Sprint, por que precisamos de uma meta da Sprint? 

Essa é a pergunta que recebo várias e várias vezes em treinamentos e no trabalho. Lembre-se de que o desenvolvimento de software é complexo e não podemos planejar perfeitamente o desconhecido. Quando criamos o Sprint Backlog, existe a expectativa de que mais trabalho surja durante a Sprint. O escopo pode precisar ser renegociado. A Meta Sprint ajuda a focar em um objetivo que queremos alcançar e permite a flexibilidade para negociar o trabalho para atingir esse objetivo.

Criar um objetivo claro da Sprint pode ser um desafio para os times Scrum. Aqui estão quatro problemas comuns com as metas da Sprint e algumas dicas para melhorá-las.

1 – A Meta da Sprint é muito grande.

Meta da sprint é grande

 

Quando temos metas de Sprint compostas (por exemplo, atingir X e Y e Z), estamos- dividindo o foco e não permitindo muita flexibilidade.- – Aqui estão algumas razões pelas quais acabamos nessa situação e sugestões de como pensar de maneira diferente.

  • Estamos trabalhando em vários projetos ou iniciativas não relacionadas. – Quando estamos ordenando o Product Backlog e fazendo o Sprint Planning, considere tanto a coesão do trabalho quanto a iniciativa de prioridade máxima (singular).- Quando colocamos muito em uma Sprint, estamos nos preparando para o fracasso. Acabamos com o desperdício devido í  mudança de contexto e pouco espaço para o trabalho emergir í  medida que aprendemos.- Se parecer impossível escolher um, talvez nossas Sprints sejam muito longas e não ofereçam ao negí³cio a oportunidade de mudar o foco e a direção com a frequência suficiente.
  • Tentamos abranger todos os itens do Product Backlog (PBI).- Quando dou cursos de Scrum, muitas vezes ouço que as equipes consideram sua Meta da Sprint como “completar todos os PBIs”. Isso é o equivalente a não ter uma meta da sprint. Isso parece um pouco preguiçoso.- Sim, chegar a bons objetivos de sprint é difícil.- Aproveite o tempo para fazê-lo.
  • Achamos que a equipe pode não trabalhar tanto se o desafio não for grande o suficiente.- Esse sentimento me lembra um pouco de comando e controle.- Para que equipes auto organizadas- e capacitadas sejam eficazes, devemos acreditar que as pessoas estão comprometidas em fazer o melhor.- Se a meta da Sprint for atingida antes do final da Sprint, os profissionais descobrirão o que mais podem fazer para contribuir de maneira significativa. Isso pode significar entregar mais funcionalidade.- Isso pode significar trabalhar em itens de melhoria contínua.- Confie neles para descobrir.

2 – O objetivo da Sprint é vago.

 

Quando chegamos ao final de um Sprint, toda a equipe está de acordo se o objetivo da Sprint foi ou não alcançado? Caso contrário, o objetivo da Sprint pode ser muito vago. Aqui estão algumas dicas para criar metas de sprint mais claras.

  • Durante o planejamento da Sprint, pergunte “como saberemos se alcançamos a meta da Sprint?” – Se tivermos respostas diferentes ou olhares confusos do Product Owner ou de qualquer membro da equipe de desenvolvimento, precisamos de mais discussão e refinamento da Meta da Sprin.
  • Torne o Objetivo da Sprint mensurável. – Isso ajuda a reduzir a subjetividade, ou opinião.
  • Durante o Planejamento do Sprint, use uma técnica de consenso para- confirmar a compreensão e o comprometimento de todos com o Objetivo da Sprint.- Essa também é uma maneira de ajudar a- incentivar a propriedade da equipe- .

Aqui estío alguns exemplos de objetivos de sprint pouco claros e modificações para torná-los mais claros.

Objetivo de sprint pouco claro Objetivo de Sprint mais claro
Melhore a funcionalidade do carrinho de compras. Simplifique o processo de compra para permitir um aumento nas taxas de conversão.
Melhorar o desempenho. Aumente o tempo de carregamento da página em 10%.
Novo segmento de mercado a bordo. Permita que um novo segmento de mercado adquira o Serviço Y.

3 – A equipe não presta atenção ao objetivo do Sprint durante o Sprint.

Distração na sprint

 

Lembre-se de que temos que realmente prestar atenção a ele para ajudar a fornecer foco.

  • Torne-o visível.
    Escreva a Meta da Sprint no Scrum Board ou prí³ximo dele. Faça-o grande.
    – Use uma cor ou borda que se destaque.
  • Ensine a equipe a- falar sobre o progresso em direção a Meta da Sprint na Reunião Diária.
    – Os membros da equipe de desenvolvimento geralmente fornecem atualizações sobre os itens do backlog do produto em que estão trabalhando, e o objetivo do Sprint nunca é discutido.
    – Faça parte do Daily Scrum.
    – O facilitador pode perguntar í  equipe no final da Reunião Diária como eles se sentem sobre a probabilidade de atingir a Meta da Sprint, se são necessários ajustes no plano diário para reorientar ou se o escopo precisa ser negociado.
    – Isso pode ajudar a melhorar a colaboração da equipe .
  • Faça da Meta da Sprint uma medida de equipe e mantenha-a visível no espaço da equipe.
    – Semelhante à  forma como uma equipe pode rastrear sua velocidade ou cobertura de teste automatizado ao longo do tempo, uma equipe também pode rastrear a conquista da meta do Sprint ao longo do tempo.
    – Manter essas informações visíveis ajuda a equipe a pensar sobre elas.
    – Dados históricos e tendências podem ser usados  para discussão na Sprint Retrospective.
  • Uma palavra de cautela: atingir uma meta de Sprint é passar/falhar.
    – Não existe 85% alcançado.

4 – A Meta da Sprint não parece significativa.

Uma meta de sprint deve fornecer propí³sito.- Isso ajuda a equipe a saber por que eles estão construindo o incremento.- As pessoas querem fazer um trabalho significativo.- As pessoas querem fazer um trabalho que tenha impacto.- Este é um driver para a- motivação intrínseca.- Vamos pensar em maneiras de tornar as metas da Sprint mais significativas para as pessoas que estão construindo o produto.

  • Torne-a focada no negí³cio ou no usuário quando possível. – O que um usuário poderá fazer quando implementarmos esse recurso?- O que uma área de negí³cio poderá alcançar quando implementarmos uma melhoria?
  • Concentre-se em testar suposições de negí³cios e obter feedback.- Muitas vezes não sabemos o que os usuários realmente precisam ou estão dispostos a fazer (porque nem os usuários sabem).
    – Um Product Owner precisa de feedback antecipado para testar suposições sobre valor para os usuários.
  • Torná-la focada na redução do risco.- Provar uma tecnologia ou design é uma parte importante da redução de riscos.- Se soubermos que uma tecnologia não vai atender í s nossas necessidades de desempenho, segurança ou escalabilidade, podemos mudar de direção.- Quanto mais cedo mudarmos de direção, mais barato será o custo da mudança.
Em resumo, uma boa Meta da Sprint pode ajudar uma equipe a se concentrar e ter a flexibilidade de criar um Incremento Feito ao final de uma Sprint.
Uma boa Meta da Sprint ajuda uma equipe a entender o propósito e o impacto do trabalho que está fazendo, o que é um fator determinante para a motivação intrínseca. Roman Pichler fornece um modelo útil- para criar metas de sprint eficazes– .

Se você acha que um desses problemas está afetando sua equipe, escolha uma técnica e experimente, entre em contato e comente aqui!

Planejamento de sprints de trás para a frente?

Sprints, aqui está o problema: muitas equipes planejam suas sprints completamente de trás pra frente. Isso não é totalmente inesperado.

Guia do Scrum é bastante escasso quando se trata do tópico de criar a meta para as sprints, basicamente afirmando que o objetivo da sprint é a meta do sprint, e serve para informar, inspirar e orientar a equipe com relação ao que mesmo explicando por que a equipe está trabalhando no produto.

No entanto, tudo isso parece um pouco autorreferencial – a meta é o que eles estão trabalhando e o que a equipe está trabalhando os traz para o objetivo? – Isso não parece fornecer muita orientação para a equipe.

Não é de surpreender que muitas equipes consigam atingir seus objetivos de maneira ascendente. A equipe examina o que está no topo da lista de pendências, com talvez um pouco de acréscimo do Product Owner e de outras partes interessadas, e estabelece o objetivo ao compilar as histórias e tarefas adicionadas ao sprint.

Para um exemplo simples, imagine que eu quero estar preparado para uma festa que estou organizando hoje à noite. Meu backlog pessoal pode conter tarefas como:

  1. Pegar gelo;
  2. Fazer lanches;
  3. Selecionar músicas; e
  4. Aspirar o tapete.

Acrescento essas quatro tarefas à minha lista diária e decido que meu objetivo é pegar gelo e comida, limpar a casa e escolher algumas músicas.

Fácil de entender e parece muito com uma lista de tarefas simples. E, no entanto, eu posso fazer todas essas coisas e ainda não estar pronto para a festa.

É assim que parece um objetivo de baixo para cima – uma lista de tarefas que, se concluídas, significa que podemos verificar tudo e encerrar o dia – Isso é inútil quando se trata de saber se você está fazendo as coisas corretas; não é uma maneira eficaz de inspirar uma equipe; e não oferece muita flexibilidade caso a situação mude ou novas informações sejam descobertas.

Essas são as razões pelas quais a missão para os sprints devem ser criada de cima para baixo – determinando como seria uma iteração bem-sucedida (“Estou preparado para a festa”), e não como a agregação das tarefas envolvidas.

Deve incluir todos os itens que já são conhecidos e vários que não são. Vejamos como uma equipe pode fazer um melhor objetivo de sprint.

Primeiro, ignore a lista de pendências

Quando a equipe inicia a sessão de planejamento, é tentador simplesmente abrir a lista de pendências, ver quais histórias estão no topo e perguntar ao proprietário do produto se essas histórias ainda são importantes.

Se o Product Owner e o Scrum Master tiverem realizado seu trabalho corretamente, um backlog bem preparado terá os itens mais críticos no topo e estarão prontos para desenvolvimento com requisitos e definições  de pronto claramente definidos.

Pegando as principais tarefas

Em seguida, é um exercício simples arrastar as principais histórias para o sprint, até que a capacidade seja esgotada e concluir o planejamento.

De fato, dada uma ferramenta sólida o suficiente e com uma lista de pendências mantida em boa forma, esse método de planejamento pode ser feito sem uma reunião ou mesmo sem a interação humana. O que também seria completamente errado.

É assim que o planejamento de baixo para cima opera; a equipe “descobre” a meta observando as tarefas que estão prestes a serem concluídas.

Embora isso atenda a todos os critérios de planejamento e, de fato, crie um sprint devidamente formado e cheio de trabalho, não criará um objetivo ou direção para a equipe.

Para usar outro exemplo simples, uma decisão que a maioria das pessoas toma diariamente é decidir o que elas querem comer no jantar.

Às vezes, o método para fazer essa determinação envolve abrir os armários, ver o que está armazenado lá e decidir o que eles querem é uma tigela de sopa, ou as sobras da noite passada.

Certamente, isso servirá ao propósito de deixar a pessoa com menos fome, e pode até ser satisfatória o suficiente, estará longe do que eles “queriam” para o jantar.

Da mesma forma, o objetivo dos sprints devem ser algo que motive a equipe, dê um objetivo à equipe e ajude com as milhares de micro decisões que precisam ser tomadas ao longo do sprint.

Foco nos resultados

Em vez de prestar atenção no que itens individuais precisam ser feitos, a equipe deve se concentrar no resultado que espera obter do sprint.

Essa seria a abordagem de cima para baixo para criar uma meta, prestando atenção ao que a equipe está tentando realizar.

Em nosso exemplo, isso seria garantir que eles estejam preparados para a festa ou que tenham uma refeição satisfatória; em um exemplo real, serão coisas como garantir que um cliente possa entrar em um site, fazer um pedido ou entrar em contato com o atendimento ao cliente para obter suporte.

Com esse objetivo em mente, a equipe pode decidir quais histórias e tarefas serão necessárias para alcançar esse resultado e adicioná-las aos sprints.

A importância das histórias e o que adiar nas sprints

Histórias importantes, mas que não ajudam a atingir o objetivo do sprint atual, podem ser adiadas por enquanto.

À medida que o sprint progride, novas tarefas, cenários e até obstáculos surgirão e precisarão ser trabalhados.

Isso não é incomum; a adição de tarefas (embora geralmente não sejam histórias) ao sprint atual acontece com frequência e pode até ser representada em um gráfico de detalhamento padrão.

Com a compreensão de qual é o objetivo do sprint, adicionar coisas que ajudem a alcançar os critérios de saída pode ser comunicado de uma maneira que faça sentido para todos.

Também ajuda a agir como uma barreira para adicionar coisas que não parecem relevantes ou urgentes.

Certamente, itens de missão crítica e coisas necessárias para manter as luzes acesas entrarão na fila, mas isso ajuda a definir um nível alto para o quão difícil deve ser a inserção de novos trabalhos nos sprints depois de ter sido concluído e planejado considerando o objetivo principal do sprint,

Prever como atingir a meta das Sprints

Depois que o objetivo do sprint é determinado, a próxima tarefa é descobrir como alcançá-lo. Um mecanismo para fazer isso é pensar no que a equipe gostaria de apresentar no final das sprints em uma demonstração.

Ao determinar o que deve estar funcionando, o que deve estar visível e como isso será mostrado, pode ajudar a esclarecer quais tarefas precisam ser trabalhadas.

A equipe pode trabalhar de trás para frente a partir dessa descrição para ajudar a identificar o que não precisa ser desenvolvido imediatamente, especialmente se puder ser mostrado de uma maneira alternativa.

Vi demonstrações em que, depois de inserir alguns dados em um formulário da web, a próxima parte da apresentação foi a saída de uma consulta SQL escrita em um editor de banco de dados.

Não é bonito, mas prova suficiente de que a capacidade estava funcionando.

Parte disso envolve uma boa fatia vertical, mas o objetivo real é fornecer uma visão do que a equipe precisa fazer. A lista de trabalhos que precisam ser concluídos – como feito, feito, feito – deve ficar claro na mente de todos.

Separando o joio do trigo

Desde o final da reunião de planejamento até a extensão completa do sprint, a equipe deve ter uma imagem mental de exibição de seu trabalho e saber como o que eles estão trabalhando ajudará a alcançar esse objetivo.

Se um desenvolvedor se encontrar trabalhando em algo que não considera que impeça a apresentação do recurso, esse trabalho deverá ser deixado de lado para se concentrar ainda mais nos principais componentes do recurso.

Afinal, um bom objetivo do sprint ajuda a inspirar a equipe, dando-lhes algo para visualizar, além de conectar o trabalho que está sendo concluído ao resultado desejado.

Ele deve ser usado tanto taticamente, na determinação da lista de histórias que a integram quanto na estratégia, motivando a equipe para a conclusão.

Decida como medir suas Sprints

Uma vez que a última parte a descobrir é como a meta será avaliada e, em particular, o que a equipe deve acompanhar para determinar o sucesso.

Entretanto, o resultado de um sprint é redigido no tempo futuro, como em que funcionalidade estará disponível no final.

Pode ser que um cliente possa efetuar login ou fazer um pedido, mas o termo operacional é que ele é capaz de fazê-lo, e não o que realmente faz.

Em geral, a equipe de desenvolvimento não é responsável por gerar interesse ou demanda por um recurso ou produto; é mais seu objetivo disponibilizar recursos e produtos.

No entanto, isso não impede a equipe de desenvolvimento de apresentar métricas de sucesso para o que está construindo.

Deixe a equipe decidir

Dependendo do recurso, a equipe pode decidir que, dentro de uma semana após o lançamento, pelo menos uma pessoa utilizará a função em um ambiente de produção.

Contanto que o próprio Product Owner o faça, isso será fácil de conseguir.

Se houver uma melhoria em algo existente, a equipe poderá observar taxas de sucesso, desempenho ou alguma medida existente, e dizer que dentro de um certo período de tempo, isso mudará para melhor.

O que fazer com sprints de trás para frente

Também é útil fazer as duas coisas:

  1. Dizer que dentro de uma semana, um certo número de pessoas usará um recurso com sucesso e,
  2. Dentro de um mês, um número ainda maior o usará.

Pode ser uma combinação de tipos diferentes, medindo o uso e o desempenho, de modo que um número de clientes use o recurso e ele tenha características de desempenho.

Qualquer que seja o pensamento por trás da métrica, o objetivo principal é pensar em primeiro lugar.

Concluindo

Em suma, definir uma meta ajuda a criar uma visão sobre o que a equipe está trabalhando, definindo a métrica ainda mais na mente da equipe de desenvolvimento.

Ambos são extremamente importantes.

Então para criar uma meta de sprint de cima para baixo não é apenas uma parte necessária do processo, pode ser a parte mais importante.

Em conformidade a essa criação que ajuda a orientar tudo, desde a decisão do que fazer nos sprints, até o que precisa ser adicionado e o que não é necessário, e permite que as pessoas se concentrem no que será demonstrado quando tudo terminar.

Em suma, ao iniciar uma sessão de planejamento, decidindo o que você está tentando realizar, levará a um resultado melhor para todos.