Podcasts about Planning poker

Pílula Ágil: Planning Poker - Estimativa Colaborativa para Projetos Ágeis O Planning Poker é uma técnica ágil popular para estimar o esforço necessário para completar as histórias de usuário em um projeto. Essa ferramenta colaborativa promove a discussão, o consenso e a compreensão do escopo do trabalho entre os membros da equipe. Cartas: Cada membro da equipe recebe um conjunto de cartas com valores numéricos, geralmente seguindo a sequência de Fibonacci (1, 2, 3, 5, 8, 13, ...). Escolha de uma História: A equipe escolhe uma história de usuário para estimar. Estimativa Individual: Cada membro da equipe, de forma independente, avalia a complexidade da história e escolhe uma carta que representa sua estimativa. Reunião e Discussão: As estimativas são reveladas simultaneamente. Se houver divergências significativas, a equipe discute os motivos e busca um consenso. Nova Rodada: Se necessário, uma nova rodada de estimativas é realizada até que a equipe chegue a um consenso. Consenso: Estimula a discussão e a colaboração, levando a um consenso sobre a complexidade das histórias. Compreensão: Aumenta a compreensão das histórias de usuário entre os membros da equipe. Priorização: Ajuda a priorizar as histórias com base em suas estimativas. Realismo: Promove estimativas mais realistas e evita o viés individual. Aprendizado: A equipe aprende a estimar melhor ao longo do tempo. Equipe Coesa: É importante que a equipe tenha um bom entendimento dos critérios de aceite e da definição de "feito". História Bem Definida: A história de usuário deve ser clara e concisa para que todos possam compreendê-la. Ambiente Colaborativo: Crie um ambiente de respeito e confiança para que todos possam expressar suas opiniões. Revisão das Estimativas: Revise as estimativas periodicamente para garantir que elas continuem sendo precisas. O Planning Poker é ideal para: Equipes Ágeis: É uma prática comum em metodologias ágeis como Scrum e Kanban. Estimativa de Histórias de Usuário: É especialmente útil para estimar o esforço necessário para desenvolver novas funcionalidades. Planejamento de Sprints: Ajuda a determinar a quantidade de trabalho que pode ser concluída em um sprint. Em resumo, o Planning Poker é uma ferramenta poderosa para as equipes ágeis, proporcionando uma forma colaborativa e eficaz de estimar o trabalho e tomar decisões mais informadas. Gostaria de saber mais sobre alguma outra técnica ágil ou tem alguma dúvida específica sobre o Planning Poker? Como funciona o Planning Poker?Benefícios do Planning PokerDicas para um Planning Poker EficazQuando Usar o Planning Poker?

Dicas para Facilitar o Processo de Refinamento do Backlog O refinamento do backlog é uma prática fundamental no Scrum para garantir que o trabalho a ser realizado em um sprint esteja claro, bem definido e priorizado. Para otimizar esse processo, considere as seguintes dicas: Frequência: Estabeleça reuniões regulares e curtas para o refinamento do backlog, idealmente antes de cada sprint planning. Foco: Concentre-se em um número limitado de itens a cada reunião para evitar sobrecarga e garantir que todos os detalhes sejam discutidos. DEEP: Garanta que os itens do backlog sejam detalhados (Detailed), estimados (Estimated), emergentes (Emergent) e prontos (Ready). INVEST: Verifique se os itens atendem aos critérios de INVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable). Envolvimento: Incentive a participação de toda a equipe de desenvolvimento, incluindo o Product Owner e o Scrum Master. Diversidade de Perspectivas: A colaboração promove a diversidade de perspectivas e ajuda a identificar possíveis problemas ou lacunas nos requisitos. Kanban: Utilize um quadro Kanban para visualizar o fluxo dos itens do backlog e identificar gargalos. Mapas Mentais: Crie mapas mentais para visualizar as relações entre os diferentes itens e requisitos. Software de Gestão de Projetos: Utilize ferramentas como Jira, Trello ou Azure DevOps para gerenciar o backlog e facilitar a colaboração. Documentação Compartilhada: Utilize ferramentas de colaboração como o Google Docs ou o Confluence para criar e compartilhar documentos sobre os itens do backlog. Valor de Negócio: Priorize os itens com maior valor de negócio para o cliente. Estimativas: Utilize técnicas de estimativa como o Planning Poker para auxiliar na priorização. Critérios: Defina claramente os critérios de aceite para cada item do backlog, garantindo que a equipe entenda o que significa "feito". Consenso: Obtenha o consenso da equipe sobre a definição de pronto. Adaptação: Revise o backlog regularmente para garantir que ele esteja alinhado com as necessidades do negócio e com as mudanças no projeto. Eliminação: Remova itens do backlog que não sejam mais relevantes ou que tenham sido completados. Transparência: Mantenha todos os membros da equipe informados sobre as mudanças no backlog. Feedback: Incentive o feedback constante para melhorar o processo de refinamento. Habilidades: Invista no desenvolvimento das habilidades da equipe em relação ao refinamento do backlog e às técnicas ágeis. Mentoria: Ofereça mentoria para os membros da equipe que necessitem de suporte. Ao seguir essas dicas, você poderá otimizar o processo de refinamento do backlog, garantir que a equipe esteja alinhada e aumentar a eficiência do seu projeto. 1. Reuniões Regulares e Curtas:2. Investimento em Detalhes:3. Colaboração da Equipe:4. Uso de Técnicas Visuais:5. Ferramentas Digitais:6. Priorização Constante:7. Definição de Pronto Clara:8. Revisão Contínua:9. Comunicação Eficaz:10. Treinamento e Desenvolvimento:

. Gostaria de explorar alguma dessas dicas com mais detalhes? Temas que poderíamos abordar: Técnicas de estimativa: Planning Poker, Fibonacci, etc. Ferramentas de gestão de projetos: Jira, Trello, Azure DevOps Como criar uma definição de pronto eficaz Superar desafios comuns no refinamento do backlog Qual tópico te interessa mais? livro Jornada do Usuário no Contexto Ágil A jornada do usuário, no contexto ágil, é uma representação visual que mapeia a interação de um usuário com um produto ou serviço, desde o primeiro contato até a conclusão de uma tarefa ou a obtenção de um objetivo. Essa ferramenta poderosa permite que as equipes ágeis compreendam profundamente as necessidades, expectativas e desafios dos seus usuários, alinhando o desenvolvimento do produto diretamente com as suas experiências.

Refinamento do Backlog: Alicerce da Agilidade O refinamento do backlog é uma prática fundamental no Scrum que garante que o trabalho a ser realizado em um sprint esteja claro, bem definido e priorizado. É nesse momento que a equipe se reúne para detalhar, estimar e priorizar os itens do backlog do produto, preparando-os para serem trabalhados em sprints futuros. Clareza e Entendimento: Assegura que todos os membros da equipe compreendam os requisitos e o escopo do trabalho. Priorização: Permite que a equipe priorize os itens de acordo com o valor de negócio e a urgência. Estimativas Realistas: Auxilia na criação de estimativas mais precisas para o tempo de desenvolvimento. Redução de Riscos: Identifica e mitiga potenciais riscos antes que eles se tornem problemas maiores. Melhora da Colaboração: Fortalece a colaboração entre os membros da equipe, o Product Owner e outros stakeholders. Reuniões Regulares: Estabeleça reuniões curtas e frequentes para o refinamento, garantindo que o backlog esteja sempre atualizado. Foco em Detalhes: Detalhe os itens do backlog, definindo critérios de aceite claros e concisos. Estimativas: Utilize técnicas como o Planning Poker para estimar o esforço necessário para cada item. Priorização: Priorize os itens com base no valor de negócio e na urgência. Divisão de Tarefas: Divida itens grandes em tarefas menores e mais gerenciáveis. Visualização: Utilize ferramentas visuais como quadros Kanban ou mapas mentais para facilitar a compreensão. Colaboração: Incentive a participação de todos os membros da equipe, incluindo o Product Owner. Invista em uma Definição de Pronto clara: Todos devem saber o que significa um item estar "feito". Utilize ferramentas adequadas: Softwares de gestão de projetos como Jira, Trello ou Azure DevOps podem auxiliar no processo. Adapte-se às mudanças: O backlog é dinâmico e deve ser ajustado conforme as necessidades do projeto evoluem. Revise o backlog regularmente: Certifique-se de que os itens ainda são relevantes e estão alinhados com os objetivos do projeto. Reuniões longas e improdutivas: Mantenha as reuniões focadas e com tempo limitado. Falta de detalhes: Itens mal definidos podem levar a mal entendidos e retrabalho. Estimativas imprecisas: Estimativas imprecisas podem comprometer o planejamento do sprint. Falta de priorização: Sem uma priorização clara, a equipe pode se perder em tarefas menos importantes. Em resumo, o refinamento do backlog é um processo contínuo e fundamental para o sucesso de um projeto ágil. Ao investir tempo e esforço nesse processo, as equipes podem garantir que o trabalho seja entregue com qualidade, dentro do prazo e atendendo às expectativas do cliente. Por que o Refinamento do Backlog é Importante?Como Realizar um Refinamento de Backlog Eficaz?Dicas para um Refinamento de Backlog de Sucesso:Erros Comuns a Evitar:

Alternativas ao Planning Poker para Mensurar Histórias de Usuário O Planning Poker é uma técnica popular para estimar o esforço necessário para completar uma história de usuário, mas existem outras abordagens que podem ser igualmente eficazes, dependendo das necessidades da sua equipe e do contexto do projeto. Por que considerar alternativas ao Planning Poker? Equipes remotas: O Planning Poker pode ser desafiador para equipes geograficamente distribuídas. Dificuldade em chegar a um consenso: Algumas equipes podem ter dificuldade em chegar a um consenso durante as rodadas de estimativa. Necessidade de uma abordagem mais rápida: Em alguns casos, pode ser necessário estimar um grande número de histórias de forma mais rápida. Alternativas ao Planning Poker: T-Shirt Sizing: Como funciona: As histórias são classificadas em tamanhos de camiseta (P, M, G, GG, etc.), com base em sua complexidade. Vantagens: Rápido e fácil de entender, ideal para equipes com pouca experiência em estimativas. Desvantagens: Pouco preciso para estimativas detalhadas. Fibonacci: Como funciona: Utiliza a sequência de Fibonacci (1, 2, 3, 5, 8, 13, ...) para representar o esforço. Vantagens: Permite uma maior granularidade nas estimativas em comparação com o T-Shirt Sizing. Desvantagens: Pode ser mais complexo para equipes iniciantes. Bucket System: Como funciona: As histórias são divididas em diferentes "baldes" (pequeno, médio, grande, etc.), com base em critérios pré-definidos. Vantagens: Simples e visual, ideal para equipes com diferentes níveis de experiência. Desvantagens: Pode ser menos preciso para estimativas detalhadas. Affordability: Como funciona: Cada membro da equipe recebe um número limitado de "pontos" para gastar nas histórias. Vantagens: Incentiva a equipe a priorizar as histórias e a considerar o valor de negócio. Desvantagens: Pode ser mais complexo de implementar e requer um bom entendimento dos conceitos de economia. Estimativas Relativas: Como funciona: As histórias são estimadas em relação a uma história de referência. Vantagens: Ajuda a equipe a ter uma visão mais clara do tamanho relativo das histórias. Desvantagens: Requer uma história de referência bem definida. MoSCoW: Como funciona: As histórias são classificadas em Must Have, Should Have, Could Have e Won't Have. Vantagens: Foca na priorização e no valor de negócio. Desvantagens: Não fornece estimativas precisas de esforço. Fatores a Considerar ao Escolher uma Alternativa: Tamanho da equipe: Para equipes pequenas, métodos mais simples como T-Shirt Sizing podem ser suficientes. Experiência da equipe: Equipes com mais experiência podem se beneficiar de métodos mais sofisticados como o Fibonacci ou o Affordability. Natureza do projeto: Projetos com requisitos complexos podem exigir métodos mais precisos como o Planning Poker ou o Fibonacci. Preferências da equipe: A escolha do método deve ser consensual entre os membros da equipe. Recomendações: Comece com um método simples: T-Shirt Sizing ou Bucket System são boas opções para iniciantes. Adapte o método às suas necessidades: Não hesite em adaptar os métodos às suas necessidades específicas. Revise o método regularmente: Avalie periodicamente se o método escolhido está funcionando bem e faça ajustes se necessário. Combine diferentes métodos: Você pode combinar diferentes métodos para obter uma estimativa mais precisa.

#5amMesterScrum Lightning Talk 1,215 Live - Stirring Up Trouble on Planning Poker for a Monday (Metric Monday) - Today's topics: (1) Last week we talked averages better than single points.  Today I wanted to explored a controversial idea that planner poker is not always needed to establish points?  It might depend on how your team is operating? Please like and subscribe and share 5amMesterScrum.  Please send me your topics.   You are are doing Great Please Keep on Sharing. 5am Mester Scrum 5am Mester Scrum Lightning Talk 1,215 went live on Youtube, LinkedIn and Facebook Metric Monday 8/5/2023 from Philadelphia, PA  Happy Scrumming, Please Don't forget to sign up to our 5amMesterScrum newsletter for freebies.  Which gets you free access to the Slack group, if you would like to share with or learning from a group of agile people! Definitely a free copy of Change Volume 20 in PDF form  https://5ammesterscrum.com/free-the-change-volume-20-pdf-book-copy-for-joining-our-weekly-newsletter/  Watch the video in our YouTube Library as well. Social Media: - search 5amMesterScrum or #5amMesterScrum  and you should find us and if not please let us know LinkedIn, Youtube, Facebook, Instagram, Twitter, TikTok     Podcasts: (search 5amMesterScrum) 

