Logo Agile SchoolLogo Agile School
Logo Agile SchoolLogo Agile School
0
R$0.00 0 item

Nenhum produto no carrinho.

Entregas de valor e organização são coisas que todo Product Owner deve se atentar, ao dividir a execução de tarefas no seu time, por isso, é extremamente importante elaborar uma boa Planning, o primeiro evento da Sprint do Framework Scrum.

A partir dela, serão definidos os objetivos do time, o planejamento do que será realizado, e as ações necessárias para tal, buscando gerar resultados positivos para a organização e equipe, através dos itens que serão executados.

Como todos os eventos do Scrum, na Planning também há input (entrada de informações), o processamento (onde acontecem as decisões) e o output (o que sairá do plano de execução). Por isso, é importante que o time esteja de acordo com a sua capacidade de realização de tarefas, e possíveis impedimentos como: ausência de colaborador, férias, entrada de novos membros…Afinal, tudo isso pode impactar na busca pelo objetivo dessa equipe. Dito isso, vamos às estratégias para que sua Planning ocorra com êxito!

1 – Dedicar 25% da Planning para a resolução de débitos técnicos

Os débitos técnicos costumam ocorrer quando os prazos são priorizados acima da qualidade de um produto ou serviço, causando consequências negativas para a equipe, que em breve, terão que ser resolvidas.

Logo, o frequente acúmulo desses débitos e situações não-resolvidas, acaba virando uma “bomba” para o time, por isso, é de extrema importância ter um tempo separado para priorizá-los de forma a não deixar a Planning exaustiva.

2 – Ter objetivo bem definido

O objetivo é o que move a execução de tarefas, portanto ele deve estar claro para todos que pertencem àquele time. Pergunte-se onde você quer chegar ao final da Sprint, e assim, é possível priorizar as entregas que estarão alinhadas a isso.

3 – Não postergar itens para a próxima Sprint

Uma vez que seu objetivo está 100% definido, é possível estabelecer as normas e políticas para que os itens sejam considerados finalizados, e a relevância dos mesmos.

Tenha cuidado com o tempo de execução de cada um deles, e procure não levar coisas de uma sprint para outra, o que pode gerar os débitos técnicos que citamos anteriormente.

4 – Não sobrecarregar ao time

É crucial entender o quanto de tarefas a equipe é capaz de executar no tempo estabelecido para a Sprint, entretanto, alguns PO’s e Stakeholders possuem o costume de colocar coisas que estão além da capacidade do time.

Afinal, uma vez que, ao final da Sprint, aqueles itens não são resolvidos, a moral de toda equipe é abalada e tanto o PO quanto os colaboradores, têm sua motivação afetada negativamente por isso.

5 – Defina o tempo exato para a Sprint

De acordo com as boas práticas da Agilidade, as Sprints costumam ter uma duração de até quatro semanas, mas é necessário que, uma vez que esse período seja definido ele seja mantido para que o time tenha uma cadência com o restante da organização.

Afinal, durante a review, os stakeholders serão convidados e eles precisam saber se as entregas ocorrerão daqui duas, três ou quatro semanas. Não manter uma cadência pode afastá-los e gerar resultados negativos.

6 – Manter a motivação do time e não trabalhar além da capacidade

Como já falamos anteriormente, um dos tópicos mais importantes para manter uma boa sprint planning, é não sobrecarregar o time, mas também, não trabalhar no seu limite. É essencial deixar espaços de folga na planning, para cuidar de imprevistos sem comprometer o BackLog que foi estimado para resolução.

Além disso, se algum membro estiver com dificuldades, outro colaborador pode auxiliá-lo sem atrapalhar a entrega do time. 

Tudo isso, implica diretamente na motivação da equipe, que o aspecto principal para que a Planning ocorra de forma positiva, então, atente-se ao quanto seus colaboradores estão satisfeitos com as entregas, com os resultados e com as execuções das tarefas, pois um time motivado é o que faz a diferença.

Para concluir…

Agora que você sabe como realizar uma Planning com bom direcionamento está hora de colocar em prática. Comece conversando com sua equipe e entenda como a demanda de cada um funciona. Com isso, vocês, como time, conseguem chegar a conclusão de qual o melhor tempo de sprint para que os resultados sejam alcançados com boa qualidade. 


Na Agile School temos o treinamento Professional Scrum Master onde especialistas do mercado ajudam os alunos a colocarem em prática o que comentamos durante o texto. Acesse aqui e garanta sua vaga.

O que é a Sprint Review?

A Sprint Review é o penúltimo evento da Sprint, geralmente acontece no seu último dia e tem por objetivo a inspeção do Incremento de Produto desenvolvido naquela Sprint e adaptação do Product Backlog caso necessário.

