POPULARITY
7 episodes with sprint backlog
7 episodes with sprint backlog
5 episodes with sprint backlog
3 episodes with sprint backlog
2 episodes with sprint backlog
2 episodes with sprint backlog
8 episodes with sprint backlog
7 episodes with sprint backlog
3 episodes with sprint backlog
Viele Teams liefern solide Features, füllen regelmäßig ihr Sprint-Backlog und schaffen es, in kurzen Zyklen Output zu produzieren. Doch was am Ende häufig fehlt, ist die entscheidende Frage: Welche Wirkung hat das eigentlich beim Nutzer? Genau darum geht es in dieser Folge. Oliver und Tim nehmen sich die drei häufig vermischten Begriffe Output, Outcome und Impact vor und ordnen sie praxisnah ein – nicht als Buzzwords, sondern als Grundlage sinnvoller Produktarbeit. Output ist schnell sichtbar. Ein Release ist gemacht, ein Feature live. Doch das allein reicht nicht. Outcome meint die Veränderung, die daraus entsteht – idealerweise beim Nutzer. Ein Verhalten, das sich ändert. Eine Aufgabe, die leichter fällt. Ein Problem, das nicht mehr existiert. Und genau darum sollte es gehen: Wirkung vor Lieferung. Es ist diese Wirkung, der wir in der Produktentwicklung hinterherlaufen sollten – nicht nur dem fertigen Feature. Was das schwierig macht: Outcome ist oft nicht sofort greifbar. Er entsteht nicht exakt in dem Moment, in dem ein Button live geht oder ein Flow angepasst wird. Es braucht Beobachtung, echtes Nutzerverständnis, Hypothesen und die Bereitschaft, Wirkung als Lernfeld zu begreifen. Viele Teams bleiben beim Output stehen, weil er einfacher zu messen ist. Doch wer wirklich wissen will, ob ein Produkt erfolgreich ist, muss sich auf Outcome fokussieren – auch wenn das bedeutet, Unsicherheit auszuhalten. Gleichzeitig braucht es gute Grundlagen, denn ohne verlässlichen, qualitativ hochwertigen Output gibt es auch keinen Outcome. Doch die reine Lieferung darf nicht zum Selbstzweck werden. Es geht darum, das Produkt so weiterzuentwickeln, dass es tatsächlich etwas verändert – beim Menschen, der es nutzt, und letztlich auch beim Unternehmen, das es anbietet. Hier kommt der Impact ins Spiel. Denn wenn ein Feature genutzt wird, weil es einen echten Unterschied macht, dann kann daraus auch ein (positives) Geschäftsergebnis entstehen. Oliver und Tim zeigen in der Folge, wie Product Owner diese Perspektive einnehmen können – nicht als dogmatischen Rollenwechsel, sondern als bewussten Schritt. Outcome-orientiertes Arbeiten bedeutet, sich stärker mit Nutzerverhalten zu beschäftigen, Hypothesen zu formulieren, die Wirkung von Features zu hinterfragen und gemeinsam im Team zu reflektieren, was funktioniert – und was nicht. Es geht darum, sich vom Projektdenken zu lösen, Raum für Lernen zu schaffen und sich nicht nur an der Anzahl der ausgelieferten Features zu messen, sondern an der Veränderung, die sie bewirken. Outcome ist aber nicht immer eindeutig zuzuordnen. Manchmal braucht es Geduld, manchmal bleibt Wirkung aus, obwohl der Output gut war. Doch genau das ist der Kern moderner Produktentwicklung. Es geht nicht um Planbarkeit, sondern um Verantwortung für Wirkung. Und wer als Product Owner diese Wirkung gestalten will, kommt um den Outcome nicht herum. Erwähntes Video zur Erklärung der Begriffe: - The Mindset That Kills Product Thinking by Jeff Patton Frühere Folgen, auf die verwiesen wird: - Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis - Finance Talk: Warum die Zahlen für deine Karriere wichtig sind - Agile Product Roadmaps - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen - Impact Mapping – was zahlt wirklich auf unser Business Ziel ein? - Outcome Goals & Product Discovery (Tim Herbig) Wie setzt du diese Begriffe ein? Wie erklärst du sie deinem Team und deinem Umfeld? Hast du weitere Tipps, um besser Outcome und Impact liefern zu können? Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.
Alle, die Scrum Master oder Product Owner werden wollen und mehr über die Prüfung erfahren wollen, kommen in dieser Folge voll auf ihre Kosten. Ich bespreche mit Kim Berger über die verschiedenen Möglichkeiten der Scrum Zertifizierung und wir pauken mit euch ein bisschen. Perfekte Prüfungsvorbereitung für Selbstlerner, perfekter Einstieg für alle, die sich mal erkundigen wollen, was so ein Zertifikat denn genau ist. Viel Spaß beim Hören und beim Pauken :) Fragebogen zum Herunterladen: https://www.dropbox.com/scl/fi/ej8ugbzidef1ygjn0dez4/Scrum-Testfragen.pdf?rlkey=163fxef6erngr8hyt1n8lwmam&st=9s0jdbk4&dl=0 Probefragen, die wir besprechen: What are three ways Scum promotes self-management? (Choose the best three answers) A, B, D A - By removing titles from Scrum Team members. B - By being a lightweight framework. C - By having the Scrum Master protect the Scrum Team from interruptions. D - By the Scrum team deciding what work to do in a Sprint Several Sprints into a project, the Product Owner tells the Scrum Master that a key stakeholder just started using the product. The stakeholder is unhappy with the quality of the product, and the Product Owner agrees with the stakeholders assessment that the quality is low. How should the Scrum Master respond to the Product Owner? B, C A - Explain to the Product Owner that it is up to the Developers to decide on acceptable quality standards B - Encourage the Product Owner to include quality specifications in the Product Backlog and to communicate the stakeholders concerns to the developers C - Work with the Product Owner to understand their desired resolution and help formulate an approach for raising the concern with the Developers D - Bring the concern to the testers to improve how the Product is verified E - Tell the Product Owner they have noted the concern and will raise this issue at the Sprint Retrospective When does a Developer become accountable for an item in the Sprint Backlog? (Choose the best answer) C A - At Sprint Planning when all of the Sprint Backlog items are split evenly across the Developers B - During the Daily Scrum C - Never. All Developers on the Scrum Team share accountablility for items in the Sprint Backlog D - As soon as a Developer oh the Scrum Team can accommodate more work An increment must be released to customers or users at the end of each sprint True False
Stop Doing Scrum All Wrong... Are you finding that Scrum isn't working for you? Do you constantly find that you're never quite able to complete your Sprint Backlog and even when you get close it never really feels like success? You're more of a feature factory than anything else. Well it's almost certainly because of this one thing. What is it? Let's find out! I've been using Scrum with teams and a variety of organisations for the past 20 years, God has it been that long! And when Scrum fatigue sets in it's almost always because the team are not using a Sprint and Product Goal or because they're using them in the wrong way. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/
The Product Owner is assigned to a team The Product Owner is responsible for the product delivery The Product Owner's sole job is to do backlog management The Product Owner is no Product Manager The Product Owner owns the Sprint Backlog and determines what the team does How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/
Are Items in the Sprint Backlog ALWAYS Smaller Than Items in the Product Backlog? Maybe... Maybe not... This question from the PSM 1 Exam facilitated by Scrum.Org certainly generated some interesting discussion in one of my Advanced Workshops! We concluded that it is all a matter of applying best techniques to how we prioritize! How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/
The Daily Scrum Defined - What does the Scrum Guide say about the daily Scrum? The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/
Heute geht es mal wieder um die Scrum Basics: das Sprint Backlog. Was einfach klingt, kann aber auch seine Tücken haben. Welche das sind, erkläre ich Dir in dieser Folge. ----- Neugierig, wie Du auf dem kürzesten Weg zum gefragten Scrum Master wirst? Als Scrum Master steht man vor der Herausforderung, immer zu wissen, was der nächste richtige Schritt für das eigene Team/Unternehmen ist, um möglichst schnell zu Ergebnissen zu kommen. Die Erwartungen an agiles Arbeiten sind hoch und oft fehlt die nötige Geduld. Wie Du trotzdem erfolgreich sein kannst, gebe ich gerne an Dich weiter. Dazu habe ich eine Fallstudie erstellt, die Du Dir hier anschauen kannst: https://marcloeffler.eu/fallstudie_start/ Viel Spaß dabei
In this episode, Eric Landes addresses the challenge of getting team members who are inclined to be quiet, reserved, or “introverted” to collaborate for the betterment of the team and the product. Check out our public Scrum training courses if you want to attend Scrum training. Key Takeaways: In the software development world, you may have noticed that many coders tend to be more introverted. If your Scrum team includes many of these personality types, your Scrum events might be quiet. The Scrum guide does not specifically have anything to say about personality types in the Developer accountability. However, it does say - "The specific skills needed by the Developers are often broad … Developers are always accountable for: Creating a plan for the Sprint, the Sprint Backlog; Instilling quality by adhering to a Definition of Done; Adapting their plan each day toward the Sprint Goal; and, Holding each other accountable as professionals." The fact that developers are accountable for the Sprint plan, and quality speaks to the need for good collaboration. Also, adapting the plan means teammates must speak up when something changes. I believe that good collaboration is needed in Scrum, so I recommend that Scrum masters help self-organizing teams ensure that all voices are heard. If you have an introverted team, here are some suggestions for helping team members' voices be heard. Use anonymous methods. For instance, have team members use whiteboards to place post-it notes on a board, then read through them. Virtually this could be using a Miro board for a retrospective. Give team members a fixed time to post their notes, then ask for feedback and explanations when needed. This helps voices be heard, even when they refuse to speak to their own notes. Another method is to have a one-on-one with all team members on a regular basis. Make sure to bring up any items mentioned in the one-on-one in an anonymous way at the appropriate Scrum event. How do you encourage team members to find their voice in collaboration? Related to this Episode: A complete list of the current Scrum Training by AgileThought. Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week, Brian Milner is joined by Julie Chickering to talk about the best practices and common pitfalls to avoid during the Daily Scrum event. Overview Brian Milner and Julie Chickering discuss the true purpose of the Daily Scrum and how to make this 15-minute meeting more efficient. According to the Scrum Guide, the Daily Scrum is to inspect progress towards the Sprint Goal, synchronize activities, and create a plan for the next 24 hours. Debunking the myth that “The Daily Scrum is a Status Meeting”, Julie and Brian share their first-hand experience of this misconception and show Scrum Masters how to transform the Daily Scrum into a purposeful and collaborative planning session led by the Developers, for the Developers. You’ll learn how to get your Daily Scrum under control and discover new approaches to encourage productivity, accountability and collective ownership as well as Daily Scrum formats that encourage teamwork. Finally, Brian and Julie dive deep into the struggles brought by remote working and the many alternatives to tackle this issue. Listen now to discover: - 02:00 - The purpose of the daily scrum and common misconceptions - 11:00 - How to use the sprint backlog to prioritize work - 00:12 - The importance of teamwork and striving for smaller stories that flow - 14:56 - How to encourage developers to take ownership of the Daily Scrum - 00:20 - Suggestions for Daily Scrum formats to encourage teamwork - 00:22 - When to update items on the Sprint Backlog to benefit the Daily Scrum meeting - 00:25 - How to encourage accountability and collective ownership of work - 00:27 - How to monitor and assess unplanned work and forecast velocity - 00:35 - Guidelines for problem identification and problem solving during the Daily Scrum - 00:38 - How to adapt the Daily Scrum for distributed teams in a remote world - 00:44 - The benefits of cross training - 00:45 - The 16th minute concept - 00:47 - Ken Schwaber’s clockwise scrum methodology Listen next time when we’ll be discussing... Julie joins Brian again to explain the true purpose of the Sprint Review and why it is a mistake to call this event a ‘demo’. References and resources mentioned in the show · Agile Project Management with Scrum by Ken Schwaber · The Scrum Guide Want to get involved? This show is designed for you, and we’d love your input. · Enjoyed what you heard today? It would be great if you left 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. Julie Chickering is a certified Scrum Trainer as well as a CST, PMP, PMI-ACP CSM, CSPO, and Path to CSP Educator. She believes that Agile practices are packed with potential — to enable business agility, and breakthrough results. Julie loves to help people implement agile even when the environments are messy, people are complicated, and situations are challenging. She brings real-world experience working with people at all levels to adopt and roll out realistic Agile strategies organization-wide.
This week, Brian Milner is joined by Julie Chickering to talk about the best practices and common pitfalls to avoid during the Daily Scrum event. Overview Brian Milner and Julie Chickering discuss the true purpose of the Daily Scrum and how to make this 15-minute meeting more efficient. According to the Scrum Guide, the Daily Scrum is to inspect progress towards the Sprint Goal, synchronize activities, and create a plan for the next 24 hours. Debunking the myth that “The Daily Scrum is a Status Meeting”, Julie and Brian share their first-hand experience of this misconception and show Scrum Masters how to transform the Daily Scrum into a purposeful and collaborative planning session led by the Developers, for the Developers. You’ll learn how to get your Daily Scrum under control and discover new approaches to encourage productivity, accountability and collective ownership as well as Daily Scrum formats that encourage teamwork. Finally, Brian and Julie dive deep into the struggles brought by remote working and the many alternatives to tackle this issue. Listen now to discover: - 02:00 - The purpose of the daily scrum and common misconceptions - 11:00 - How to use the sprint backlog to prioritize work - 00:12 - The importance of teamwork and striving for smaller stories that flow - 14:56 - How to encourage developers to take ownership of the Daily Scrum - 00:20 - Suggestions for Daily Scrum formats to encourage teamwork - 00:22 - When to update items on the Sprint Backlog to benefit the Daily Scrum meeting - 00:25 - How to encourage accountability and collective ownership of work - 00:27 - How to monitor and assess unplanned work and forecast velocity - 00:35 - Guidelines for problem identification and problem solving during the Daily Scrum - 00:38 - How to adapt the Daily Scrum for distributed teams in a remote world - 00:44 - The benefits of cross training - 00:45 - The 16th minute concept - 00:47 - Ken Schwaber’s clockwise scrum methodology Listen next time when we’ll be discussing... Julie joins Brian again to explain the true purpose of the Sprint Review and why it is a mistake to call this event a ‘demo’. References and resources mentioned in the show · Agile Project Management with Scrum by Ken Schwaber · The Scrum Guide Want to get involved? This show is designed for you, and we’d love your input. · Enjoyed what you heard today? It would be great if you left 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. Julie Chickering is a certified Scrum Trainer as well as a CST, PMP, PMI-ACP CSM, CSPO, and Path to CSP Educator. She believes that Agile practices are packed with potential — to enable business agility, and breakthrough results. Julie loves to help people implement agile even when the environments are messy, people are complicated, and situations are challenging. She brings real-world experience working with people at all levels to adopt and roll out realistic Agile strategies organization-wide.
This week, Brian Milner is joined by Julie Chickering to talk about the best practices and common pitfalls to avoid during the Daily Scrum event. Overview Brian Milner and Julie Chickering discuss the true purpose of the Daily Scrum and how to make this 15-minute meeting more efficient. According to the Scrum Guide, the Daily Scrum is to inspect progress towards the Sprint Goal, synchronize activities, and create a plan for the next 24 hours. Debunking the myth that “The Daily Scrum is a Status Meeting”, Julie and Brian share their first-hand experience of this misconception and show Scrum Masters how to transform the Daily Scrum into a purposeful and collaborative planning session led by the Developers, for the Developers. You’ll learn how to get your Daily Scrum under control and discover new approaches to encourage productivity, accountability and collective ownership as well as Daily Scrum formats that encourage teamwork. Finally, Brian and Julie dive deep into the struggles brought by remote working and the many alternatives to tackle this issue. Listen now to discover: - 02:00 - The purpose of the daily scrum and common misconceptions - 11:00 - How to use the sprint backlog to prioritize work - 00:12 - The importance of teamwork and striving for smaller stories that flow - 14:56 - How to encourage developers to take ownership of the Daily Scrum - 00:20 - Suggestions for Daily Scrum formats to encourage teamwork - 00:22 - When to update items on the Sprint Backlog to benefit the Daily Scrum meeting - 00:25 - How to encourage accountability and collective ownership of work - 00:27 - How to monitor and assess unplanned work and forecast velocity - 00:35 - Guidelines for problem identification and problem solving during the Daily Scrum - 00:38 - How to adapt the Daily Scrum for distributed teams in a remote world - 00:44 - The benefits of cross training - 00:45 - The 16th minute concept - 00:47 - Ken Schwaber’s clockwise scrum methodology Listen next time when we’ll be discussing... Julie joins Brian again to explain the true purpose of the Sprint Review and why it is a mistake to call this event a ‘demo’. References and resources mentioned in the show · Agile Project Management with Scrum by Ken Schwaber · The Scrum Guide Want to get involved? This show is designed for you, and we’d love your input. · Enjoyed what you heard today? It would be great if you left 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. Julie Chickering is a certified Scrum Trainer as well as a CST, PMP, PMI-ACP CSM, CSPO, and Path to CSP Educator. She believes that Agile practices are packed with potential — to enable business agility, and breakthrough results. Julie loves to help people implement agile even when the environments are messy, people are complicated, and situations are challenging. She brings real-world experience working with people at all levels to adopt and roll out realistic Agile strategies organization-wide.
Épisode 37 avec Jimmy "Le PO" Carroll À propos de Jimmy: Passionné par l'agilité depuis 2006, Jimmy challenge constamment sa réflexion en se plongeant dans les livres et en expérimentant avec ces équipes. Il a commencé sa carrière comme gestionnaire de projet et a rapidement évolué dans des rôles de Product Owner, de Scrum Master et de Coach Agile. Son expérience en coaching d'équipes et en gestion de produit lui a permis de développer des connaissances et compétences complémentaires qu'il applique présentement dans son quotidien de Product Owner dans une start-up mêlant intelligence artificielle et robotique https://www.linkedin.com/in/jimmycarroll/ 0:00 - Introduction 0:32 - Self-Selection 1:28 - Self-Selection de Jimmy 9:23 - Le Scrum Master 11:51 - La posture du Scrum Master 14:18 - Definition de projet traditionnel 16:21 - Jimmy comme PO 17:51 - Jimmy comme SM 19:05 - SM ou PO? 19:38 - Être PO et SM en même temps 21:38 - Réflexe du SM en tant que PO 24:42 - Conseils pour nouveaux PO 32:57 - WSJF 33:48 - MVP 35:29 - MTP 40:02 - Modèle INVEST 42:00 - Outils et pratiques 42:12 - Story Mapping 50:04 - Scrum 101 50:47 - PO et le Sprint Planning 55:04 - PO et le Daily Scrum 57:18 - PO et le raffinement de Backlog 1:06:39 - PO et la Sprint Review 1:23:29 - PO et la Retrospective 1:27:00 - Abnormal Termination of Sprint 1:30:52 - PO et le Sprint Backlog 1:33:25 - PO et le Product Backlog 1:40:06 - Ne plus dire Agile! 1:44:46 - Book Review en Vrac 1:46:00 - Dichotomy of Leadership 1:50:54 - Ego is the Enemy 1:54:18 - DevOps Handbook 1:56:24 - Conclusion Quelques liens: Self-Selection avec Stéphane Bourque https://www.youtube.com/watch?v=p1dfmtCrW44 https://www.liberatingstructures.com/1-1-2-4-all/ https://agilepartnership.com/fr/agile-coaching-%E2%80%93the-pickle-principle/ https://fr.wikipedia.org/wiki/Mod%C3%A8le_de_Kano https://www.jpattonassociates.com/story-mapping/ https://www.scrum.org/resources/scrum-guide ----------------------- Comme coachs agiles, nous sommes entourés de talents incroyables sur l'agilité et il est grand temps qu'on se dote d'un podcast et partager avec vous cette mine d'or de connaissances. Bonne écoute!
A Daily Scrum é um evento de 15 minutos que tem como objetivo inspecionar o progresso em direção a meta da Sprint e adaptar o Backlog conforme necessário, sempre ajustando as próximas demandas. Esse evento ajuda a diminuir a complexidade dos ambientes. E, por ser um evento mais focado nas demandas, muita gente tem a dúvida se o Scrum Master e o Product Owner precisam ou não participar das dailys diárias do time. Segundo o Scrum Guide, o SM e o PO, precisam participar do evento se eles estiverem trabalhando ativamente em alguns itens do Sprint Backlog, nesse caso eles participam como Developers. No episódio de hoje, Rodrigo Pinto, co-fundador da Agile School e Agile.Inc, contou se a participação desses dois papéis deve ou não ser obrigatória durante a Daily Scrum. Além disso, ele traz dicas de práticas e situações desses papéis mais ativos nos eventos do Scrum. Caso tenha alguma dúvida, você enviar uma mensagem para nós que respondemos: https://wa.me/551138846925 ou um e-mail para faleconosco@agileschool.com.br • Nosso site: http://agileschool.com.br • Blog: https://agileschool.com.br/category/a… • Ouça nosso Podcast: - Spotify: https://spoti.fi/31GeHfy - iTunes:https://apple.co/31OAxNO • LinkedIn:https://www.linkedin.com/company/agil… • Instagram: https://www.instagram.com/agile.school/ • Facebook: https://www.facebook.com/agileschoolbr/ #eventodailyscrum #papelproductowner #papelscrummaster
Many CSM and CSPO participants have recently asked, why is the sprint backlog even relevant? If we are trying to avoid time based estimation practices, how does this help us achieve our goals? Join V. Lee Henson as we discover the real value behind the Sprint Backlog and the Sprint Goal.
Applying Empiricism to the Sprint Backlog. Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Take a Professional Scrum with Kanban Course with Todd, Ryan, and Daniel Vacanti! https://www.eventbrite.com/e/professional-scrum-with-kanban-psk-online-certification-class-psk-i-tickets-167900832911 Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummaster See omnystudio.com/listener for privacy information.
How Does a PBI Relate to a Sprint Backlog Item? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummasterSee omnystudio.com/listener for privacy information.
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
Scrum Events The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Optimally, all events are held at the same time and place to reduce complexity. The Sprint Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints. During the Sprint: ● No changes are made that would endanger the Sprint Goal ● Quality does not decrease ● The Product Backlog is refined as needed ● Scope may be clarified and renegotiated with the Product Owner as more is learned Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint. Sprint Planning Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. Sprint Planning addresses the following topics: Topic One: Why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility in the current Sprint. Topic Two: What can be Done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. Selecting how much can be completed within a Sprint may be challenging. Topic Three: How will the chosen work get done? For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. Daily Scrum The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. Sprint Review The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. Sprint Retrospective The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. Aleph Technologies specializes in providing hands-on classroom-based and onsite IT certification training courses taught by expert instructors with practical industry experience. Classes span focuses on Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on Certified #SCRUM Master, #ScaledAgile #Certifications in Dallas and leadership roles in #Agile development. Since 2000, over 3000 course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/ev... https://www.aleph-technologies.com/co... https://www.aleph-technologies.com/tr... We guide you through your #Agile Transformation. Reap the benefits of --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
Scrum Artifacts Scrum's artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation. Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured: ● For the Product Backlog it is the Product Goal ● For the Sprint Backlog it is the Sprint Goal ● For the Increment it is the Definition of Done These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders. Product Backlog The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs. Commitment: Product Goal The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal. The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum. Commitment: Sprint Goal The Sprint Goal is the single objective for the Sprint. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. Increment An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. Work cannot be considered part of an Increment unless it meets the Definition of Done. Commitment: Definition of Done The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done. Aleph Technologies specializes in providing hands-on classroom-based and onsite IT certification training courses taught by expert instructors with practical industry experience. Classes span focuses on Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on Certified #SCRUM Master, #ScaledAgile #Certifications in Dallas and leadership roles in #Agile development. Since 2000, over 3000 course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/ev... https://www.aleph-technologies.com/co... https://www.aleph-technologies.com/tr... We guide you through your #Agile Transformation. Reap the benefits of Aleph Technologies' expertise applying #Agile methods --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
The #Sprint Goal is an objective set for the #Sprint that can be met through the implementation of Product Backlog. It provides guidance to the #Development Team on why it is building the Increment. It is created during the #Sprint Planning meeting. The #Sprint Goal gives the #Development Team some flexibility regarding the functionality implemented within the #Sprint. The selected Product Backlog items deliver one coherent function, which can be the #Sprint Goal. The #Sprint Goal can be any other coherence that causes the #Development Team to work together rather than on separate initiatives. As the #Development Team works, it keeps the #Sprint Goal in mind. In order to satisfy the #Sprint Goal, it implements functionality and technology. If the work turns out to be different than the #Development Team expected, they collaborate with the #Product #Owner to negotiate the scope of #Sprint Backlog within the #Sprint. In the next video, we'll be talking about the "Daily #Scrum" #Aleph Technologies is a premier IT #training and staffing group with state-of-the-art facilities based in Dallas, Texas. #Aleph Technologies specializes in providing hands-on classroom-based and onsite IT #certification #training courses taught by expert instructors with practical industry experience. Classes span focuses on #Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on #Certified #SCRUM #Master, Scaled #Agile #Certifications in Dallas and leadership roles in #Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/events https://www.aleph-technologies.com/courses https://www.aleph-technologies.com/trainers We guide you through your #Agile Transformation. Reap the benefits of #Aleph Technologies' expertise applying #Agile methods and solutions. We will be your guide and mentor through your business's #Agile transformation and align you with a trajectory of growth that maintains strategic priorities. The benefits of an #Agile transformation include dramatic improvements to delivery effectiveness, shortened time cycles, and heightened responsiveness to change. Work in tandem with #Aleph Technologies to develop a practical plan of action, #implement necessary changes, and move your company to new heights with a culture of learning, innovation, and growth throughout your organization. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance #productmanagement #psm #agilecoach #scaledagileframework #devops #scrumtraining #productmanager #itbusinessanalyst #businessanalyst #agileproblems #itbusinessowner #developmentteam #scrumteam #agileprocess #scrummasters #scrumdotorg #agil #certificacaoscrum #retrospectivas #teambuilding #agiledevelopment --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
The #Sprint Backlog is the set of Product Backlog items selected for the #Sprint, plus a plan for delivering the product Increment and realizing the #Sprint Goal. The #Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "#Done" Increment. The #Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the #Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. The #Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily #Scrum. The Development Team modifies the #Sprint Backlog throughout the #Sprint, and the #Sprint Backlog emerges during the #Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the #Sprint Goal. As new work is required, the Development Team adds it to the #Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its #Sprint Backlog during a #Sprint. The #Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the #Sprint, and it belongs solely to the Development Team. Monitoring #Sprint Progress At any point in time in a #Sprint, the total work remaining in the #Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily #Scrum to project the likelihood of achieving the #Sprint Goal. By tracking the remaining work throughout the #Sprint, the Development Team can manage its progress. Next time we'll be talking about the "Increment" #Aleph Technologies is a premier IT #training and staffing group with state-of-the-art facilities based in Dallas, Texas. #Aleph Technologies specializes in providing hands-on classroom-based and onsite IT #certification #training courses taught by expert instructors with practical industry experience. Classes span focuses on #Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on #Certified #SCRUM #Master, Scaled #Agile #Certifications in Dallas and leadership roles in #Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/events https://www.aleph-technologies.com/courses https://www.aleph-technologies.com/trainers We guide you through your #Agile Transformation. Reap the benefits of #Aleph Technologies' expertise applying #Agile methods and solutions. We will be your guide and mentor through your business's #Agile transformation and align you with a trajectory of growth that maintains strategic priorities. The benefits of an #Agile transformation include dramatic improvements to delivery effectiveness, shortened time cycles, and heightened responsiveness to change. Work in tandem with #Aleph Technologies to develop a practical plan of action, #implement necessary changes, and move your company to new heights with a culture of learning, innovation, and growth throughout your organization. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance #productmanagement #psm #agilecoach #scaledagileframework #devops #scrumtraining #productmanager #itbusinessanalyst #businessanalyst #agileproblems #itbusinessowner #developmentteam #scrumteam #agileprocess #scrummasters #scrumdotorg #agil #certificacaoscrum #retrospectivas #teambuilding #agiledevelopment --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
The Daily #Scrum is a 15-minute time-boxed event for the Development Team. The Daily #Scrum is held every day of the #Sprint. At it, the Development Team plans to work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily #Scrum and forecasting upcoming #Sprint work. The Daily #Scrum is held at the same time and place each day to reduce complexity. The Development Team uses the Daily #Scrum to inspect progress toward the #Sprint Goal and to inspect how progress is trending toward completing the work in the #Sprint Backlog. The Daily #Scrum optimizes the probability that the Development Team will meet the #Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the #Sprint Goal and create the anticipated Increment by the end of the #Sprint. The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the #Sprint Goal. Some Development Teams will use questions, some will be more discussion-based. Here is an example of what might be used: What did I do yesterday that helped the Development Team meet the #Sprint Goal? What will I do today to help the Development Team meet the #Sprint Goal? Do I see any impediment that prevents me or the Development Team from meeting the# Sprint Goal? The #Scrum #Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily #Scrum. The #Scrum #Master teaches the Development Team to keep the Daily #Scrum within the 15-minute time-box. The Daily #Scrum is an internal meeting for the Development Team. If others are present, the #Scrum #Master ensures that they do not disrupt the meeting. Daily #Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team's level of knowledge. This is a key to inspect and adapt meeting. In the next video, we'll be talking about the "#Sprint Review" #Aleph Technologies is a premier IT #training and staffing group with state-of-the-art facilities based in Dallas, Texas. #Aleph Technologies specializes in providing hands-on classroom-based and onsite IT #certification #training courses taught by expert instructors with practical industry experience. Classes span focuses on #Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on #Certified #SCRUM #Master, Scaled #Agile #Certifications in Dallas, and leadership roles in #Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/events https://www.aleph-technologies.com/courses https://www.aleph-technologies.com/trainers We guide you through your #Agile Transformation. Reap the benefits of #Aleph Technologies' expertise applying #Agile methods and solutions. We will be your guide and mentor through your business's #Agile transformation and align you with a trajectory of growth that maintains strategic priorities. The benefits of an #Agile transformation include dramatic improvements to delivery effectiveness, shortened time cycles, and heightened responsiveness to change. Work in tandem with #Aleph Technologies to develop a practical plan of action, #implement necessary changes, and move your company to new heights with a culture of learning, innovation, and growth throughout your organization. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance #productmanagement #psm #agilecoach #scaledagileframework #devops #scrumtraining #productmanager #itbusinessanalyst #businessanalyst #agileproblems #itbusinessowner #developmentteam #scrumteam --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
The Daily #Scrum is a 15-minute time-boxed event for the Development Team. The Daily #Scrum is held every day of the #Sprint. At it, the Development Team plans to work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily #Scrum and forecasting upcoming #Sprint work. The Daily #Scrum is held at the same time and place each day to reduce complexity. The Development Team uses the Daily #Scrum to inspect progress toward the #Sprint Goal and to inspect how progress is trending toward completing the work in the #Sprint Backlog. The Daily #Scrum optimizes the probability that the Development Team will meet the #Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the #Sprint Goal and create the anticipated Increment by the end of the #Sprint. What did I do yesterday that helped the Development Team meet the #Sprint Goal? What will I do today to help the Development Team meet the #Sprint Goal? Do I see any impediment that prevents me or the Development Team from meeting the# Sprint Goal? The Development Team or team members often meet immediately after the Daily #Scrum for detailed discussions, or to adapt, or replan, the rest of the #Sprint's work. The #Scrum #Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily #Scrum. The #Scrum #Master teaches the Development Team to keep the Daily #Scrum within the 15-minute time-box. The Daily #Scrum is an internal meeting for the Development Team. If others are present, the #Scrum #Master ensures that they do not disrupt the meeting. Daily #Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team's level of knowledge. This is a key to inspect and adapt meeting. In the next video, we'll be talking about the "#Sprint Review" #Aleph Technologies is a premier IT #training and staffing group with state-of-the-art facilities based in Dallas, Texas. #Aleph Technologies specializes in providing hands-on classroom-based and onsite IT #certification #training courses taught by expert instructors with practical industry experience. Classes span focuses on #Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on #Certified #SCRUM #Master, Scaled #Agile #Certifications in Dallas, and leadership roles in #Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/events https://www.aleph-technologies.com/courses https://www.aleph-technologies.com/trainers We guide you through your #Agile Transformation. Reap the benefits of #Aleph Technologies' expertise applying #Agile methods and solutions. We will be your guide and mentor through your business's #Agile transformation and align you with a trajectory of growth that maintains strategic priorities. The benefits of an #Agile transformation include dramatic improvements to delivery effectiveness, shortened time cycles, and heightened responsiveness to change. Work in tandem with #Aleph Technologies to develop a practical plan of action, #implement necessary changes, and move your company to new heights with a culture of learning, innovation, and growth throughout your organization. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance #productmanagement #psm #agilecoach #scaledagileframework #devops #scrumtraining #productmanager #itbusinessanalyst #businessanalyst #agileproblems #itbusinessowner #developmentteam #scrumteam #agileprocess #scrummasters #scrumdotorg #agil #certificacaoscrum #retrospectivas #teambuilding #agiledevelopment --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
The work to be performed in the #Sprint is planned at the #Sprint Planning. This plan is created by the collaborative work of the entire #Scrum Team. #Sprint Planning is time-boxed to a maximum of eight hours for a one-month #Sprint. For the shorter #Sprints, the event is usually shorter. The #Scrum #Master ensured that the event takes place and that attendants understand its purpose. The #Scrum #Master teaches the #Scrum Team to keep it within the time-box. #Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming #Sprint? How will the work need to deliver the Increment be achieved? What can be done in this #Sprint? The Development Team works to forecast the functionality that will be developed during the #Sprint. The #Product #Owner discusses the objective that #Sprint should achieve and the Product Backlog items that, if completed in the #Sprint, would achieve the #Sprint Goal. The entire #Scrum Team collaborates on understanding the work of the #Sprint. How will the chosen work get done? Having set the #Sprint Goal and selected the Product Backlog items for the #Sprint, the Development Team decides how it will build this functionality into a "Done" product Increment during the #Sprint. The Product Backlog items selected for this #Sprint plus the plan for delivering them is called the #Sprint Backlog. The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product #Increment. Work may be of varying size or estimated effort. However, enough work is planned during #Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming #Sprint. Work planned for the first days of the #Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the #Sprint Backlog, both during #Sprint Planning and as needed throughout the Sprint. By the end of the #Sprint Planning, the Development Team should be able to explain to the #Product #Owner and #Scrum #Master how it intends to work as a self-organizing team to accomplish the #Sprint Goal and create the anticipated #Increment. In the next video, we'll be talking about "The #Sprint Goal" #Aleph Technologies is a premier IT #training and staffing group with state-of-the-art facilities based in Dallas, Texas. #Aleph Technologies specializes in providing hands-on classroom-based and onsite IT #certification #training courses taught by expert instructors with practical industry experience. Classes span focuses on #Business Analysis, Health Insurance & Systems Domain, IT Project Management, and IT Services with emphasis on #Certified #SCRUM #Master, Scaled #Agile #Certifications in Dallas and leadership roles in #Agile development. Since 2000, over 3000-course participants from more than 100 organizations across the globe have enhanced their skills through intensive, applicable exercises and education. https://www.aleph-technologies.com/ https://www.aleph-technologies.com/events https://www.aleph-technologies.com/courses https://www.aleph-technologies.com/trainers We guide you through your #Agile Transformation. Reap the benefits of #Aleph Technologies' expertise applying #Agile methods and solutions. We will be your guide and mentor through your business's #Agile transformation and align you with a trajectory of growth that maintains strategic priorities. The benefits of an #Agile transformation include dramatic improvements to delivery effectiveness, shortened time cycles, and heightened responsiveness to change. Work in tandem with #Aleph Technologies to develop a practical plan of action, #implement necessary changes, and move your company to new heights with a culture of learning, innovation, and growth throughout your organization. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
The Scrum Team achieved their Sprint Goal early. The Sprint Backlog is clear. Now what? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummasterSee omnystudio.com/listener for privacy information.
This week is a doubleheader (baseball term for two games played by the same teams on the same day against each other). We begin our re-read of Monotasking by Staffan Nöteberg and we have my interview with Staffan. Several years ago I read Staffan's book on Pomodoro which changed how I work. Monotasking might be even more useful and impactful. We discussed how to apply the ideas in the book to improve focus, productivity, and quality of life. Staffan Nöteberg is an enterprise agility coach with years of experience in improving personal productivity. He is also the author of Pomodoro Technique Illustrated (2009) and teaches seminars on monotasking to companies in North America, Europe, and East Asia. Twitter: https://twitter.com/staffannoteberg Website: https://monotasking.staffannoteberg.com/ Re-Read Saturday News We start our re-read of Monotasking by Staffan Nöteberg. The book is 237 pages published by Racehorse Publishing (an imprint of Simon & Schuster) and was released in English on June 1, 2021. For most of the readers of the blog and listeners to the podcast, this will be an initial read. The book's contents include a Preface, Introduction, 7 numbered chapters, an Afterword, and then other stuff like index and more (we will not cover the other stuff but I am glad for the index and endnotes). Now the fun part. Instead of a straight re-read and discussion. I am going to read a chapter, highlight the parts I am going to implement in the next week, tell you what I am going to do, and then the following week admit how well I performed. Week 1 - Logistics, Game Plan, and Preface - https://bit.ly/3x1oVap As a reminder, all of the entries from Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller are available! Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Week 11: Sprint Backlog - https://bit.ly/3njezit Week 12 - Reclaiming The Daily Scrum - https://bit.ly/3eNzMgz Week 13: Deconstructing the Done Product Increment - https://bit.ly/3bedTGc Week 14: The Sprint Review - https://bit.ly/3huZvgP Week 15: The Retrospective - https://bit.ly/3bOK2Vg Week 16 - Final Thoughts - https://bit.ly/3p3tbU0v Upcoming Events! ISMA 18 Virtual Conference, June 24th, 2021 8 AM EDT to 11:15 EDT I will host the event. The event will have a host of great speakers on great topics! ISMA 18 will be free for both IFPUG members and non-members. IFPUG members are eligible for 1 credit at the CFPS Extension Program (CEP) and also attract 3 Technical PDUs in the PMI Talent Triangle®, both by attending the full conference! Register: https://www.ifpug.org/isma18/ Real Value of TMMi (SPaMCAST is a Friend of TMMi America) Free webinar from TMMi America featuring Mark Summers June 25th, 2 to 3 PM EDT This webinar will explore the common usages of the TMMi Test Process Improvement framework. We will dive into how: You can leverage this framework to transform the way your organization delivers software. The model can transform your career. Next steps to take on your journey to becoming a Test Process Improvement superhero. The real value of the TMMi is to help you dramatically change the frequency and quality of your software delivery. Register at https://bit.ly/2RtoGpy Next SPaMCAST In the next Software Process and Measurement Cast, we talk with Ajit Ghuman, Head of Product Marketing at Narvar. Ajit and I talk pricing, marketing, product engagement/ownership, and development. Is there an ideal pattern for product and development to work together? If not, what are the consequences?
Follow our Youtube Channel: https://www.youtube.com/c/ProjectManagementKnowledge In this video, we aimed to inform our audience about the project team members. This is our first video. We will continue to publish similar videos in the coming days. We mentioned some terms like Work Breakdown Structure, RACI Matrix, Product Backlog and Sprint Backlog. These terms will be explained in the following videos. Please do not forget to subscribe to our channel and like our videos. Hope to see you in the next video. We offer course related to the following subjects. Contact us via email if you questions about the courses we offer: can.izgi@gmail.com or gokremtekir@gmail.com * Project Management * Project Management Certification Exam Preparation * Agile Project Management If you'd like support us please visit: www.patreon.com/projectmanagement
Work Entry: An Introduction, focuses on what work entry is and why it is the single most important part of determining whether a team is dependable, predictable, and even remotely agile. We will also have a visit from Jon M Quigley and his Alpha and Omega of Product Development. Jon and I discuss, wrestle, and chew on how the idea of a product backlog can exist in a project environment. Re-Read Saturday News We have read or re-read Fixing Your Scrum: Practical Solutions to Common Scrum Problems by Todd Miller and Ryan Ripley cover-to-cover if you don’t count the index at the back of the book (and I certainly do not). As a wrap-up, I briefly consider three points that came to mind during the re-read. If you have not bought your copy -- what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems Next week we will start our re-read of Monotasking by Staffan Noteberg by laying out an approach. I am contemplating combining the re-read with experience reports as I try to put the ideas in the book to use. More on that next week. This Week’s Installment Week 16 - Final Thoughts - https://bit.ly/3p3tbU0v Previous Installments Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Week 11: Sprint Backlog - https://bit.ly/3njezit Week 12 - Reclaiming The Daily Scrum - https://bit.ly/3eNzMgz Week 13: Deconstructing the Done Product Increment - https://bit.ly/3bedTGc Week 14: The Sprint Review - https://bit.ly/3huZvgP Week 15: The Retrospective - https://bit.ly/3bOK2Vg Next SPaMCAST Speaking of Monotasking by Staffan Noteberg, in the next podcast, we will feature the interview I did with Staffan covering the book that we are about to re-read. We discussed how to apply the ideas in the book to improve focus, productivity, and quality of life.
Intellectual property protection impacts almost everyone whether they are aware of it or not. Trademarks, copyrights, patents, and trade secrets are all part of a wide-ranging discussion of IP protection in the software environment. Rick provides great insight into a rapidly evolving field. Rick Martin is the owner and founder of Martin IP Law Group which is based in Evansville, Indiana but serves clients throughout the United States. He is a graduate of the Purdue University School of Industrial Engineering and the Catholic University of America, Columbus School of Law. Prior to beginning his career as an Intellectual Property Attorney, Rick worked as a patent examiner at the U.S. Patent & Trademark Office. Rick has obtained hundreds of patents for inventors in a variety of fields, including timing systems, mine safety devices, broadband antennas, RFID, electronics, ranging, oil & gas, semiconductors, and other mechanical and electro-mechanical devices. For over 25 years, he has been helping entrepreneurs and businesses protect their ideas, inventions, and identities through patents, trademarks, copyrights, trade secrets, and related contracts, licenses, and agreements. Email: rick@ipsolutionslaw.com Website: https://ipsolutionslaw.com/ LinkedIn: linkedin.com/in/rickmartinlaw Re-Read Saturday News Chapter 15 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, covers the retrospective. The retrospective, I think, is the most important part of Scrum. Helping it to work well is important. Next week we will conclude our re-read with a few closing remarks. Make sure I have your input on what to re-read next by voting in the poll that can be found in the show notes. Don’t like polls? Email me your choice at tcagley@tomcagley.com. If you have noT bought your copy of Fixing Your Scrum: Practical Solutions to Common Scrum Problems -- what are you waiting for? This Week’s Installment Week 15: The Retrospective - https://bit.ly/3bOK2Vg Previous Installments Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Week 11: Sprint Backlog - https://bit.ly/3njezit Week 12 - Reclaiming The Daily Scrum - https://bit.ly/3eNzMgz Week 13: Deconstructing the Done Product Increment - https://bit.ly/3bedTGc Week 14: The Sprint Review - https://bit.ly/3huZvgP Next SPaMCAST The next Software Process and Measurement Cast will feature a longer essay titled, Work Entry: An Introduction. This essay brings together a number of concepts to focus on what work entry is and why it is the single most important part of determining whether a team is dependable and predictable. We will also have a visit from Jon M Quigley and his Alpha and Omega of Product Development.
This week Dr. Eric Cole and I talk cybersecurity and entrepreneurship. Most of you will have been on the edge of your seat while you tracked the news of the ransomware attack on the Colonial Pipeline. Security can not be an afterthought. Remember this is not a drill; this not hype. Also, preorder Dr. Cole’s new book Cyber Crisis which will be released on June 1st. Dr. Cole is a world-renowned cybersecurity entrepreneur and founder of Secure Anchor Consulting, Eric understands the dangers of cybersecurity and knows how to build successful companies. Today, Dr. Cole shares the many lessons learned from overcoming adversity and staying committed to your purpose. Dr. Cole focuses on security and innovation with a mission to make cyberspace safe in a world where it can be an unrecognized danger and threat. Website: https://secure-anchor.com/ LinkedIn: https://www.linkedin.com/in/ericcole1/ The Software Process and Measurement Cast is a proud media sponsor of the Global Scrum Master Summit which starts tomorrow! The First Global Scrum Master Summit Week of May 17th, 2021, Live and Recorded Organized by the Scrum Master Toolbox Podcast http://bit.ly/scrummastersummit21 Re-Read Saturday News Chapter 14 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, shines its spotlight on the Sprint Review. This event is geared to generating feedback to help the team and organization deliver value. We are getting close to the end of the book and I would like your input on what to tackle next. There is a poll in the show notes to collect your ideas! If you have not bought your copy -- what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems This Week’s Installment Week 14: The Sprint Review - https://bit.ly/3huZvgP Previous Installments Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Week 11: Sprint Backlog - https://bit.ly/3njezit Week 12 - Reclaiming The Daily Scrum - https://bit.ly/3eNzMgz Week 13: Deconstructing the Done Product Increment - https://bit.ly/3bedTGc Next SPaMCAST In the next Software Process and Measurement Cast, I talk with Rick Martin about intellectual property, and why everyone involved in software needs to understand how IP law can impact the value they deliver. Copyrights, patents, trademarks, and trade secrets are all part of protecting intellectual property.
ALEPH - GLOBAL SCRUM TEAM - Agile Coaching. Agile Training and Digital Marketing Certifications
In diesem Video werden wir die #Scrum-Terminologie diskutieren, wie sie in das #SAFe-Framework passt Tägliches #Scrum: #Scrum Event ist ein 15-minütiges Time-Boxed-Event, das jeden Tag für die Entwickler abgehalten wird. Das Daily Scrum findet jeden Tag im Sprint statt. Die Entwickler planen, für die nächsten 24 Stunden zu arbeiten. Dies optimiert die Zusammenarbeit und Leistung des Teams, indem die Arbeit seit dem letzten Daily Scrum überprüft und die bevorstehende Sprint-Arbeit prognostiziert wird. Das Daily Scrum findet jeden Tag zur gleichen Zeit und am gleichen Ort statt, um die Komplexität zu verringern. In #SAFe nennen wir es Daily Stand-up, auch bekannt als DSU Daily Stand-up ist eine 15-minütige Zeitbox-Veranstaltung, die jeden Tag für die Entwickler stattfindet. Der tägliche Standup findet jeden Tag der Iteration statt. Die Entwickler planen, für die nächsten 24 Stunden zu arbeiten. Dies optimiert die Zusammenarbeit und Leistung des Teams, indem die Arbeit seit dem letzten täglichen Stand-up überprüft und bevorstehende Iterationsarbeiten prognostiziert werden. Der tägliche Stand-up findet jeden Tag zur gleichen Zeit und am gleichen Ort statt, um die Komplexität zu verringern. Sprintplanung Sprint-Planung: #Scrum-Ereignis, das auf 8 Stunden oder weniger festgelegt ist, um einen Sprint zu starten. Es dient dem #Scrum-Team, die Arbeit aus dem Product Backlog zu überprüfen, das als nächstes am wertvollsten ist, und diese Arbeit in das Sprint-Backlog zu entwerfen. In #SAFe nennen wir dies Iterationsplanung Iterationsplanung Iterationsplanung ist eine Veranstaltung, bei der alle Teammitglieder bestimmen, wie viel Team-Backlog sie während einer bevorstehenden Iteration bereitstellen können. Das Team fasst die Arbeit als eine Reihe von festgelegten Iterationszielen zusammen. Sprint Review #Scrum-Ereignis, das auf einen Zeitrahmen von 4 Stunden oder weniger festgelegt ist, um die Entwicklungsarbeit eines Sprints abzuschließen. Es dient dem Scrum-Team und den Stakeholdern, die aus dem Sprint resultierenden Produktinkremente zu untersuchen, die Auswirkungen der durchgeführten Arbeiten auf den Gesamtfortschritt in Richtung des Produktziels zu bewerten und den Produktbestand zu aktualisieren, um den Wert des nächsten Zeitraums zu maximieren. IN #SAFe nennen wir es "The Iteration Review" Die Iterationsüberprüfung ist ein kadenzbasiertes Ereignis, bei dem jedes Team das Inkrement am Ende jeder Iteration überprüft, um den Fortschritt zu bewerten, und dann seinen Rückstand für die nächste Iteration anpasst. Sprint Retrospektive Sprint-Retrospektive: #Scrum-Ereignis, das auf eine Zeitspanne von 3 Stunden oder weniger festgelegt ist, um einen Sprint zu beenden. Es dient dem Scrum-Team, den vergangenen Sprint zu inspizieren und Verbesserungen für den nächsten Sprint zu planen. In #SAFe nennen wir es "Iteration Retrospective" Iterations-Retrospektive Die Iterations-Retrospektive ist eine regelmäßige Veranstaltung, bei der Mitglieder des agilen Teams die Ergebnisse der Iteration diskutieren, ihre Praktiken überprüfen und Verbesserungsmöglichkeiten ermitteln In #SAFe nennen wir es das Iterationsziel Iterationsziele sind eine allgemeine Zusammenfassung der geschäftlichen und technischen Ziele, die das Agile Team in einer Iteration erreichen möchte. Sie sind entscheidend für die Koordination eines Agile Release Train (ART) als selbstorganisierendes, selbstverwaltendes Team. Zusätzlich hat #SAFe auch Program Increment (PI) Programminkrement (PI) Ein Programminkrement (PI) ist eine Zeitbox, in der ein Agile Release Train (ART) einen inkrementellen Wert in Form von funktionierender, getesteter Software und Systemen liefert. PIs dauern normalerweise 8 bis 12 Wochen. Das häufigste Muster für einen PI sind vier Entwicklungsiterationen, gefolgt von einer Iteration für Innovation und Planung (IP). Das #Scrum-Team #Scrum-Team: Ein selbstverwaltendes Team, das aus einem Scrum-Master, einem Product --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message
Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. This week we talk about five common patterns. On Tuesday I will include the PDF in the feed to see if I can spur a discussion about other patterns. We also have a visit from Tony Timbol with his To Tell A Story column. In this installment we discuss different forms of user stories and when to use them. The Software Process and Measurement Cast is a proud media sponsor of the Global Scrum Master Summit. The First Global Scrum Master Summit Week of May 17th, 2021, Live and Recorded Organized by the Scrum Master Toolbox Podcast http://bit.ly/scrummastersummit21 Re-Read Saturday News Chapter 13 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, discusses the concept of a deployable product increment and done. What we deliver is a big deal, getting it right is the difference between satisfaction and all sorts of stress. We are getting close to the end of the book and I would like your input on what to tackle next. If you have not bought your copy -- what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems This Week’s Installment Week 13: Deconstructing the Done Product Increment - https://bit.ly/3bedTGc Previous Installments Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Week 11: Sprint Backlog - https://bit.ly/3njezit Week 12 - Reclaiming The Daily Scrum - https://bit.ly/3eNzMgz Next SPaMCAST In the next Software Process and Measurement Cast, we talk to Dr. Eric Cole. We talk cybersecurity and entrepreneurship. If you did not understand the potential impact of security, just find any major newspaper for Sunday, May 9th, and read about the ransomware attack on the Colonial Pipeline. This not a drill, this not hype.
Experimentation is a dirty word in many organizations, however, it can be a powerful tool to drive and guide change. Tammy Gretz shares how she adopted experiments in her practice and how she uses them to change the behavior and culture of people and organizations. I am occasionally asked why I enjoy meet-ups so much. Meeting people like Tammy is a major part of the reason. Thanks to the Women in Agile, Cleveland for the great introduction which lead to this interview! Tammy’s bio: Tammy is an “Agile Coach Making Shift Happen” “I exist to generously collaborate, embrace tension and use it to make shift happen.” I have been influencing change through servant leadership, elbow grease, and lattes for over 20 years. I am a massive maker and the majority of my education comes from experimenting and the relentless pursuit of understanding team dynamics, embracing tension, and using it to fuel innovation and change in the workplace and beyond. https://tammygretz.com/ linkedin.com/in/tammygretz tsgretz@gmail.com The Software Process and Measurement Cast is a proud media sponsor of the Global Scrum Master Summit. The First Global Scrum Master Summit Week of May 17th, 2021, Live and Recorded Organized by the Scrum Master Toolbox Podcast http://bit.ly/scrummastersummit21 Re-Read Saturday News Chapter 12 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, talks about the daily scrum. The daily “meeting” might be a ubiquitous feature of corporate life but it can be better! If you have not bought your copy -- what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems This Week’s Installment Week 12 - Reclaiming The Daily Scrum - https://bit.ly/3eNzMgz Previous Installments Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Week 11: Sprint Backlog - https://bit.ly/3njezit Next SPaMCAST In the next SPaMCAST, we will chew on work entry patterns. There are 5 basic patterns which are you? Why is one better than another (some are downright not useful for agile). We will also have a visit from Tony Timbol bringing the story on user stories to the Software Process and Measurement Cast listeners
Das Sprint Planning ist für Product Owner ein wichtiges Event in Scrum. Dennoch passieren oft zahlreiche Fehler im Hinblick auf Selbstorganisation und Product Ownership des ganzen Teams. Zudem fühlt das Planning sich für viele Product Owner auch häufig eher merkwürdig an. Oliver und Dominique berichten von ihren eigenen Erfahrungen und welche Fehler ihnen selbst im Sprint Planning schon unterlaufen sind. Im Gespräch beleuchten die beiden das Event aus Sicht des Product Owners. Dabei geht es sowohl um die Zweck, den das Planning für den Product Owner erfüllen soll, welche Vorbereitungen man treffen sollte und letztlich wie ich ein gutes Sprint Planning als Product Owner gestalte. Die Ergebnisse aus dem Sprint Planning haben einen großen Einfluss auf den Erfolg eines Sprints. Daher ist es so wichtig, die drei grundsätzlichen Fragestellungen gut zu bearbeiten: Warum, Was und Wie? Warum? Als Product Owner solltest Du einen Vorschlag machen, warum es Sinn macht, in den nächsten Sprint zu investieren und damit dem Team auch die Relevanz erklären können. Den Kontext für das kommende Sprintziel geben dabei Produktvision, Roadmap und Product Goal. Was? In diesem Schritt erfolgt die Auswahl der Product Backlog Elemente und ihre Übernahme in das Sprint Backlog durch bzw. gemeinsam mit den Developern. Dabei sollte der Fokus darauf liegen, was zur Erfüllung des Sprintziels notwendig ist und nicht ob die Auslastung aller Teammitglieder sichergestellt ist. Schließlich wollen wir primär den Wert des Produkts maximieren und nicht die Auslastung optimieren. Wie? Während die Developer in diesem Schritt planen, wie sie während der Iteration vorgehen wollen, um das Sprint Goal zu erreichen, nimmt der Product Owner eine passive Rolle ein und steht mindestens für weitere Rückfragen und Entscheidungen zur Verfügung. Stolperfalle: hier geht es ums Planen, wie das Team das "Wie" angeht - noch nicht um die (technische) Konzeption und Lösungsfindung an sich! Als Ergebnis vom Sprint Planning haben wir ein vollständiges Sprint Backlog. Dies umfasst das Sprintziel, die ausgewählten Items und den gemeinsam erstellten Plan für Umsetzung.
Alex Omeyer and I discussed defining, tracking, and measuring technical debt. Technical debt generates a liability that every organization must deal with. As Alex states, “tech debt might not be the sexiest topic” but if teams and organizations don’t address their liabilities it will be difficult to deliver the value customers need and expect. We also talk about the practicalities of pivoting life ambitions and entrepreneurship. Alex is the Co-founder and CEO of Stepsize. Alex personally spends most of his time speaking to the best software development teams in the world about how they handle technical debt. Hit him up to talk tech debt. He loves to share what they taught him. Alex and his co-founders are building Stepsize—a free tool for engineering teams to track and prioritize technical debt. Stepsize’s mission is to make software development more accessible, efficient, and powerful. Website: https://www.stepsize.com/ LinkedIn: https://www.linkedin.com/in/alexandre-omeyer-060a0175/ Twitter @AlexOmeyer The Software Process and Measurement Cast is a proud media sponsor of the Global Scrum Master Summit. The First Global Scrum Master Summit Week of May 17th, 2021, Live and Recorded Organized by the Scrum Master Toolbox Podcast http://bit.ly/scrummastersummit21 The Software Process and Measurement Cast is a proud media sponsor of the DevOps Online Summit. Last call! The DevOps Online Summit is nearly here! During the week of April 26th – 30th Tom Henricksen and crew will deliver the third summit. The goal is to bring together 5000 DevOps professionals. Grab a ticket! Re-Read Saturday News Chapter 11 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, talks about the sprint backlog. The sprint backlog is the work teams do on a day-to-day basis. If you have not bought your copy -- what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems This Week’s Installment Week 11: Sprint Backlog - https://bit.ly/3njezit Previous Installments Week 1: Re-read Logistics and Front Matter - https://bit.ly/3mgz9P6 Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad - https://bit.ly/37w4Dv9 Week 3: Breaking Bad Scrum with a Value-Driven Approach - http://bit.ly/3stGc9Q Week 4: The Product Owner - https://bit.ly/3qpKvSn Week 5: The Product Backlog - http://bit.ly/3cAEk9c Week 6: The Development Team - http://bit.ly/2OLVAAs Week 7: Embracing The Scrum Master Role - https://bit.ly/3m0HB5D Week 8: Management - https://bit.ly/31Kv39l Week 9: Thinking In Sprints - https://bit.ly/321wXTg Week 10: Sprint Planning - https://bit.ly/3stWOhx Next SPaMCAST In the next SPaMCAST, we talk to Tammy Gretz. Experimentation is a dirty word in many organizations. Tammy explains how she uses powerful experiments to change the behavior and culture of people and organizations. Thanks to the Women in Agile, Cleveland for the great introduction!
This week on the Agile Coaches’ Corner Dan and Sam are switching things up with a new episode format. In this episode, they’re looking back on Sam’s three-part Trainer Talk series on the key changes that were made in the new Scrum Guide that was released in November 2020. This episode compiles all three of Sam’s Trainer Talks that focus on the three key changes that were made to the Scrum Guide around the product goal, the sprint goal, and self-organizing teams. Sam shares his thoughts on why these changes are important to recognize; what these changes mean for organizations, Scrum Teams, and Product Owners; and the specific benefits that come with these changes. Tune in to learn all about the three key changes that organizations using Scrum need to pay close attention to! Key Takeaways How has the Product Goal Changed with the New Scrum Guide? Why is it important and what are the benefits? What the Scrum Guide has to say about the Product Goal: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define ‘what’ will fulfill the Product Goal” The Scrum Guide is now making the Product Goal an explicit part of Scrum (which is crucial in creating a unified vision for the team to work toward) This change highlights the difference between a Product Goal and a Product Vision which is important because a product vision is lacking the characteristics of SMART goals (“specific, measurable, achievable, relevant, and time-bound” goals) With the Product Goal in the Product Backlog, the rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal (this has specific benefits such as creating transparency, understanding what the value is that is expected to be created so that the team can validate if their efforts are creating the desired outcome, and in helping the team understand what should be in the Product Backlog vs. what should be out of it) With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, it is possible to validate PBIs against the Product Goal The Scrum Guide also says that “The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next” (which is hugely beneficial as it will help teams focus) With a Product Goal and the expectation that the Product Backlog, by and large, contains items that emerge as a result of that Product Goal, it is possible to make much more meaningful Sprint Goals The Product Goal helps the Product Owner move beyond being a mere order taker and, instead, create a stance where they are initiating requirements How has the Sprint Goal Changed with the New Scrum Guide? Why is it important and what are the benefits? The new Scrum Guide underscores the commitment and purpose of a Sprint Goal Jeff and Ken introduce a new topic for Sprint Planning in this update, which is: “Why is this Sprint valuable?” (In other words, “What do we hope to get out of it?”) — Asking this question helps craft the Sprint Goal Establishing a Sprint Goal allows the team to create a well-rounded SMART (“specific, measurable, achievable, relevant, and time-bound”) goal If you don’t have a Sprint Goal, the Sprint Backlog becomes just a list of Product Backlog Items to fill up a team’s capacity with no coherence to it With a Sprint Goal, the team is able to create a coherent Sprint backlog that will help them meet their goals and objectives Though there might be things in your Sprint Backlog that are not strongly correlated to the Sprint Goal, doing what is necessary to achieve the Sprint Goal needs to be the priority (If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a Sprint Goal themselves) Once a Sprint Goal is established and it has helped the team select a coherent group of Product Backlog Items for their Sprint Backlog, the Sprint Goal then helps address the topic of: “How are we going to do it?” Good Sprint planning includes creating a plan for working together and breaking things down into the tasks that the team needs to achieve Without a Sprint Plan, there is a lack of transparency and the Scrum Team cannot see at their Daily Scrums whether or not they are making good progress towards the Sprint Goal The Sprint Goal creates transparency and the ability for a Scrum Team to deliver reliably and predictably each and every Sprint (additionally, it helps establish a sustainable pace, which creates better morale and a more fulfilling work environment) How has Self-Organizing Changed to Self-Managing in the New Scrum Guide? Why is it important and what are the benefits? Even though the change may seem merely semantic, it has a massive impact on how organizations will see Scrum in a new light and will be a shock to those organizations that have not allowed their teams to be self-organizing or self-managing at all When organizations use Scrum but do not allow their teams to be self-managing this leads to a lack of engagement and a lack of ownership; it destroys morale and causes turnover In Daniel H. Pink’s book, Drive, he discovered the three factors that truly motivate knowledge workers are autonomy, mastery, and purpose (and self-managing teams leverage all three of these things [and Scrum done well has all three built-in!]) Scrum gives team autonomy by allowing them to decide what to work on and in setting their own Sprint Goal “Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that ‘This is my area and I don’t have to do anything else.’ We all expand our knowledge together and work together.” — Sam Falco Self-managing teams create less overhead for managers as they don’t have to spend time directing people and telling them what to do “Self-managing is serendipity in development” (when you hand someone a problem, get out of their way, and they will solve it in ways that you never could have imagined [and maybe even better than if you had solved it yourself!]) In complex product development, something new is always going to come up and there is an enormous amount of uncertainty — Scrum allows self-managing teams to adapt to this uncertainty as it arises and every Sprint offers an opportunity to change direction You can work towards self-managing teams by empowering your Product Owners to make decisions and shepherd their products; feeding your teams with objectives, not tasks; setting the boundaries within which your teams can make their own decisions and steer their own course; encouraging the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes Mentioned in this Episode: The Scrum Guide Agile Coaches’ Corner: Trainer Talk: “How Has the Product Goal Changed with the New Scrum Guide?” Agile Coaches’ Corner: Trainer Talk: “How Has the Sprint Goal Changed with the New Scrum Guide?” Agile Coaches’ Corner: Trainer Talk: “How Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?” Agile Coaches’ Corner Ep. 106: “What’s New with Scrum?” Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
Today's question is does a Scrum Team handle unexpected work that interrupts the creation of features and value? Todd and Ryan break down the tactics they've used to address this issue and how a focus on technical debt and technical excellence is essential. How do you handle unexpected work? Let us know in the comments! This is one of those Scrum Master interview questions that can throw you off. Do you understand the impact of unplanned work? These Scrum Master day in the life questions can be tricky. Perhaps Scrum Master training could help? Want to learn more about Scrum? Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #professional scrumSee omnystudio.com/listener for privacy information.
A recent student asked Ryan and Todd to talk about the differences between a Sprint Backlog and a Product Backlog. It's an interesting question as these are two Scrum Artifacts that teams use to keep information transparent. The Sprint Backlog is a representation of present work while the Product Backlog represents future work. Check out the video to learn even more ways the Sprint Backlog and Product Backlog are different. // Want to learn more about Scrum? Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3b96j0A // Join Ryan and Todd in a Professional Scrum Master course: Visit https://agileforhumans.com/ for a list of upcoming courses. And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide I may receive a small commission. There is no additional charge to you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.See omnystudio.com/listener for privacy information.
Today's question is from a viewer who wants to know if every Sprint Backlog Item relates to the Sprint Goal commitment? Watch as Todd and Ryan break down how to use the Sprint Backlog and Sprint Goal to help guide development decisions, manage progress, and keep the Scrum team focused on delivering an increment by the end of the Sprint. Want to learn more about Scrum? Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #professional scrumSee omnystudio.com/listener for privacy information.
A YouTube viewer (Kaleb) asked whether or not the Sprint Backlog could change during a Sprint. Todd and Ryan discuss how a Sprint Backlog is emergent and how the Developers are encouraged to update the Sprint Backlog as new things are learned about their Product. Check out the video for more tips on how to manage complexity during your product development efforts. Want to learn more about Scrum? Check out Ryan and Todd's book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3b96j0A Want to Join Ryan and Todd in a Professional Scrum Master course? Visit https://agileforhumans.com/ for a list of upcoming courses.See omnystudio.com/listener for privacy information.
Episodul 10 vizează artefactele folosite de o echipă Scrum: Product & Sprint Backlog, Definition of Ready, Definition of Done, Task Board și Burndown Chart Youtbe: https://www.youtube.com/watch?v=epXcAklPX24 (Gestionarea Proiectelor Software | S1E10 | Metodologia Scrum - Artefacte)
A three minute talk on Working in Agile - Tracking Progress through The Sprint Backlog. w: 2andh.com
A five minute talk on Working in Agile - Planning Releases and Sprints - Sprint Planning - The Sprint Planning Meeting - Part Two - Creating Tasks in the Sprint Backlog. w: 2andh.com
A two minute talk on Working in Agile - Planning Releases and Sprints - Sprint Planning - The Sprint Backlog. w: 2andh.com
Scrum Institute, Scrum Framework Episode #13 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 A Sprint Planning Meeting? This Might Surprise You! During the Sprint Planning Meeting, the Scrum Team builds a viable Sprint Backlog, which determines the user stories and tasks the team is going to implement until the end of this Sprint (Product Increment). A Sprint Planning Meeting constitutes two parts, namely the WHAT-Meeting, and the HOW-Meeting. As those names imply, the WHAT-Meeting focuses on the scope of a Sprint, whereas the HOW-Meeting focuses on how this scope will be implemented. During Sprint Planning Meetings, the presence of the Scrum Product Owner is mandatory. So she can answer questions from the Scrum Team and bring clarifications for the requirements and their acceptance criteria. Stakeholders such as end-users or line managers can join Sprint Planning Meetings as view-only audiences. They’re not allowed to influence the flow of the Sprint Planning Meeting. The Sprint Goal The Scrum Product Owner defines the Sprint Goal. It is a concise and realistic description of what the Sprint will attempt to achieve for business, end-users, and IT systems. The Team Capacity The total capacity of the Scrum Team might change from Sprint to Sprint. To make realistic commitments, the Scrum Team needs to know its capacity for the upcoming Sprint. The team needs to take vacations, public holidays, time spent on Scrum Rituals, and a small contingency for unforeseen issues into account to propose a reasonable capacity. The WHAT-Meeting A Sprint Planning Meeting starts with a WHAT-Meeting. It requires some preparation: The Scrum Product Owner defines the Sprint Goal.Based on this goal, the Scrum Product Owner chooses the candidate user stories for the Sprint from the Scrum Product Backlog.These user stories are edited and broken into smaller user stories when necessary so that they can be processed within one Sprint.The user stories are estimated and prioritized.The Scrum Team plans its capacity for the upcoming Sprint. The duties of various Scrum roles during the course of the WHAT-Meeting part of Sprint Planning Meetings are the following: The Product Owner introduces the Sprint goal and her preselection of requirements, which should go into the product increment.The Scrum Team identifies the required tasks and their estimations. It’s the role of the Scrum Team to decide which and how many requirements preselected by the product owner they can confidently deliver in this Sprint.The Scrum Master moderates the meeting. She ensures that the self-organization and autonomous decision-making capability of the Scrum Team remain intact. The HOW-Meeting The goal of HOW-Meeting is to fill the Sprint Backlog by identifying the concrete tasks needed to implement committed user stories for the Sprint. These tasks usually (but not limited to) include activities such as analysis, design, development, testing, software build packaging, and documentation. The HOW-Meeting can be done in a separate session after the WHAT-Meeting, or it may follow the WHAT-Meeting without a pause. After identifying the tasks to be completed, the Scrum Team estimates these tasks. The unit for this estimation can be person-hours. Based on these estimates, the team has now its baseline about how long each user story will take them to deliver. What Is A Daily Scrum/Stand-Up Meeting? This Might Surprise You! The Daily Scrum Meeting is a maximum of 15 minutes meeting.These meetings take place every working at the same time in the same place. It’s best to conduct Daily Scrum Meetings with direct access to the Sprint Backlog and Sprint Burndown Chart. So the Scrum Team can direct the Daily Scrum Meeting based on the facts and progress which are visible to everyone in the team. Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically. All members of the Scrum Team, the Scrum Master and the Scrum Product Owner need to join Daily Scrums. Other stakeholders can also join these meetings, but only as a view-only audience. Daily Scrum Meetings are structured in the following way. Every member of the Scrum Team answers three questions. Daily Scrum Meeting – Question #1: What activities have I performed since the last Daily Scrum Meeting? Daily Scrum Meeting – Question #2: What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan? Daily Scrum Meeting – Question #3: Did I encounter or am I expecting any impediment which may slow down or block the progress of my work? The Scrum Master has to moderate Daily Scrum Meetings. She needs to ensure disciplined and fast-pacing progress so that all team members can answer these three questions in at most 15 minutes. The goal of Daily Scrum Meetings does not include to give time-consuming decisions or solve problems. On the other hand, no issues or concerns from any Scrum Team member should be ignored or undermined due to the time constraint of the Daily Scrum Meeting. Concerns associated with specific user stories must be clearly articulated, discussed, and resolved after the meeting with the Scrum Team members related to these user stories. To align on decisions and solve problems, the Scrum team can organize separate on demand basis meetings. These separate meetings to focus on decisions or issues take usually place subsequently after Daily Scrum Meetings. The Scrum Master documents the identified impediments and its dates in a separate log, flip chart or report which is accessible to the team. We find it very beneficial to quickly update the status of all known impediments at the very end of Daily Scrum Meetings. What Is A Sprint Review Meeting? This Might Surprise You! The Sprint Review Meeting happens at the end of the Sprint.Regardless of the duration of the Sprint, it usually takes one to two hours. Depending on the type of software and available infrastructure, the Sprint Review Meetings take place in a meeting room, in a lab or in the room of the Scrum team. The goal of the Sprint Review Meeting is to review the shippable product increment built during the Sprint and bring transparency to the product development process. The Scrum Team members do not need to prepare a Powerpoint or Keynote presentation to show in the Sprint Review Meetings. They should instead spend their energy on the successful completion and demonstration of the Sprint outcome, which we call the shippable product increment. The Scrum team demonstrates its work results. The Product Owner controls whether the Scrum team delivered the requirements they had committed during the Sprint Planned Meeting accurately or not. The Sprint Review Meeting enables the Product Owner to inspect the current status of the product and adapt the goals of the subsequent Sprint. Therefore, Sprint Review Meetings are another way of formal and practical application of “inspect and adapt”. Participants of the Sprint Review Meeting are the Scrum Team, the Scrum Product Owner, the Scrum Master. Optionally all other stakeholders such as end-users, clients, business representatives can join Sprint Review Meetings. In Sprint Review Meetings, everyone is allowed to deliver their feedback about the demonstrated product increment. In this way, the Scrum team has the opportunity to get unfiltered and direct input from stakeholders for whom they’re building the software. What Is A Sprint Retrospective Meeting? This Might Surprise You! The goal of the Sprint Retrospective Meetings is to improve the teamwork of Scrum Team members and the application of the Scrum process. The Sprint Retrospective Meeting happens directly after the Sprint Review Meeting, and it closes the Sprint. Therefore, Sprint Retrospective Meetings lead to an increase in productivity, the performance of Scrum Team members, and the quality of engineered software. The Sprint Retrospective is an integral part of the “inspect and adapt” process. Without this meeting, the Scrum Team will never be able to improve its overall throughput, and they cannot focus on the improvement of team performance. Remember this: What you focus on is what becomes better! A Sprint Retrospective Meeting is virtually a mini postmortem to define improvement potentials and remove process-related obstacles. Some examples of such improvement potentials that we frequently see in our project are: Adoption of agile software development practices such as extreme programming (XP) or test-driven development (TDD), Identification of new team norms and principles, orIncreased availability of the Scrum Product Owner. Without exception, the Scrum team conducts Sprint Retrospective Meetings at the end of every Sprint. Only in this way, these meetings enable the Scrum Team to systematically adapt and improve their use of the Scrum process to the specifics of their project. What Is A Scrum Grooming (Backlog Refinement) Meeting? This Might Surprise You! Scrum Backlog Refinement (Grooming) Meetings aim to keep the Product Backlog up to date. So the Product Backlog reflects the best know-how and understanding of the Scrum team about the ongoing Scrum project. Scrum Backlog Refinement meetings can happen on-demand or scheduled basis up to two times a week, 30 minutes each session. The Scrum Team, the Scrum Product Owner, and the Scrum Master participate in these meetings. During Scrum Backlog Refinement (Grooming) meetings, the participants fine-tune the Product Backlog with the following actions: Add new user stories based on newly discovered requirements.Remove user stories which are no longer required for the product.Fine-tune estimates of user stories.Update priorities of user stories.Split giant user stories into digestible smaller user stories, and prioritize them accordingly. Here are our other suggestions to improve the outcomes of Backlog Refinement Meetings: Ensure Cross Team Participation, which means you identify the dependencies as early as it is possible, Size User Stories Correctly, which means all user stories can result in a shippable product increment within one single Sprint,Prioritize User Stories, which means you deliver immediate value to end-users, enable quick wins, and make them happy,Estimate Like a Pro, which means you obtain actionable inputs for reliable release planning,Identify Dependencies, which means you pull required teams and resources on board to make your project a success,Uncover Risks, which means you avoid tedious surprises during the later stages of your project.
Scrum Institute, Scrum Framework Episode #12 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 A Scrum Burndown? This Might Surprise You! The “Scrum Burndown Chart” is a visual measurement tool that shows the completed work per Sprint against the projected rate of completion for the current project release. Its purpose is to enable the Scrum Product Owner, the Scrum Team, and other stakeholders to control the progress of the project. So the Scrum Team achieves to deliver the requested software solution within the desired timeline. Simple Scrum Burndown Chart The speed/rate of progress of a Scrum Team is called “Velocity”. It expresses the total number of story points completed that the Scrum Team delivers per Sprint (Iteration). An essential rule to assess and calculate the Velocity is that; Only entirely completed user stories that precisely fulfill their Definition of Done (DoD) are counted. The velocity calculation shouldn’t take partially completed user stories into account. (For instance, coding of a user story is done, but its tests are still missing) Only a few Sprints after a new Scrum Team is formed, the Velocity of the team can be reliably calculated. That helps the Scrum Product Owner to predict the throughput of the Scrum Team better, and he or she can foresee what user stories the Scrum Team can deliver in a given Sprint. That would enable the Scrum Product Owner to plan software releases more accurately, with less surprises towards business clients and end-users. As a simple example: Let’s assume the Velocity of your Scrum Team is 50 story points per Sprint. And the total amount of remaining work has been estimated as 300 story points. Then you can predict that you need 6 Sprints to deliver all of the remaining user stories from the Product Backlog. However, in reality, the user stories in the Scrum Product Backlog will change over the course of the project. New stories are added, and other stories are modified or even deleted. In the Simple Burndown Chart, the Velocity of the Scrum Team and the change of the scope cannot be visualized accurately. To increase this lost accuracy and visibility, Scrum Teams use another type of diagram, which we call “Extended Burndown Chart”. Extended Burndown Chart uses a bar chart instead of a line diagram. The size of each bar represents the total number of remaining user stories at the beginning of each sprint. The Velocity of the Scrum Team is subtracted from the top bar, while changes of the Product Backlog are presented at the bottom of the bar. Extended Burndown Chart Separating Velocity and Scope Changes To get even more accurate results with the Burndown Chart, we can also take the rate of changes in total work into account. We call this more precise model “Extended Burndown Chart With Prediction”. However, we have to be careful when using this model. The magnitude of changes in the Product Backlog will be relatively higher at the beginning. And yet, the rate of changes will usually drop, and they approach zero towards the end of the project. What Is A Scrum Burndown Report? This Might Surprise You! The Sprint Burndown Chart (Sprint Burndown Report) visualizes the progress within the Sprint towards reaching the Sprint goal. It enables transparency and actionable progress data about the actual performance (burndown rate) of the Scrum Team. That allows the Scrum Product Owner and the Scrum Team to easily monitor how the Sprint is going. Thanks to this overview delivered by the Sprint Burndown Chart, the team can predict if the Sprint goal can be accomplished until the end of the Sprint on time. Otherwise, the Scrum Master and the Scrum Team should consider and implement other measures to speed-up the execution of the remaining tasks and user stories in the Sprint Backlog. In the Sprint Burndown Chart, the initial Sprint Backlog defines the start-point for the remaining efforts. Every day the remaining effort which needs to be completed until the end of the Sprint is summed up, and it’s logged on this graph. Sprint Burndown Report/Chart It's worthwhile to remember that; While a new Scrum team is forming, the performance is often not as good as how the ideal burndown rate envisioned it. That usually happens due to wrong estimates or unforeseen impediments that have to be removed to bring the Scrum Team on full speed.
Scrum Institute, Scrum Framework Episode #11 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 The Scrum Product Backlog? This Might Surprise You! Product Backlog (Scrum Backlog) or Scrum Product Backlog is the central element to manage all of the known requirements of a Scrum Project. It consists of all customer requirements and work results that are needed to execute and finish a successful project. As requirements, you count functional and non-functional requirements and other features related to user experience and user interface design. The Product Backlog contains feature requests and their high-level user stories. These can also include pre-requisite or complementary project requirements such as building test and development environments. Moreover, other user stories required to resolve known bugs or reduce technical debt or improve certain software features have also their places in the Product Backlog as well. Every Scrum Project has its Product Backlog. The Scrum Product Owner is responsible for the creation, maintenance, and fine-tuning of a Product Backlog. The Product Backlog doesn’t and shouldn’t answer the question of how these requirements will be developed and delivered. That’s the duty of the Scrum Team. The Scrum Team decides and documents the required tasks to address these requirements in Sprint Backlogs. Note that Product Backlog and Sprint Backlog are physically separate entities although entries in the Product Backlog drive the contents of the Sprint Backlog. The owner of the Scrum Product Backlog is the Scrum Product Owner. The Scrum Master, the Scrum Team, and other Stakeholders contribute it to build a broader list of user stories to bring the product to success. Working with a Scrum Product Backlog does not mean that the Scrum Team is not allowed to create and use other artifacts to manage work. Examples for additional artifacts could be a summary of the various user roles, workflow descriptions, user interface guidelines, storyboards, or user interface prototypes. However, note that these artifacts do not replace the Scrum Product Backlog but complement and detail its contents. he Product Backlog is a living document. Similar to how the software incrementally improves, the Product Backlog grows in time as well. The Scrum framework doesn’t require a separate change management process per se. The Scrum Product Owner creates the first versions of the Product Backlog based on his best initial understanding of the product. While the Scrum Product Owner closely observes how the product emerges from sprint to sprint and while the knowledge about client requirements augments, he or she adds, removes and fine-tines requirements in the Product Backlog. The Scrum Product Owner prioritizes requirements in the Product Backlog. The more priority an element in the Product Backlog has, the more details it should contain. So the Scrum Team can easily make sense of these high priority requirements and create the required tasks to build them. Furthermore, by using story points, the Scrum Team regularly estimates the requirements in the Product Backlog. These estimations should be fine-tuned and improved for high-priority user stories to make them ready for Sprint Planning Meetings. Each Scrum Product Backlog has specific attributes that differentiate it from a simple to-do list: A user story in the Scrum Product Backlog always add a business or technical value to its client, business owner and end-users, All user stories in the Scrum Product Backlog are prioritized and ordered from highest to lowest priority, The level of details stored in a user story depends on its position within the Scrum Product Backlog, User stories are estimated,Scrum Product Backlog is a living document,There are no action items or low-level tasks in the Scrum Product Backlog. User Stories Add Value To Client, Business, and Systems Each user story in the Scrum Product Backlog must offer some client value. User stories without any client value are a pure waste of resources, and they should be eliminated. The Scrum Product Backlog can include user stories for: The specification of functional and nonfunctional requirements,The summary of high-level break-down of the work necessary to launch the software product, Setting up non-production development and demonstration environments,Remediating defects. Example Scrum Product Backlog Some tasks may not add direct value to the functionality of software system and business clients. Nevertheless, they should add value by increasing quality, reducing technical debt, and increasing maintainability of the product during the long run. Product Backlog Is A Living Document The Scrum Product Backlog is a living document. It changes and evolves throughout the entire course of a project. If needed, new user stories are added, existing user stories may be altered, defined in more detail, or even deleted. Requirements of Scrum projects are no longer frozen early on like we used to have them with the Waterfall Methodology. Instead, the final set of requirements within the Scrum Product Backlog are developed iteratively, together with the emerging software increments.That is different from traditional requirements engineering. Still, this new way of handling client requirements allows the Scrum Team to maximize client value and minimize waste of resources. Different Level Of Details The requirements in the Scrum Product Backlog can have varying depths with their granularities. Only those requirements that will be implemented during the next few Sprints should be defined with greater detail. All other user stories should remain coarse-grained; they should be only processed “just in time” before the Scrum Team needs to know more about them. It does not make sense to invest time and resources into the specification of these requirements, as some of these requirements may change or disappear until they are needed for implementation. “Just in time” handling of requirements is one of the most excellent benefits the Scrum Framework offers to deal with “unknown unknowns” in your projects. No Low-Level tasks In The Product Backlog The Scrum Product Backlog should not contain detailed task break-down of user stories. The Scrum Product Owner defines the requirements together with the business clients and stakeholders before he or she brings them to the Backlog Refinement or Sprint Planning Meetings. Detailed task break-down and distribution of these tasks among the Scrum Team Members are the responsibility of the Scrum Team. The Scrum Product Backlog Is Ordered Based On Priority All user stories are prioritized, and the Scrum Product Backlog is ordered based on the priority of user stories (from highest to lowest). The Scrum Product Owner performs the prioritization with the support of the Scrum Team. During this prioritization exercise, the added value created for the business of the client, costs, risks, and dependencies are the most common factors which are into account by the team. Thanks to this prioritization, the Scrum Product Owner can decide what the Scrum Team should subsequently build and deliver. All User Stories Are Estimated All user stories within the Scrum Product Backlog have to be estimated according to the agreed norm of story point units such as Fibonacci number or S/M/L/XL/XXL, etc. More about this comes later in this material. These estimations then impact the capacity planning of Sprints, contents of Sprint Backlog, and release plans. Working With The Backlog The Scrum Product Backlog needs regular care and attention. It needs to be carefully managed because it’s the source of truth to understand what your software product is all about. At the beginning of a project, it’s filled with a lot of high-level stories that may or may not be highly relevant to contribute to the success of the project. While the project progresses from one Sprint to another, the Scrum Product Owner and the team learn more about the project. Subsequently, the contents of the Scrum Product Backlog will become perfectly reasonable to reflect your product better. After this initial setup, the Scrum Product Backlog has to be continuously maintained. The maintenance of the Scrum Product Backlog stands for: As new requirements are discovered, they are described and added. Existing requirements can be changed or removed as appropriate,Ordering (Prioritizing) the Scrum Product Backlog. The most important (highest priority) user stories are moved to the top,Preparing the high-priority user stories for the upcoming Sprint Planning Meetings (usually during Backlog Refinement Meetings), (Re-)Estimating the user stories in the Scrum Product Backlog (usually during Backlog Refinement Meetings). The Scrum Product Owner is responsible for making sure that the Scrum Product Backlog is always in good shape. And yet maintaining the Scrum Product Backlog is a collaborative process. A reasonable capacity of the Scrum Team members should be reserved for managing the Scrum Product Backlog for the time they need to spend during Scrum Rituals (Events). Furthermore, note that, this collaborative maintenance of the Scrum Product Backlog helps to clarify the requirements and creates buy-in of the emerging software product from the Scrum Team members. What Is The Sprint Backlog? This Might Surprise You! The Sprint Backlog stores and maintains user stories required to deliver the shippable software increment of a Sprint. These user stories are the ones the Scrum Team committed during the Sprint Planning Meeting. All user stories in the Sprint Backlog are estimated to enable the monitoring and tracking of the work. The Sprint Backlog is a living artifact, and during the course of Sprint, the Scrum team members continuously update it. When a Scrum Team member works on a task, his or her name is associated with it. The status of the task is set to “Started Tasks” or “Work In Progress”. When the task is completed according to its Definition of Done, its status is set to “Done” or “Completed”. New tasks (not new user stories) can be added to the Sprint Backlog during the Sprint. At the end of every day, the remaining effort to deliver the full Sprint Backlog is calculated. This helps the Scrum Team and the Scrum Product Owner to monitor the remaining amount of work to bring the Sprint goals to success. The Sprint Backlog can be kept electronically by using a Scrum Project Management Software or spreadsheet software such as Excel or Google Sheet. Alternatively, for smaller and new teams, cards (or post-its) glued on a real physical board can be used too. The latter has some advantages such as transparency of work and easy access for everyone, including the stakeholders. Its downside is that it’s not sustainable if the Scrum Team is distributed over multiple locations. The figure below shows a sample of how such a Sprint Backlog Board can be built. The structure should be adapted to reflect the needs of the project and the Scrum Team. A Sample Sprint Backlog Board It’s evident that for a Scrum Team to work productively, they need to understand the difference between a Product Backlog and a Sprint Backlog, and how these two elements interact to execute forward the project. Remember that there is a complete list of user stories from the Product Backlog. And now, a small subset of this list is being moved to Sprint Backlog to accomplish the goals of the Sprint. During the Sprint Planning Meeting, all members of the Scrum Team should discuss what tasks must be done and how these tasks will be completed. It’s at this point that each item on the Sprint Backlog is broken down into tasks or steps that will be taken to complete the committed user stories. All of this must be clearly communicated and agreed upon, so the Scrum Team members have an unmistakable consensus about what is coming in the Sprint and what it takes to accomplish its goals. What Is A Sprint? This Might Surprise You! In the scrum framework, all activities to implement the requirements happen during Sprints. Sprints are cycles of work activities to develop shippable software product or service increments. Sprints are also sometimes called iterations. You think about sprints as if they’re micro projects. As the term “Sprint” implies, a sprint doesn’t take long, and it’s maximum for four weeks. Sprints are always short, usually between 2 to 4 weeks. But depending on the reliably foreseen amount of work or for Exploration Sprints, a one week long Sprint is also typical. With the approval of the Scrum Product Owner, a Scrum Team may need an Exploration Sprint to investigate new technology, build a mock-up or a proof of concept. Different from a running race, at the end of a Sprint, the Scrum Team shouldn’t be out of breath and power. Instead, the Scrum Team should be fresh, and they should energetically start the next Sprint. The Scrum Software Development and Delivery Framework has nothing to do to create pressure and stress for its team members. It’s a well known fact that people perform best when they can work focused, relieved, and undistracted. If it’s applied correctly this is what Sprints help us accomplish. Every Sprint starts with a Sprint Planning Meeting. During the Sprint Planning Meeting, the Scrum Team decides what and how many requirements they will implement in this given Sprint. Subsequently, the Scrum Team starts the execution of activities to deliver requirements. Daily Scrum (Daily Scrum Meeting) happens every day at the same time in the same place. The goal of this meeting is to align all members of the Scrum Team regularly. Scrum Team Members can also ask help from the Scrum Master to remove any impediments which may potentially slow down or block the progress of a Sprint. The Scrum Team finalizes a Sprint with Sprint Review and Sprint Retrospective meetings. The Sprint Review Meeting enables the Scrum Product Owner to review and control the work results the Scrum Team has created during the Sprint. During the Sprint Retrospective Meeting, the Scrum Team reflects the way they work together, how they use the Scrum Framework, and how they can improve. So the Scrum Team jointly takes these improvement potentials and feedback into account during the next Sprint Planning Meeting.Sprints enable such feedback loops during short periods with small batch sizes of work. That’s one of the significant reasons why and how the Scrum framework helps teams and organizations to improve themselves continuously.
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.
Does your Scrum Team use Sprint Goals? If not, why? Perhaps your team finds it hard to identify a goal for the Sprint out of the patchwork of items on the Sprint Backlog? Or perhaps your Product Owner doesn't know how to balance the requests from many different groups of stakeholders?In this episode, we bust one of the most persistent myths in Scrum; the notion that Sprint Goals are optional in Scrum. That they are nice-to-have, but hardly ever practically possible. We will show that the reverse is true. It is very hard, maybe even impossible, to do Scrum well when you don't have Sprint Goals.This episode is based on this blog-post (where you can find the other things we reference):http://bit.ly/2kZhh0VDonate to support our workhttps://bit.ly/supportheliberatorsFollow us on Medium:https://medium.com/the-liberatorsSupport the show (https://bit.ly/supportheliberators)
Scrum Institute, Scrum Framework Episode #8 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 The Role Of The Scrum Team? This Might Surprise You! The Scrum Framework recognizes three roles: The Product Owner,The Scrum Team Member,The Scrum Master. In addition to other programs it’s providing to its worldwide students, International Scrum Institute provides three primary training and certification programs for these three roles. These programs are namely Scrum Product Owner Accredited Certification (SPOAC), Scrum Team Member Accredited Certification (STMAC), and Scrum Master Accredited Certification (SMAC) . A proper scrum organization must adequately possess people from all these three skill-sets. That’s particularly essential to succeed with the scrum software development framework. None of these roles is indispensable and irreplaceable. They cannot be combined with the other scrum roles and functions.Each Scrum Product Owner typically works together with one scrum team. Each Scrum Team has its own Scrum Master, and each Scrum Master cares and works with one single Scrum Team. Please don’t underestimate the importance of understanding the purpose and function of these roles and employing them with adequate talents. Many times we observed that the root cause of difficulties of a scrum team is either because these roles are not understood or they don’t employ the right people. Each of these roles has a defined set of responsibilities. Only if the owners of these roles fulfil these responsibilities, closely interact, collaborate, and work together, they can finish a Scrum project successfully. Scrum Roles & Stakeholders The Scrum Team Within the Scrum Framework, dedicated Scrum Teams do all work delivered to the business clients. A Scrum Team is a collection of individuals working together to provide the requested and committed product increments. To work effectively, it is essential for a Scrum Team that everyone within the team: Embraces values of the Scrum Framework such as Courage, Focus, Commitment, Respect, and Openness, Adheres the same norms and rules,Follows the common goal, which wires them to both IT and business outcomes. When setting up a new Scrum Team, you always need to keep in mind that no new team will deliver with the highest possible performance right from the beginning. After setting up the team, it has to go through certain phases as described by the Tuckman-Model: Forming, Storming, Norming, Performing. Tuckman's Stages of Team Development How long it takes until the Scrum Team reaches the Performing Phase varies from team to team. Hiring good basketball players for the same club will not make a good basketball team as soon as they start to play together. They first need to learn and adapt their playing styles, their strengths and weaknesses to assist each other, and to play in harmony. Scrum teams are not that different. Therefore, it’s vital to keep in mind that it usually takes about 3 to 5 Sprints until the team becomes mature enough to deliver its results effectively and predictably. Characteristics of a Scrum Team Scrum Teams have the following characteristics: Team members share the same norms and rules,The Scrum team as a whole is accountable for the delivery,The Scrum Team is empowered,The Scrum Team is working as autonomous as it is possible,The Scrum Team is self-organizing,The skills within the Scrum team are balanced,A core Scrum Team is small and has no sub-teams,The Scrum Team members are dedicated to their teams with 100% capacity,Scrum Team members are collocated, and they ideally share the same room. Rules & Norms The environment, business, IT, and geographical ecosystem of Scrum Teams invisibly define some of the norms the teams follow. And yet, to become a truly successful Scrum Team, some rules and norms should be explicitly developed and exercised during the Norming phase. These common standards are essential, and they can’t be overemphasized to deliver smooth gameplay, IT, and business results. Otherwise, the Scrum Team members would have to continually switch back and forth between different value systems and rule sets, and they waste their valuable time. Just a few examples of such norms and rules are: The goal, scope, duration, location, participants and outcomes of Scrum Rituals (Events),Required level of details to write clear, concise and unmistakable Definition Of Dones (DoDs),Guidelines to prioritize and estimate user stories and tasks, Guidelines, procedures and the level of details to create living documents, Tools to use and tools not to use (remember, sometimes less is more), Coding standards,Tools and guidelines to build/perform manual/automated tests and ensure quality,The process to resolve bugs,The process to handle change requests,The process to prepare to product increment demonstrations during Sprint Review Meetings,The process to handle the outcomes of each Scrum Ritual (Event), Frequency, depth, and duration of Backlog Refinement Meetings. Accountability The Scrum Team as a whole is responsible for delivering the committed user stories in time and with the highest possible quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team. Empowerment & Self-organization The Scrum Team has to be empowered to define What the team commits to deliver at the end of the Sprint, How the committed user stories will be broken down into tasks,Who will perform a specific task and in which order the tasks are implemented. Only if the Scrum Team is empowered to decide these and similar internal decisions, the team members will work with higher performance and motivation for the interest of their client stakeholders. Balanced set of skills Each Individual within the Scrum Team will most certainly have specialized skills, focus, and personal preference of interests. However, to achieve the best possible performance, your Scrum Team needs to have a balanced set of skills. Only then the Scrum Team will be able to deal with the ever-changing IT and business challenges, and they can act as autonomous as it is possible. That means a Scrum Team should be multidisciplinary (designers, developers, testers, architects, etc.) right from the beginning. On the other hand, this also means that each team member should learn a little bit from each other’s specialization. For instance, to be able to finish a committed user story until the end of the Sprint, a developer should willingly write and execute tests, and consult the tester whenever necessary. The roles of the Scrum Team members are not compartmentalized like the architect, the developer, the tester, and so on. They all share the same title, “Scrum Team Member” regardless of their core personal competencies. Size of the Scrum Team Scrum Teams are small. The ideal size is 7 +/- 2 people. Note that if the Scrum Team contains more than nine members, your team will most probably suffer due to excessive overhead of alignment and communication. And yet, there is no one size fits all answer. Your Scrum Teams may still productively function even if they have less than five or more than nine members. The only way to find this out is to test, learn, and adapt. If you find out that a team of 13 people cannot perform well enough, then these Scrum Teams need to be split into two teams. These Scrum Teams should closely align, and they correlate their goals and user stories. Besides that, they work independently. Collocation To minimize unnecessary communication overhead, each Scrum Team should be collocated. If the work has to spread over multiple geographical locations, independent Scrum Teams need to be created. These teams need to align and correlate their goals and user stories. Responsibilities of the Scrum Team The Scrum Team has specific responsibilities they need to fulfill: They have to breakdown the user stories, create tasks, define priorities and estimates, and they self-organize the implementation. In other words, they have to create, process, and deliver the Sprint Backlog.They have to perform Daily Scrum Meetings.They have to ensure that at the end of the Sprint, potentially shippable product increment is delivered and demonstrated. They have to update the status and the remaining work efforts for their tasks to allow the creation of a Sprint Burndown Diagram. What Is The Role Of The Scrum Master? This Might Surprise You! The Scrum Master serves all participants of a Scrum Project and the external stakeholders to comprehend and apply the Scrum Framework correctly. He or she supports the Scrum Team to execute the Scrum Framework successfully and contributes them to improve their productivity and performance continuously. The role of the Scrum Master is to establish the Scrum Process in its organization, the new way of thinking and acting. Furthermore, the Scrum Master acts as a change agent. He or she coaches the team to develop new team norms and standards. The Scrum Master has its desk somewhere very close to the rest of the scrum team. Essential tasks of a Scrum Master owner are: To establish the Scrum Framework in his or her business and IT ecosystem,To act as a change agent and support the adaptation of existing processes to maximize productivity of the Scrum Team.To coach the Scrum Team to understand and live the values of the Scrum Framework,To ensure efficient and close collaboration between the Scrum Product Owner and the Scrum Team,To remove impediments which hinder the continuity of work,To lead progress of work by serving,To moderate the Scrum Rituals (Scrum Events).To guard the Scrum Team from external interference and interruptions while the team does work it has originally committed for a Sprint. Easily Learn Scrum and Officially Prove Your Know how To effectively do this work, a Scrum Master needs to possess savvy moderation and coaching skills. He or she needs to be a continuous learner to inspire others to learn, change, and grow. To learn more about Scrum Master’s duties as a facilitator, I recommend you to have a look at this article: If I had 5 Minutes to explain Scrum Master As a Facilitator. To learn more about Scrum Master’s duties as a facilitator, I recommend you to have a look at this article: If I had 5 Minutes to explain Scrum Master As a Facilitator. The Scrum Master is part of the Scrum Team and acts as a servant-leader for the Scrum Team. In the beginning, this will be a full-time job so that the Scrum Master will not be able to contribute to the Sprint results directly. However, after a few Sprints, while the Scrum Team approach to the Performing phase of the Tuckman model, the initial workload as moderator and coach will reduce. So, the Scrum Master could actively contribute to the Sprint goals. Since there must be trust between the Scrum Master and the Scrum Team members, it can always be a good idea that the Scrum Team chooses its Scrum Master. However, in reality, the management usually imposes who the Scrum Master will be. To get the required trust, the Scrum Master should have no line management responsibility above the Scrum Team members. Otherwise, open communication in the Scrum Team and joint ownership of work and decision-making ability of the Scrum Team can suffer. Guarding The Scrum Team, Removing Impediments An essential job of the Scrum Master is to safeguard the Scrum Team from a false sense of urgency. Line management and the Scrum Product Owner often attempt to add unplanned user stories to the Sprint Backlog while the team focuses on the work of a planned Sprint. However, one of the critical aspects of the Scrum Framework is that all user stories are known and committed only during the Sprint Planning Meetings. The Scrum Team cannot be forced to take over new user stories. The job of the Scrum Master is to ensure that until the next Sprint Planning Meeting, these new user stories are stored in the Scrum Product Backlog. Alternatively, if the ongoing Sprint does not make any business and/or technical sense to continue, it can be canceled, and a new Sprint can be planned. Scrum Team members should only concentrate on delivering client value by building potentially shippable product increment. The Scrum Master helps by removing impediments that block or slow down the progress of work. Examples of removing impediments could be: To arrange support, resources,To find missing know how, andTo do hands-on work to help the Scrum Team Members. Scrum Master as a Change Agent One of the cornerstones of the Scrum Framework is the continuous improvement through Inspect & Adapt. The Scrum Master hosts and moderates the Scrum Retrospective Meeting, and his or her job is then to facilitate, control and measure the change of the identified shortcomings. Facilitation of Scrum Rituals (Event) The Scrum Framework defines several meetings that have to be organized and facilitated by the Scrum Master: Scrum Grooming (Backlog Refinement) Meetings,Sprint Planning MeetingsDaily Scrum Meetings,Sprint Review Meetings, andSprint Retrospective Meetings What Is The Role Of The Scrum Product Owner? This Might Surprise You! The Scrum Product Owner is a central role within the Scrum Framework. That role unifies product and project management tasks, and it’s also firmly integrated with software development and delivery. The product owner’s role is far broader than traditional project management, program manager, or product management roles. He or she represents the end customers and/or other stakeholders and is responsible for maximizing the value of the product by ensuring that the Scrum Team delivers the right work at the right time. The Scrum Product Owner decides the software requirements provided for a specific software version, and when the software will be released. She represents functional and nonfunctional demands from end-users. That means that the Scrum Product Owner has to work very closely with the Scrum Team and coordinates their activities over the entire lifecycle of the project. No one else is allowed to impose the Scrum Team to work for a different set of priorities. Essential tasks of a Scrum Product owner are: To manage and clarify project requirements,To guide releases and to ensure return on investment (ROI),To closely work with the Scrum Team and enable it to deliver the correct work on time,To manage stakeholders and their expectations,To manage the Scrum Product Backlog. The Scrum Product Owner can delegate certain activities (like physically maintaining the Scrum Product Backlog). However, he or she still owns the accountability of his or her tasks. Managing the Product Backlog The Scrum Product Owner is the only person allowed to own the contents of the Scrum Product Backlog. That means he or she needs to: Create, maintain and clearly describe user stories in the Scrum Product Backlog,Prioritize user stories to accomplish business goals and fulfil the mission of software product,Ensure that the Scrum Team correctly comprehends and implements the user stories in the Scrum Product Backlog. Release Management The Scrum Product Owner is responsible for reaching the project goals. He or she creates and maintains the release plan and decides about deliveries, end-user functions, and the order they need to be delivered. Scrum Product Owners often manage the costs and budget of Scrum Teams too. They collaborate with the Scrum Team members to fine-tune, prioritize, and estimate user stories. Stakeholder Management External stakeholders should not directly bring their demands to the Scrum Team members. Instead, the Scrum Product Owner should collect and assess required functionalities with the stakeholders (for instance, with internal clients, representatives of external clients or end-users). The Scrum Product Owner combines, filters and initially prioritize these user stories before they're discussed them with the rest of the Scrum Team. Collaboration With The Scrum Team For a successful project, the Scrum Product Owner and the Scrum Team must work very closely. The Scrum Product Owner is responsible for ensuring that the Scrum Team members are informed and aligned about the aimed goals of software they’re building. During Sprint Review Meetings, the Scrum Product Owner is responsible for inspecting, accepting, or declining deliverables of the Scrum Team. What Is The Role Of The Scrum Team Member? This Might Surprise You! The Scrum Team Members implement the software. They jointly decide the number of requirements that they can undoubtedly deliver during a particular product increment called“Sprint”. A high-performer scrum team has most of the software engineering skills typically in it. Software developers, architects, testers, database administrators, and team members from all other roles work together. They jointly build and deliver great software their client is paying for. Scrum team members do no longer belong to a functional silo of a matrix organization. Developers do no longer belong to software development competence centers, and testers do no longer belong to the software testing competence center, and so on. Regardless of their past coordinates in the organization, members of a scrum team belong to their particular scrum project. Now their job is to build the best possible software to deliver the requirements of their scrum product owner. Characteristics of scrum teams are: Empowered and Autonomous,Cross-functionalSelf-organized and smallFull-time participantsWorking in the same roomOne for all, all for one. It's an excellent time to remind that the Scrum Team members follow Scrum values persistently. CourageFocusCommitmentRespectOpenness
Scrum Institute, Scrum Framework Episode #6 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 Learn Scrum Framework Using Real World Case Study! This Might Surprise You! Before Starting The First Sprint Alex works as the Scrum Product Owner of a new software development project. One of his first tasks is to assess and find out requirements to deliver business value his client is looking for. He needs to make sure that his client will get the correct software to achieve tangible business results. He writes down the essential use cases and discusses them with the architects, client representatives, and other stakeholders from IT and business units. After assembling the high-level use-cases and requirements, he writes them into the Scrum Product Backlog and initiates an estimation and prioritization session with the Scrum Team. As a result of this session, all items in the Scrum Product Backlog get an initial rough estimate and priority. During those sessions, Anna, the Scrum Master, ensures that everyone speaks the same language. So, the Scrum Product Owner, the Scrum Team Members, and their stakeholders arealigned with the anticipated goals. So they have an adequate understanding of potentially new concepts for them, such as Use Case, Backlog, Sprint, and so on. And most importantly, the Scrum software development and delivery process is correctly applied in the store. Now Alex, the Scrum Product Owner, begins to break down the high-level requirements into the first draft of smaller-grained user stories. With this list, he then calls for the first Sprint Planning Meeting. Sprint 1 – Day 0 During the Sprint Planning Meeting, Alex presents the Scrum Product Backlog items from the highest priority to the lowest. The Scrum Team asks and clarifies open questions. For each item, the team discusses if they have enough 25 capacity and the required know-how to develop and deliver it. The Scrum Team needs to ensure that all required human and technical resources are in place before the start of the Sprint. They need to confirm that all prerequisites and dependencies are fulfilled, which could be critical to delivering certain software features successfully. During Sprint Planning Meeting (What-Part), the Scrum Team commit to complete the user stories 1,2,3,6,7 and 8 until the end of the Sprint. So these user stories are now moved from the Scrum Product Backlog to the Sprint Backlog. The user stories 4 and 5 cannot be accomplished in this Sprint, as some prerequisite technical infrastructure is not yet in place. After the What-Part of the Sprint Planning Meeting, Anna, the Scrum Master, calls the Scrum Team to drill down how the team is going to implement the committed user stories (How-Part). The emerging tasks during the How-Part of the Sprint Planning Meeting are written down on the cards, and the team store them into the Sprint Backlog. Now all members of the Scrum Team are ready to select a task to begin to work on. Sprint 1 – Day 1 In the morning, the whole team gets together for their Daily Scrum Meeting. Everyone gives a brief and concise statementabout what he or she has done so far, updates the estimates of remaining work on the cards of the Sprint Backlog. Everyone tells what he or she is planning to do today, and reveals if there are any impediments which hinder them from processing any tasks. Today one of the Scrum Team members, Melinda, informs the Scrum Team that she has a problem with the license of the integrated software development environment she is using. Anna, the Scrum Master, checks if other team members have the same problem and confirms that she’ll take care of this impediment after the meeting. After about 15 minutes of this Daily Scrum Meeting, everyone goes back to work. After this meeting, Anna updates the Sprint Burn down Chart to visualize the progress of work during this Sprint. Then she calls the software vendor, orders the missing license, and delivers it to Melinda. Introduction to Scrum A Real World Example (Case Study ) across various Scrum Phases and Sprints Sprint 1 – Day 2 In the morning, the whole team gets together again for their Daily Scrum Meeting. In the afternoon, a member of the Scrum Team, James, has uncertainty about the expected outcome of one of the user stories. He calls Alex, Scrum Product Owner, and they discuss this user story to ensure that James properly understands it. After Alex gets informed and confident about how to proceed with this user story, he continues working on its implementation. Sprint 1 – Day 6 The days starts again with the Daily Scrum Meeting of the team. Anna, the Scrum Master, notices this morning that the meeting tends to take more than 15 minutes. The Scrum Team members are engaging with a discussion regarding the optimization of some database queries. Anna reminds the team that the Daily Scrum Meetings are not meant to do the work, but formally aligning the team about the work and bringing them on the same page. After the Daily Scrum Meeting, Alex (Product Owner) informs Anna (Scrum Master) that the client brought up several new requirements that may potentially impact the ongoing Sprint and the subsequent Sprints. Anna politely reminds Alex that the Scrum Team is unable to pick up these requirements during the current Sprint as the team has already committed to the scope (user stories) of this Sprint. And yet, Anna calls a Backlog Refinement Meeting for the afternoon so that Alex can inform the team about these new requirements. During this meeting, the group supports Alex to figure out where these user stories fit the overall development plan of the software, their initial task break-down, estimates, and priorities. Sprint 1 – Day 10 Finally, that’s the last day of this first Sprint. Anna, the Scrum Master, invites the Scrum Team for the Sprint Review Meeting. The team has prepared a non-production server with the latest version of the shippable software increment they created. Alex, the Scrum Product Owner, and Mr. Rich, one of the client stakeholders, sit in front of an instance of a graphical user interface of this software. They validate if the implementation meets the expectations and if the team documented details regarding the current level of application adequately. At the end of the Sprint Review Meeting, Alex concludes: The team delivered user stories 1,2,6 and 7 as committed and expected. The team couldn’t finish the user story 3 on time, and they didn’t demonstrate this user story at all. So, the remaining tasks of this user story are shifted to this next Sprint.The user story 8 did not fulfill some of its Definition of Done (DoD) criteria. This user story is moved to the next Sprint, so the team can define and complete the associated tasks to satisfy the DoD of this user story later. Alex, the Scrum Product Owner, and Mr. Rich, the client stakeholder, shortly debrief the Scrum Team about the upcoming changes and challenges about the software requirements and the direction of the overall strategy about this software should be going. Mr. Rich thanks the Scrum Team for their efforts and commitment and leaves the room. After the completion of the Sprint Planning Meeting, the Scrum Team sits together for the Sprint Retrospective Meeting. During this meeting, they discuss what went well during the Sprint and what could be improved, so that the likelihood of failed commitments like it happened with user stories 3 and 8 will reduce in the next Sprints. One of the hurdles identified from the Sprint Retrospective Meeting is that the team do not know enough about the overall system architecture. Anna, the Scrum Master, takes over the task of bringing a system architect on board to coach and guide the team at the beginning of the next Sprint. Sprint 2 – Day 1 Alex, the Scrum Product Owner, keeps on adding new requirements to the Scrum Product Backlog based on his recent client meetings. Moreover, he improves the way he articulated DoD of user story 8, so the Scrum Team can better envision the expected outcome from this user story. Alex then invites the team for the Sprint Planning Meeting for Sprint 2. The Scrum Team discuss and commit to user stories with the guidance of Anna, the Scrum Master, and subsequently, the second Sprint begins.
Scrum Institute, Scrum Framework Episode #4 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 Self Organization In Scrum Framework? This Might Surprise You! The scrum team organizes itself. Scrum team members decide in consensus about tasks they need to execute to deliver the goals of a sprint. A self-organized team doesn’t require a manager or a team leader. Self-organization in the scrum framework is very disciplined. Sprint Backlog, Sprint Burn down Chart, and Daily Scrum Meetings which you are going to learn more about them later in this material build the foundation of self-organization. Organizing the work by themselves requires for the most teams a learning phase. Competent scrum masters who own scrum master certifications support their scrum teams to excel with self-organization quickly. Self-organization also includes the ability to work together despite different opinions and possible conflicts among various scrum team members. Self-organization requires compliance and trust in joint decision-making processes. Those decision-making process in the scrum framework includes, but not limited to, planning, estimating, implementing, reporting, and reviewing the work the scrum team is jointly responsible. Yes? Then you need to bring up a team that can self-organize its own work! What Is Inspect And Adapt In Scrum Framework? This Might Surprise You! Scrum Inspect and Adapt is a straightforward concept to comprehend, but the hardest to properly implement and master. Companies have finally confirmed that none of their project managers can fully foresee the big picture of complex systems. They were unable to do reliable end-to-end planning. It was evident for them that they needed to try something different. Together with lean manufacturing (also known as lean movement), companies needed to develop a process to empower them strategically. They needed a standard operating procedure to help them learn and fix their courses of action while they’re running their projects and even operations. That was the birth of Toyota Improvement Kata, which we today call “Inspect and Adapt” while we talk about scrum software development and delivery framework. According to “Scrum Inspect and Adapt”: Step 1. Inspect: We do our best to grasp the current status of the project with our current level of know how and understanding about it. Step 2. Adapt: We define a direction and vision about the next steps of our project and then strategize and execute our vision. Step 3. Learn: We carefully observe, learn, and teach each other while we do so. We continuously log what works and what doesn’t work while we do our work.Step 4. Restart: Start over from Step 1 again. Note that those four steps described above are analog, but not limited to the following Scrum rituals (Scrum events). Step 1. Inspect is analog to Sprint Review Meetings and Sprint Retrospective Meetings.Step 2. Adapt is analog to Sprint Planning Meetings and Backlog Refinement Meetings.Step 3. Learn is analog to Daily Scrum Meetings.Step 4. Restart is analog to the closure of a sprint and the start of a new sprint.
Do Development Teams commit to completing all the items on the Sprint Backlog? Or is it okay for the Sprint Backlog to change as new insights emerge. Find out in this episode.We love to share our materials. Please help us by supporting our work. You can do so by giving us a thumbs-up on the platform you're listening on. Or follow us on Twitter, Medium or LinkedIn (Barry & Christiaan).This podcast is an audio recording of this post on Medium: http://bit.ly/2yRWnEfFollow us on Medium:https://medium.com/the-liberatorsOr check out our upcoming events at:https://theliberators.com/eventsDonate to support our workhttps://bit.ly/supportheliberatorsSupport the show (https://bit.ly/supportheliberators)
© 2020-2025 Ivy Podcast Discovery LLC