Join Brian Milner and Hunter Hillegas as they unveil Goatbot, Mountain Goat Software's latest AI innovation designed to transform how we access and learn from Agile and Scrum resources. Tune in to hear Hunter delve into the intricate process of developing and testing this AI platform. Overview In this episode of the Agile Mentors Podcast, Brian and Hunter Hillegas, Mountain Goat Software’s CTO, dive deep into the capabilities of Goatbot, an AI-powered tool that makes accessibility of reliable Agile and Scrum knowledge easier. Developed by Mountain Goat Software, Goatbot answers queries using the company’s extensive array of training materials, blog posts, and articles, ensuring that users receive precise and reliable information. The discussion also covers the rapid advancements in AI technology, exploring its burgeoning role in coding and testing. Join Brian and Hunter as they explore how Goatbot was created, its impact on learning Agile methodologies, and the exciting future of AI in software development. Listen Now to Discover: [1:05] - Brian welcomes our beloved Chief Executive Officer at Mountain Goat Software, and creator of Goatbot, our Agile & Scrum AI, Hunter Hillegas. [4:06] - Hunter explains how he and the team were able to make an AI platform to answer Scrum and Agile questions accurately every time. [7:07] - Hunter talks about the experience of working with and developing AI from a long-term programmer's perspective. [10:35] - Hunter and Brian share that Goatbot is available, accessible, and free on the Mountain Goat Software website. [12:25] - Hunter walks through the process of creating Goatbot and some of the challenges the team faced to bring it to life. [15:42] - Brian invites you to come on over and test out Goatbot, run it through its paces, and tell us what you think. Goatbot is free to use and specifically programmed to answer all your Agile and Scrum questions. Ask away! [17:23] - As a technologist, Hunter talks about the parts of AI that are exciting and interesting in the tech world. [19:05] - Brian points out the pace that AI technology is improving, underscoring its impact on setting new standards of improvement industry-wide. [22:36] - Hunter shares his approach to integrating AI tools in his coding and testing processes, highlighting when they're beneficial and when they're not. [28:46] - Brian shares a big thank you to Hunter for joining him on the show. [29:30] - Brian shares the array of complimentary tools available at Mountain Goat Software, including Relative Weighting, as well as those tailored for users in the Agile Mentors Community, such as Planning Poker. [30:41] - If you want to ask a question or provide feedback on Goatbot, email hello@mountaingoatsoftware.com [31:06] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [31:39] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. References and resources mentioned in the show: Hunter Hillegas Goatbot Mountain Goat Software’s Free Tools Mountain Goat Software’s Relative Weighting Tool Mountain Goat Software’s Planning Poker Mountain Goat Software Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Hunter Hillegas is CTO at Mountain Goat Software. With over 20 years in software development and a knack for creating high-quality digital solutions, he thrives at a company that values excellence in education and customer satisfaction, living in Santa Barbara with his wife and their distinctive Pitsky, Enzo. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors Podcast. I am with you as always, Brian Milner. And today I have a very special guest, a coworker of mine, Mr. Hunter Hillegas is with us. Welcome in Hunter. Hunter (00:17) Hey Brian, thanks for having me. Brian (00:19) Absolutely. Hunter is our CTO. He is the guy who's all about technology. And anytime I have technology questions, this is who I go to. And he is very patient with me and helps me to understand things when I don't understand them. But we wanted to have Hunter on to talk about one thing in particular that we felt like maybe not everyone knows about yet. or maybe you've crossed paths with it, but really are kind of interested in the story behind it a little bit. That is Goatbot. If you don't know, actually, I shouldn't be answering this stuff. If you don't know what Goatbot is, Hunter, tell them what Goatbot is. Hunter (00:54) Yes. Sure, so as the listeners may know, Mountain Goat, Mike Cohn in particular, but also Brian and other contributors, we generate a lot of content, whether it's training material or blog posts, other articles. And for a long time, we've wanted to make that more accessible to people. There's just so much of it that that's always been a little bit of a challenge, even using search and other technologies. And like, A lot of other people, about I guess 18 months or so ago when ChatGPT launched, I became a lot more interested in large language models and got a better sense of what the state of the art was there. So Goatbot is our attempt to meld those two things together to try to solve that problem to make all of our content more accessible using some of that technology. So it is a tool that lets you ask questions about scrimmage topics and it will answer them based on all the stuff that we've written and trained on, etc. Brian (02:06) That's a great explanation. Yeah, that's what it is. That's the idea behind it. And I'm sure Hunter will back me up on this. I'll tell you, when we first started doing this, I was trying as much as I could to put it through the paces. And I think I may have even said this on other podcasts before, but my go -to question I used to ask any kind of LLM about Agile and Scrum, was to have it tell me the difference between a product owner and a product manager. And in fact, I would say specifically, what does Scrum say the difference is between these two things? And the answers I would typically get, they would just give me an answer. They would say, well, a product manager is this and a product owner is that. Hunter (02:46) Hmm. Brian (03:00) And I remember telling Hunter, this is wrong. It shouldn't say that, right? Because Scrum doesn't have a product manager. How are we able to handle those kind of one -off kind of exceptions in working with this? Hunter (03:14) Sure. So anybody that's used some of the more general tools like chat GPT is like I think the go -to example that probably most people are familiar with even though there are other chatbots out there. know that, you know, sometimes it will give you wrong answers. Sometimes it will give you sort of strange answers. It will do what they call hallucinate and make things up essentially, because it really wants to give you an answer, even if it doesn't know what the answer should be. And, you know, that was something that I was worried about when I started to prototype this. Like we are, we have a, I think, I hope. to say, a great reputation in terms of the stuff that we put out there. And the last thing that I wanted to do was to put that in danger in any way by having some kind of a tool that's spouting nonsense out there. So. That was important. And I didn't really know how well it was going to work when I started sort of prototyping this whole idea. And I had some doubts. But what I discovered was that if I gave the model very specific instructions about where it should be pulling. It's, uh, it's information from, i .e. please only use this information I'm giving you, um, that is, we know it's from our materials and not sort of maybe some random article that they found on the web somewhere. That's part of the larger trainings that be very specific. And if you don't know an answer, say, you don't know, you don't need to make anything up. Um, so those sorts of what they call system messages did a lot of tuning there. Um, and ended up with something that actually works. pretty well, I think. I mean, it exceeded my expectations once I started getting, once I got to the point where there was something where I felt like I should share it with the team, that it wasn't embarrassing. And I feel like, you know, the feedback internally was really good and the feedback that we've gotten from people that have been using it has been really good. So I'm happy with how it's going so far. Brian (05:09) Yeah, I've been really, really impressed. It's been just a really nice tool. It's done a good job. We initially had it sort of internal, like you said, and we put it through its paces. We had kind of widening circles of people that would test it out and try it and give us feedback. And Hunter kept tweaking and making adjustments to it. But I'll tell you, I don't know if I even told this to you, Hunter, but I was doing a... ACSM class a few weeks back. And one of the opening exercises we do in that class is to really kind of consider some of the other Agile frameworks that are out there, not just Scrum and see how they compare. And one of the ones I have on my list is one that doesn't get used very often. It's kind of one that died out, but it's called Crystal or Crystal Clear if you know that or you're familiar with that. Hunter (06:00) Mm -hmm. Brian (06:07) But I wanted to see what the Goatbot would say about it, so I asked it specifically, just give me an overview of what Crystal is. And I think I said specifically the Agile framework Crystal, just to make sure it wasn't anything strange. But the response that came back was, I don't have any information on that. I know about Scrum, and I can give you answers about that, but I just don't have any information on anything else. And I. Hunter (06:21) Right. Brian (06:34) Honestly, it really impressed me. Here's another thing that it could have made something up and said, oh, yeah, yeah, it's this. Or it could have pulled from some general database or something else out there. But it's tuned really well to only pull from our data. And I just think that's awesome. Hunter (06:50) One of the things that's been strange slash interesting for me as a long time programmer in all kinds of different technologies from the web to native applications to other things. is how different it is working with these LLMs and trying to get them to bend them to your will. There are instructions in the system message that in all capital letters say do not make anything up. And the fact that I'm having to program a computer, I'm doing scare quotes here, program a computer by telling it not to invent things is just so bizarre coming from a very two plus two equals four world of more traditional programming. But it's also been really exciting and interesting. Brian (07:32) Yeah. Yeah, it is kind of completely opposite from a programming perspective, right? Because we're so used to, oh, it's not going to do anything but exactly what you tell it to do. And it can't fill in gaps at all. And now the problem is it could fill in too many gaps or try to fill in too many gaps. Yeah. Hunter (07:44) Right. Right. Absolutely. And you can think even just beyond, you know, your example of a, of a, of a framework that's not in common use and probably not something that we've talked a lot about on the website and our own own materials. There's all kinds of other instructions that I had to put in. Cause I didn't want this thing sort of going far afield and, and, and, you know, coming up with a really wacky, potentially terrible answer, um, to some of these questions. And so, yeah, we're, you know, we, we do give it some very specific instructions on how it should behave. Brian (08:21) I tell people who come to the class that, you know, I can't a hundred percent guarantee. I can't a hundred percent say, yeah, it's always going to give you a hundred percent the right answer. But what I can tell you is I've, you know, we've all put it through its paces. We've all asked it things that we feel like, Hey, this is kind of tricky. I wonder what it would do with this. And, uh, you know, just my own personal perspective has been when I, when I ask it a question and it gives me an answer, it's, it's. damn close to what my answer would be. It's really close to what I would say on that matter. Hunter (08:55) Yeah, it's encouraging to hear that. And I've heard that from you and from Mike as well, and then also from customers that have been using it over the past, so whatever month and change or so it's been more publicly available that they are really happy with the output. And it's a great way for us to take advantage of all of this material that we've built up over all of these years that otherwise some of it probably would be. something from 10 years ago, still really relevant in a lot of cases, but maybe gathering justice. Cause it's not, you know, the top blog posts on the website or something. So some of this knowledge, it's a little bit more varied. We can resurface it with a tool like this. Brian (09:33) Now, this was something that we initially just had in the Agile mentors community, right? Hunter (09:39) That's how it started. And that was for a few reasons, mostly because, well, a couple of important reasons. One is that with these types of LLM things, there are costs associated with it in the sense that it does cost us per question effectively. And just we wanted to make sure that we understood what those costs were before that we just let it loose on the wider internet. So that was part of it. But also to get a sense of how people would react to it in those early weeks and months got a lot of feedback. feedback on the responses just to get a general sense of did people think that this was a good answer or not so good and use that to calibrate it because you know frankly if it underperformed where we wanted it to be that would be a good signal that we needed to do some more work on it or give it some more time to bake. Brian (10:26) Yeah. Yeah. And now we kind of have opened that up, and it's available to anyone. You can go to Mount Goat Software and look in our menus. And there in our tools, it's under Tools, right? Hunter (10:41) Yeah, so you can get to it from the Mountain Goat site. You can either go to it is in the navigation, I think right next to the podcast for those of you that are familiar with where to find that on the website. I think it's right next to it, at least for now. No matter what you can go to mountaingoatsoftware .com slash goat bot and that will take you to the right place. That's G -O -A -T -B -O -T. And it is free right now. So we've couched that with at least for a limited time. We are again, sort of experimenting with the model and where it's going to go. But you can sign up for an account today and use it for free and get put it through its paces. And we're pretty happy with what we've got so far. So please do do that. And hopefully it's useful and give us feedback if you find something that you think could be improved or or let us know if you worked out for you to like to hear those as well. Brian (11:29) Yeah, yeah, absolutely. And yeah, we kind of buried our lead here just to say that, yeah, it is free, right? We're not selling you on something. We don't have a package of things that we're not. Yes, we did originally have it in our Agile mentors community. But like Hunter said, there was a lot of reasons for that. We wanted to be safe with it. We wanted to have a smaller audience, see what kind of responses we got. Hunter (11:38) Right. Yes. Yeah. Brian (11:58) We'd hate to put something out there in the world and then have people say, you know what kind of crazy stuff this thing told me to do? So yeah, kind of a safer audience there to start with. But yeah, it's available to anyone for free. You can just go to our site and use it. And as Hunter said, yeah, please give us feedback. If there's anything that you want to just let us know that it was useful to you in any way, or maybe you used it for something unusual, we wouldn't have anticipated. Hunter (12:04) Right. Right. Hahaha. Brian (12:27) Yeah, let us know. We're trying to tweak it and make it as useful as we possibly can. What surprised you most in this work of putting this together? Did it go just as you expected or did it throw you for some loops along the way? Hunter (12:42) There were definitely some loops. I mean, I sort of alluded to the fact before that it's a little bit different of a mentality in terms of how you get it to do what you want. GoPod is actually a few technologies glued together. There's the content itself. So as you might imagine, we've got... all of this various content, whether it's transcripts from training courses and videos or blog posts that Mike has written or weekly tips, books, all kinds of stuff. So there's a ton of different content. It's all in these different places. So, you know, step one was creating a sort of pipeline that could take all of this content that's all in these different places and clean it up a little bit so that it didn't have, say, you know, editors notes in it and other things like that that don't make any sense. and then put that content into a vector database. So I'm sure that many listeners are familiar with more traditional relational databases. Vector databases are not new, but they have become a lot more popular with the rise of the LLM stuff. And basically a vector database will chunk up the various content and lets you query to figure out how content that is close to the query that you asked in a mathematical vector space. And so we use that when you... pose a query to go, but it will go and find relevant pieces of information related to your query that the LLM in this case we use GPT -4 as the model underneath our underneath go pot can take the content that was retrieved these sort of chunks of content that by themselves don't read very well, wouldn't be a very good answer. And it can use that to reformat it, to summarize, to put stuff together into a way that makes sense. Putting those pieces together was something that was new to me. I can't remember the last time I had used a vector database for anything. And the LLM bit was new for me as well. But despite the fact that it was new to me technologies, at least in those cases, the pieces of it coming together actually was simpler than I imagined for how well it worked even in its first incarnation. It kind of came together more quickly, the basic core of it came together more quickly than I thought that it would. There was then a lot of refining, especially around the prompting and the messaging stuff. But... These technologies, especially if you are a programmer, even if you don't have any background in machine learning or AI stuff, I think it's accessible and, in my opinion at least, fun to play with because it is kind of like a whole new world there. So I guess I'd say for those that are interested and maybe are worried that I don't know anything about these technologies, I would go check them out because I think you'll find that they're more accessible than you may think. Brian (15:39) Yeah, and they're getting better. I mean, the pace of their improvement is just so rapid. You know, you tried something, you know, two weeks ago, and then two weeks later, it's just a completely different experience because it's just incrementally, you know, nonstop getting better all the time. Gosh, I'm... Hunter (15:45) Yep. The models, I'm sorry to interrupt you, Brian, but yeah, I mean, I agree 100%. The models that we've been using have gotten faster and cheaper, I think two or three times in big step change moments since we started the project. I mean, that is a technology that's moving quickly. Brian (16:13) Yeah, yeah. No, I was just going to make a joke about the fact that I think we've quoted about two or three songs there, and I just did another one with getting better all the time. Yeah, so this is a fascinating topic, Gary, obviously, for a lot of people. And what I'm kind of curious here, because we're maybe about halfway through our time, and I'm just kind of curious if we shift gears a little bit. from talking about GoPot to talking about AI in general, because you've done a lot of work in this area, and you're obviously in technology, and you're an aficionado, a technologist. What have you seen most recently in this area? Where do you think this is headed? What kind of trends have you noticed recently? Hunter (17:01) Well, I mean, it's obviously an area of great interest for the development community. It also, it seems like in the last year, every product that we use as tools or whatever, they are talking about the AI features that they're adding. Um, and at least in my experience, you know, some of those are really interesting, you know, like we use zoom often for internal meetings and, you know, it has a feature now that can automatically summarize a meeting and you can ask it, you know, what were the follow -up items and stuff like that. That's great. There's also maybe a little bit of sort of round peg square hole with some of this. Like, I don't know if every tool in the world needs an AI feature, and there are definitely some where I seems a little bit useless. Um, Brian (17:40) Yeah. Hunter (17:48) I guess that's to be expected with something like this that's got so much interest. The things that I'm excited about, and it feels like it's still very much early days, but you can see the contours are what many people would refer to as agents. So basically, AI tools that are going to go out and do things on your behalf. So not just write me a blog post or summarize this email, but... You know, and the example that's often used in some of these demos is like book me a vacation. I personally, I want to pick the seat I'm sitting in. So I don't know if I'm going to do that, but, um, you know, when the, when the tools can get good enough to go out and do things for you. Right. So I don't know example of this podcast recording, uh, we, you sent me a link to the calendar tool. I found a time that was open, but in theory that could be completely automated away, right? My agent could talk to your agent and it could just find the time. And that would, we would just both be told like, Oh, you guys are recording. Brian (18:21) Yeah, me too. Hunter (18:44) You know, at X time, that sort of thing, right? And then going several steps beyond that. I think that's really interesting. People are starting to build those. The models need to get, I think, a good bit better before, you know, that really works well. But I can't wait to see where that goes in particular. I think that's gonna be a lot of fun. Brian (19:05) Yeah, I agree. I mean, like Zoom is a great example because we were even having conversations about this recently, just that there's a lot of criticism about how good and the quality of those summaries that take place after a meeting. But previously, when we encounter a technology tool like that, you'd see the product and you'd say, oh, it's either useful or it's not useful. Hunter (19:18) Mm -hmm. Mm -hmm. Brian (19:34) And it's kind of a binary one or zero. If it wasn't useful, then it really was about how that company implemented that feature. And they weren't going to do a massive overhaul of how it was implemented. It kind of is what it is. So we're kind of conditioned, I think, to have this response. Or at least if you're of a certain age, you're kind of conditioned to have this response of, hey, if it didn't work, it probably is not going to work. I can move on and find something else. But. Hunter (19:43) Right. Right. Brian (20:03) The pace of how this gets better is such that you try the Zoom tool, you look at the response and think, oh, that wasn't very useful. But you do it again in two weeks later. And all of a sudden, it's everything that you wanted it to be in the first pass. Because people have been saying, hey, this doesn't work, and I wish it was this way, and then the tool can update and modify. And it's crazy to think about, we have to get our heads wrapped around the pace of improvement is now vastly different. Hunter (20:13) Mm -hmm. It's it is definitely that's a very good point and it is different and you know, I know that there are some folks that you know, you take exception at calling these things AIs because they're not actually smart, right? How do how they work? They're not. They're not intelligent. But they are pretty impressive and they do unlock a whole lot of interesting new categories of stuff. And maybe you could have done some of these tasks before in other ways procedurally, but these can make some of those problems a lot easier to solve because of how they work. Now, I mean, I don't think I'd want ChatGPT to do my taxes, but... Brian (21:12) Yeah. Hunter (21:14) But it does have a lot of really interesting use cases. And you are absolutely right that these models are improving so quickly. And it is kind of like that little brain in there. And they can upgrade it with the latest version. And all of a sudden, it's just a little bit smarter. And again, I know some people take Umbridge as smart and intelligent. But I think you know what I mean. Brian (21:34) Yeah, no, and the funny thing there about, I mean, your example about doing your taxes is, you know, I laughed about that and thought, oh yeah, I'm kind of with you. I wouldn't want to have an AI do my taxes, but that's our opinion. There's probably others that would say, no, I'm fine with it doing it. If it's been trained and it's, you know, been programmed to do it a certain way, then yeah, that's fine. And I, you know, I'm aware of services that will do that with legal documents now that will create entire contracts and... wills and all sorts of stuff from a legal perspective. And that kind of leap, maybe that's the line for me. I look at that and say, oh, I could see that. Because it's a kind of a limited knowledge base. But taxes are kind of the same thing. They're, yeah. Hunter (22:18) I think it's doable. Yeah. I, I, I'm still at the stage with something like that where I'm in the trust, but verify mode. Like I, you know, it's, I would want to check it over and make sure it was correct, but I can easily see, you know, a little bit further down the road where a defined problem set like that, you can pretty much guarantee that it's going to, you know, give you a valid answer. Brian (22:24) Yeah. Yeah. Well, so I do want to dip our toe just a little bit in this other area too, because I know there's probably people wondering about this. You're in technology. You're at the levels where you're doing coding work. And I'm sure that you have made use or tried to make use of some of the tools that are out there now that assist and help with coding. What's your opinion of the current state of that art? Hunter (22:56) Mm. Yeah, no, great question. And I do use those tools. I'll use ChatGPT sometimes to work through a problem, or GitHub Copilot is the other tool that I use often. It's integrated into some of my other tools. I have found it useful in a bunch of different ways. I can find it useful to either... Help me write code that I 100 % could have written myself, no problem, but it would have just taken a little bit longer because I would have to go look something up and then remember some function name that I had forgotten. So like a script to reformat a CSV file or something like that, right? Not complicated, not breaking any new ground, something that I'm gonna use once and throw away. It's really good at that sort of thing and just creating something for me that I, you know, again, could have done myself easily, but it'll save me 10 minutes and I'll take it. I've also used it to help me understand a little bit. Maybe there's code in a language that I don't use very often or a framework I don't use. It's kind of like, what is happening here exactly? And having it try to explain it to me and walk through certain things. And that's also been useful for me, kind of just like I would talk to a colleague that might know a different area of a system better than I do, have a little bit of a back and forth. And that's been useful. I do not. do and at least right now would not feel comfortable with is like, I guess the equivalent of like copy and pasting code from Stack Overflow, right? So just taking huge chunks of code where I have no idea how it works or what it does and saying, it seems to give me the right answer, so I'm just gonna use it. That I wouldn't feel comfortable with in any context, whether it was AI generated or something that I found on a website someplace. So. I kind of treat it like, and others have said this too, but maybe like a pair program situation or like a junior programmer that might not have all of the experience, but is definitely very competent and can help with things. And I do find it saves me time. So I'm glad that it's there. Brian (25:10) Yeah, you know, it's funny because when you said that I wouldn't copy and paste, you know, things over, I kind of feel that same way. I'm not doing code, but I just didn't, you know, anything I would write or anything I would, uh, you know, kind of come up with in that way. Um, my, my kind of opinion is it hasn't really helped me as much with brainstorming type activities. I don't find it to be as, as creative. Hunter (25:38) Mm -hmm. Brian (25:38) To give me different ideas. But I do really, really enjoy how I can take a rough draft of something and then put it in and say, help me tweak this or help me make this better. It seems like it does a really good job with something like that. Hunter (25:42) Right. Yep, I'd spend my general experience as well. And it's, you know, I, I will take any tool assistance I can find here and there. And I do think even if I, even if it's not perfect, it's still an improvement and I can get some, maybe it'll make a suggestion for something I wouldn't have thought of or looking at it a slightly different way, which I find useful. So I'm happy to have it. Brian (26:19) Have you utilized it in any ways to test any of the code that you work on? Hunter (26:24) Oh. Yeah, that's a great question. For many programmers, writing tests can be kind of drudgery. And actually, I do find that it can be pretty good at writing certain kinds of tests for you. And actually, it's interesting if it struggles to write a test for something, it may be a sign that what you're trying to test needs to be refactored because it may not be, if it's not understandable enough or it's too Brian (26:50) Ha. Hunter (26:55) Big of chunks or whatever, that can also be an interesting indicator that maybe you need to go back and tweak that as well. But yes, I mean, I don't always enjoy writing automated tests, but they are very important. And so it is nice to have any kind of labor saving in that department. It's another area where I welcome. Brian (27:17) Yeah, you threw out the term refactor as well. I'm kind of curious there. If it does a good job of reformatting a couple of paragraphs, how good a job does it do with refactoring code? Hunter (27:28) It depends, like a lot of these things, but I definitely have thrown stuff in and said, hey, rewrite this function, tell me how you would do it. And there have been times where it will say, oh, well, you could, this is maybe a little verbose, you could compact this down, you could write this like this. In some cases, I originally wrote it in a certain way on purpose, because sometimes it'll generate code that is correct, but kind of hard to read. And there's a tension there between. something that's that future you will be able to read and understand versus the most compact terse code possible, right? So I don't always take its suggestions, but it can be good. Also it's good at finding, you know, silly programmer bugs off by one errors and those sorts of things that are really common. that we, the kinds of mistakes that we all make. Um, and so, yeah, another area where I'm happy to, to get a helping hand and just save me from banging my head into the wall, trying to figure out why this thing should work. And it turns out I just put a stomach hole in the wrong place. You know, something like that. Brian (28:25) Yeah, I'm always kind of careful with how I phrase this, but I know there's a lot of panic and there's a lot of concern about these things being able to replace the human element. And so I always try to preface this by saying, right now, the way the thing is right now. And the kind of examples we both gave, I think, are good examples to show that right now, it can't really do that. It can't really just completely wholesale. Hunter (28:35) Yeah. Yeah. Brian (28:53) Replace the human element in it. But I think that our examples are good examples of how it can be a beneficial tool to help create these things. Hunter (29:05) I definitely see it as a productivity enhancer. I don't think, at least none of the models that I've seen, none of the chat bots that I've seen, I have seen a couple of products that claim they're sort of an AI developer in a box. I have not seen any that are very good. I mean, I saw a chat GPT demo of a guy that drew a picture of an iPhone app on the piece of paper and it... Brian (29:23) Yeah. Hunter (29:32) Gave it the code for a working app, but OK, great, now I want to add another feature. And like, oh, well, you can't really, because it's a piece. So some of those demos are impressive for sure. But in terms of the kinds of things that working software developers are doing every day, I have not seen anything that could replace the people that I work with on my various teams. Brian (29:40) Ha ha ha. Yeah, I mean, who knows where it'll be a year from now or two years from now. But yeah, I think we can only kind of deal with the state of it today. And that's sort of the state of it today. Well, Hunter, I really appreciate you coming on. This has been a fascinating topic. Again, for those who want to check it out, the whole reason we wanted to have this is just to make sure people were aware of this Goatbot tool. And hey, if you want to give someone some thanks for it, this is your guy. Hunter (29:57) Right. Yep. Hahaha. Brian (30:25) You can, if you want to send something to hello at mountegoatsoftware .com, that's our general kind of email address for anything from Mountain Goat. So send something to hello at mountegoatsoftware .com and tell us what you think of it. Let us know what you think. And if you have suggestions, let us know, right? Hunter (30:42) We're very excited to hear your feedback. I appreciate the kind words, Brian. I will say GoPot would be nothing without all of the content that you guys write for. So I can't take all of that credit, but it is fun to kind of pull all these things together in a way that people seem to enjoy. Brian (30:50) Ha ha ha. Awesome. Well, thank you again for coming on. Hunter. Hunter (30:59) Thank you.