Esse é o único evento no qual, por definição, temos a participação de pessoas externas ao Time Scrum. Esses “envolvidos” na criação do produto, seja um patrocinador, membro da área usuária, parte da governança corporativa, compliance ou qualquer papel que tenha interesse e influência sobre o escopo da solução, devem ser convidados pelo PO para estarem presentes.

Portanto, o fórum participante da Sprint Review é todo o Scrum Team (PO, SM e Dev Team) e os Stakeholders. A ideia é que todos deem feedback sobre o que já foi feito, troquem informação, discutam as oportunidades de mercado para o produto e colaborarem sobre o que vem a seguir.

Como acontece a dinâmica?

A Sprint Review tem uma dinâmica sugerida pelo Scrum Guide. O evento começa com o Product Owner falando sobre o Objetivo da Sprint e quais itens estão “Prontos” – ou seja, aqueles que atenderam a definição de pronto estabelecida – e quais não estão, caso o Sprint Backlog não tenha sido completamente concluído. Contudo, esta não é uma reunião de status e a apresentação do incremento destina-se a motivar, coletar feedback e promover a colaboração.

Em seguida, o Time de Desenvolvimento apresenta o que foi bem dentro da Sprint, que problemas ocorreram e como estes foram resolvidos, e por fim realiza uma demonstração do incremento “Pronto” e que estará disponível para ser lançado.

Por fim, o PO fornece uma visão de budget, roadmap de produto e prováveis próximas datas de entrega. Além de ser mais uma oportunidade para todos colaborarem sobre os próximos passos, possíveis dependências externas e débitos técnicos previamente conhecidos devem estar mapeados e dar transparência para todos os presentes.

Cabe ao Scrum Master garantir que o evento ocorra e que os participantes entendam o seu propósito, ensinando a todos os envolvidos a manter a reunião dentro do time-box (limite máximo de tempo). Como referência, para Sprints de 4 semanas, o time-box da Review é de 4 horas e proporcionalmente menor para Sprints menores.

 

Nenhum incremento pode ser mostrado? E agora?

Mesmo na ocasião do time Scrum não ter um incremento pronto para inspecionar, a Sprint Review deve ser mantida como uma forma de:

1º) dar transparência aos stakeholders do trabalho desenvolvido, não é porque não houve entrega de incremento pronto, que o time não trabalhou;

2º) obter feedback dos stakeholders;

3º) mostrar os avanços e problemas encarados pelo time, como esses problemas impactaram a entrega e como foram resolvidos.

Conclusão

Ciclos curtos permitem que o Time Scrum foque no objetivo da entrega de valor. A Sprint Review tem o objetivo de mostrar a entrega sem causar “distúrbios” ao time ao longo da Sprint, ou seja, como as Sprints são curtas, o loop de feedback é rápido, o stakeholder não fica descolado do andamento do produto e assim o time consegue manter o foco naquilo que é importante, evitando interrupções ao longo do desenvolvimento, e as Reviews passam a ser uma oportunidade tanto de inspecionar o incremento, quanto de adaptar o Backlog do Produto caso seja necessário corrigir o seu curso, seja por estratégia, mudança de mercado ou tecnologia.

Se por outro lado, não houvesse essa oportunidade de ao menos uma vez ao mês, stakeholders estarem alinhados, o risco do time trabalhar em algo desalinhado com a entrega de valor cresceria de forma acentuada. Se assumirmos que o plano inicial está sempre certo e não fizermos esses alinhamentos intermediários, provavelmente ao final da entrega teremos surpresas e frustrações por parte do cliente.

Vamos falar sobre a Sprint Planning, o primeiro evento numa Sprint do Scrum. Nela acontece o planejamento do que o time buscará realizar, o objetivo a cumprir e o desenho de um plano, ou seja, as ações necessárias para cumprir com uma entrega de valor dentro dos próximos 30 dias ou menos.

Como funciona a Sprint Planning?

O evento tem um timebox (tamanho máximo) de 8 horas para Sprints de 30 dias e geralmente utiliza de menos tempo para Sprints menor duração. Os participantes são todos os membros do Time Scrum: Product Owner, Scrum Master e Development Team. Assim como em todos os eventos do Scrum, na Planning temos um input (entrada de informações), um processamento (entendimento, discussão e tomada de decisão) e um output (saída de um plano).

Quais são os inputs da Sprint Planning?

O elemento mais simples (e óbvio) trazido como entrada para a Planning é o Product Backlog (PB). O PB é uma lista extensa e ordenada contendo os desejos e características funcionais e não funcionais que devem ser parte do produto, serviço ou solução a ser construída.

