Quer aprender mais sobre o Scrum, passar em uma certificação para Scrum Master e se transformar no Scrum Master Definitivo? Confira meu treinamento: www.scrumdefinitivo.com.br/ São mais de 12 horas de aulas, estudos de caso, atividades práticas e simulados preparatórios criados e ministrados por mim, André Gomes, um agilista com mais de 15 anos de experiência profissional, ÚNICO no Brasil com TODAS certificações ágeis da Scrum.org, incluindo PSM1, PSM2 e PSM3 e diretor responsável por liderar times com até 150 profissionais em transformações ágeis de grande porte.
André, bom dia. E como fazemos uma correspondência entre o valor da carta e um valor unidade de medida de tempo real? Exemplo. Carta 1 equivale a 30 minutos. Carta 20 = 10 horas de trabalho.
Olá, estou iniciando na agilidade agora, vim do modelo tradicional, então todo meu modelo de pensamento era sequencial. Estou no primeiro projeto ágil como agilidade, o time e mais maduro em relação as metodologias ágeis, até o momento tem sido bom. Hoje fiz a primeira planning poker, corri no google e achei o seu vídeo, gostei da explicação e amadureci algumas ideias. Os itens que houve discrepância na pontuação, discutimos os pontos que cada um do time, promovi uma nova votação para aquele item e chegamos num concesso. Obrigada pelo conteúdo.
Muito legal André, seus vídeos estão caindo uma luva. O trabalho que estou realizando com o time é exatamente sobre os temas que você explica. A prática de entender o capacity do pelo planning poker ao invés de horas, é algo que venho colocando no dia a dia com o time. Mais uma vez show de bola. E logo mais vamos conversar. Abraço.
André, muitas vezes o planning poker é mais uma coisa que é usada por padrão por quem acha que usar o Scrum é seguir um processo definido. Senti falta no vídeo de uma explicação do porquê seria interessante usar o planning poker, quando decidir adotar e quais ganhos em usar a sequência de Fibonacci por exemplo.
Ola Andre, excelente forma de abordar. Eu tentei usar aqui na empresa, mas usando apenas nùmeros, o pessoal ficou com um pouco de confusao. Então optei por usar a forma com T-Shirt size e por tràhs de cada tamanho eu coloco um numero do fibonacci pra obter dados para as minhas métricas. dai pensei em ficar usando dessa forma até mudar um pouco a forma de pensar aqui.
Andre, tivemos nossa primeira sprint utilizando o conceito de Planning Poker. Ao invés de votar estamos somando as cartas e tirando uma média para definir um valor para estória. O que acha dessa definição de pontos?
Gleidson, uma das partes mais importantes do planning poker são as conversas para entender porque as pessoas estão dando valores diferentes para um product backlog item. Ao tirar a média e não conversar você perde isso e pode estar aumentando seu risco.
O que vc acha de uma planing em que o gestor ja chega com a sprint estimada por ele mesmo onde o intuito da planing é apenas botar o nome de quem vai fazer la na task? 😂😂😂😂😂😂
Acho que seu gestor está promovendo um ótimo Ágil Zumbi 😂 (vídeo explicando o que é Ágil Zumbi: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ltz0jMdqcVU.html)
Andre começando um time novo em um projeto novo. Apos estimar as historias como conseguimos definir o backlog da sprint ate ter conhecimento da real capacidade do time? Nesses casos e melhor trabalhar com kanban?
Olá Antônio! Obrigado por comentar por aqui! Em qualquer modelo de estimativa e trabalho ágil - seja ele Kanban ou Scrum - da primeira vez que o time vai estimar e executar uma atividade eles não sabem qual será a produtividade do time. Entretanto, os profissionais sempre podem basear suas estimativas em suas experiências profissionais passadas, estimando com base em atividades semelhantes que já tenham executado. O grande objetivo da estimativa é ter uma certe previsibilidade do que o time acredita que pode entregar em um determinado periodo de tempo (no caso do Scrum, em uma Sprint). Conforme esse entendimento evolui (junto com a performance do time) eles conseguem ajudar o negócio a planejar melhor quando certa funcionalidade ou requisito estará em produção. Outro ponto legal aqui é que é possível combinar Scrum e Kanban para obter o melhor dos dois mundos. Se tiver interesse, sugiro ler o Guia do Kanban para Times Scrum: andrelmgomes.com.br/artigosedocumentos/Andr%C3%A9%20Gomes%20-%20Guia%20Kanban%20para%20Times%20Scrum%202018.pdf
O vídeo é excelente, mas como nunca trabalhei com planning poker, fiquei com uma dúvida, você pode acordar com o time que cada ponto será um tempo específico? Exemplo, cada ponto ser 1h, 2h e a partir disso o time conseguir estimar de uma forma assertiva?
André, e como fica a divisão em tarefas com o planning poker? Pessoalmente, eu já tive experiências melhores em quebrar a US em tarefas e estimar elas do que deixar "solto" com o planning poker apenas com o planejamento da US.
Oi Catarina! Legal te ver por aqui! No geral eu sempre recomendo que as tarefas fiquem perto de um dia de trabalho, na média (podendo durar um pouco menos, mas de preferência nunca mais do que isso). Trabalhar com tarefas de duração muito pequena faz com que o time foque muito em controlar atividades, o que pode levar à uma micro gestão que não agrega muito valor. Por outro lado, em tarefas muito grandes o risco de erros e retrabalho também aumenta, então não é muito legal. A forma de quebrar os itens do backlog do produto pode variar de time pra time e entre tipos de trabalhos diferentes - usar tarefas ao invés de user stories como você comentou é, por exemplo uma alternativa válida. O ideal é que o time trabalhe com uma unidade de medida que os faça serem produtivos enquanto trabalham de maneira confortável. =)
Fala Bruno! Dando uma resposta mais "purista", não precisa, pois em algumas sprints o time já vai conseguir definir sua velocidade média e usar suas medidas pra poder prever melhor suas estimativas. Inclusive, muitos agilistas acreditam que a velocidade dos times não deveria ser comparada (o que exclui o uso de réguas) pois isso pode gerar micro gerenciamento, além de atrapalhar um pouco no uso de medidas abstratas. No meu ponto de vista, acho que dá sim pra fazer um bem bolado e unir omelhor dos dois mundos, tenho alguns padrões corporativos que ajudem a padronizar mais o fluxo de trabalho e aumentar a produtividade dos times, ao mesmo tempo em que damos liberdade pra eles trabalharem e estimarem suas tarefas, trazendo assim mais comprometimento e qualidade nas entregas finais. =)
Ok, mas como é feita a conversão do valor da carta para o volume de horas? Ex: A maioria votou na carta 8, aí seriam 8h. Mas veio outra demanda bem mais complexa, (sei lá, algo de cerca de 300h) . Aí não tem uma carta para 300. Mesmo que todo mundo vote na carta 20, ainda ficariam 20h apenas. Ou seja, como é este De x Para entre o número das cartas e o volume de horas, pois vai variar de acordo com a demanda.
Olá! No mundo ágil, assim como André comentou no vídeo, está caindo por terra esta questão de números de horas trabalhadas. Até mesmo no livro de Scrum de Jeff ele fala sobre como mensurar o quanto de trabalho precisa ser feito! Não em quanto tempo, mas o quanto de trabalho. Ainda que você queira mensurar em horas, apenas colocando em pratica e mapeando isso, de modo ágil, dando autonomia para o time, você verá quanto tempo será necessário para finalizar um projeto como um todo. 300h? Quebre, quebre, quebre... 20% disso tudo, em teoria, é o essencial! Busque esses 20%, converse com o seu time, dê autonomia a eles e depois de uma semana faça uma retrospectiva ágil com eles para poder entender tudo o que foi trabalhado! Se realmente aquilo que foi estimado foi entregue conforme o planejado e entenda, junto deles, o que foi feito, o que será feito e quais foram os empecilhos e como irão agilizar na próxima sprint! Atualmente eu tenho atuado apenas como Agile Coach numa startup! Na nossa próxima sprint vou implementar o Plannin Poker e vai ser muito interessante! :D Faz 3 meses desde o seu comentário! Você encontrou outra solução amigo? Forte abraços e boas festas de fim de ano! :)
Gostaria que tirasse uma dúvida por favor que ateh o momento não encontrei em nenhum vídeo sobre pontos de história... A partir do momento em que se estimaram os pontos de cada história, como sabemos ou como podemos visualizar em um gráfico burndown por exemplo, o total de pontos de história que Jah foram feitos durante a sprint? Vc diminui os pontos no gráfico somente qndo a história eh terminada ? Ou se uma história demorar 5 dias por exemplo, eu consigo mensurar diariamente quantos pontos foram feitos por dia?
A forma mais fácil é usar uma ferramenta que gere isso automaticamente pra você, como o Jira ou o Azure DevOps (meu preferido). Ele calcula e tira toda essa complexidade das suas mãos. =)
Olá André, parabéns pelo vídeo! Tenho acompanhado seus vídeos, são muito bons! Tenho uma dúvida relativa ao tema. Eu também nunca gostei de estimar em horas e sim em dias. Supondo no Plannig Poker (PP) estimem uma user story igual a 2 e outra igual a 8, eu poderia converter estas estimativas sendo 1 dia e a outra para 3 dias, por exemplo? Pensei algo do tipo: 1~2 = 1 dia 3~5 = 2 dias 8 = 3 dias De 13 em diante, precisaria refinar mais. Penso que eu precise fazer uma relação dos números das cartas com a quantidade de dias na sprint. Poderia fazer assim?
Eu tenho visto essa prática mais como algo durante a transição definitiva para estimativas abstratas. Dá pra fazer, mas no fim do dia não é o ideal pois continua sendo não preciso.
Andre o valor definido não significa a valor em horas ou dias daquela tarefa correto? Esse valor equivale ao nível de complexidade apenas? E esse valor serve para que exatamente?
Com o tempo o time vai aprendendo a medir o que cabe dentro da sprint de acordo com as complexidades. É uma abstração que não precisa das horas pra ser feita. =)
Olá, André! Eu vi que você fechou seu projeto no 99freelas para criadores de artigos do wordpress. Caso queira entrar em contato, eu tenho uma proposta interessante pra você. Sou freelancer e Engenheiro de Produção, tenho uma experiência que pode certamente te ajudar!