Have you ever returned to an old User Story and wondered, “what was I thinking?” On today’s episode, Mike Cohn, walks us through how and why he recently revisited and updated 200 Real Life User Story Examples from his past projects and updated a resource for you! Listen in as Mike and Brian share what worked and what didn’t work from the past, in an effort to make their user story writing skills stronger. Overview What makes a user or job story great? In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software, share Mike’s recent updates and edit to 200 Real Life User Story Examples. Listen as they revisit 200 older user stories, breaking down their analysis through the lens of more experience and an evolving technological landscape. Plus, in true iterative fashion, Mike shares how he is still working to write better user stories after years of perfecting and teaching the art of story writing. Tune in to learn what makes a great clear user story, and what makes a story that stinks. Listen Now to Discover: [00:57] - Brian is joined today by Mike Cohn who will be revisiting user stories. [02:58] - Mike talks about how he came back to these 200 user stories and decided that some of them sucked and needed updating. [04:42] - When writing user stories, Mike talks about prioritizing meaningful conversations over perfect user stories. [06:35] - Brian underscores the importance of efficient communication with developers through unconventional yet practical user stories. [07:22] - Brian points to previous podcast episodes with Mike that delve into the basics of writing user stories, in episode, #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn and #39 The Art of Writing User Stories with Mike Cohn [08:22] - Mike walks through a story written for the development of the Scrum Alliance website, noting it is framed well within the site's premise. [09:10] - Brian raises considerations about inserting information mid-story. [09:57] - Mike finds the story intriguing but suggests simplifying it by moving details into acceptance criteria, a notion that didn’t exist at the time, for clarity. [12:03] - Mike advocates for concise user stories, suggesting omitting unnecessary details and using acceptance criteria for specifics. [13:52] - In a job story example, Mike and Brian point out common mistakes from an era without distinct fields. [16:34] - Brian understands the attempt to prompt discussion in the job story but finds it normal overall. [17:32] - Mike critiques a job story for site admins approving job postings, suggesting modernizing language for notification methods and flexibility. [19:34] - Reflecting on a story about user authentication, Mike acknowledges a bias toward email-centric perspectives, and questions if this story goes too far separating the what and the how. [21:22] - Mike highlights story #42, recognizing a potential mistake in specifying UI details in a story about navigating job listings. [23:24] - If you’re struggling to get your team or organization on the same Agile page from team members to senior executives. Mountain Goat Software can help you Build a Common Understanding of Agile on your team! [24:17] - If you’re a visual learner or you’d like to follow along, you can find the pdf of all the user and job stories discussed in this episode, plus many more, right here. [25:12] - Mike defends a story about viewing detailed course pages, acknowledging UI implications but justifying the necessity of the detail. [27:13] - Mike critiques a user story about creating user accounts, cautioning against a potentially misleading "so that" clause with a specific example. [29:18] - Reflecting on the evolution of user stories, Mike emphasizes a shift from stating "I can" or "I want to" to a more neutral "I." [30:40] - Critiquing a user story about browser compatibility, Mike suggests that it's a nonfunctional requirement and better suited as part of the definition of done. [33:18] - Brian presents a user story for Mountain Goat Software’s Planning Poker tool about database indexes, expressing reservations about the commonality of developer-focused stories. [34:00] - Mike reflects on the “as a developer” story and expresses uncertainty about its inclusion, considering it potentially problematic. [36:22] - Mike critiques a story about database analysis, acknowledging its verbosity but justifying the detail as necessary for clarifying the researcher's role and objectives. [38:03] - Brian appreciates the brevity of the "I want" part of a user story and finds the "so that" clause acceptable as it provides examples and context for developers. [38:39] - Considering a story about storing results, Mike deems it not bad but potentially too long. [40:00] - Mike highlights that the best way to get better at writing stories is to write a bunch of them, acknowledging that his early stories taught him valuable lessons. [41:03] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts. [41:29] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Free download: 200 User Story Examples #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn #39 The Art of Writing User Stories with Mike Cohn User Stories Applied: For Agile Software Development by Mike Cohn Job Stories Offer a Viable Alternative to User Stories by Mike Cohn Mountain Goat Software’s Planning Poker Better User Stories Course Build a Common Understanding of Agile Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software Certified Scrum and Agile Training Schedule Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

«Покер стал моей волшебной дверцей в мир больших денег, технологий, политики, шоу-бизнеса и искусства», — сказала героиня фильма «Большая игра» — одной из самых известных кинокартин про покер А для нас, людей продуктивных и непроктастинирующих, покер может стать прекрасным методом эффективного решения задач и формирования командных спринтов. Но! Только, если мы будем использовать его в планировании А как это сделать правильно, слушай в нашем новом выпуске 00:36 — Что такое Planning Poker 01:24 — Как работает метод Planning Poker 03:50 — Зачем использовать покер планирование 05:49 — Как происходит сам процесс метода Planning Poker 10:40 — Частые ошибки в Planning Poker и как их избежать 12:56 — Planning Poker и другие методы оценки 15:40 — Рекомендации от команды WEEEK

In this episode, I talk with my former LinkedIn colleague, Lara Nowak, about adopting Agile for customer experience work. Neither Lara nor I are Agile experts, far from it in my case. But our recent experience of having to learn Agile and apply it to customer experience work gives us "Fresh Eyes" to both the challenge and opportunity of using Agile. We cover the important elements of Agile, concepts like Sprints, Retros, User stories, Planning Poker and the like. Fittingly, in a podcast called CX Patterns, we also talk about using the Fibonacci Sequence for estimating time and effort during sprnt planning. More background on the meaning of Slow is Smooth. Smooth is fast. Planning Poker OverviewPlanning Poker Online Tool Fibonacci SequenceThe Treasure Hunt RetroMiro – Tool for customer journey mapping, among other experience design methodologiesLara NowakCheck out the CX Patterns Newsletter for a complete transcript of every full podcast episode (Loose Threads / Mini Threads transcripts are included in the show notes) Hosted on Acast. See acast.com/privacy for more information.