O segundo elemento trazido para a Planning são a capacity e velocity do time. Mas o que que significa isso? A capacity representa a capacidade de trabalho do time, seja a quantidade de pessoas e a quantidade de dias da Sprint. Por exemplo, precisamos saber se todos do time estarão presentes todos os dias da Sprint, se alguém sairá de férias ou terá de ausentar para uma consulta médica. Nessa Sprint temos todos os dias “úteis” e dedicados ou teremos um feriado, treinamento ou evento corporativo?

Outro item a ser considerado é velocity ou velocidade do time. Isso diz respeito ao histórico de quanto de trabalho esse time conseguiu executar nas Sprints anteriores. Todos esse itens nos ajudarão a fazer um bom planejamento.

O terceiro elemento trazido para a Sprint Planning é a Definition of Done ou Definição de Pronto. Esse item é essencial pelo simples fato que estamos executando um planejando das atividades de trabalho para a Sprint. Para termos um planejamento mais assertivo, é necessário que todos os membros do time tenham um mesmo conceito de completude. Quais as atividades devem ser preenchidas para que cada item da Sprint possa ser considerado pronto?

Por último, temos o plano de melhoria que foi gerado na Retrospectiva da Sprint anterior. Por que isso deve fazer parte da Planning? Pelo simples fato que ao menos uma ação de melhoria traçada na Retrospectiva da última Sprint deve fazer parte da Sprint atual. Isso é uma regra que obriga o time Scrum a ter dinâmica de melhoria contínua e toma tempo do time, e portanto, deve ser considerada no planejamento.

O processamento da Planning

Dentro da Planning acontecerá o processamento de todos esses inputs mencionados. O time terá um momento de alinhamento, discussão, priorização, estimativa, criação para que possa construir um plano para Sprint que se inicia.

Não existe uma regra formal para executar a Planning. O framework Scrum permite o formato que o time achar conveniente. Uma sugestão pode ser o Product Owner iniciar com uma explicação sobre os primeiros itens do Product Backlog, que são os itens de maior prioridade. O Time de Desenvolvimento pode fazer a estimativa ou quebrar esses itens em tarefas menores, caso isso já não tenha sido feito numa atividade de refinamento.

O Time de Desenvolvimento determina a quantidade de trabalho que pode realizar dentro da Sprint. Isso geralmente é feito por heurísticas (práticas complementares), ou seja, não fazem parte do Scrum e cada time escolhe a prática que mais se adequa. A prática mais conhecida de estimativa é o Planning Poker, porém estimativas em horas ou projeções estatísticas (Probabilistic Forecast) da quantidade de trabalho que o time consegue executar também podem ser utilizadas.

Quais os outputs da Sprint Planning?

São três os elementos resultantes da Planning. Esses itens são uma decomposição um do outro e podem ser sintetizados pelas expressões PORQUE, O QUE e COMO.

O primeiro elemento é o Sprint Goal que simboliza uma meta a ser alcançada na Sprint, demonstra um objetivo comum compartilhado e um PORQUE para o time.

Em segundo lugar temos o Sprint Backlog que por sua vez pode ser dividido em duas partes. A primeira parte do Sprint Backlog é composto por O QUE nós vamos fazer. Esses são os PBIs (Itens do Product Backlog) que o time escolhe fazer dentro da Sprint, sendo uma previsão do que o time consegue construir. E por último vem o COMO o time vai trabalhar. São as tarefas que o time vai executar para implementar os PBIs.

Resumindo, temos o Sprint Goal (PORQUE) que pode ser atingido por meio dos PBIs (O QUE), que podem ser implementados por meio das tarefas (COMO), ambos são sintetizados no Sprint Backlog.

Esses são os Inputs, Processamento e Output de uma Sprint Planning. O grande princípio a ser levado em conta é, como tudo no Scrum, que seu time deve inspecionar o melhorar continuamente. Avalie o que estão fazendo, teste novas abordagens e reestruture a Planning para que seja mais efetiva possível na construção de um plano para a próxima Sprint.

Te vejo na próxima, Scrum On!

Momento curiosidade:
Você sabia que a Sprint Planning tinha um outro formato no passado?
Não sei há quanto tempo você já trabalha com Scrum, mas se for há mais de 5 anos, com certeza já ouviu falar dos termos Sprint Planning 1 e Sprint Planning 2. Pode ser que alguns desavisados ainda utilizam esses termos, porém eles não fazem mais parte da definição do framework Scrum. Por volta de 2013 o Scrum Guide foi revisto e Planning passou a ser um evento único, sem as tais divisões.

menu