
Um dos grandes paradigmas da metodologia ágil é a simplicidade, porém como manter essa simplicidade com uma estrutura complexa e de maneira escalada? Grandes frameworks nos ajudam a organizar as ideias, um deles e talvez o mais famoso é o SAFe (Scaled Agile Framework). Nele são previstas diversas cerimônias e estruturas para que seja possível escalar o SCRUM ou outra metodologia que esteja utilizando. No artigo de hoje falaremos principalmente do SCRUM.
A técnica de priorização MOSCOW é uma abordagem eficaz no planejamento, pois categoriza os requisitos em quatro grupos: “Must have” (Deve ter), “Should have” (Deveria ter), “Could have” (Poderia ter) e “Won’t have” (Não terá). Essa metodologia permite uma visão clara do que é crucial para o sucesso do projeto, concentrando-se nos itens essenciais antes de explorar opções desejáveis. A ênfase na entrega de valor ao cliente é central, assegurando que as prioridades estejam alinhadas com os objetivos principais. Isso facilita a tomada de decisões informadas e o uso eficiente de recursos durante o desenvolvimento, resultando em entregas mais significativas e impactantes.
Em um mundo empresarial dinâmico e competitivo, equipes ágeis tornaram-se essenciais para impulsionar a inovação e a entrega de valor contínuo. A Sprint Planning, uma prática crucial no framework ágil, desempenha um papel central na maximização de resultados e engajamento das equipes. Neste post, exploraremos um método em três fases para a Sprint Planning, visando não apenas atingir metas de curto prazo, mas também alinhar-se estrategicamente com objetivos a longo prazo.
Segundo o Scrum Guide o tempo de duração de uma Sprint planning pode variar de acordo com o tamanho da sua Sprint. Podendo chegar até em 8 horas, para sprints de 4 semanas, porém alocar um time por 8 horas parece inviável nos dias atuais, principalmente em times que estão em formação. Recomenda-se realizar sprints mais curtas, começe com 2 semanas e isso pode reduzir o tempo da sua Planning para até 2h. Verifique se esse tempo é suficiente após algumas execuções.
No mundo do desenvolvimento ágil, os scrum masters desempenham um papel crucial na orientação das equipes para a conclusão bem-sucedida do projeto. Uma das principais responsabilidades de um scrum master é medir com precisão a velocidade de suas equipes. Isto permite-lhes tomar decisões informadas, definir metas realistas e garantir a entrega de produtos de alta qualidade. Um método eficaz para medir a velocidade da equipe é utilizar story points em histórias de usuários. Descubra como os story points funcionam e como eles podem ajudar os scrum masters a medir a velocidade e a eficiência de suas equipes.
Caros colegas Scrum Masters e entusiastas da metodologia ágil,
Aprimorar a capacidade produtiva de uma Sprint é uma busca constante para garantir entregas eficientes e de alta qualidade. Vamos explorar um método inteligente para calcular essa capacidade, considerando pontos de User Stories, demandas urgentes e as inevitáveis interrupções não planejadas. Uma das atividades mais complexas de uma Sprint ou de qualquer planejamento acaba sendo estimar a capacidade produtiva do time. Uma estimativa é basicamente um palpite, porém esse palpite pode ficar melhor com o decorrer do tempo. Neste artigo vamos aprender como contornar certos problemas e ao final, tem uma surpresa! Receba um modelo para lhe ajudar no cálculo da capacidade do time!
Qual é a melhor metodologia para se usar no projeto? Já parou para pensar sobre isso? Se a resposta for “sim” então reserve um tempo e leia o conteúdo abaixo.
Scrum é uma metodologia muito completa, ela prevê diversos ritos ou cerimônias para acompanhamento das atividades. Segundo o livro Scrum: A arte de fazer o dobro do trabalho na metade do tempo, é possível aplicar o Scrum em qualquer atividade, inclusive neste livro você vai poder ver alguns exemplos. Um dos grandes segredos do Scrum é o tratamento de impedimentos, por isso ele permite que a velocidade do time aumente, você simplesmente remove obstáculos que fazem seu time “esperar”, organiza o backlog em uma ordem que faça sentido e que permita o time acelerar em direção ao resultado. Alguns autores mencionam que Scrum não é sobre velocidade, mas sim sobre aceleração!
Então, Scrum é a melhor metodologia, certo? Vamos ver.
No Kanban, o card pode ou não pode voltar?
Para responder a essa pergunta, vou ilustrar uma história.
Sabadão, Solzão, céu azul, um dia lindo para ir à praia. Mas não para Davi, que aproveitará esse lindo dia para colocar a casa em ordem.
Davi tem 3 tarefas para fazer: lavar a louça, estender a roupa e arrumar a casa.
Como Davi tem alguns conhecimentos sobre Kanban, ele sabe que, se fizer as 3 tarefas ao mesmo tempo, será ineficiente, portanto ele só começará a próxima quando terminar a tarefa atual.
Davi pegou alguns posts-its que tinha em sua gaveta e resolveu fazer na parede da sua casa um quadro Kanban. Dividiu em 3 colunas: “Para Fazer”, “Fazendo” e “Feito” e colocou em 3 post-its diferentes, cada uma das tarefas a serem realizadas e as colocou na coluna “Para Fazer”.
O Burndown do Sprint é uma ferramenta gráfica usada na metodologia ágil Scrum para visualizar o progresso de uma equipe durante um sprint. Um sprint é um período de tempo fixo, geralmente de duas a quatro semanas, no qual uma equipe se compromete a entregar um conjunto de funcionalidades ou incremento de produto.
O gráfico de Burndown mostra a quantidade de trabalho restante ao longo do tempo durante o sprint. Ele é representado em um eixo horizontal (tempo) e um eixo vertical (trabalho restante), indicando como a equipe está progredindo em relação ao plano original.
A linha de Burndown ideal, muitas vezes representada como uma linha reta descendente, mostra a quantidade de trabalho que a equipe planejou concluir até o final do sprint. A linha real do Burndown é atualizada diariamente para refletir o trabalho concluído e o trabalho restante.
Em um mundo ágil, a eficiência na elaboração de histórias de usuário é essencial. Descubra como criar histórias que não apenas atendam a um único critério de aceite, mas também permitam fácil percepção, estimativa rápida e conclusão em até 3 dias seria o ideal. Vamos explorar as dicas para uma comunicação eficaz entre Product Owner e Time, promovendo uma execução fluida e bem-sucedida.
– Fique por dentro das novidades
Seja notificado sempre que um artigo for publicado