Get ready for an electrifying episode of DrunkenPM Radio as I welcome the esteemed James Grenning to unravel the world of Test Driven Development (TDD). Agile 2023 is just around the corner, and during the conference, James will be leading a workshop called "Your First Test-Driven Development." While TDD is not a new concept, it remains unfamiliar to many tech professionals who didn't come from a development background. That's precisely why I reached out to James and invited him to join me for this inspiring podcast. If you're immersed in Agile or managing technology projects, and TDD is still a mystery to you, this is a must-watch. TDD is a game-changer, and understanding it is crucial for your professional growth. I assure you that this episode will significantly impact your job in the best way possible. Now, let's talk about the best part of this podcast: our incredible guest, James Grenning. He personifies the epitome of old-school OG Agile Royalty. Not only is James one of the co-authors of the Agile Manifesto, but he also penned the definitive book on TDD. That's not all—James is the brilliant mind behind Planning Poker, a technique that has revolutionized Agile estimation. Stay tuned as we delve into this fascinating topic towards the end of our conversation. But wait, there's more! At the conclusion of our interview, James will unveil a remarkable system he designed and developed for his training classes. When off-the-shelf solutions fell short of meeting his requirements, James took matters into his own hands. His ingenuity and determination to deliver top-notch training are truly awe-inspiring. Don't miss out on this captivating podcast episode. James Grenning's wisdom and expertise will reshape the way you approach your work. Join me as we embark on a journey of discovery and empowerment with one of the brightest minds in the world of Test Driven Development. (This podcast was originally recorded using video. You can find that version here: https://youtu.be/k5OaxLCIzzI) James's Book Test Driven Development for Embedded C (Pragmatic Programmers): https://bit.ly/43CMsP0 James's session at Agile 2023 Your First Test-Driven Development at Agile 2023 https://events.agilealliance.org/Agile2023/session/1423798/your-first-test-driven-development-james-grenning Monday, July 24, 2023, 2:00 PM - 5:00 PM Lafayette 4 Contacting James Web: https://wingman-sw.com/about LinkedIn: https://www.linkedin.com/in/jwgrenning/ Twitter: https://twitter.com/jwgrenning Agile, Extreme Programming, XP, Scrum, TDD, Test Drive Development, James Grenning, Dave Prior, Reluctant Agilist, drunkenpm, Drunken PM Radio, Planning Poker, Estimation, Wingman-SW, Agile Development and Design Techniques,

In case you haven't heard of it yet, ChatGPT is an AI-powered chatbot created by the OpenAI platform. Using prompts, ChatGPT can craft original jokes, plan trips, explain complex topics, and even write code. This begs the question: will ChatGPT take our jobs? To test this theory, we asked ChatGPT to write a 10-minute script for an agile software development podcast where the topic is Planning Poker, a consensus-based agile estimation and planning technique.

Die UX-Vision ist ein wertvolles Instrument, wenn es darum geht die Kräfte eines Teams auf das gleiche Ziel zu fokussieren. Im Gegensatz zur Produktvision beschreibt die UX-Vision aber in erster Linie, wie ein Mensch die Interaktion mitd em Produkt erleben und anschließend auch beschreiben soll. Nicht jedes Produkt erzeugt das gleiche Nutzungserlebnis bzw. sind je nach Produkttyp andere Faktoren wichtig. Eine Waschmaschine wird andere relevante Faktoren haben als eine Banking-App. Doch bevor jeder im Team eine eigene Vorstellung entwickelt, wird eine gemeinsame UX-Vision entwickelt und alle Teammitglieder können sich dadurch ein geteiltes, mentales Modell erzeugen. Bei jeder noch so kleinen Entscheidung können sie dann immer fragen, wie ihre Entscheidung auf die für ihr Produkt wichtigen Aspekte der User Experience einzahlen würde. Wenn die wichtigen UX-Faktoren für das eigene Produkt bekannt sind, können diese auch genutzt werden, um bei der Priorisierung der Product Backlog Items eine informierte Entscheidung zu treffen. Wie groß ist der Einfluss eines PBI auf einen Faktor der User Experience? Dies zu ermittelt ist manchmal gar nicht so leicht. Darum hat Dominique mit Andreas Hinderks (https://www.linkedin.com/in/andreashinderks) das UX Poker entwickelt, bei dem ein Team den EInfluss eines PBI auf einen Faktor bewerten kann und dabei auch bewährte Techniken aus dem Planning Poker zurückgreifen kann. Einen aktuellen Forschungsartikel findet ihr dazu hier. Nachdem nun im Product Backlog jedes Item nach seinem Einfluss auf die UX bewertet werden kann, braucht es auch eine Möglichkeit des Messens. Dazu empfiehlt Dominique in dieser Folge den UEQ+. Mehr zu diesem Fragebogen findet ihr unter https://ueqplus.ueq-research.org/. Der UEQ+ ist eine modulare Erweiterung des User Experience Questionnaire (UEQ) und enthält eine größere Liste von möglichen UX-Faktoren. Oft sind da schon die wichtigsten Faktoren für das eigene Produkt dabei. In der Folge wurde auf diese früheren Beiträge von uns verwiesen: - Agiles Schätzen: Planning Poker (https://produktwerker.de/agiles-schaetzen-planning-poker/) - Wie die Produktvision hilft, Product Ownern eine Richtung zu geben (https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/) - Video vom Live-Event zur Entwicklung von UX-Visionen (https://youtu.be/B1lAA4iWkH4) Wenn du Tipps, Tricks und Erfahrungen für uns alle hast, freuen wir uns über dein Feedback. Lass einfach einen Kommentar unter https://produktwerker.de/ux-vision/ da oder kommentiere auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker).

Nachdem wir bereits über die agilen Schätzmethoden Magic Estimation und Planning Poker in vorherigen Podcastfolgen gesprochen haben, geht es in dieser Episode um NoEstimates. Dominique und Oliver sprechen darüber, warum sie auch "Nicht-Schätzen" in diese Reihe der Praktiken einordnen. Statt beispielsweise mit der Fibunacci-Reihe zu agieren werden bei NoEstimates in der Regel die Anzahl der Items gezählt und so Prognosen anhand von historischen Daten erstellt. Dominique und Oliver schauen auf die grundsätzlichen Schwierigkeiten, sofern ich als Product Owner mit Schätzungen arbeite. Sie diskutieren die eine oder andere Dysfunktion und die Gefahr, sich zu sehr auf Fristen und Product Delivery zu konzentrieren. Nachdem so die Motivation sich mit NoEstimates zu beschäftigen geklärt ist, geht es im Kern der Folge um die Voraussetzungen, die ich schaffen muss. Und natürlich werfen Oliver und Dominique auch einen kritischen Blick auf Schwierigkeiten, die bei dieser Methode aufkommen kann. Wie immer runden persönliche Tipps aus dem eigenen beruflichen Werdegang diese Episode ab. Dominique empfiehlt folgende YouTube-Videos für einen Einstieg in das Thema: NoEstimates von Vasco Duarte NoEstimates von Allen Holub

Planning Poker ist ein weit verbreitete Technik, wenn es darum geht im agilen Kontext zu schätzen. Dabei kann ein Team durch gemeinsames Schätzen und einem gezielten Austausch von Argumenten sich nach und nach ein gemeinsames mentales Modell erarbeiten. Schätztungen, die so entstehen werden anschließend zur Priorisierung und Planung eingesetzt. Die Grundlage für Planning Poker bildet im Grunde eine Technik namens Breitband-Delphi, bei der auch mehrere Experten zusammen ein Urteil abgeben und sich zwischen ihren individuellen Aussagen abstimmen dürfen. In dieser Folge besprechen Oliver und Dominique welche Rolle die Technik für Product Owner hat und an welchen Stellen sie vielleicht noch wertstiftend eingesetzt werden kann. Nach der Klärung, woher die Technik eigentlich kommt sprechen die beiden über den konkreten Ablauf und mögliche Einsatzzwecke. Außerdem denken die beiden auch darüber nach, welche Vor- und Nachteile die Technik hat. Gerade um die Nachteile sollten Product Owner wissen, damit sie mit den Ergebnissen einer solchen Schätzung umgehen können bzw. wissen an welchen Stellen Ergebnisse vielleicht auch mal hinterfragt werden sollten. Oliver und Dominique schließen wie immer mit einigen Tipps, die ihrer Erfahrung nach dabei helfen noch ein wenig mehr aus der Planung mittels Planning Poker herauszuholen. Im Gespräch wird auf folgende anderen Folgen verwiesen: - Agiles Schätzen: Magic Estimation (https://produktwerker.de/magic-estimation/) Folgende Referenzen finden wir in dem Kontext wertvoll: - The Original Paper (https://wingman-sw.com/articles/planning-poker) - Planning Poker auf der Website von Mountain Goat Software (https://www.mountaingoatsoftware.com/agile/planning-poker) Darüber hinaus empfiehlt sich bei Gelegenheit ein Blick in das Buch "Agile Estimating and Planning" von Mike Cohn, auch wenn es mittlerweile an einigen Stellen etwas in die Jahren gekommen ist.

"What is Planning Poker?" Find out in this episode of Appfire Presents: The Best Project Portfolio Management Show by Appfire. Appfire's own Agnes Józwiak joins Kerry O'Shea Gorgone to talk Planning Poker: what it is, how it helps agile teams estimate projects, how you do it, AND how it works when your team is remote. Agnes is Product Marketing Manager for Agile Apps Category at Appfire. An experienced marketing practitioner with a demonstrated history of success in the computer software industry, she's a big supporter of product+marketing+sales trio. Website: https://appfire.com/ LinkedIn: https://www.linkedin.com/in/agneswilinska/ About The Show: The BEST Project Portfolio Management Show by Appfire covers everything you ever wanted to know about PPM by talking with project management experts who've seen it all. And every episode is 10 minutes or less, so you can get back to changing the world, one project at a time. Appfire.com

Durch das Refinement wird das Product Backlog zu einem gut gepflegten Product Backlog und ist dadurch ein wichtiges Werkzeug für Product Owner. Tim und Dominique unterhalten sich in dieser Folge über das Refinement des Product Backlogs und welche Bedeutung es für uns als Product Owner hat. Zu Beginn klären wir erst einmal, was Refinement eigentlich ist und wie es in Scrum passt. Das Refinement wird zwar oft als Termin gesehen, ist aber eigentlich ein Prozess. Deshalb sprechen wir über den allgemeinen Ablauf des Refinements, wer alles mitwirkt und was wir als Product Owner vorbereiten sollten. Wir sind nämlich davon überzeugt, dass wir neben Vision und Product Goal auch eine aktuelle Roadmap dabei haben sollten. Dank dem Refinement haben wir dann nicht nur ein gepflegtes Product Backlog; wir erhalten auch neuen Input für die Priorisierung von Product Backlog Items und erlangen ein Verständnis über Umfang, Kosten, Risiken und anderer Aspekte der ganzen Backlog Items. Wir können daher dank des Refinements bessere Entscheidungen treffen. Und wie in jeder Folge wollen wir mit ein paar Tipps abschließen. Habt ihr beispielsweise mal daran gedacht das Refinement eines bestimmten Themas als Product Backlog Item einzuplanen, damit im nächsten Sprint an diesem Thema gearbeitet wird? In der Folge erwähnen wir übrigens kurz das Product Backlog Refinement Canvas, eine gut geeignete Vorlage, um sich eine strukturierte Übersicht zu machen. Ihr findet es unter https://www.kaizenko.com/the-product-backlog-refinement-canvas/ Wenn ihr noch mehr über das Product Backlog hören wollt, dann empfehlen wir euch die folgenden Folgen: - Das Product Backlog (https://produktwerker.de/product-backlog/) - Ist dein Product Backlog voll bzw. zu groß? (https://produktwerker.de/product-backlog-voll/) - Product Backlog Einträge sind nicht nur User Stories! (https://produktwerker.de/product-backlog-eintraege/) Wenn euch dieser Podcast gefällt, freuen wir uns auch über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter (@produktwerker).

(T.I.A. Ep 42). Anatoly Shamkin, a versatile Product Manager, passionately describes his move from humble beginnings at HP in Russia, to transitioning to a Product Owner, (Agile) Project Manager, Scrum Master and Product Manager roles around the world, and some of the hurdles along the way. Anatoly brings to bear his favorite Scrum estimating tools, whether Prioritization Poker, Planning Poker, or Fibonacci; the detailed differences between a Waterfall and Agile Project Management; overcoming pitfalls with Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; and how to transition from a Project Manager to a Product Manager. YouTube: https://www.youtube.com/watch?v=Gqjml824BQk Anatoly Shamkin: LinkedIn: https://www.linkedin.com/in/shamkin/ Sponsored by The Lewis Institute: Website - https://lewisinstituteinc.com/; Project Leader Courses (60% discount) - https://lewisinstitute.kartra.com/page/Wif255 Business Agility Institute: Emergence Journal - https://businessagility.institute/emergence; promo code "analyst" (for 10% discount on annual subscription)

Tue, 18 May 2021 15:00:00 +0000 https://keine-zeit.podigee.io/36-neue-episode 979aeed9822959ff9a96a8903ad92c97 „Welcome to the Hotel California“ Show Notes Review Scrum: The Art of Doing Twice the Work in Half the Time von Jeff Sutherland Amazon | Blinkist | Apple Books Diskussion Chris beginnt die Show mit einer Rechtfertigung und kriecht zu Kreuze vor den Köchen dieser Welt. Mix entschuldigt sich vorab für eine schlechte Show, da er traumatisiert wurde. Vielen Dank, Bayern 1: „Welcome to the Hotel California…“ Chris liefert zum ersten Mal eine sehr erwachsene Antwort, koppelt diese aber gleich an einen cholerischen Anfall. Der Fundamental Attribution Error. Das wichtigste ist, dass wir Ergebnisse erzielen. Mix spricht von Hunden, Chris von Hasen. Und das auf Italienisch. Aus dem 12. Jahrhundert. Mix spricht über das Hochzeitsproblem, „Planning Poker“ und das Streichen eines Hauses. Chris lässt nicht locker und kehrt zu seinem Baguette zurück. Hacks Mix: - Chris: - Nuggets „Ich bin Matsch im Kopf.“ „Der Tag ist gut, wenn du ein Ergebnis erzielst. Punkt, Aus, Ende.“ „Wieviel Hasen habe ich nach 50 Wiederholungen, Mix?“ „Was würde die Milch dazu sagen?“ Links Chris erklärt die Fibonacci-Folge: Projektmanagement mit der Fibonacci-Folge Leonardo Fibonacci hat im Jahr 1202 das Anwachsen der Kaninchenpopulation beschrieben. Dabei ging er davon aus, dass jedes Paar ein weiteres Paar Kaninchen pro Monat wirft. Das neugeborene Paar wirft allerdings erst im zweiten Monat ihres Lebens ein neues Paar. Zudem geht die Folge von einem abgeschlossenen Raum aus, in den keine Kaninchen hinzu und auch nicht wegkommen; zudem leben die Kaninchen unendlich (!) Dadurch entsteht folgende Fibonacci-Folge: 1,1,2,3,5,8,13,21,34,55,89,144,233,377,… Beim Projektmanagement teilen wir das Projekt in möglichst viele Einzelschritte ein. Für ein Beispiel gehen wir von 5 Schritten aus: A, B, C, D und E. Danach suchen wir jenen Schritt heraus, den wir am besten einschätzen können (sei es, weil wir ihn schon oft durchgeführt haben, oder weil er sehr eindeutig vorherzusagen ist). Für das Beispiel nehmen wir Schritt 4 D. Schritt D ist nicht besonders komplex und benötigt 10 Stunden. Jetzt kommt der entscheidende Teil. Wir versuchen den Aufwand und die Komplexität der anderen Schritte in ein Verhältnis zu D zu bringen: Zuerst suchen wir uns den einfachsten Schritt heraus. In dem Beispiel sei das A. Im Verhältnis zu D ist A extrem einfach zu erledigen und benötigt vermutlich auch nur einen Bruchteil der Zeit von etwa 2 Stunden. Bereits jetzt gehen wir auf die Fibonacci-Folge: Der primitivste Schritt kommt auf die 1. Wir schätzen hier einen Zeitaufwand von 2 Stunden. Damit ist festgelegt, dass die Zahlen der Fibonacci-Folge immer mit den 2 Stunden multipliziert werden müssen. Dementsprechend kommt D auf die 5, denn wir wissen aus der Vergangenheit das dieser Schritt 10 Stunden beansprucht. Im Team wird jetzt diskutiert, wie die verbleibenden Schritte im Verhältnis zu D einzuordnen sind. Gehen wir von folgendem Ergebnis aus: B ist sehr viel komplexer und aufwändiger als D. C ist etwas weniger komplex und aufwendig als D. E ist deutlich aufwendiger als D, aber nicht ganz so aufwendig wie B. Das ergibt folgende Verteilung auf der Fibonacci-Folge: Für die Schritte A und D sind die voraussichtlichen Zeiten bekannt. A wird 2 Stunden dauern, D 10. Ein Wert der Fibonacci-Folge entspricht in unserem Beispiel zwei Stunden. Mit dieser Information kann jetzt die gesamte Fibonacci-Folge mit Zeiten “belegt“ werden: In unserem Beispiel ergibt sich ein voraussichtlicher Gesamtaufwand von 2+6+10+26+42=86 Stunden. Das System ist natürlich immer noch fehlerbehaftet und basiert auf Vermutungen. Aus unserer Erfahrung wissen wir jedoch, dass wir damit am nächsten an den Aufwand herankommen, den das Projekt dann wirklich erfordert. 36 full „Welcome to the Hotel California“ no Produktivität,Effizienz,Zeitmanagement,Ziele,Gewohnheiten,Routinen,Organisation,Kommunikation,Fokussiertheit,Motivation Michael Widemann & Christian W. Huber

T.I.A. (Ep 22). Mike Cohn, co-founder of Agile Alliance and Scrum Alliance, talks about how he initially got involved with Agile/Scrum, how to overcome some problems with writing user stories, and suggestions on how to transition from a BA role to a Product Owner role. Mike also chats about how Mountain Goat Software helps organizations introduce Agile to their business, the Scrum Master role, the best time to initiate Planning Poker, the Agile Mentors Community, and Scrum stand ups. YouTube: https://www.youtube.com/watch?v=sj9czKhWirI Mike Cohn: Website 1: https://www.mountaingoatsoftware.com/; Website 2: https://learn.mountaingoatsoftware.com/better-user-stories/; Website 3: https://learn.agilementors.com/agile-mentors/ LinkedIn: https://www.linkedin.com/in/rami-kaibni/; YouTube: https://www.youtube.com/user/AgileMikeCohn Sponsored by The Lewis Institute: Website - https://lewisinstituteinc.com/; Project Leader Courses (60% discount) - https://lewisinstitute.kartra.com/page/Wif255 Business Agility Institute: Emergence Journal - https://businessagility.institute/emergence; promo code "analyst" (for 10% discount on annual subscription)

Daniel und David unterhalten sich in dieser Folge über agiles Schätzen. Dabei orientieren sie sich am Simon Sineks "Golden Circle". Nachdem es als erstes um das "Why" geht, werden "How" und "What" nacheinander vertieft. Dabei kommen sie sowohl auf Schätzmethoden, als auch das oft diskutierte Thema Komplexität vs. Aufwand zu sprechen. Viel Spaß beim Hören!

A melhor maneira de fazer o planning poker à distância.

Uma dinâmica rápida que serve como alternativa ao planning poker tradicional ideal para quando se tem um backlog muito grande.

La fisicità nel mondo agile è estremamente importante, permette di rendere tangibili concetti astratti come user stories, pianificazioni e retrospettive. Abbiamo realizzato delle carte per il Planning Poker, un “gioco” utile per valutare il peso di una storia durante la riunione del Refinement. Potete Scaricare il template qui https://kutt.it/255planningpoker Trovate tutte le istruzioni utili per usare questo strumento nella seguente puntata Stampa, Ritaglia e... Pesa! *** Una chiacchiera tra Paolo Meregalli e Gabriele del Vecchio, rispettivamente CEO e UX in 255. *** Canale Telegram: https://t.me/techtalks255 Canale Telegram per inviarci i tuoi feedback. https://t.me/techtalks255chat Citazioni e crediti: https://www.mountaingoatsoftware.com/uploads/documents/agile-estimating-and-planning-preview.pdf https://www.diva-portal.org/smash/get/diva2:881296/FULLTEXT01.pdf --- Send in a voice message: https://anchor.fm/255/message

**Alle Skripte zum Nachlesen der Folgen & Download** für dein persönliches Wissensmanagement zum Managen von Projekten erhältst du hier: https://pm-botschaft.com/podcast/alle-skripte // INTRO: Das Schätzen von zeitlichen Aufwänden und Budgets ist einer der diskussionsintensivsten Schritte im Projekt überhaupt. Oft geht es da ziemlich heiß und entsprechend emotional zur Sache. In dieser Folge schauen wir uns daher an: 1. Wie dir eine profunde Schätzung von Aufwänden gelingt. 2. Welche klassischen wie agile Methoden du dabei anwenden kannst. 3. Und was dir das langfristig nützt überhaupt diesen Aufwand zu betreiben. SHOWNOTES // Schaubild "3-Zeiten-Methode" https://bit.ly/2EapqZw // Anmeldung zum Live-Webinar "Entfesselungskunst im Projekt": https://calendly.com/pm-botschaft/webinar-entfesselungskunst-im-projekt KONTAKT // Schreib mir via E-Mail chris@pm-botschaft.com // Lass uns vernetzen via LinkedIn www.linkedin.com/in/schiebelchris/ // Vereinbare direkt ein kostenloses Erstgespräch https://bit.ly/3gHTFWB // Videoaufzeichnung "Die 7 Magischen Zutaten im Projekt" https://pm-botschaft.com/mehr-leichtigkeit-im-projekt/

Aprenda a estimar em pontos da mesma forma que aprendi na minha certificação de Scrum Master Certified, ouça algumas descobertas dos meus mais de 10 anos de experiência no uso do framework e conheça uma abordagem prática que acerta 90% das vezes.

Scrum Institute, Scrum Framework Episode #10 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is User Story In The Scrum Framework? This Might Surprise You! The entries in the Scrum Product Backlog are often written in the form of User Stories. A User Story tells a short story about the requirements of someone while he or she is using the software product we are building. It has a name, a brief narrative, and acceptance criteria for the story to be counted as completed. The advantage of user stories is that they precisely focus on what the user needs and wants without going into the details on how to achieve them. How to achieve them will be the job of the Scrum team as a later stage, There are different recommendations on how to define User stories. A well known and reliable template is: As an [actor], I [want|must] [action] so that [achievement] Or in a shorter version:As an [actor], I [want|must] [achievement] The Actor is the owner of the user story. That is often a user, but it is advisable to be more specific. By using particular actors such as an administrator, logged in customer, or unauthenticated visitor or so on, user stories become distinctive. So they set requirements into a proper context everyone can understand. The Action is what the Actor wants to do. If it is a mandatory requirement, it can be prefixed as must. Otherwise, it’s prefixed as want. The Achievement is what the Actor wants to achieve by performing the Action. That’s the Actor’s envisioned business result or a functional technical component that emerges once the Action is completed. How To Estimate Effort For Stories In The Scrum Framework? This Might Surprise You! All user stories within the Scrum Product Backlog have to be estimated to allow the Scrum Product Owner to prioritize them and plan releases. That means the Scrum Product Owner needs a reliable assessment of how much the delivery of each user story will take. Nevertheless, it is recommended that the Scrum Product Owner does not interfere with the estimations that the Scrum Team performs. So the Scrum Team delivers its estimates without feeling any pressure from the Scrum Product Owner. The Scrum Framework itself does not prescribe a way for the Scrum Teams to estimate their work. The teams who rely on the Scrum Framework do not deliver their estimates of user stories based on time or person-day units. Instead, they provide their estimates by using more abstract metrics to compare and qualify the effort required to deliver the user stories. Common estimation methods include: Numeric sizing (1 through 10),T-shirt sizes (XS, S, M, L, XL, XXL, XXXL), orthe Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, etc) An Example User story The Scrum Team members must share a common understanding and consensus of the unit of estimations they use so that every member of the team feels and acts comfortable with it. Planning Poker® / Scrum Poker One commonly used method for the estimation process is to play Planning Poker® (also called Scrum Poker). When using Planning Poker®, the social proof influence among the Scrum Team members are minimal. Therefore, the Scrum Team produces more accurate estimation results. What you need to play Planning Poker® game is straightforward: The list of features to be estimatedDecks of numbered cards. A typical deck has cards showing the Fibonacci sequence, including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Other similar progressions are also possible. The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. It would be a waste of time to discuss if a user story should have a size of 19, 20 or 21. And yet, it’s relatively easier to decide if the user story fits better to the size 13 or 21. A high estimate could mean that the Scrum Team members have not very well understood the user story yet. So they can attempt to secure extra capacity for contingency before their commitment to this user story. Alternatively, that could also mean that the user story should be broken down into multiple smaller user stories.Scrum teams can usually estimate smaller and clearer user stories with higher confidence. Finally, the Scrum Team plays Planning Poker® by adhering the following steps: The Scrum Product Owner presents the story to be estimated. The Scrum Team asks questions, and the Scrum Product Owner articulates the user story in more detail. If the Scrum Team has to assess many user stories, estimates can be time-boxed in a way that the Scrum Team does not spend more than a few minutes for each user story. If the team cannot still estimate a user story in a given time-box, then this could be a signal to which the Scrum Product Owner needs to pay attention. This signal indicates that either the end-user requirement or the user story or both of them are not clear enough, so they need to be rewritten.Each member of the Scrum Team privately chooses the card representing the estimation.After everyone has selected a card, all selections are revealed.People with high and low estimates are asked to explain their assessment because they may have thought something that the majority of the Scrum Team members have been unable to see.Another estimation is done for this particular user story until the team reaches a consensus for an estimate.The Scrum Team repeats the game until they estimate all user stories. Planning Poker® is a registered trademark of Mountain Goat Software, LLC. What Is The Definition Of Done In The Scrum Framework? This Might Surprise You! In the Scrum framework, the factors which define when a feature is complete and when it meets the required quality standards are set by Definition of Done (DoD). As it was clarified before in this material, DoDs specify the expected outcome in terms of functional and non-functional requirements, design, coding, unit testing, end-user validations, documentation, and so on. DoDs are defined in the levels of both user stories and tasks. DoDs of user stories focus on functional and non-functional client requirements, whereas DoDs of tasks focus on the desired working activities from the Scrum Team members. The Scrum Team is not allowed to close the user stories, and obviously, the tasks that do not fulfill their DoDs. Definition of Done (DoD) is used to decide whether a User Story from the Sprint Backlog is complete or not. DoD is a comprehensive checklist of required activities to ensure that only truly completed features are delivered, not only in terms of functionality but in terms of quality as well. The norms which a Scrum Team uses to define DoDs may vary from one team to another, but it must be consistent within a given Scrum Team. There are usually different DoDs at various levels: DoD for a Project/Product (In the project goals)DoD for a Release (In the release goals)DoD for a Sprint (In the sprint goals)DoD for a User Story (In the User Story)Dod for Tasks (In the task) One more essential thing to keep in mind here is that a DoD is neither static nor indisputable. During the course of a project, a release, or a sprint, a DoD can be challenged by anyone from the Scrum team or other business and IT stakeholders. As long as the proposed changes of a DoD makes sense and they’re brought up to bring the project to success, the Scrum Team and the Scrum Product Owner should be open minded to listen to those proposals and implement them when and where necessary.

5am Mester Scrum Show #292 Live - Planning Poker - Today's topics: (1) Is the purpose of Planning Poker (a) Sizing or (b) Conversation? Please like and subscribe and share 5amMesterScrum. Please send me your topics. You are are doing Great Please Keep on Sharing. #5amMesterScrum #scrum #agile #business #scrummaster #agilecoach #coaching #planningpoker #userstory #points #storypoints #conversation #sizing 5am Mester Scrum Show #292 went live on Youtube at 554am EST Saturday 5/9/2020. Happy Scrumming, Social Media Roll Call   LinkedIn: https://www.linkedin.com/company/5ammesterscrum/ Youtube: https://www.youtube.com/c/5ammesterscrum Facebook: https://www.facebook.com/5ammesterscrum/ Instagram: https://www.instagram.com/5ammesterscrum/ Twitter: https://twitter.com/5amMesterScrum/ TikTok: (search 5amMesterScrum)  Podcasts: (search 5amMesterScrum) Spotify, Google Music Player, PodBean, iTunes, Stitcher, PlayerFM, Breaker 

Metagality in the year 2020 will have a Denver event on May 7th and 8th. Otherwise, their event calendar is visible at: http://www.metagility.technology Dr. David A. Bishop is Founder and CEO of Agile Worx. He is a technologist, consultant, researcher, entrepreneur, and instructor with over 25 years of experience in telecommunications, transportation, government, and utility …

WORUM ES IN DIESER FOLGE GEHT … Hallo und ein herzliches Willkommen zum Game Changer-Podcast. Der Podcast für deinen Erfolg mit wirksamen Impulsen, spannenden Inspirationen, erkenntnissreichen Interviews und persönlichen Game Changern, die DICH in die Umsetzung bringen. Und das Ganze von und mit Torsten Koerting. In diesem Podcast möchte ich dir exklusiven Einblick in einer unserer Jump-Mentee-Gruppen-Calls geben, die jeden Mittwoch im exklusiven Kreis all meiner Mentees stattfinden, in dem ich ganz explizit darauf eingegangen bin, welchen Impact Corona auf die Erfolgsformel hat. Nochmal für dich zur Nachvollziehbarkeit: Die Erfolgsformel beschreibt, das Erfolg entsteht durch: deine Substanz, gepaart mit deinen Fähigkeiten plus das Momentum, was du aufnimmst, und dem Fokus und die Dynamik, die du in etwas hineingibst. Und das in Klammern mal den Glauben, den du an dich selbst hast, den andere auf dich haben beziehungsweise du an dein Team hast. Und das Ganze wird beeinträchtigt, also geteilt durch, das Risiko, welches du in der Lage warst im Vorfeld zu antizipieren, beziehungsweise die Unsicherheiten, sprich, wie du mit den Unsicherheiten auf deinem Weg in der Lage bist umzugehen. Und das Ganze wird potenziert durch dein Warum, also durch deine intrinsische Motivation, die dich antreibt. Das alles in meiner Welt als Ergebnis führt zum Erfolg. Und in diesem Gruppen-Call haben wir genau diese Erfolgsformel demaskiert und den Einfluss von Corona auf die einzelnen Elemente auf die einzelnen Variablen und Parameter dieser Erfolgsformel reflektiert und besprochen. Viel Spaß dabei! So und ich darf sagen, dass dieser Call genau zum richtigen Zeitpunkt stattfindet. Wir sind ja inmitten einer der, ja, fast schon größten Krisen, die zumindest unsere Generation miterlebt hat. Und was uns diese Krise lehrt, ist, dass wir jetzt in die Umsetzung kommen dürfen, dass wir jetzt innovieren dürfen, um uns auf die Zeit nach der Krise vorzubereiten. Ich sage immer, wenn es keine Zeit nach der Krise gibt, haben wir eh ein anders Problem. Deswegen dürfen wir jetzt noch positiv nach vorne schauen und mit der Antizipierung weitergehen, dass es eine Zeit nach der Krise gibt. Egal, wie sie aussieht. Ich war heute Mittag in einem Call von der CEIBS, der Chinese European International Business School, ein sehr exklusiver Call, auch wenn über zweihundert Teilnehmer dabei gewesen sind, weil diese Business School die größte Business School in China ist und mehrere Campus in Shanghai in Beijing und in Peking hat. Und es gibt einen europäischen Hub und zu diesem europäischen Hub gehöre ich. Ich habe dort eine Gastprofessur und darf dort einmal im Jahr Projektmanagement als Professor für Projektmanagement, wusste gar nicht, dass es sowas gibt, aber so heiße ich da, fazilitieren. Und die CEIBS ist schon länger in unserem Kosmos und wir machen nächstes Jahr für sie eine sehr exklusive Nature-Leadership-Experience: Alpencross, wo wir dreißig Global-Executives-NVAs über die Alpen führen werden. Ich wurde eingeladen zu einem Call, der auch die aktuelle Krise zeigt und einer der Professoren, der auch sehr umtriebig im Bereich der Unternehmenstransformation und im Bereich Führung und Talent-Acquisition und Talent-Management ist. Also Jessie, das ist genau dein Thema, in dem er dort unter anderem unterwegs ist. Und der hat einen sehr interessanten Graphen aufgemalt und ich würde den gerne mit euch teilen, das geht aber nicht. Deswegen darf ich ihn aufzeichnen. Und in diesem Graph kann man erkennen, dass die Technologie, ich zeige euch das gleich in der Kamera, dass die Technologie, das ist dieses rote Chart, also dieser rote Pfeil, über die letzten Jahrhunderte extrem nach oben gegangen ist. Das heißt, dass die Technologieinnovation in der Welt, angefangen mit der Industrialisierung bis ins heutige Zeitalter exponentiell nach oben geht, also ähnlich, wie diese Corona-Kurve. Und wir als Menschen nicht in der Lage sind dem zu folgen. Das heißt, wir werden langsam, aber sicher von der Technologie abgehängt. Und er hat jetzt was ganz Spannendes aufgezeigt, nämlich, dass, was jetzt passiert, ist eine sogenannte Acceleration. Das getriggert durch das, was aktuell in dieser Welt passiert, wir forciert werden, wir dazu getrieben werden, zu innovieren. Und dass Technologien, die unser Leben zwar in den letzten Jahren bereichert haben, wie jetzt hier dieses Zoom mit der Videokonferenz, exponentiell nach oben gehen. Also er hat auch gezeigt, ich weiß nicht, ob ihr das verfolgt habt, Zoom war ja in der Presse, weil es Daten zu Facebook vermittelt, ob schon wir vielleicht gar keinen Account bei Facebook haben oder keinen Account bei Zoom haben. Also auf jeden Fall werden irgendwelche Daten zu Facebook übermittelt. Und der Aktienkurs in den letzten drei Monaten hat sich verdreifacht. Und so geht es vielen anderen Unternehmen, Alibaba zum Beispiel mit Digitalk, das kennen wir gar nicht, ein exponentielles Wachstum in den letzten Wochen hingelegt hat. Er hat auch beschrieben, dass Unternehmen, die im Bricks-Market unterwegs sind, das heißt, die Geschäfte haben und dort ihre Sachen verkaufen, im letzten Monat komplett umgestellt haben, weil sie neunzig Prozent ihres Umsatzes von einem auf den anderen Tag verloren haben, weil die Geschäfte schließen. Jessie wird das bestätigen können, sie hat ja immer noch einige Restaurants in Berlin und gute Verbindungen in Hotellerie und in die Gastronomie. Alles zu! Und von einem auf den anderen Tag bricht dir der gesamte Umsatz weg, den du halt auch mit Lieferservice und mit Drive-In, und wie kreativ die auch immer sind, nicht aufholen können. Und dieses Unternehmen ist beispielhaft in China dafür. Die haben nämlich von einem auf den anderen Tag, oder innerhalb von wenigen Tagen, alles ins Online gebracht und haben mit diesem Weg zweihundert Prozent mehr Umsatz, als im stärksten Monat ihres Offline-Daseins. Und er hat die Frage ganz provokant gestellt, ob die jemals diese Geschäfte überhaupt wieder aufmachen … das ist noch ein Fragezeichen. Auch wenn Corona sich wieder in eine ganz andere Richtung entwickelt, kann es durchaus sein, dass die Geschäfte nie wieder aufmachen und komplett online gehen. Und wir erleben das auch aktuell bei unseren Kunden, die weg von Kontrolle, hin zu Selbstorganisation, zu Selbstbestimmung, weg von Misstrauen, hin zu gefordertem und notwendigem Vertrauen in die Mitarbeiter gehen. Weil es aktuell gar keine andere Chance mehr gibt, als den Mitarbeitern zu vertrauen, die halt im Homeoffice nicht erreichbar sind. Diejenigen, die im Projektmanagement-Business oder auch viel bei Kunden vor Ort sind oder waren, werden nachvollziehen können, dass es einige Kunden gibt, und ich/wir habe/n auch einige, die einfordern, dass man vor Ort ist. Und nur dann, wenn man sichtbar ist, was abrechnen darf. Dieses Zeitalter ist vorbei! Und das passiert aber nur dann, und gerade bei den Firmen, die heute Mittag in diesem einstündigen Webinar auch genannt wurden. So und das passiert aber nur dann, bei den Unternehmen, die in der Lage sind zu innovieren. Und was heute Mittag auch gesagt wurde ist, dass deutlich mehr Unternehmen als man jemals erwartet hätte, in der Lage sind, zu transformieren. Und zwar speziell die, die nicht abhängig sind von irgendwelchen Fabriken, wie die Autoindustrie aktuell, die halt kein Auto produzieren kann, weil die Lieferketten langsam austrocknen. Aber Menschen wie wir und Unternehmen, mit denen wir zusammenarbeiten, sind jetzt gefordert in die Umsetzung zu kommen und das Offline ins Online zu bringen. Und das wird einer unserer Schwerpunktthemen heute sein. Es gibt zwei, drei Protagonisten hier, die ich auch im Vorfeld schon angesprochen habe, dass sie uns ein paar Insights geben. Nur bevor wir dazu kommen, muss ich es aufmalen, weil, wie gesagt, der Screen sich nicht teilen lässt. Für die, die Erfolgsformel kennen, gibt es hier ein paar im Call, die sie noch nicht kennen, zum Beispiel die Annick und das ist nicht schlimm, das kriegen wir noch aufgeholt. Was steht oberhalb des Bruchstriches? Haut es einfach mal rein. ((FÄHIGKEIT + MOMENTUM) x GLAUBE / (RISIKO + UNSICHERHEIT)) WARUM Super! Also Erfolg ist das Ergebnis von eurer Substanz, plus dem Momentum, was ihr aufnehmt, also die Dynamik, der Fokus, die Energie, die ihr in ein System reinbringt, welches entweder nochmal grandios multipliziert wird oder verstärkt wird, nämlich durch den Glauben, den ihr an euch habt und an das Momentum, was ihr aufgenommen habt, beziehungsweise Menschen, die an euch glauben von außen, und Menschen denen ihr euren Glauben schenkt, nämlich das Team, für das ihr vielleicht verantwortlich seid. Es aber auch alles zum Erliegen bringen kann, wenn nämlich der Glaube zusammenbricht, wie bei Solveig fast am Tag acht des John-Muir-Trails, wo sie gesagt hat „wie soll ich das denn schaffen und jetzt kommen noch acht Tage und es war eh schon so hart und die nächsten acht Tage werden noch viel härter und überhaupt, dieses Team, die sind alle so stark und ich bin so schwach und was mache ich alles?“ War das Momentum nicht beeinträchtigt. Die Fähigkeiten waren die gleichen, außer, dass vielleicht ein paar Blasen mehr an den Füßen gewesen sind, kann der Glaube entweder alles nach oben bringen oder alles zusammenfallen lassen. Das Ganze wird bisschen beeinträchtigt durch Risiko und Unsicherheit und wird nochmals potenziert durch die intrinsische Motivation, nämlich euer Warum und das, was euch im Kern antreibt. Das nochmal zu Wiederholung. Wir machen jetzt kein Super-Learning, um das nochmal zu verinnerlichen, sondern meine Schlüsselfrage ist an euch: ? Was ist der Impact auf diese Erfolgsformel durch Corona?? Inwieweit verändert sich für jeden einzelnen von euch, und für uns als System, wie wir jetzt hier sitzen, für uns als Gesellschaft, für das Land, für den Kontinent, für die Welt, was verändert sich hier an diesen Parametern für, oder aufgrund Corona? Risiko und Unsicherheit:Ist das Risiko eingetreten, was wir nicht auf dem Schirm hatten? Das heißt, ich vergleiche das immer mit 9/11, das ist ein bisschen böse, aber auch bei 9/11 hatte niemand auf dem Schirm, dass da zwei Flugzeuge in zwei Tower fliegen und dreieinhalb tausend Menschen alleine in New York sterben. Dann später nochmal dreieinhalb tausend US-Soldaten im Krieg. Das hatte keiner auf dem Risikoregister. Und somit ist ein Risiko jetzt auch mit Corona, was vielleicht Bill Gates und ein paar andere kluge Köpfe schon vor Jahren vorhergesehen haben und die kommen jetzt alle, nicht Bill Gates, aber die anderen, die es vermeintlich auch gesehen haben, kommen jetzt alle aus ihren Löchern und sagen: „Alle zehn Jahre gibt es eine Wirtschaftskrise und ich wusste genau, dass das jetzt kommt“, … aber Corona hatte trotzdem keiner aufm Schirm. Und das Spannende ist, dass Corona, und das ist für dich ein Lerngeschenk Solveig, kein Risiko war in dem Sinne, weil das haben wir nicht antizipiert. Das stand auf keinem Risikoregister, das war nichts, was wir gesehen haben, sondern es ist jetzt etwas, nämlich eine massive Unsicherheit, die bei jedem einzelnen von euch auftritt, aber wir kommen so langsam wieder aus dem Schlamm raus. Ihr merkt das vielleicht an euch oder auch an eurem Umfeld, dass wir uns langsam mit dieser Situation, na ja, arrangieren und somit wieder Gas geben können, aber dabei trifft uns diese Unsicherheit gerade massiv. Und die Frage ist bei dieser Erfolgsformel, wie sind wir in der Lage mit Risiken, die wir nicht auf dem Schirm hatten, und die massiv eintreten und mit Unsicherheiten auf dem Weg, die wir nicht gesehen haben, aber mit denen wir umgehen dürfen, wie sind wir in der Lage auf das zu reagieren? Das macht den außergewöhnlichen Leader und das seid ihr, jeder einzelne von euch unterscheidet das von der Masse. Wie sind wir in der Lage mit Risiken, die wir nicht aufm Schirm hatten, wie Corona, als auch die Unsicherheiten, die uns beziehungsweise unser Umfeld gerade umtreiben, wie sind wir in der Lage damit umzugehen? Was passiert weiter durch Corona, Solveig? Was ist der weitere Impact durch Corona auf diese Erfolgsformel oder jede andere? Solveig, du hast das super gesagt. Jetzt mal die anderen. Was ist weiterer Impact durch Corona auf die Erfolgsformel und somit ein Impact auf den gesellschaftlichen beziehungsweise euern persönlichen Erfolg? Haben sich eure Fähigkeiten mit dem Ausbruch von Corona verändert? Das heißt, Fähigkeiten und Substanz ist die gleiche, aber … wir müssen unsere Fähigkeiten, die wir in uns haben, über andere Medien, über andere Formen ins Außen bringen, weil was weggebrochen ist? Die reale Welt. Wir sitzen zuhause. Und was hat das für einen Impact, dass wir jetzt zuhause sitzen, auf die Fähigkeiten, die wir vor, ich sage mal vier Wochen nur hatten? Reichen unsere Fähigkeiten? Das gilt nicht für alle hier im Call, aber für einige, reichen die Fähigkeiten aus, um mit der aktuellen Situation umzugehen, dass wir in Selbstquarantäne in unserem Homeoffice ohne Kontakt nach außen zur vollen Leistung, zur vollen Güte einbringen können? Ein(e) Teilnehmer(in) berichtet:Also ich kann ja nur mal von mir sagen, liebe Grüße aus dem Norden.Ich hatte vorhin einen Anruf von meinem Auftraggeber, den ich zusammen mit TJ an den Haken bekommen habe. Und da geht es um einen digitalen Change-Prozess, in dem sie ihre Akten „elektronisieren“ wollen. Das lag jetzt durch Corona eine oder zwei Wochen brach und ich habe mit ihnen vorbereitet, dass wir digital weiterarbeiten. Heute kam der Anruf, dass es weitergeht und dass sie diese elektronische Akte noch schneller haben wollen als vorher. Und diese ganze Veränderung und das ganze Change-Management, was wir da jetzt anstoßen werden, wird halt nur einen anderen Kanal finden. Aber sie nutzen das jetzt auch und das, was ich dann vor drei oder vier Wochen schon prognostiziert habe, dass wir so weiterarbeiten werden, dass sie mich auch so schnell nicht loswerden, das machen wir jetzt einfach. Aber das hat halt einen Moment gedauert. Also ein Stück weit, weil es einfach Verunsicherung von deren Seite gab. Ich wusste jetzt auch nicht, ob sie weiter mit mir arbeiten werden, aber da gab es gar keinen Zweifel dran. Es wird sich nur der Kanal ändern. Und die Fähigkeiten bleiben die gleichen. Du hast was ganz Wichtiges gesagt. Der Kanal ändert sich. Wir haben dieselben Möglichkeiten. Unsere Substanz reicht aus, um über den neuen Kanal mit unseren Kunden und mit unserem Umfeld, mit der Nachhaltigkeit und mit der Intensität, mit dem Impact zu agieren. Genauso wie wir es vor Corona hatten? Auf was ich hinaus möchte ist, dass sich mit Corona mit einem Schlag herausstellen wird, ob wir in der Lage sind, schnell zu dem Menschen zu werden, der in der Lage ist Erfolg zu erreichen, indem wir uns nämlich der neuen Situation stellen. Das ist das Thema Unsicherheit und Risiko. Und die Fähigkeit vielleicht bei dem ein oder andern nicht ausreicht, sich dieser neuen Situation zu stellen. Ich mache ein Beispiel: Weil wir vielleicht nicht wissen, wie Zoom funktioniert und wie wir mit unseren Kunden über Zoom in einer wirkungsvollen Art und Weise kommunizieren. Ich habe heute Mittag diesen Call gehabt, zweihundert Leute im Call. Das war wie ein YouTube-Video. Ja, ihr werdet das sehen, wenn ich das mit euch teile. Das ist ein Riesenlerngeschenk, weil mich der Europaverantwortliche nach dem Call gefragt hat „TJ, hast du ein paar Impulse?“ Und meine Zeit, die halbe Stunde, die ich zwischen diesem Call und dem Erreichen der WhatsApp-Nachricht hatte, reicht nicht aus, um ihm die ganzen Impulse zu schicken, die ich habe, um seinen Call zu verbessern. …. ein paar Informationen zum Ablauf des Zoom-Calls: Sie haben den Call aufsetzen können und sie waren in der Lage alle stumm zu schalten, so dass man keinen sieht, sondern nur den Sprecher mit seinen Folien. Und der Sprecher hat ein Skript abgelesen und jemand hat für ihn die Folien geswitcht. Also wie so ein Redner, der am Pult steht und nicht weiß, wie man Folien switcht und dafür jemanden braucht. Diese Menschen sind nicht in der Lage, über die aktuellen neuen Medien nicht in der Lage andere Menschen zu erreichen. Das heißt, was passiert ist am ersten März oder rund um den ersten März ist, dass mit einem auf den anderen Tag die Fähigkeiten von uns nicht mehr ausreichen, um wirksam in der Welt zu agieren, weil wir noch nicht verstanden haben, wie wir das Offline ins Online bringen, teilweise. Wie gesagt, es gilt für manche, nicht für alle. Aber wie viele von euch haben in den letzten vier Wochen ganz viele Lerngeschenke erhalten und so viel dazugelernt, wie vielleicht die zwölf Wochen davor nicht? So, und das ist genau der Punkt. Worauf ich raus möchte ist, dass durch so ein Event sich die Fähigkeit und die Substanz, die wir in uns tragen, nicht verändert, diese aber von einem auf den anderen Tag nicht mehr ausreichen, um am Markt wirksam zu sein. Normalerweise ist das ein Prozess, der ein bisschen länger dauert. Und in dem Fall hängt uns das ab, was jetzt notwendig ist. Wenn wir nicht in der Lage sind, der Technologie zu folgen. Deswegen haben wir heute ein ganz spezielles Thema. Jörg beziehungsweise auch Florian werden mit uns, und ich hoffe, dass wir das mit dem Bildschirm irgendwie hinkriegen, dass ihr das teilen könnt, welche Erfahrungen ihr im Bereich eurer Webinare gemacht habt. Wie du, Jörg, letzte Woche Montag interagiert hast, und was du daraus gelernt hast. Und Florian hat mit uns in der letzten Woche, in einer anderen Mastermind-Gruppe, via Zoom mit einem Interaktionstool gearbeitet, das sich Mural nennt. Damit waren wir in der Lage uns mit virtuellen Post-its und allem, was man so in Workshops macht, virtuell online für alle sichtbar, kollaborativ (mit sechs Leuten) über eine gesamte Woche durch einen Prozess zu führen. Das war grandios. Dabei haben wir auch mega viel gelernt und das wird er nachher mit uns teilen, damit wir euch an den Erfahrungen teilhaben lassen, die euch in die Lage versetzen, diese Fähigkeiten und Substanz ganz schnell aufzubauen. Damit ihr in der Lage seid, mit euren Kunden aus dem Homeoffice heraus zu interagieren. Und ich darf euch versprechen, dass nach Corona, wenn die Krise jetzt lange genug anhält, [wenn die morgen fertig ist, fallen wir sofort wieder in alte Muster zurück, die Flugzeuge fliegen wieder, wir gehen wieder zur Arbeit] hat sich das Ganze so eingeschwungen und so manifestiert, dass es deutlich schwerer fallen wird in die alten Muster zurückzukommen. Vielmehr werden die Menschen das einfordern, zuhause zu sitzen, weil es einfach geil ist mit der Familie und mit Kindern und mit dem Partner einfach eine schöne Zeit zu haben, und nicht wieder zwei Stunden jeden Tag im Stau zu stehen. Also Fähigkeiten und Substanz, über Nacht sind sie nicht mehr wert, beziehungsweise wir dürfen ganz schnell aufholen, weil uns sonst der Markt abhängt. Welchen Impact hatte Corona auf das Momentum? Was habt ihr wahrgenommen? Ein(e) Teilnehmer(in) berichtet:Auf einmal gehen Sachen, die sonst nicht gehen. Also wir haben alleine im ganzen Umfeld der Bedenkenträger, mit Genehmigungsverfahren und was man alles machen darf und nicht machen darf, viele Teilen ad acta gelegt. Und wir haben Dinge getan, weil wir sie tun mussten, um einfach voranzukommen. Das habe ich zumindest im Projekt wahrgenommen.  Also zusammengefallen ist es in der alten Welt.Ein gutes Beispiel sind Fabriken der Automobilbereich, die Bereiche in denen Berater tätig sind: Flugbereich (Lufthansa), Autombilbranche … et cetera. Diese haben alle Berater heimgeschickt, haben Cost-Saving gemacht und viele Projekte eingestellt. Das ist der Augenblick, in dem das Momentum teilweise komplett zusammengefallen ist.Lorenzo Scibetta und Oliver Buhr haben erlebt, dass innerhalb von zwei Tagen die gesamten Buchungen für Workshops und Speakings abgesagt werden mussten. So auch bei Jessica, die Restaurantbetriebe erstmal schließen mussten. Ein(e) Teilnehmer(in) berichtet weiter von einem Beispiel aus der Telco-Branche:Es gab eine Aktion, in der sie erstmal stumpf ihren ganzen Kunden kostenlos die Internet-Bandbreite verdoppelt haben, damit die Kunden besser online arbeiten können. Die Software-Projekte, die wir da im Moment machen, die werden halt weitergeführt, weil die strategisch extrem wichtig sind. Also das ganze Thema rund um: Wie kann ich Customer-Experience und Kundenbindung verbessern? Das heißt, die Software-Projekte laufen alle weiter. Es gab natürlich auch Cost-Savings, aber die ganzen Software-Projekte wurden im Budget nicht beschränkt, sondern weiter ausgebaut. Ich habe jetzt von einem Tag auf den anderen ein Scrum-Team mit ungefähr zwanzig Leuten, und das machen wir jetzt eben halt komplett remote. Wir haben in Bezug auf die Remote-Arbeit auch noch viel zu lernen. Also da sind wir wieder bei den Fähigkeiten. Zum Beispiel die Frage: Wie kriegen wir die Sachen geshared? Wie können wir kollaborieren? Wie können wir Ideen sammeln? Wie können wir coole Retros machen? Wie können wir gemeinsam lernen? Wie kriegen wir die Interaktion zwischen den Leuten verbessert? Und so weiter und so fort. Und das planen wir für jeden Tag. Ich möchte jetzt für alle, die nicht so firm sind: Was wir hier machen ist viel Kommunikation und ganz wenig Kollaboration. Also natürlich mal jemanden sprechen lassen, mal hier was in die Kamera halten, ein bisschen was zeigen. Aber das geht natürlich noch deutlich weiter, wenn du ein Planning-Poker machen musst oder eine Retrospektive mit Post-it's. Da geht es natürlich nochmal ganz anders zur Sache, was notwendig ist, um echt zu kollaborieren. Darf ich euch allen mitgeben, dass Mark, und gleich auch Florian, das werdet ihr erleben, Kollaborations-Monster sind. Sie werden euch bei jedweden Offline ins Online gebrachte, Kollaborations- und Workshop-Ansätzen grandios unterstützen. Ihr werdet das, nur ein kurzer Zwischen-Impuls, erleben. Für alle die, die bei dem PBM-Workshop im Mai (den werden wir komplett online machen) teilnehmen werden, komme ich am Schluss nochmal dazu. Es wird darum gehen Online-Trainings, gepaart mit solchen Calls über zwei bis drei Tage, [wir, Birgit und ich, sind gerade noch dabei das in Kombination Florian Hameister, als jemand, der die Technik und im Hintergrund aktiv mit fazilitiert auszugestalten] ein Online-Workshop-Konzept mit Nachübung zu entwickeln. Und ich darf das nur jedem anraten. Macht euch solche Kompetenzen zunutze, es ist unglaublich, was es heißt, jemanden an seiner Seite zu wissen, der die Technik für einen managt und in der Lage ist das gleich sehen, wie zum Beispiel bei Florian -  schafft und etabliert Euch ein Umfeld, indem ihr als Moderator frei seid von der Technik, damit ihr Menschen in die Kollaboration bekommt. Und das ist gerade hier im Bereich Momentum und Substanz ein Killer, denn das, was Corona auch mit euch macht ist was? Der Glaube. Wie viel haben deutlich weniger Glaube oder im Englischen würde man sagen, Absolute-Certainty, also diese absolute Zuversicht? Bei wie vielen von euch ist da etwas zusammengebrochen im Sinne von: ? Kann ich in dieser Krise noch wirksam sein?? Was mache ich jetzt mit meinen Kunden?? Bin ich gut genug, um das noch liefern zu können, für das, was ich eigentlich stehe? Wie schaffe ich das überhaupt?? Wie komme ich da durch?? Wie kommen wir da durch? (Ich, meine Familie, alle drumherum, meine Kunden?) Wie viele treibt das aktuell um? Gut, einige von euch, und bei den anderen gehe ich davon aus, dass sich die Frage nicht so straight forward formuliert hat. Also mich und uns hat die letzten Wochen, die Frage umgetrieben: are we ready? Sind wir in der Lage, Mehrwerte zu schaffen? Sind wir gut aufgestellt, um für all die, für die wir dienen dürfen? Wenn ihr nämlich den Glauben an euch verliert, und ihr vom Außen sagt: Mensch, ist alles so mies da draußen - schaut euch nur die ganzen Online-Zeitungen an (schon wieder zehntausend tot, Lieferketten brechen zusammen…), was macht das mit unserem Glauben? Deswegen sind solche Gruppen hier so wichtig, weil wir lernen werden und verstehen werden, dass es auch anders geht. Wie jetzt die Beispiele heute Mittag aus dem Call beziehungsweise die Beispiele, die wir jetzt auch von Mark gehört haben. Also achtet darauf und nutzt die Gruppe, nutzt uns. Also ich habe zu Birgit schon gesagt und zu einigen von euch: Ich habe in den letzten Wochen so viel gearbeitet, wie selten zuvor und es fühlt sich trotzdem an wie Urlaub. Birgit meint, es wäre pervers, ich sage: Nein, es ist einfach wunderbar! Es ist wunderbar mit euch zusammenzuarbeiten und jeden einzelnen nach vorne zu bringen. Fordert das ein, speziell, wenn es am Glauben hakt, wenn ihr Fragen habt, wo ihr mit eurer Substanz am Hadern seid - beziehungsweise Andreas Rogallas, der jetzt gerade noch nicht im Call ist, der aber die Frage heute Mittag noch reingeworfen hat:  Was ist, wenn man in eine Lethargie verfällt? Dann ist nämlich das Momentum zusammengefallen. Andreas, wir reden gerade über dich. Ja, wenn Andreas sagt, ich bin in die Lethargie verfallen, dann ist das Momentum zusammengebrochen und nutzt den Austausch mit dieser Gruppe. Fordert es aktiv von uns ein! Es gibt kaum jemanden, der nicht jeden Tag hier von euch bei mir auf der Matte steht und sagt „TJ, ich brauche einen Impuls. TJ, können wir sprechen? Hast du irgendwas? Was mache ich damit?“ Ja? Gibt so ein paar Role-Models von euch, die ich will nicht sagen fast stündlich, aber, in denen es halt richtig „zimmert“ in WhatsApp und am Telefon. Fordert das ein, um gerade hier, in dieser Erfolgsformel euch mit dem was passiert neu aufzustellen. Was denkt Ihr, wie viele glauben, dass sich eine intrinsische Motivation, also das, was euch im Inneren antreibt, durch Corona gerade verändert? Ein(e) Teilnehmer(in) berichtet:Also ich habe das Gefühl, dass ich durch das ganze Zurücknehmen von diesem Ganzen, ich will jetzt nicht sagen im Hamsterrad, aber ich bin irgendwie weggerannt vor Corona. Und ich bin irgendwie gefühlt um mein Leben gerannt und habe irgendwie alles gar nicht mehr so unter einen Hut gekriegt, was ich alles machen wollte und habe gar nicht mehr so gefühlt, was ich eigentlich wirklich möchte. Und durch dieses ganze Corona-Krisenmanagement, wozu ich jetzt auch gezwungen bin, mir das ganze zuhause zu organisieren, ist es für mich erstmal so ein bisschen innehalten, und zu schauen wo ich jetzt den Fokus drauflege. Ich habe für mich ganz klar momentan die Punkte, wo ich meinen Fokus drauflege. Und ich habe eine ganz andere Motivation, da jetzt ranzugehen, als vorher. Ich kann das jetzt gar nicht so in Worte fassen, aber für mich hat Corona einiges klarer gemacht, würde ich mal sagen, … auch beruflich und überhaupt meine ganze Lebensweise. Also diese Motivation von innen heraus für meinen Fokus, ist anders als vorher. Weil vorher war ich in so vielen Rollen, wurde in vielen Sachen gebucht. Ich habe meine Gastronomie in Berlin, ich habe so viele Parallelen gehabt, wo ich Energie reingesteckt habe, weil ich es machen musste - teilweise, weil es nun mal mein Job war oder ich dafür gebucht wurde. Aber diesen Fokus, den ich eigentlich verfolgen wollte, dafür hatte ich dann keine Motivation. Die Energie hat mir dann auch gefehlt. Und momentan ist es so, dadurch, dass natürlich einiges wegbricht, weil es nun mal so ist, wie es ist in Berlin (wir können nicht aufmachen, uns sind die Hände gebunden) habe ich aktuell einen ganz anderen Fokus und eine ganz andere Motivation, Dinge anzuschieben, als vorher. Und aus der Not heraus entstehen sowieso immer die besten Dinge. Und aus der Not heraus habe ich jetzt gerade das Glück in Anführungszeichen mich auch mit dieser Technik auseinanderzusetzen. Hätte ich vorher gar nicht gemacht, weil mir die Zeit auch gefehlt hat. Wann sollte ich das denn noch machen? So war immer mein Gefühl. Ich war halt so getrieben in diesem Ganzen. Man schwimmt so mit und versucht irgendwie noch neue Dinge anzuschieben, aber es war nichts Halbes, nichts Ganzes. Die Nachfrage, ob die Gefahr besteht wieder in alte (intrinsische Motivations-)Muster zu verfallen, oder diese neue Motivation ein achtsamer und bedachter Anfang einer neuen Zukunft ist, antwortet der/die Teilnehmer(in): Ich glaube nicht, dass wir ins alte Muster geraten. Wenn wir jetzt mal alle an uns selber denken, wenn wir an irgendwas Gefallen finden, machen wir das ja weiter und noch mehr. Und ich glaube wir sind jetzt in der Lage, dass wir neue Dinge ausprobieren können und müssen und wir dann Step by Step daran Gefallen finden. Und dadurch, dass wir halt jetzt alle eine andere Zeit haben und einen anderen Sinn dahinter sehen, legen wir ganz anders den Fokus auf bestimmte Dinge und werden das natürlich in Zukunft auch mehr verfolgen. Also ich glaube nicht, dass wir da in alte Muster verfallen. Wie viele sehen auch Veränderungen und glauben, dass sie nicht zurückfallen werden in alte Muster? Also was heißt das im Umkehrschluss? Wir dürfen Corona auch als eine Chance verstehen. Ich habe eingangs gesagt, wenn es ein Leben nach Corona gibt. Wenn es keins gibt, haben wir eh ein anderes Problem. ABER, wenn es ein Leben nach Corona gibt, haben wir jetzt die Chance in die Umsetzung zu kommen und uns auf diese Veränderung einzulassen und deutlich gestärkter bei allen Herausforderungen, die hieraus resultieren, deutlich gestärkter aus dieser Krise hervorzugehen, als wir hineingegangen sind. ---------------------------------- Und nun, wenn du als Trainer, Coach, Berater, Speaker, Experte dein nächstes Level erreichen möchtest und in die Umsetzung kommen möchtest, wenn du deine Strategie entwickeln, deine Vision entstehen, deine Ziele erreichen möchtest, dann lade ich dich ein, auf www.torstenkoerting.com/termin einen persönlichen Umsetzungstermin mit mir zu vereinbaren. Wir können uns dort kennenlernen, wir können dort deine aktuelle Situation analysieren. Wir können besprechen wo du hin möchtest, wir können betrachten, wie du dort hinkommst. Wir analysieren, was dich davon abhält und was möglicherweise notwendig ist, damit du deine Ziele erreichst. Gleiches gilt für Organisationen, die ihre Teams entwickeln möchten, die Workshops fazilitiert haben möchten und die Projekte aus der Schieflage wieder auf die gerade Bahn und Teams darzubringen möchten, ihre Projekte zu liefern. Auch Sie und dich lade ich ein, diesen Termin zu vereinbaren, damit wir genau die aktuelle Situation, das Zielbild und wie kommt ihr dahin besprechen können unter www.torstenkoerting.com/termin. Ich freue mich auf deine Anfrage und das persönliche Gespräch mit dir. Bis dahin. Der Torsten. Ciao, Ciao   Quick Links: Sichere Dir jetzt ein Ticket für das 2 tägige Event ‚LEADERS BASECAMP‘ ... denn ... Leader werden nicht geboren, sie werden gemacht. Und sicher Dir mit dem Code PODCAST25 einen Rabatt in Höhe von 25% www.leaders-basecamp.com Vereinbare jetzt einen persönlichen Umsetzungstermin mit mir ... in dem wir Deine Aktuelle Situation analysieren, betrachten wo Du oder Dein Team hin möchtest, wir können aufzeigen, wie Du dahin kommst, was Dich aktuell davon abhält und was möglicherweise notwendig ist, um Dich einen Schritt weiter zu bringen und damit Du Deine Ziele erreichst. www.torstenkoerting.com/termin/ Torsten J. Koerting auf Facebook www.torstenkoerting.com/facebook/ Torsten  J. Koerting auf Linkedin www.torstenkoerting.com/linkedin/ Torsten J. Koerting auf XING www.torstenkoerting.com/xing/ Torsten J. Koerting auf Instagram www.torstenkoerting.com/instagram/ Mehr Infos und alle Folgen des Podcasts findest du hier! www.torstenkoerting.com/podcast/

Haben Sie Lust erste Schritte in Richtung agiles Arbeiten zu gehen? Von Daniela Behrendt erfahren Sie mehr über agile Methoden – heute: Planning Poker. Hören Sie rein.

Stuff mentioned in this podcast:https://clubhouse.io37signals Employee handbook.The Famous git flow article for git workflow.https://keepachangelog.com/ for changelog tracking.A good article for git mentioning git rebase, squashing .. etc.Gitlab ChatOps.Health Check Monitoring Tools.Nightwatch: End-to-end testing, the easy way.Elk stack.LogRocket.Sentry.Prometheus.Grafana.Planning Poker for estimation.Architectural decision records.Cypress for E2E testing.Lighthouse.FastlaneToday Picks:Alfy: How to raise an adult book.Luay: Business wars podcast.

In dieser Folge haben wir mit David über seinen Weg vom Freelancer zum Unternehmer gesprochen. Kontakt David: david@helloagile.de Twitter: @HelloAgileDe Freelancer Schmiede: https://www.helloagile.de/freelancer-schmiede Infos zu Lego Serious Play: https://www.helloagile.de/lsp Infos zu Planning Poker: https://www.helloagile.de/planningpoker Planning Poker Karten auf Amazon: https://amzn.to/2Qj8JRe Alle Workshoptermine: https://www.helloagile.de/termine Scrum Flow Poster: https://www.helloagile.de/scrum-flow Poster auf Amazon: https://amzn.to/31yIzvc Günter Faltin - Kopf Schlägt Kapital: https://amzn.to/2LAQC4P Tim Ferriss - Die 4-Stunden-Woche: https://amzn.to/2QhhziE -- Schreib uns bei Instagram: https://www.instagram.com/freelancerpodcast Schreib uns bei Facebook: https://www.facebook.com/FreelancerPodcast/ LearnFreelancing App: https://learn.goodlanceapp.com/de/ Stundensatzrechner: https://stundensatz.goodlanceapp.com/ Stundensatz-Analyse: https://analyse.goodlanceapp.com/ Doku “Freelance Germany”: https://watch.freelance-germany.de/ Tritt unserer Facebook-Kooperations-Gruppe bei: http://bit.ly/2yE2laI Tritt unserem Slack Workspace für Freelancer bei: https://bit.ly/2sM1d39 Kontaktiere uns: http://Freelancer-Podcast.de Rechnungstool, Buchhaltung, Zeiterfassung und Planung in einem: https://GoodlanceApp.com 1 Monat kostenlos mit dem Code "FacebookGruppe"

Czym jest Planning Poker? Do czego służy ta technika i jak z niej skorzystać? Jak wykorzystywać ją w różnego rodzaju projektach, nie tylko informatycznych? O tym będzie w dzisiejszym odcinku. Serdecznie zapraszam

Pour voir la version vidéo : https://youtu.be/LWUmGsEY6N4?list=PLxTb_ZC4kmrSaj0NIY0v2_wLT-9Ov4cIY Le Product Owner prend-t-il part aux estimations lors du Planning Poker ? Cette question est posée par Martin Scher concernant l'animation du Sprint Planning ou du Backlog Refinement. Découvrez-en plus dans la description ci-dessous

Wer ein neues Projekt im täglichen Geschäft einplant, für den ist auch das Schätzen des nötigen Aufwands ein entscheidender Faktor. Eine wichtige Unterscheidung liegt dabei in den Aspekten Umfang, das heißt Größe und Komplexität eines Vorhabens, und dem zugehörigen Aufwand.Wie sich mit neuen Methoden aus der agilen Welt frischer Wind in verschiedene Problemfelder bringen lässt, zeige ich Ihnen im Folgenden am Beispiel von Planning Poker. Gerade im Bereich von Softwareprojekten hat sich gezeigt, dass Entwicklungs- und Produktfertigungsprozesse so komplex sind, dass sich die Umsetzung bzw. einzelne Umsetzungsschritte nur sehr schwierig im Voraus planen lassen. Deshalb ist es in der Regel sehr schwierig, eine Prognose zu wagen: Manche legen auf ihre Schätzung einen ordentlichen Puffer drauf, andere schätzen eher sportlich und bekommen dann Ärger mit dem Auftraggeber, wenn das Projekt in Verzug gerät.

Spendere tanto tempo per arrivare ad una stima non aumenta necessariamente la precisione della stima.Uno Story Point è una unità di misura relativa, decisa e utilizzata dai singoli team Scrum, per fornire stime relative dell' effort necessario al completamento delle funzionalità. Gli Story Point hanno lo scopo di facilitare la stima del team. Invece di guardare un elemento del product backlog e stimarlo in ore, i team considerano solo quanto effort richiederà un elemento del backlog rispetto ad un altro elemento del backlog. Gli Story Points forniscono stime più accurate, riducono drasticamente i tempi di pianificazione, predicono in modo più accurato le date di rilascio e aiutano i team a migliorare le prestazioni. Le ore danno stime peggiori, introducono grandi sprechi di tempo nel sistema, ostacolano la pianificazione del rilascio del Product Owner e confondono il team su quali miglioramenti del processo abbiano realmente funzionato.Anche se è risaputo che le migliori stime sono date da chi effettivamente farà il lavoro, ma in un team Scrum non sappiamo in anticipo chi sarà. Pertanto, la stima dovrebbe essere un'attività collaborativa per il team. Un modo divertente ed efficace per il team di pianificare in Story Points è il Planning Poker. Nel Planning Poker, ad ogni membro del team viene assegnato un mazzo di carte con una stima valida riportata su ogni carta (tipicamente un numero della serie di fibonacci). La funzionalità da stimare è discussa fin quando non sarà sufficientemente chiara per tutti, dopo di che ogni membro del team seleziona la carta che rappresenta la sua stima. Tutte le carte sono mostrate nello stesso tempo. Le stime vengono discusse e il processo viene ripetuto fino a quando non viene raggiunta una stima condivisa.

Spendere tanto tempo per arrivare ad una stima non aumenta necessariamente la precisione della stima.Uno Story Point è una unità di misura relativa, decisa e utilizzata dai singoli team Scrum, per fornire stime relative dell' effort necessario al completamento delle funzionalità. Gli Story Point hanno lo scopo di facilitare la stima del team. Invece di guardare un elemento del product backlog e stimarlo in ore, i team considerano solo quanto effort richiederà un elemento del backlog rispetto ad un altro elemento del backlog. Gli Story Points forniscono stime più accurate, riducono drasticamente i tempi di pianificazione, predicono in modo più accurato le date di rilascio e aiutano i team a migliorare le prestazioni. Le ore danno stime peggiori, introducono grandi sprechi di tempo nel sistema, ostacolano la pianificazione del rilascio del Product Owner e confondono il team su quali miglioramenti del processo abbiano realmente funzionato.Anche se è risaputo che le migliori stime sono date da chi effettivamente farà il lavoro, ma in un team Scrum non sappiamo in anticipo chi sarà. Pertanto, la stima dovrebbe essere un'attività collaborativa per il team. Un modo divertente ed efficace per il team di pianificare in Story Points è il Planning Poker. Nel Planning Poker, ad ogni membro del team viene assegnato un mazzo di carte con una stima valida riportata su ogni carta (tipicamente un numero della serie di fibonacci). La funzionalità da stimare è discussa fin quando non sarà sufficientemente chiara per tutti, dopo di che ogni membro del team seleziona la carta che rappresenta la sua stima. Tutte le carte sono mostrate nello stesso tempo. Le stime vengono discusse e il processo viene ripetuto fino a quando non viene raggiunta una stima condivisa.

Estimating product backlog items using planning poker is the topic for this episode. The benefits of planning poker: gain a shared understanding of the work, bring diverse perspectives to the estimation process and estimate the work as we learn about the Dynamics 365 system. Who plays planning poker: the role of Scrum team developers, the product owner and proxy product owners in estimation. When to play planning poker during each sprint: sprint planning and storytime. What to play planning poker with: planning poker cards, PlanningPoker.com, Planitpoker.com or Scrumpoker.online, or ScrumPoker4Devs from the Visual Studio Marketplace. How to play planning poker: describe the requirement, estimate independently, reveal estimations, discuss outliers and play again until a consensus is reached. Things to do before you play: agree your estimation units and scale, baseline user story and definition of done.

Le blog de Jean-Pierre : https://jp-lambert.me L'entreprise de Michael : http://wealcomecompany.com Pour rejoindre la communauté des artisans développeurs : https://artisandeveloppeur.fr

Heute geht es wieder um Scrum und um das Thema Planning Poker. Wieso es wichtig ist und wie es abläuft. Danke und viel Spaß damit. Email: podcast@lundero.de Folge direkt herunterladen

In this weeks episode Mick and Edd have a long overdue catchup! We start off the show by discussing Mick’s new job, the new stack he is using, and the benefits of working in a team. From here we highlight how his company uses Scrum (Sprints, Planning Poker and Story Points), handling event-sourced models with the introduction of GDPR, and logic within annotations. Finally, we touch upon Edd’s recent engagement and marathon, a new Serverless/React blog series he is working on, developing applications for the Ethereum blockchain, and how to manage application secrets.

With 120+ podcast episodes, hundreds of speaking engagements, and hundreds of teams/companies coached, Bob and Josh have seen just about everything.  Using all of that experience, we narrowed down on some of the most frequently asked questions across everyone we helped. What questions do you field over and over again in your travels?  Let's discuss! Help Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on  Google Play (https://www.patreon.com/metahyphencast) Sponsor Links: Is your team struggling with planning? PlanningPoker.com is here to help!  Use promo code METACAST to save 20% off the first month of a Standard of Pro plans.  Need more info?  Check out planningpoker.com/metacast to learn how to improve your planning! The AgilePacks team is excited to offer a 20% off discount code on your first purchase of an AgilePacks kit. There's a Starter and a Pro option to fit you and your team's needs. Simply enter METACAST at checkout to save.  Get your discount here. Support this podcast

Planning poker is great - if people respect each other.

On today's episode we're talking story points, story sizes and story planning. What happens when you're working as team, and find out that a two is actually secretly a five? What happens when stakeholders come in and add additional scope creep? Today we discuss how to derive those story sizes and some of the things that happen when the point system that you used gets used (and perhaps misinterpreted) by humans. From scope creep, to edge cases, to Planning Poker, sandbagging and YOGONY – How do we handle external pressure and continue to ship it real good? Take a listen!

Estimating is hard. In fact, estimating is sometimes considered one of the hardest aspects of development. While for reasons beyond your control you can never guarantee the accuracy of our estimates, you can control how well you deliver and defend the estimates you provide. In this episode we are not talking about how you can provide better estimate numbers, but the processes you can develop in yourself so that you can be confident about the estimates you deliver. Why estimating is an important development skill Something that you will be constantly asked to do in your development career Helps you to think more critically of your development work Provides opportunities for collaboration and communication with our team Before creating an estimate Establish what you know vs. what you do not know Ask questions to remove as many gaps as possible Have the mindset that your estimates will never be the actual number Methods of estimating PERT system: Optimal value, Nominal value, Pessimistic value. Averaged. Planning Poker: work with team to discuss and agree upon a value. Comparative: Look at similar previous work, how long did that take you? Breakdown: Split item into smaller workable pieces then estimate the pieces. How to deliver estimates Establish that you are providing your best guess based on what you know Provide context and information around your estimate Defend your estimate with your assumptions and experiences. Record and get sign-off of your estimate from stakeholders. Listener Challenges What methods/tools do you use to develop estimates? What are your opinions about estimates? Write some code to generate a PERT number for your estimates. Links from this episode Deep Work* by Kal Newport The Clean Coder* by Robert C. Martin Law of large numbers Previous episodes mentioned Developing a Plan The three key phrases you need to know to be a great developer. *We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.

Obwohl wir in Projekten gerade am Anfang, bei der Projektplanung, meistens eine sehr hohe Unsicherheit und Ungewissheit haben, müssen wir oft Aussagen zur Dauer, den Kosten oder dem erwarteten Ressourcenbedarf machen. Wir dürfen also die Aufwände, Dauern und Kosten im Projekt abschätzen. Wie das geht und was Du dabei beachten solltest erkläre ich Dir in dieser Episode. So habe ich die Episode für Dich aufgebaut: 1. Warum du etwas über Schätzung wissen solltest (und was eigentlich im Projekt geschätzt wird) 2. Welche Schätzmethoden gibt es? - Expertenschätzung - Analogieschätzung - parametrische Modellierung 3. Wie kannst Du beim Schätzen genau vorgehen - Einfache Schätzung - Planning Poker - 2-Punkt-Schätzung - 3-Punkt-Schätzung 4.Meine Tipps und Tricks für Dich! 5. Meine Fragen an Dich zum Weiterdenken

Agile Manifesto signatory James Grenning is your Agile wingman: when you need Agile technical coaching help, he can do it all. For Agile Alliance Technical Conference 2016, he's focusing on the three critical skills of refactoring: 1. Detecting smells in code. 2. Bright idea about how to build the code differently 3. How to transform the code into the new state James also talks about how Agile has changes since years ago when he signed the Agile Manifesto. One of the biggest changes: the majority of the signatories were developers and tech-minded individuals, but largely Agile has become more focused on process management. James Grenning trains, coaches and consults worldwide bringing modern technical and management practices to embedded systems development. He is the author of Test-Driven Development for Embedded C (http://wingman-sw.com/tddec). He invented Planning Poker, and participated in the creation of the Manifesto for Agile Software Development. SolutionsIQ's Neville Poole hosts. About Agile Amped The Agile Amped podcast series engages with industry thought leaders at Agile events across the country to bring valuable content to subscribers anytime, anywhere. To receive real-time updates, subscribe at YouTube, iTunes or SolutionsIQ.com. Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www.solutionsiq.com/agile-amped/ Follow: http://bit.ly/SIQTwitter Like: http://bit.ly/SIQFacebook

ENTHÄLT WERBELINKS   Schätzt eigentlich irgendjemand gern Aufwände? Ich bin noch niemandem begegnet. Nach meiner Erfahrung scheuen sich viele Menschen, eine Schätzung abzugeben, wie lange eine Aufgabe dauert und wie viel Aufwand sie verursachen wird. Und doch bildet die Aufwandsschätzung die Basis für die Beantragung von Projektbudgets und wird im Projektauftrag vermerkt. Schätzungen zu Beginn eines … Aufwände schätzen mal anders: Planning Poker Weiterlesen » The post Aufwände schätzen mal anders: Planning Poker appeared first on Projekte leicht gemacht.

本期由 Kevin Wang 主持，邀请到了魏伦, Bindo Labs 的 CTO 来谈远程团队的建设和远程工作的体会. 魏伦的联系方式： Blog Weibo Bindo Labs Fengche.co Redmine Trello Jira Toggl Planning Poker Intridea Campfire Rails Jobbers Tealeaf Academy 爱燃烧 比赛控 Exercism 寿司之神 Concentrate Special Guest: 魏伦.

missing content