Agile

When it comes to online services, uptime is crucial, but it’s not the only thing to consider. Imagine running an online store — having your site available 99.9% of the time might sound good, but what if that 0.1% of downtime happens during the holiday shopping season? That could mean losing out on big sales. And what if most of your customers are only interested in a few popular items? If those pages aren’t available, it doesn’t matter that the rest of your site is working fine. Sometimes, being available during peak moments can make or break your business. It’s not just e-commerce — a small fraction of airports handle most of the air traffic, just a tiny minority of celebrities are household names, and only a handful of blockbuster movies dominate the box office each year. It’s the same distribution pattern everywhere. To be successful, it’s important to not only maintain uptime but also be ready for significant events. Some teams implement change freezes before key times, such as Prime Day, Black Friday, or Cyber Monday. This approach is reasonable, but it can be limiting as it doesn’t allow teams to quickly respond to unexpected opportunities or critical situations. Additionally, not all demand can be predicted, and it’s not always clear when those high-impact events will happen. This is where “Reliability when it matters” comes in. We need to be able to adapt and respond quickly to changes in customer demand without being held back by code freeze periods and being prepared for unforeseen situations. By considering time as a valuable resource and understanding the relative significance of different moments, organizations can better translate customer value and adjust risk and availability budgets accordingly. This approach allows organizations to be flexible and responsive to changes in demand without missing out on crucial features or opportunities. In the end, it’s about being ready when luck comes your way. It’s important to note that a system is not static and is constantly changing. The system itself, the infrastructure it’s hosted on, and the engineering organization all change over time. This means that knowledge about the system also changes, which can impact reliability. Besides that, incidents and outages are inevitable, no matter how much we try to prevent them. Bugs will be shipped, bad configurations will be deployed, and human error will occur. There can also be interdependencies that amplify outages. An incident rarely has a single cause and is often a combination of factors coming together. The same goes for solutions, which are most effective when they involve a combination of principles and practices working together to mitigate the impact of outages. Operating a system often means dealing with real-world pressures, such as time, market, and management demands to deliver faster. This can lead to shortcuts being taken and potentially compromise the reliability of the system. Growth and expansion of the user base and organization can also bring additional complexity and result in unintended or unforeseen behaviors and failure modes. However, by adopting a holistic approach and utilizing the principles and practices of engineering I’m going to cover below, we can have the best of both worlds — speed, and reliability. It’s not an either-or scenario but rather a delicate balance between the two. What Is Reliability? Reliability is a vital component of any system, as it guarantees not only availability but also proper functioning. A system may be accessible, yet if it fails to operate accurately, it lacks reliability. The objective is to achieve both availability and precision within the system, which entails containing failures and minimizing their impact. However, not all failures carry equal weight. For instance, an issue preventing checkout and payment is far more crucial than a minor glitch in image loading. It’s important to focus on ensuring important functions work correctly during critical moments. In other words, we want to focus on being available and functioning correctly during peak times, serving the most important functionality, whether it be popular pages or critical parts of the process. Making sure systems work well during busy times is tough, but it’s important to approach it in a thoughtful and thorough way. This includes thinking about the technical, operational, and organizational aspects of the system. Key parts of this approach include: Designing systems that are resilient, fault-tolerant, and self-healing. Proactively testing systems under extreme conditions to identify potential weak spots and prevent regressions. Effective operational practices: defining hosting topology, auto-scaling, automating deployment/rollbacks, implementing change management, monitoring, and incident response protocols. Navigating the competing pressures of growth, market demands, and engineering quality. Cultivating a culture that values collaboration, knowledge sharing, open-mindedness, simplicity, and craftsmanship. It also requires a focus on outcomes in order to avoid indecision and provide the best possible experience for customers. Further, we’re going to expand on the concept of “Reliability when it matters” and provide practical steps for organizations to ensure availability and functionality during critical moments. We’ll discuss key elements such as designing systems for reliability, proactively testing and monitoring, and also delve into practical steps like automating deployment and incident response protocols. Reliability Metrics: A Vital Tool for Optimization When optimizing a service or system, it's essential to initially define your objectives and establish a method for monitoring progress. The metrics you choose should give you a comprehensive view of the system’s reliability, be easy to understand, share, and highlight areas for improvement. Here are some common reliability metrics: Incident frequency: the number of incidents per unit of time. Incident duration: the total amount of time incidents last. While these metrics are a good starting point, they don’t show the impact of incidents on customers. Let’s consider the following graph: Blue — the number of requests per five minutes, Red — errors, Green — reliability in 0..1 Suppose we have two incidents, one at 1 am and one at 2 pm, each causing about 10% of requests to fail for an equal duration of 30 minutes. Treating these incidents as equally impactful on reliability wouldn’t reflect their true effects on customers. By considering traffic volume, the reliability metric can better show that an incident during peak traffic has a bigger impact and deserves higher priority. Our goal is to have a clear signal that an incident during peak traffic is a major problem that should be fixed. This distinction helps prioritize tasks and make sure resources are used effectively. For example, it can prevent the marketing team’s efforts to bring more visitors from being wasted. Additionally, tracking the incident frequency per release can help improve the deployment and testing processes and reduce unexpected issues. In the end, this should lead to faster delivery with lower risks. Digging Deeper Into Metrics To get a deeper understanding of these metrics and find areas for improvement, try tracking the following: Time to detection: how long it takes to notice an incident. Time to notification: how long it takes to notify relevant parties. Time to repair: how long it takes to fix an incident. Time between incidents: this can reveal patterns or trends in system failures. Action item completion rate: the percentage of tasks completed. Action item resolution time: the time it takes to implement solutions. Percentage of high-severity incidents: this measures the overall reliability of the system. Finally, regularly reviewing these metrics during weekly operations can help focus on progress, recognize successes, and prioritize. By making this a regular part of your culture, you can use the data from these metrics to drive better decisions and gradually optimize the system. Remember, the usefulness of metrics lies in the actions taken from them and their ability to drive progress. It’s a continuous feedback loop of refining both the data and the action items to keep the system improving. Designing for Resilience A system that isn’t designed to be resilient probably won’t handle peak times as smoothly. Here are some considerations that can help ensure a system’s reliability under a variety of conditions: Do’s: Prepare for component failure: By partitioning the service or using isolation, you can limit the blast radius and reduce the impact of failures. Implement fault-tolerance: Implementing mechanisms like retries, request hedging, and backpressure will improve the system’s availability and performance. Use rate-limiting and traffic quotas: Don’t rely solely on upstream dependencies to protect themselves. Use rate-limiting and traffic quotas to ensure that your system remains reliable. Categorize functionality: Prioritize functions by categorizing them into “critical,” “normal,” and “best-effort” categories. This will help keep essential functions available at all costs during high demand. Implement error-pacing and load-shedding: These mechanisms help prevent or mitigate traffic misuse or abuse. Continuously challenge the system: Continuously challenge the system and consider potential failures to identify areas for improvement. Plan for recovery: Implement fail-over mechanisms and plan for recovery in the event of a failure. This will help reduce downtime and ensure that essential services are available during challenging conditions. Make strategic trade-offs: Make strategic trade-offs and prioritize essential services during challenging external conditions. Dont’s: Don’t assume callers will use your service as intended. Don’t neglect rare but potential failures; plan and design prevention measures. Don’t overlook the possibility of hardware failures. I explored some of the ideas in the following blog posts: Ensuring Predictable Performance in Distributed Systems Navigating the Benefits and Risks of Request Hedging for Network Services FIFO vs. LIFO: Which Queueing Strategy Is Better for Availability and Latency? Isolating Noisy Neighbors in Distributed Systems: The Power of Shuffle-Sharding Reliability Testing Reliability testing is essential for maintaining the availability and functionality of a system during high demand. To ensure a reliable system, it is important to: Design for testability so each component can be tested individually. Have good enough testing coverage as a prerequisite for being agile. Calibrate testing by importance, focusing on essential functions and giving a bit of slack to secondary or experimental features. Perform extensive non-functional testing, such as load testing, stress testing, failure-injection testing, soak testing, and fuzzing/combinatorial testing. It’s crucial to avoid: Blindly pursuing high coverage numbers. Assuming that a single data point provides a comprehensive understanding. Ensure that results are robustly reproducible. Underinvesting in testing environments and tooling. Proper testing not only ensures correctness, serves as living documentation, and prevents non-functional regressions but also helps engineers to understand the system deeper, flex their creative muscles while trying to challenge them, and ultimately create more resilient, reliable systems for the benefit of all stakeholders. Remember, if you don’t deliberately stress test your system, your users will do it for you. And you won’t be able to choose when that moment comes. Reliability Oriented Operations Operating a distributed system is like conducting an orchestra, a delicate art that requires a high level of skill and attention to detail. Many engineers tend to underestimate the importance of operations or view it as secondary to software development. However, in reality, operations can have a significant impact on the reliability of a system. Just like a conductor’s skill and understanding of the orchestra is vital to ensure a harmonious performance. For example, cloud computing providers often offer services built on open-source products. It’s not just about using the software but how you use it. This is a big part of the cloud computing provider business. To ensure reliability, there are three key aspects of operations to consider: Running the service: This involves hosting configuration, deployment procedures, and regular maintenance tasks like security patches, backups, and more. Incident prevention: Monitoring systems in real-time to quickly detect and resolve issues, regularly testing the system for performance and reliability, capacity planning, etc. Incident response: Having clear incident response protocols that define the roles and responsibilities of team members during an incident, as well as effective review, communication, and follow-up mechanisms to address issues and prevent similar incidents from happening or minimize their impact in the future. The incident response aspect is particularly crucial, as it serves as a reality check. After all, all taken measures were insufficient. It’s a moment of being humble and realizing that the world is much more complex than we thought. And we need to try to be as honest as possible to identify all the engineering and procedural weaknesses that enabled the incident and see what we could do better in the future. To make incident retrospectives effective, consider incorporating the following practices: Assume the reader doesn’t have prior knowledge of your service. First of all, you write this retrospective to share knowledge and write clearly so that others can understand. Define the impact of the incident. It helps to calibrate the amount of effort needed to invest in the follow-up measures. Only relatively severe incidents require a deep process, do not normalize retrospectives by having them for every minor issue that doesn’t have the potential to have a lasting impact. Don’t stop at comfortable answers. Dig deeper without worrying about personal egos. The goal is to improve processes, not blame individuals or feel guilt. Prioritize action items that would have prevented or greatly reduced the severity of the incident. Aim to have as few action items as possible, each with critical priority. In terms of not stopping at the “comfortable answers,” it’s important to identify and address underlying root causes for long-term reliability. Here are a few examples of surface-level issues that can cause service disruptions: Human error while pushing configuration. Unreliable upstream dependency causes unresponsiveness. Traffic spike leading to the temporary unavailability of our service. It can be difficult to come up with action items to improve reliability in the long term based on these diagnoses. On the other hand, deeper underlying root causes may sound like: Our system allowed the deployment of an invalid configuration to the whole fleet without safety checks. Our service didn’t handle upstream unavailability and amplified the outage. Our service didn’t protect itself from excessive traffic. Addressing underlying root causes can be more challenging, but it is essential for achieving long-term reliability. This is just a brief overview of what we should strive for in terms of operations, but there is much more to explore and consider. From incident response protocols to capacity planning, there are many nuances and best practices to be aware of. The Human Factor in System Reliability While procedures and mechanisms play a vital role in ensuring system reliability, it is ultimately the humans who bring them to life. So, it’s not just about having the right tools but also cultivating the right mindset to breathe life into those mechanisms and make them work effectively. Here are some of the key qualities and habits that contribute to maintaining reliability (and not only): Collaboration with other teams and organizations in order to share knowledge and work towards a common goal. A degree of humility and an open-minded approach to new information in order to adapt and evolve the system. A focus on simplicity and craftsmanship in order to create evolvable and maintainable systems. An action-driven and outcome-focused mindset, avoiding stagnation and indecision. A curious and experimental approach akin to that of a child, constantly seeking to understand how the system works and finding ways to improve it. Conclusion Ensuring reliability in a system is a comprehensive effort that involves figuring out the right metrics, designing with resilience in mind, and implementing reliability testing and operations. With a focus on availability, functionality, and serving the most important needs, organizations can better translate customer value and adjust risks and priorities accordingly. Building and maintaining a system that can handle even the toughest conditions not only helps drive business success and pleases customers but also brings a sense of accomplishment to those who work on it. Reliability is a continuous journey that requires attention, skill, and discipline. By following best practices, continuously challenging the system, and fostering a resilient mindset, teams, and organizations can create robust and reliable systems that can withstand any challenges that come their way.

Is self-management an essential building block on an organization’s path to business agility or a nice-to-have cultural twist to, for example, keep teams happy and attract new talent? While many people, particularly at the management level, are skeptical about the concept, I am convinced that organizations need to descale and regroup around aligned, autonomous, self-managing teams in a complex environment. Ultimately, only the people closest to the customers’ problems can solve those within the given constraints while contributing to an organization’s sustainability. Please continue reading and delve into the reasons that support self-management. The Top Ten Business Reasons To Embrace Self-Management Here are my top ten reasons why self-management is essential for developing new products in complex environments and addressing customer needs: Increased innovation: Self-management fosters a culture of creativity and experimentation. Team members are empowered to take risks, try new ideas, and learn from failures, leading to more innovative solutions for customers. Greater adaptability: In a complex environment, change is inevitable. Self-managed teams are more agile and can adapt to new situations, pivot their approach, and respond to customer needs more effectively than traditional hierarchical teams. Improved communication: Self-management promotes open and transparent communication within the team. Transparency ensures that information is shared effectively, leading to better collaboration and problem-solving. Empowerment and autonomy: Self-management empowers individuals and teams to make decisions and take responsibility for their work. This autonomy leads to higher job satisfaction and increased commitment to the organization’s goals. Moreover, it attracts talent from other organizations. Faster decision-making: Self-managed teams can make decisions quickly without waiting for approval from multiple levels of management, accelerating the development process and enabling more immediate responses to customer needs. Better problem-solving: Self-managed teams work close to customers and have a deeper understanding of their needs. This proximity enables them to identify and address problems more effectively than a management-driven approach. Resilience and risk mitigation: Self-managed teams are better equipped to identify and address potential risks early in development. This proactive approach to risk management helps build resilience and ensures more predictable outcomes. Continuous improvement: Self-managed teams focus on continuous learning, improving, refining processes, and iterating on products within the given constraints of the organization. This commitment to constant improvement ensures that products evolve to meet customer needs. Higher engagement: When team members own their work, they are more engaged and motivated. This ownership leads to increased productivity, better quality work, and a more substantial commitment to meeting customer needs. More efficient use of resources: By allowing team members to allocate their own time and prioritize tasks, self-managed teams can use resources better, improving productivity and reducing waste. Now that we have established the usefulness of self-management from a business perspective, the question is: how do we get there? (Spoiler alert: Your teams won’t become self-managing by contracting McBoston to roll out a new initiative.) Why the Change to Self-Management Cannot Be Outsourced While external consultancies may support your organization’s effort to become an agile organization due to their broad experience with other clients, real change can only come from within an organization. Any change effort needs to include people, give them a voice, and convince them that change is in their best interest: “Agile” cannot be pushed; it needs to be pulled. Consequently, avoid relying on external consultants. Instead, to foster self-management within the organization, consider the following suggestions: Redefine leadership roles: Shift the focus of management from controlling and directing to supporting and enabling teams. Managers should help remove obstacles and provide resources for self-managed teams to thrive. Managers need to move on from problem-solvers on behalf of their teams to become servant-leaders who strive to make their teams successful. Internal agile champions: Identify and empower individuals with experience or interest in agile practices. These internal champions can advocate for and drive the adoption of self-management practices across teams. Agile training and education: Invest in training and education for employees at all levels, including workshops, online courses, or even certifications, to help them better understand and apply agile principles and self-management practices. Coaching and mentoring: Encourage experienced agile practitioners to coach and mentor others, helping to create a culture of learning, sharing, and fostering the growth of self-managed teams. Foster a culture of trust and transparency: Encourage open communication and collaboration across all levels of the organization. Transparency will build trust among team members and empower them to take more ownership of their work. Regularly inspect and adapt: Conduct periodic Retrospectives and assessments to gauge the progress of self-management adoption. Use the insights gathered to inspect and adapt the approach, ensuring it aligns with the organization’s unique needs and culture. Incremental adoption: Start small by implementing self-management practices in a few pilot teams. Learn from their experiences and gradually expand self-management adoption to other teams as they become comfortable with the new approach. Encourage cross-functional teams: Form cross-functional teams that bring together individuals with diverse skills and backgrounds. This encourages collaboration and knowledge-sharing and fosters self-management. Provide the necessary tools: Equip teams with the tools and resources to collaborate, plan, and track their work effectively. This could include agile project management tools, communication platforms, and continuous integration and deployment systems. Celebrate successes and learn from failures: Recognize and celebrate the accomplishments of self-managed teams. At the same time, encourage a culture of learning from mistakes and iterating on processes to improve continually. By focusing on these strategies, an organization can foster self-management among its teams and embark on its journey to become agile. Conclusion Self-management is essential for developing new products in complex environments and addressing customer needs. By embracing self-management, organizations can foster innovation, adaptability, and a stronger customer focus, ultimately leading to better products and satisfied customers. Moreover, adopting self-management also offers tangible benefits to shareholders by increasing efficiency, promoting innovation, and enhancing adaptability, ultimately driving growth and success for the organization. What is your experience with self-managing teams? Please share with us in the comments.

My son is in seventh grade and appearing for his final exams. As part of the preparation, he wrote a pre-exam at home and asked me to review the paper. While going through it, I came across a topic that recharged my mind and reminded me of a science topic that we all studied in school. I immediately had a thought that connected this topic to one of the Agile principles I’m discussing in this article. Autotrophic nutrition is a topic in biology that describes the process by which an organism/plant prepares its own food from simple inorganic materials such as water, mineral salts, and carbon dioxide in the presence of Sunlight.” The term “autotrophic” is derived from the combination of two terms: “auto” (self) and “trophic” (nutrition). Likewise, Photosynthesis provides food to all living beings. During photosynthesis, water and carbon dioxide are used in the presence of sunlight to produce carbohydrates and oxygen. Oxygen, one of the main components of life on Earth, is released by plants during photosynthesis. Using this Autotrophic and Photosynthesis metaphor in Agile and aligning with one of the Agile principles that mention the concept of self-organization. “The Best Architectures, Requirements, and Designs Emerge From Self-Organizing Teams” Plants, as we know, require sufficient sunlight, water, and carbon dioxide to grow and produce oxygen for living things. Agile teams, in my opinion, should act like autotrophic organisms by self-managing the work, developing the necessary skills, and establishing the necessary tools to eventually deliver value in the presence of Agile. These are some of the characteristics that will enable Agile teams to self-organize. In line with the autotrophic and photosynthesis metaphor diagram, here are a few more details that will help Agile teams self-organize to create the best designs, architectures, and requirements. Sun is depicted as Agile in the diagram, and the plant is an Agile team. In the presence of Agile, teams should manage work by owning the project, maintaining flow, comprehending the entire end-to-end requirements, removing ambiguities, and clarifying queries through appropriate discussions and meetings. They should ascertain that the requirements contain sufficient information to begin design and development. It is extremely similar to a plant absorbing carbohydrates in the presence of sunlight. Absorb whatever one can by comprehending the ask of the customer. Create wireframes and business flows, and at the core, incorporate Design Thinking strategy to understand the need of the customer. Similarly, Agile teams must brainstorm to determine what skills are required within the team to develop the understood requirements and created tasks. The onus will be on Agile teams to create or identify the tools (TDD, BDD, Automation, DevOps tools, etc.) required to simplify their work while maintaining high quality. As we all know, plants produce oxygen by using water and carbon dioxide in the presence of sunlight; similarly, Agile teams will be able to deliver and release great products and solutions if they have the power to handle the work as well as the necessary skills and tools. An organization/management, on the other hand, can act as soil for Agile teams. So, what should an organization do to assist teams in becoming self-organized? Create a psychologically safe environment for them to act in, trust them in what they do, encourage participation, provide adequate support, and finally, be strong enough so that the teams can feel strong as well. I would like to encourage readers to leave any additional Co2 and H2O points in the comments that will enable Agile teams to self-organize in order to create O2 for customers.

Agile and Scrum are two related concepts that are often used in software development. Agile is an umbrella term encompassing a set of values and principles for software development, while Scrum is a specific framework within the Agile methodology. Agile emphasizes collaboration, flexibility, and adaptability, as well as the ability to respond to change. It emphasizes, In addition, iterative development and continuous improvement, where teams work in short cycles called sprints, with frequent feedback and re-evaluation. Scrum is a framework for implementing Agile methodology that provides a structure for managing and completing projects. It emphasizes teamwork, accountability, and iterative progress. Scrum involves a set of roles, ceremonies, and artifacts that help teams work together effectively, such as sprint planning, daily stand-ups, sprint reviews, and retrospectives. What Is Agile Methodology? Agile methodology is an exercise that helps continuous iteration of development and testing in the Software development life cycle process. Basically, Agile breaks the product into a few smaller builds. It also encourages teamwork and face-to-face communication. In agile methodology, Businesses, stakeholders, developers, and clients must work together to develop high-quality products. An agile methodology is an approach to project management that emphasizes flexibility, collaboration, and customer satisfaction. It is a set of values and principles prioritizing responding to change over following a rigid plan. What Is Scrum Methodology? Scrum is an Agile software development methodology that is commonly used in testing. It is an iterative and incremental approach to software development that focuses on delivering working software in short time frames, known as sprints. In Scrum, the testing process is integrated into the development process, with testers working collaboratively with developers, product owners, and other team members. The testing process is continuous throughout the development lifecycle, with tests being automated where possible and executed at every stage of development. Overall, the Scrum methodology emphasizes collaboration, communication, and continuous improvement, making it an effective approach to testing in software development. Difference Between Agile and Scrum Agile Scrum Agile development is based on iterative and incremental approaches. Scrum is the implementation of the agile process. In this process, after every two to three weeks, we deliver the incremental build to the customer. Agile software development has been widely used in small but expert project development teams. Scrum is generally used in that projects where the requirement is changing frequently. Compared to Scrum, agile methodology is a more rigid method, so we cannot change the requirement frequently. The important advantage of Scrum to use nowadays is its flexibility, as it quickly reacts to changes. The agile methodology involves participation and face-to-face interactions between the team members of various cross-functional teams. In Scrum, participation is cognizable in a daily stand-up meeting with a fixed role assigned to each team member. In Agile Methodology, we will Deliver and update the software daily. In Scrum, When the team is done with the current sprint activities, after that, we can plan the next sprint. In Agile methodology, there is a Project head who takes care of all the tasks related to the project. In Scrum, there is no team leader, so the entire team addresses the issues or problems related to the project. In Agile Design and execution should be kept simple and easy to understand. In Scrum methodology, design, and execution is innovative and experimental. Conclusion Agile and Scrum are two related concepts that have become popular in software development and project management. Agile is a philosophy that emphasizes flexibility, collaboration, and iterative development, while Scrum is a specific framework that puts these principles into practice. The Agile approach to software development and project management is designed to be responsive to change, with a focus on delivering value to the customer in short, iterative cycles. Scrum is a framework within the Agile methodology that provides a structured approach to managing and organizing teams to deliver projects in an Agile way. One of the key benefits of Agile and Scrum is that they allow teams to be more responsive to changes in project requirements and customer needs, as well as enable faster delivery of working software. This approach also encourages collaboration and communication among team members, leading to better outcomes and higher-quality work. Overall, Agile and Scrum have proven to be effective methodologies for managing complex projects, particularly in software development. However, as with any approach, their success depends on proper implementation and adaptation to the specific needs of each project and team.

TL; DR: Workshop Design With ChatGPT The following article explores whether we can use ChatGPT-4 to create workshops for agile practitioners; for example, Scrum Masters. While Liberating Structures have simplified the task, workshop design with ChatGPT may provide an alternative. As you will learn, and despite being prone to lapse into project management speak, ChatGPT is remarkably capable of doing so, provided we feed it suitable prompts. Whether this requirement gives ChatGPT an edge over manually creating workshops remains to be seen. Prompt Summary for Workshop Design With ChatGPT This is the sequence of prompts I used for the workshop design with ChatGPT: I want to create a workshop on using ChatGPT as a Scrum Master in real life. I want you to act as a class or workshop designer and apply your knowledge of Scrum, the agile manifesto, the duties of a scrum master, higher educational practices, and the organization of successful workshops to design an outline of how you would teach the application of ChatGPT for scrum practitioners. The workshop comprises lessons of at most 15 minutes each and has an overall length of 2 hours. I want you to create a schedule, name the exercises, and point to sources where I can learn more about the suggested activities. Can you be more specific regarding the exercises for lessons 4 to 7? Please suggest what kind of exercises best advance the respective lesson topic for the students. Please elaborate on the exercise of lesson 4: “ChatGPT Stand-up Simulator.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the exercise as a workshop facilitator. You designed the class around three Daily Scrum questions from the Scrum Guide 2017, which are no longer recommended. Can you rephrase the exercise without building it upon these three Daily Scrum questions? Please elaborate on the exercise of lesson 5: “ChatGPT for Sprint Planning.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the activity as a workshop facilitator. You are using a typical project management approach to planning. First, however, you shall design an exercise for a Scrum team. The Sprint Planning is a core event that defines how your customers’ lives will improve with the new product Increment. This is how Sprint Planning works for a Scrum team: (1) First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. (2) The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. (3) Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. (Alternatively, they create new work items.) (4) Also, the Developers need to create a preliminary “plan” on how to accomplish the Sprint Goal. Please redesign the “ChatGPT for Sprint Planning” exercise according to general agile principles and Scrum in particular. Please elaborate on the exercise of lesson 6: “ChatGPT for Sprint Review and Retrospective.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the activity as a workshop facilitator. The suggested time box of 15 minutes will not be sufficient to cover Sprint Review and Retrospective. Also, you should have provided the original Sprint Goal for the Sprint Review part to the work groups while you compare the Sprint outcome to it. Based on what information or data shall each group use ChatGPT to analyze their team’s performance during the Sprint? Reconsider your choices; velocity data or burndown charts without context do not hold any value. Let’s come back to the exercise on the Retrospective. I want you to consider Esther Derby’s and Diana Larsen’s five-stage model for Retrospective practice, comprising (1) setting the stage, (2) gathering data, (3) generating insights, (4) deciding what to do, and (5) closing the Retrospective. Lastly, please elaborate on the exercise of lesson 7: “Improving Scrum Master Communication with ChatGPT.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the activity as a workshop facilitator. Setting up the Workshop Design With ChatGPT Session I ran the session on ChatGPT on Sunday, April 2, 2023, from 6:10 am CET to 8:15 am CEST on the GPT-4 model after upgrading to ChatGPT Plus. I did not apply Grammarly to ChatGPT’s answers. Creating a Workshop on Using ChatGPT as a Scrum Master Basic Workshop Design With ChatGPT I used the following initial prompt to prime ChatGPT: Prompt 1: I want to create a workshop on using ChatGPT as a Scrum Master in real life. I want you to act as a class or workshop designer and apply your knowledge of Scrum, the agile manifesto, the duties of a Scrum Master, higher educational practices, and the organization of successful workshops to design an outline of how you would teach the application of ChatGPT for Scrum practitioners. The workshop comprises lessons of at most 15 minutes each and has an overall length of 2 hours. I want you to create a schedule, name the exercises, and point to sources where I can learn more about the suggested activities. ChatGPT: Title: Leveraging ChatGPT for Effective Scrum Mastery. Duration: 2 hours. Total Lessons: 8 Lesson; duration: 15 minutes each. Schedule: Introduction and Icebreaker (15 min) Understanding ChatGPT (15 min) Agile Manifesto and Scrum Overview (15 min) ChatGPT for Daily Stand-ups (15 min) ChatGPT for Sprint Planning (15 min) ChatGPT for Sprint Review and Retrospective (15 min) Improving Scrum Master Communication with ChatGPT (15 min) Wrap-up and Q&A (15 min). Lessons: Lesson 1: Introduction and Icebreaker: Brief introductions “Scrum Master Bingo” icebreaker activity. Source: https://www.agilesparks.com/resources/scrum-master-bingo-ice-breaker/. Lesson 2: Understanding ChatGPT: Overview of ChatGPT and its capabilities Key considerations for using ChatGPT as a Scrum Master. Source: https://openai.com/research/. Lesson 3: Agile Manifesto and Scrum Overview: Review of Agile Manifesto principles Source: https://agilemanifesto.org/ Scrum framework and Scrum Master responsibilities. Source: https://www.scrum.org/resources/what-is-scrum. Lesson 4: ChatGPT for Daily Stand-ups: Automating stand-up updates with ChatGPT Analyzing team progress with ChatGPT-generated insights Exercise: “ChatGPT Stand-up Simulator” Lesson 5: ChatGPT for Sprint Planning: Using ChatGPT to help with backlog refinement Assisting in sprint goal formulation with ChatGPT Exercise: “Backlog Refinement with ChatGPT.” Lesson 6: ChatGPT for Sprint Review and Retrospective: Generating sprint review summaries with ChatGPT Facilitating retrospective discussions using ChatGPT Exercise: “Retrospective Facilitation with ChatGPT.” Lesson 7: Improving Scrum Master Communication with ChatGPT: Crafting effective communication using ChatGPT Utilizing ChatGPT for conflict resolution and coaching Exercise: “Coaching Conversations with ChatGPT.” Lesson 8: Wrap-up and Q&A: Recap of workshop content Open Q&A session Closing remarks. Considerations: Remember that while ChatGPT is a powerful tool, it should be used to complement and enhance the Scrum Master’s role rather than replace human judgment and interaction. Encourage participants to use the workshop as an opportunity to explore how ChatGPT can improve their Scrum practice and facilitate more effective collaboration within their teams. Comment: I appreciate ChatGPT’s thoughtfulness regarding the human component of the challenge. Also, it summarized the purpose of the workshop design with ChatGPT session well. Adding Depth to Lessons 4-7 of the Workshop Design with ChatGPT Prompt 2: Can you be more specific regarding the exercises for lessons 4 to 7? Please suggest what kind of exercises best advance the respective lesson topic for the students. ChatGPT: Lesson 4: ChatGPT for Daily Stand-ups. Exercise : “ChatGPT Stand-up Simulator.” Goal: Participants learn how to use ChatGPT to automate stand-up updates and analyze team progress: Divide participants into small groups, each representing a fictional project team. Provide each group with a set of predefined stand-up updates (e. g., tasks completed, tasks in progress, blockers). Ask each group to input their updates into ChatGPT and generate a synthesized stand-up summary. Have groups share their summaries and discuss how ChatGPT helped identify patterns or trends in the updates. Lesson 5: ChatGPT for Sprint Planning. Exercise : “Backlog Refinement with ChatGPT.” Goal: Participants learn how to use ChatGPT to assist in backlog refinement and sprint goal formulation: Provide each group with a sample product backlog containing user stories, bugs, and technical tasks. Ask groups to use ChatGPT to prioritize the backlog items, taking into account dependencies and team capacity. Have participants generate sprint goals using ChatGPT based on the refined backlog. Invite groups to share their sprint goals and discuss the role of ChatGPT in the planning process. Lesson 6: ChatGPT for Sprint Review and Retrospective. Exercise : “Retrospective Facilitation with ChatGPT.” Goal: Participants learn to use ChatGPT for generating sprint review summaries and facilitating retrospective discussions: Provide each group with a fictional sprint review report containing completed work, sprint metrics, and stakeholder feedback. Ask groups to use ChatGPT to prioritize the backlog items, taking into account dependencies and team capacity. For the retrospective, provide each group with a set of fictional team member inputs (e.g., what went well, what didn’t, and suggested improvements). Instruct groups to use ChatGPT to identify common themes and generate retrospective discussion questions. Have groups share their summaries and retrospective questions, discussing how ChatGPT aided in the process. Lesson 7: Improving Scrum Master Communication with ChatGPT. Exercise : “Coaching Conversations with ChatGPT.” Goal: Participants learn to use ChatGPT for crafting effective communication, conflict resolution, and coaching: Present participants with a set of common Scrum Master communication scenarios (e.g., addressing a team conflict, coaching a team member on Agile principles, or explaining a complex concept). Ask participants to use ChatGPT to craft responses or talking points for each scenario. In their groups, have participants role-play the scenarios using the ChatGPT-generated responses. Bring the groups together for a debrief to discuss the effectiveness of ChatGPT in facilitating clear and impactful communication. Comment: The answer comprises much project management speak, false assumptions (“automate stand-up updates”), and words not used in a Scrum context, like “stand-up.” Nevertheless, it is a start. So let’s dig deeper into lessons four to seven to move the workshop design with ChatGPT beyond a bullet point-style draft. Elaborating on Lesson 4 Prompt 3: Please elaborate on the exercise of lesson 4: “ChatGPT Stand-up Simulator.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the exercise as a workshop facilitator. ChatGPT: Exercise Title: ChatGPT Stand-up Simulator. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to automate daily stand-up updates, analyze team progress, and identify trends or potential issues within their Scrum team. The desired outcome is for participants to gain practical experience in using ChatGPT to streamline stand-ups and improve team communication. Duration: 15 minutes. Materials: Predefined stand-up updates for each group (include tasks completed, tasks in progress, and blockers) Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people, each representing a fictional project team. Provide each group with a set of predefined stand-up updates for each team member. These updates should include the following information for each member: Tasks completed since the last stand-up Tasks currently in progress Any blockers or impediments Instruct each group to input their updates into ChatGPT, using a specific format or template for consistency. For example: “Yesterday, I completed Task A and started Task B. Today, I will continue working on Task B and aim to finish it. I have no blockers.” Ask each group to use ChatGPT to generate a synthesized stand-up summary based on the team members’ updates. This summary should identify patterns or trends in the updates, such as common blockers, progress toward sprint goals, and potential risks. Once the groups have generated their stand-up summaries, invite them to share their results with the rest of the workshop participants. Encourage discussion around how ChatGPT helped identify patterns or trends in the updates and how this could benefit their Scrum teams. As a facilitator, guide the discussion and address any questions or concerns participants may have about using ChatGPT in their daily stand-ups. Provide examples of how ChatGPT can save time, improve communication, and uncover hidden issues within the team. Takeaways Participants should understand the benefits of using ChatGPT to automate and analyze stand-up updates, such as improved efficiency, communication, and issue detection. Participants should gain hands-on experience in using ChatGPT for stand-ups, giving them confidence to integrate it into their Scrum teams’ practices. Participants should learn how to format stand-up updates consistently for optimal results with ChatGPT and how to interpret the generated summaries for actionable insights. Comment: “Streamline,” “automate,” and the three questions from the Scrum Guide 2017: This suggestion for lesson #4 mimics a classic report status. Let’s address one of the issues: three Daily Scrum questions from the Scrum Guide 2017 for the next workshop design with ChatGPT prompt. Eliminating Scrum Guide 2017 Practices Prompt 4: You designed the class around three Daily Scrum questions from the Scrum Guide 2017, which are no longer recommended. Can you rephrase the exercise without building it upon these three Daily Scrum questions? ChatGPT: Exercise Title: ChatGPT Stand-up Enhancer. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to facilitate daily stand-ups and improve team communication. Participants will learn how to extract valuable insights from team updates, identify trends or potential issues, and streamline the stand-up process. The desired outcome is for participants to gain practical experience in using ChatGPT to enhance their Scrum team’s daily stand-ups. Duration: 15 minutes. Materials: Predefined stand-up updates for each group (include various aspects of ongoing work and potential challenges) Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people, each representing a fictional project team. Provide each group with a set of predefined stand-up updates for each team member. These updates should cover various aspects of their ongoing work, such as progress on tasks, collaboration with other team members, and any challenges or concerns they might be facing. Instruct each group to input their updates into ChatGPT, using a concise and clear format that captures the essence of each team member’s progress and challenges. Encourage participants to focus on the most important and relevant information for the stand-up. Ask each group to use ChatGPT to generate a synthesized stand-up summary based on the team members’ updates. This summary should identify patterns, trends, or potential issues within the team, such as recurring challenges, dependencies between tasks, or areas where the team may need additional support. Once the groups have generated their stand-up summaries, invite them to share their results with the rest of the workshop participants. Encourage discussion around how ChatGPT helped identify patterns, trends, or issues in the updates and how this could benefit their Scrum teams. As a facilitator, guide the discussion and address any questions or concerns participants may have about using ChatGPT in their daily stand-ups. Provide examples of how ChatGPT can save time, improve communication, and uncover hidden issues within the team. Takeaways Participants should understand the benefits of using ChatGPT to automate and analyze stand-up updates, such as improved efficiency, communication, and issue detection. Participants should gain hands-on experience in using ChatGPT for stand-ups, giving them confidence to integrate it into their Scrum teams’ practices. Participants should learn how to present stand-up updates effectively for ChatGPT processing and how to interpret the generated summaries for actionable insights. Comment: While I am still uncomfortable with the idea of “using ChatGPT to automate and analyze stand-up updates,” ChatGPT’s suggestion will help to understand how ChatGPT might be helpful to Scrum practitioners. Elaborating on Lesson 5 of the Workshop Design with ChatGPT Prompt 5: Please elaborate on the exercise of lesson 5: “ChatGPT for Sprint Planning.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the activity as a workshop facilitator. ChatGPT: Exercise Title: ChatGPT for Sprint Planning. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to assist with sprint planning by generating task breakdowns, estimating effort, and identifying dependencies or potential risks. The desired outcome is for participants to gain practical experience in using ChatGPT to enhance the sprint planning process and improve overall team efficiency. Duration: 15 minutes. Materials: Predefined project goals or user stories for each group Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people, each representing a fictional project team. Provide each group with a set of predefined project goals or user stories that they will be working on during the sprint. Instruct each group to input their project goals or user stories into ChatGPT, asking it to generate a list of tasks or subtasks necessary to achieve the goal or complete the user story. Next, have each group use ChatGPT to estimate the effort required for each task or subtask, either in terms of story points or hours. Encourage participants to compare ChatGPT’s estimations with their own to evaluate its accuracy and usefulness. Ask each group to use ChatGPT to identify any dependencies or potential risks associated with the tasks. This could include dependencies between tasks, potential bottlenecks, or external factors that might impact the sprint’s progress. Once the groups have completed their sprint planning with the help of ChatGPT, invite them to share their results with the rest of the workshop participants. Encourage discussion around how ChatGPT contributed to the planning process, and whether it helped the team make more informed decisions. As a facilitator, guide the discussion and address any questions or concerns participants may have about using ChatGPT in their sprint planning. Provide examples of how ChatGPT can save time, improve planning accuracy, and help the team uncover hidden dependencies or risks. Takeaways Participants should understand the benefits of using ChatGPT to assist with sprint planning, such as increased efficiency, better-informed decisions, and improved risk management. Participants should gain hands-on experience in using ChatGPT for sprint planning, giving them confidence to integrate it into their Scrum teams’ practices. Participants should learn how to effectively use ChatGPT to generate task breakdowns, estimate effort, and identify dependencies or risks within their sprint planning process. Comment: Once again, ChatGPT is falling for a project management approach to a Scrum event. Consequently, the LLM does not “recall” what it learned about Sprint Planning. That will require providing a more detailed follow-up prompt. Overcoming the Project Management Approach to Sprint Planning Prompt 6: You are using a typical project management approach to planning. First, however, you shall design an exercise for a Scrum team. The Sprint Planning is a core event that defines how your customers’ lives will improve with the new product Increment. This is how Sprint Planning works for a Scrum team: First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. (Alternatively, they create new work items.) Also, the Developers need to create a preliminary “plan” on how to accomplish the Sprint Goal. Please redesign the “ChatGPT for Sprint Planning” exercise according to general agile principles and Scrum in particular. ChatGPT: Exercise Title: ChatGPT-Assisted Sprint Planning. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to facilitate the Sprint Planning process in Scrum, enhancing collaboration, refining the Sprint Goal, and supporting the creation of the Sprint Backlog. The desired outcome is for participants to gain practical experience in using ChatGPT to improve the Sprint Planning process and strengthen the alignment between the Product Goal, Sprint Goal, and Sprint Backlog. Duration: 15 minutes. Materials: Predefined Product Goal and business objective for each group Predefined Product Backlog items for each group Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people, each representing a fictional Scrum Team. Provide each group with a predefined Product Goal and a business objective for the upcoming Sprint. Instruct each group to use ChatGPT to brainstorm and refine a Sprint Goal based on the provided Product Goal and business objective. Encourage participants to explore various options and consider the availability of team members and the target they want to accomplish. Once the groups have established their Sprint Goals, have them use ChatGPT to help forecast the work required to achieve the Sprint Goal. The Developers in each group should select the most relevant Product Backlog items or create new ones, forming a Sprint Backlog. Ask each group to use ChatGPT to generate a preliminary plan on how to accomplish the Sprint Goal. This plan should outline the proposed sequence of tasks and any dependencies or risks that might affect the Sprint’s progress. After the groups have completed their ChatGPT-assisted Sprint Planning, invite them to share their results with the rest of the workshop participants. Encourage discussion around how ChatGPT contributed to the process and whether it helped the teams establish better-aligned Sprint Goals and Sprint Backlogs. As a facilitator, guide the discussion and address any questions or concerns participants may have about using ChatGPT in their Sprint Planning. Provide examples of how ChatGPT can foster collaboration, improve alignment with the Product Goal, and support the development of realistic and actionable plans. Takeaways Participants should understand the benefits of using ChatGPT to facilitate Sprint Planning in Scrum, such as enhanced collaboration, improved alignment with Product and Sprint Goals, and more effective Sprint Backlog creation. Participants should gain hands-on experience in using ChatGPT for Sprint Planning, giving them confidence to integrate it into their Scrum teams’ practices. Participants should learn how to effectively use ChatGPT to refine Sprint Goals, forecast work, and create actionable plans for achieving their Sprint Goals. Comment: Garbage in, garbage out applies to workshop design with ChatGPT, too. The specific second prompt delivered a much better-suited exercise on how to use ChatGPT for Sprint Planning. (PS: An estimation of the workload using ChatGPT? I’m curious about that!) Elaborating on Lesson 6 Prompt 7: Please elaborate on the exercise of lesson 6: “ChatGPT for Sprint Review and Retrospective.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the activity as a workshop facilitator. ChatGPT: Exercise Title: ChatGPT for Sprint Review and Retrospective. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to facilitate Sprint Reviews and Retrospectives, enabling them to efficiently analyze team performance, identify areas for improvement, and gather insights for future sprints. The desired outcome is for participants to gain practical experience in using ChatGPT to improve these Scrum events and support continuous improvement within their teams. Duration: 15 minutes. Materials: Predefined Sprint data (completed and incomplete Product Backlog items, feedback from stakeholders, etc.) Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people, each representing a fictional Scrum Team. Provide each group with predefined Sprint data, including completed and incomplete Product Backlog items, feedback from stakeholders, and any other relevant information. Sprint Review: Instruct each group to use ChatGPT to generate a summary of the Sprint’s outcomes, including the completed Product Backlog items and their impact on the Product Goal. Encourage participants to consider stakeholder feedback and evaluate the team’s overall progress. Have each group use ChatGPT to identify areas where the team can improve their product and process, based on the Sprint outcomes and stakeholder feedback. Sprint Retrospective: Ask each group to use ChatGPT to analyze their team’s performance during the Sprint. Encourage participants to identify strengths, weaknesses, and areas for improvement in their teamwork and processes. With ChatGPT’s help, have each group brainstorm potential action items to address the identified improvement areas. Encourage participants to prioritize the action items based on their potential impact on the […] Comment: Here, ChatGPT stopped generating the answer; regenerating the response did not help either. Anyway, the suggested time boxes are insufficient, so let’s move on with a follow-up prompt to address this issue. (Granted, ChatGPT sticks to the original prompt.) Adjusting Time Boxes Prompt 8: The suggested time box of 15 minutes will not be sufficient to cover Sprint Review and Retrospective. Also, you should have provided the original Sprint Goal for the Sprint Review part to the work groups while you compare the Sprint outcome to it. ChatGPT: You’re right, it would be more appropriate to allocate more time for this exercise and provide the original Sprint Goal. Here’s an updated version of the exercise: Exercise Title: ChatGPT for Sprint Review and Retrospective. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to facilitate Sprint Reviews and Retrospectives, enabling them to efficiently analyze team performance, identify areas for improvement, and gather insights for future sprints. The desired outcome is for participants to gain practical experience in using ChatGPT to improve these Scrum events and support continuous improvement within their teams. Duration: 30 minutes. Materials: Predefined Sprint data (completed and incomplete Product Backlog items, feedback from stakeholders, original Sprint Goal, etc.) Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people, each representing a fictional Scrum Team. Provide each group with predefined Sprint data, including completed and incomplete Product Backlog items, feedback from stakeholders, the original Sprint Goal, and any other relevant information. Sprint Review (15 minutes): Instruct each group to use ChatGPT to generate a summary of the Sprint’s outcomes, comparing the completed Product Backlog items to the original Sprint Goal. Encourage participants to consider stakeholder feedback and evaluate the team’s overall progress. Have each group use ChatGPT to identify areas where the team can improve their product and process, based on the Sprint outcomes and stakeholder feedback. Sprint Retrospective (15 minutes): Ask each group to use ChatGPT to analyze their team’s performance during the Sprint. Encourage participants to identify strengths, weaknesses, and areas for improvement in their teamwork and processes. With ChatGPT’s help, have each group brainstorm potential action items to address the identified improvement areas. Encourage participants to prioritize the action items based on their potential impact on the team’s performance and effectiveness. Takeaways Participants should understand the benefits of using ChatGPT to facilitate Sprint Reviews and Retrospectives, such as streamlining the evaluation of the team’s performance, identifying improvement areas, and generating actionable insights for continuous improvement. Participants should gain hands-on experience in using ChatGPT for Sprint Reviews and Retrospectives, giving them confidence to integrate it into their Scrum teams’ practices. Participants should learn how to effectively use ChatGPT to analyze Sprint outcomes, gather stakeholder feedback, and generate data-driven action items for team improvement during the Sprint Retrospective. Comment: Let’s delve into the topic of team performance with a follow-up prompt. The Team Performance Issue Prompt 9: Based on what information or data shall each group use ChatGPT to analyze their team’s performance during the Sprint? ChatGPT: Apologies for the oversight. To provide a more realistic context for the exercise, you can supply the groups with predefined Sprint performance data. Here’s an updated version of the instruction step for the Sprint Retrospective part: Provide each group with predefined Sprint performance data, including metrics such as team velocity, burndown charts, lead time, cycle time, and any notable incidents or challenges that arose during the Sprint. Ask each group to use ChatGPT to analyze their team’s performance during the Sprint, inputting the provided data. Encourage participants to identify strengths, weaknesses, and areas for improvement in their teamwork and processes based on the analysis. This additional information will give participants a more comprehensive understanding of their fictional team’s performance during the Sprint, helping them to better utilize ChatGPT for the Sprint Retrospective exercise. Comment: While lead time and cycle time are helpful team metrics, velocity and burndown charts may be useless. Velocity, Burndown Charts? Prompt 10: Reconsider your choices; velocity data or burndown charts without context do not hold any value. ChatGPT: You are right. I apologize for the confusion. Instead of providing velocity data or burndown charts, we can supply qualitative data that is more relevant to the Sprint Retrospective. Here’s an updated version of the instruction step for the Sprint Retrospective part: Provide each group with qualitative Sprint performance data, including anecdotal feedback from team members about their experiences during the Sprint, any challenges or obstacles they faced, successful practices they employed, and examples of collaboration or communication issues. Ask each group to use ChatGPT to analyze their team’s performance during the Sprint, inputting the provided qualitative data. Encourage participants to identify strengths, weaknesses, and areas for improvement in their teamwork and processes based on the analysis. By providing qualitative data, participants can engage in a more meaningful analysis of their fictional team’s performance during the Sprint, which will better support their use of ChatGPT for the Sprint Retrospective exercise. Comment: Much better! Now let’s address the format of the Retrospective exercise. Applying Esther Derby’s and Diana Larsen’s Five-Stage Model Prompt 11: Let’s come back to the exercise on the Retrospective. I want you to consider Esther Derby’s and Diana Larsen’s five-stage model for Retrospective practice, comprising (1) setting the stage, (2) gathering data, (3) generating insights, (4) deciding what to do, and (5) closing the Retrospective. ChatGPT: Exercise Title: ChatGPT for Sprint Retrospective Objective: The purpose of this exercise is to teach participants how to use ChatGPT to facilitate the five-stage model of Retrospectives, ultimately enabling more effective and efficient reflection and continuous improvement within their Scrum teams. Duration: 15 minutes Materials: Access to ChatGPT (laptops or tablets for each group) A fictional Sprint scenario with qualitative data (e.g., team experiences, challenges faced, successes, and collaboration or communication issues) Flipcharts or whiteboards for each group Sticky notes and markers Instructions: Divide participants into small groups of 3-4 people. Provide each group with a fictional Sprint scenario and qualitative data related to the team’s performance during the Sprint. Instruct each group to use ChatGPT to facilitate the five-stage Retrospective process: Stage 1: Setting the stage: Have each group use ChatGPT to generate an icebreaker or a focus question to set the stage for the Retrospective and create a safe space for open discussion. Stage 2: Gathering data: Ask each group to review the provided qualitative data and use ChatGPT to help categorize and visualize the information in a meaningful way. Stage 3: Generating insights: Encourage each group to use ChatGPT to analyze the categorized data and generate insights on potential patterns, strengths, weaknesses, and areas for improvement. Stage 4: Deciding what to do: Have each group use ChatGPT to generate a list of possible actions or improvements based on the insights gathered. They should then prioritize and select the most impactful and feasible actions. Stage 5: Closing the Retrospective: Instruct each group to use ChatGPT to create a summary of their Retrospective, including the selected actions and any follow-up steps. Have each group share their Retrospective outcomes and experiences using ChatGPT with the rest of the workshop participants. Encourage a discussion around the effectiveness of using ChatGPT in facilitating the Retrospective process. Takeaways Participants should understand the potential of ChatGPT in facilitating the five-stage Retrospective process for more effective and efficient reflection and continuous improvement. Participants should gain hands-on experience in using ChatGPT throughout the different stages of the Retrospective process. Participants should recognize the importance of integrating AI tools like ChatGPT in their Scrum practices to enhance collaboration and decision-making. Comment: The revised Retrospective exercise is my favorite from this workshop design with ChatGPT session. Elaborating on Lesson 7 Prompt 12: Please elaborate on the exercise of lesson 7: “Improving Scrum Master Communication with ChatGPT.” Prepare a detailed description of the exercise, its purpose, the desired outcome, what lessons students will learn, and how to practice the activity as a workshop facilitator. ChatGPT: Exercise Title: Improving Scrum Master Communication with ChatGPT. Objective: The purpose of this exercise is to teach participants how to use ChatGPT to enhance their communication skills as Scrum Masters, enabling them to more effectively convey information, address challenges, and facilitate team collaboration. The desired outcome is for participants to gain practical experience in using ChatGPT to improve their communication abilities, equipping them to better support their Scrum teams. Duration: 15 minutes. Materials: Predefined communication scenarios (e.g., addressing team conflicts, providing feedback, updating stakeholders, etc.) Access to ChatGPT (laptops or tablets for each group) Projector or screen for sharing results Instructions: Divide participants into small groups of 3-4 people. Provide each group with a set of predefined communication scenarios that a Scrum Master might encounter. Examples include addressing team conflicts, providing feedback to team members, updating stakeholders on Sprint progress, and facilitating collaborative decision-making. Instruct each group to choose one or more communication scenarios and use ChatGPT to generate sample messages, emails, or conversation starters that address the selected scenarios. Encourage participants to explore different communication styles and tones while focusing on clarity, empathy, and effectiveness. Have each group share their generated communication samples with the rest of the workshop participants. Encourage discussion around the effectiveness of the ChatGPT-generated content and how it might impact team dynamics and collaboration. As a facilitator, guide the discussion and address any questions or concerns participants may have about using ChatGPT in their Scrum Master communications. Share best practices and tips for crafting effective messages with ChatGPT, and encourage participants to consider how they can apply these learnings in their own Scrum Master roles. Takeaways Participants should recognize the potential of ChatGPT to support their communication as Scrum Masters, helping them convey information more effectively, address challenges, and foster collaboration within their teams. Participants should gain hands-on experience in using ChatGPT for various communication scenarios, enabling them to feel more confident in leveraging the tool for their Scrum Master responsibilities. Participants should learn to critically evaluate the effectiveness of ChatGPT-generated content and how it might influence team dynamics, allowing them to refine their communication strategies for improved outcomes in their Scrum teams. Comment: This one is to complete all four original workshop design with ChatGPT lessons. Given that ChatGPT is good at dealing with communication-related tasks, see previous articles below, I leave it to you to go deeper on this one. My respect for staying with me until now! Conclusion A workshop design with ChatGPT can be an alternative to other practices; for example, Liberating Structures. As always with LLMs, prompt engineering requires most of the workshop creator’s attention. The question if this is a time-saving investment needs to be answered individually. On the positive side, ChatGPT also can deliver new perspectives on how to create workshops. What is your experience with workshop design with ChatGPT? Please share it with us in the comments.

Value streams have been a central tenet of Lean thinking for decades, starting with Toyota and the Lean Manufacturing movement, and are now widely adopted across industries. Despite this, many businesses still need to harness the full potential of value streams to drive organizational change and achieve greater efficiency and effectiveness. Instead, they may focus narrowly on metrics like team velocity or production pipeline speed, missing the broader picture of the end-to-end system. In modern product development, understanding value streams is crucial to optimizing our ways of working and delivering value to customers. By mapping the path to value, we can gain visibility into our processes and identify improvement areas, such as code deployment bottlenecks or mismatches between personnel and roles. In this blog, we will explore the concept of value stream mapping and its role in actualizing the purpose of DevOps transitions. We'll debunk common myths and misunderstandings around value stream mapping and introduce principles to help you succeed in this activity and beyond. Whether you're a seasoned DevOps practitioner or just starting on your journey, you will want to take advantage of this opportunity to unlock the holy grail of Agile-DevOps value stream hunting. What Is Value Steaming, and Why the Path to Value Streaming Is Quintessential for Your Agile-DevOps Journey? Value stream mapping is the process of analyzing and improving the flow of value to customers by mapping out the end-to-end process, from idea to delivery. Understanding value streams and mapping the path to value streaming is essential for any Agile-DevOps journey. Consider a software development team struggling to deliver value to customers efficiently in real-life scenarios. They may focus on completing tasks and meeting deadlines but only take a holistic view of the entire process. Through value stream mapping, they can identify bottlenecks in the development process, such as long wait times for testing or approval processes, and adjust and streamline the flow of value to customers. Value stream mapping is quintessential to an Agile-DevOps journey because it helps teams understand how their work fits into the larger picture of delivering value to customers. By mapping out the entire process, teams can see where delays occur, where handoffs are inefficient, and where there is room for improvement. Consider a DevOps team struggling to smoothly integrate code changes into the production environment. Through value stream mapping, they may discover that their testing process could be more time-consuming or that there are too many manual steps in the deployment process. By identifying these inefficiencies, they can automate testing and deployment, leading to faster value delivery to customers. By taking a holistic view of the entire process, teams can identify inefficiencies, reduce waste, and deliver customer value more efficiently and effectively. Value stream mapping helps organizations identify and eliminate inefficiencies in their processes, leading to the faster, more efficient delivery of value to customers. Following are some more examples: A financial services company wants to improve the time it takes to process customer loan applications. Through value stream mapping, they discover that there are long wait times between different departments and multiple handoffs that slow down the process. By identifying these inefficiencies, they can redesign the operation to eliminate unnecessary steps and reduce wait times, resulting in faster loan processing and improved customer satisfaction. A healthcare organization wants to improve patient care by reducing the time it takes for lab results to be processed and returned to the doctor. Through value stream mapping, they discover that there are too many manual steps in the lab testing process and bottlenecks in the information flow between departments. By redesigning the process to automate testing and improve communication, they can reduce the time it takes to process lab results, leading to faster patient diagnosis and treatment. A software development company wants to improve the quality of its code releases. Through value stream mapping, they discover that multiple handoffs between development, testing, and operations teams lead to errors and delays. By redesigning the process to automate testing and improve communication between teams, they can reduce the time it takes to identify and fix bugs, resulting in higher-quality code releases and happier customers. Embarking a Lightweight Quest to Value Stream Mapping for Agile-DevOps Teams A lightweight approach to value stream mapping can help Agile-DevOps teams to streamline their processes, improve efficiency, and deliver value to their customers more quickly. By avoiding unnecessary complexity and focusing on the most critical areas of the process, teams can achieve success and stay competitive in today's fast-paced business environment. A lightweight approach means using simple tools and methods to map out your processes instead of getting bogged down in complex and time-consuming activities. This approach can be particularly beneficial for Agile-DevOps teams, often focused on delivering value quickly and efficiently. By taking a lightweight approach, teams can focus on identifying the most critical areas of the process that need improvement and acting quickly to address them. A lightweight approach also allows for greater flexibility and agility, which is essential in the fast-paced world of Agile-DevOps. Teams can quickly adapt and adjust their value stream mapping activities as needed to stay aligned with their goals and objectives. Busting the Myths and Misconceptions: The Truth About Value Streams and Value Stream Mapping Some common myths and misconceptions about value streams and value stream mapping include the idea that they are only relevant to manufacturing or physical products, that they are too complex and time-consuming to implement, or that they are only helpful for large organizations. However, the truth is that value streams and value stream mapping can be applied to any industry or process, regardless of its size or complexity. Instead, they provide a holistic view of the end-to-end process, allowing teams to identify and address bottlenecks, reduce waste, and improve efficiency. Another misconception is that value stream mapping is a one-time activity, but in reality, it should be an ongoing process that evolves with the organization's needs and goals. It's also optional to completely understand all the processes upfront. It's perfectly acceptable to start with a smaller scope and build on that as needed. By busting these myths and misconceptions, teams can better understand the actual value of value stream mapping and how it can be a valuable tool in their Agile-DevOps journey. They can avoid unnecessary complexity and focus on the critical areas of the process that need improvement. Ultimately, this will lead to a more efficient and effective operation and better customer value delivery. Unlocking Business Excellence: Maximize the Benefits of Agile-DevOps Value Stream Mapping Using 8 Lean Principles If you want to take your Agile-DevOps team to the next level, then unlocking business excellence with Agile-DevOps value stream mapping and eight Lean principles is the way to go. Value stream mapping (VSM) is a Lean tool that visually represents the process steps required to deliver value to customers. The VSM process identifies bottlenecks, waste, and opportunities for improvement in the value stream. In addition, it helps Agile-DevOps teams to focus on value-added activities and eliminate non-value-added activities, resulting in reduced lead time, improved quality, and increased customer satisfaction. To maximize the benefits of VSM, Agile-DevOps teams should follow eight Lean principles. These principles are: Define value from the customer's perspective: Identity what your customers consider valuable and focus your efforts on delivering that value. Map the value stream: Create a visual representation of the entire value stream, from idea to delivery, to identify inefficiencies and opportunities for improvement. Create flow: Eliminate waste and create a smooth workflow through the value stream to improve delivery time. Implement pull: Use customer demand to drive work and avoid overproduction. Seek perfection: Continuously improve the value stream to eliminate waste and improve efficiency. Empower the team: Provide your Agile-DevOps team with the tools, resources, and authority they need to succeed. Practice Lean leadership: Create a culture of continuous improvement and empower your team to drive change. Respect people: Treat your team members respectfully and create a positive work environment encouraging collaboration and innovation. By implementing these eight Lean principles, Agile-DevOps teams can unlock business excellence and deliver superior customer value. Deploying the Power of Principles: Succeeding in Value Stream Mapping in a Lightweight Way and the Horizons Beyond By embracing a lightweight approach and deploying the power of Lean principles, organizations can succeed in value stream mapping and achieve business excellence. The lightweight approach enables organizations to identify areas that need improvement, break down silos, and facilitate collaboration across teams, thus unlocking the true potential of value stream mapping. It also helps organizations to sustain their efforts and continue to make improvements in the long run. By embracing the eight Lean principles, organizations can achieve business excellence by continuously improving their value stream and delivering value to their customers. These principles include creating customer value, mapping the value stream, establishing flow, implementing pull, seeking perfection, embracing scientific thinking, empowering teams, and respecting people. So, if you're looking to unlock the true potential of your Agile-DevOps transition, take advantage of value stream mapping. Don't wait; take the first step towards success, start your value stream mapping (VSM) journey today, and take your Agile-DevOps team to the next level!

I think that probably most development teams describe themselves as being “agile” and probably most development teams have standups, and meetings called retrospectives. There is also a lot of discussion about “agile,” much written about “agile,” and there are many presentations about “agile.” A question that is often asked is, what comes after “agile?” Many testers work in “agile” teams, so this question matters to us. Before we can consider what comes after agile, we need to consider what agile is — an iterative, incremental development methodology. Agile teams develop software in iterations and each iteration makes an increment toward the team’s goal. An agile team can decide, after an iteration or two, that the goal they are working towards should be changed and start to work on a new goal. Working iteratively makes the team agile as it can change direction quickly and easily. There are several agile methodologies and one of the most widely used methodologies is scrum. What Is Agile? When thinking about how to define what agile is we tend to be drawn to the Agile Manifesto which was created in 2001, but there were agile ways of working before the “Agile Manifesto.” The earliest Iterative and incremental development I found was at Bell Telephone labs in the 1930s. Walter Shewhart was an engineer at Bell Telephone Labs In his lectures in the 1930s, he introduced the concept of a straight-line, three-step scientific process of specification, production, and inspection. He went on to revise this idea into a cycle. The creation of this cycle has been described as part of the evolution of the scientific method and it became known as the Shewhart Cycle. The cycle is shown in the diagram below: The cycle is sometimes known as the Plan-Do-Study-Act-Cycle. A team using the Shewhart Cycle will Plan a change or test. The team will then Do, which means to carry out the change or test. Then the team will Study the results of the change or test to consider what they have learned before Acting on what they have learned. The team will then repeat the cycle and move onward. W. Edwards Deming said that the cycle is a helpful procedure to follow for the improvement of anything in production stage. He also said that at the end of a cycle the team might tear up the work that they had done previously and start again with fresh ideas and that doing this was “a sign of advancement.” Deming said the reason to study was to “try to learn how to improve tomorrow’s product.” Sometimes the Deming Cycle is referred to as the Plan Do Check Act. Deming did not like replacing the word study with the word check as studying is an important part of the cycle. He felt that the word check was inaccurate because it meant to “hold back.” The Shewhart Cycle was included by Deming in his lectures to senior management in Japan in 1950, and the cycle went into use in Japan as the Deming Cycle. What Is the Deming Cycle? The Deming Cycle has also been described as the Deming Wheel, as it just rolls on without a beginning or an end. All four parts of the Deming Cycle can be drawn inside a circle as below. This means that the four parts of the cycle are related to one another and that there is no hierarchy, as can be seen in the diagram below: Scrum is one of the most widely used agile methodologies, and Jeff Sutherland, one of the co-creators of scrum, has written that the Deming Cycle is how scrum development is done. He also says that retrospectives are the “check” part of the “Plan-Do-Check-Act cycle,” and says that it is important to get the team to change and improve their process by moving on to the act part of the cycle. It is useful for software testers that retrospectives were designed to be used in this way as we want to help the teams we work with to improve quality. Testers can use retrospectives to raise issues that help to improve quality. Sutherland says that he trains people to use Scrum by asking them to use the Deming Cycle to build paper airplanes and that by the third iteration they are making much better paper airplanes. The Deming Cycle is the heart of agile as it is a cycle that enables teams to change and improve quickly. The cycle enables change to be made at each iteration of the cycle. However, is this how agile is understood? Do we sometimes work in teams that describe themselves as “agile” but do not use The Deming Cycle? Is “agile” sometimes described through its ceremonies rather than through using the Cycle? Are teams using “agile” for continual improvement as Deming and Sutherland recommended? New ideas, such as Jobs to be Done, continue to be influenced by the Deming Cycle. Alan Klement describes the system of progress in Jobs to be Done as a cycle and says that his cycle is not an original idea as it comes from the Deming Cycle. Lean has also been influenced by the Deming Cycle. Lean is an American description of Japanese production systems and comes from a study by MIT. The Toyota Production System was of special interest in the study. Deming worked in Japan after World War Two where he helped to rebuild the Japanese economy. Jeffrey K. Liker says that “the Deming cycle embodies the learning cycle in the Toyota Production System.“ Teams, and testers, can develop their understanding of the cycle by reading the books in the references below, by using the resources of the Deming Institute, and by using the Deming Cycle. Teams can learn to use the cycle by planning an initiative, then carrying out the planned work or test, then studying the result of their work, and then acting on what they learned before repeating the cycle. Testers can help their teams to gain an understanding of the Deming Cycle by using plan-do-study-act for testing. When we test we plan the test, for example, we write a testing charter, then perform software testing, then we study the result of the test, and then act on the result as shown in the diagram below: Teams should not be put off by the Deming Cycle creating a new structure for their team. The Deming Cycle creates a new structure for a team because a team using the Deming Cycle must plan first, then do the work or test that they have planned, then study the effect of the work or test, and then act on what the team has learned. Using the Deming Cycle can sound demanding as it places a new structure on the team. However, all teams have structures that place constraints on them. If a team always has its planning meeting on a certain day of the week this practice places a constraint on the team. How often a team releases its work also puts a constraint on the team. If a team releases once a month then that monthly release will force the team to work towards that release. If a team releases many times a day with continuous delivery then that will create a different constraint for the team. All teams want to improve how they work and improve their product, and they will find that using the Deming Cycle will help them to improve their processes and product. Undoubtedly, there will be something after “agile.” It will have a new name, and I guess it will have to have new “ceremonies.” However, will the Deming Cycle be replaced by what replaces agile? The Deming Cycle is a profound philosophical insight that has been used by engineering teams to improve quality for nearly one hundred years and is continuing to influence new ideas. It seems unlikely that the Deming Cycle will be replaced by what comes after agile because it was so innovative, so useful, and is still being used after so many years. It would be great if the new way of working that comes after agile created a deeper understanding of the Deming Cycle, as this would help teams to learn, improve how they work, and improve the products they make.

An architecture spike in agile methodologies usually implies a software development method, which originates in the extreme programming offshoot of agile. It boils down to determining how much effort is needed to solve a particular problem or discover a workaround for an existing software issue. So, let us explore the benefits and see how these spikes can help in improving quality and making testing easier—by shifting our attention to the left—challenging the specification at a very early phase, asking questions, and getting the ground ready for sensible software architecture, which will, in turn, improve the testability of our application under test. More Details About Spikes There are many benefits of spiking—to get to know the unknown unknowns, discover risks, reduce complexity, and provide proof for proving or disapproving a theory. Taking a deep dive into the idea behind the solution can help us better understand the potential architectural solutions and the likelihood of whether it will work. A spike is not there to provide a finished working product or even an MVP. Its purpose is mainly to test a theory, so even though this concept is used (in the long run) to produce working software, the code written for spikes is often discarded after it has served its purpose. Spiking is usually done by ignoring architecture styles (which might seem odd at first as it can help discover the right architectural approaches for the system we are building), coding styles, design patterns, and general clean coding practices in favor of speed. Even though the spike may not directly produce software that will be delivered to the customer, in the long run, it still helps us ship better code in the end. Spiking is a good tool for handling risks by discovering unknown risks and provides a great way to learn and reduce complexity. A very common approach is to come up with spikes around a theory and follow the code with a small number of tests. Even though the spikes are seen as discardable code, we don’t just throw them aside. While they don’t end up in the actual code that gets delivered, they provide insights and can serve as documentation to show how a solution was reached. A Simple Example Let us assume that we have a new feature we need to develop, so we need to allow the users to be able to save a photo in their profile. To do that, a developer can make a spike where the following could be done: Have the JavaScript on the frontend communicate with the database: Set up a database server locally. Set up Node.js (or another server). Use ODBC (Open Database Connectivity) API to connect to the DB. Test the spike: Run a few sample queries. Test the CRUD functionality. What is mentioned in this simple example is all we need for a spike; it does not require any detailed documentation. The developer working on a spike will need to do some Googling, run a few commands from the terminal, and write a few lines of code for each theory. The spike would provide a possible direction for solving the challenge at hand; it can also include links for resources used, installs scripts, and the produced code to be used as a blueprint. Trying things out is way more beneficial than simply their sizing about them. The team was able to reduce the risk related to this feature—in this example, especially from the technical integrations side and even discovered new risks, such as accessing the DB using local JS! How Does This Impact Testing? Allowing us to explore spikes helps us identify the unknown unknowns, so, in a sense, spikes are a tool for early testing (used often when shifting testing to the left). By getting answers to what works and what will not work, we avoid many potential issues and delays by probing the requirements to distill them further. In turn, there are fewer bugs to report, fix, verify, and keep track of. Also, the earlier the testing is done; the more economical and fast it will be. Can QA Use Spikes? There is no real reason why not to. I have seen testers use spikes to try out and experiment with different approaches to automating some parts of the system under tests to determine the best approach. An architecture spike can help us try out different testing tools, such as new frameworks and libraries, and give us a first-hand experience of how a tool would behave without a system (when we try to automate some business rule, for example). Spikes are generally regarded as technical tasks (different than user stories), usually under an epic that is in the early development stages. Conclusion Spikes in agile are one of the tools that allow us to do what agile is intended to do in the first place: short, quick feedback cycles give us answers early in the development process. We focus on doing and trying instead of long, overly detailed planning. That is not to say that code architecture does not matter in agile (as we know, in waterfall architecture, it is very important and usually done in the design phase). In agile, we use a different approach. Agile practices, such as spikes, allow us to get an idea about architectural solutions that may work and info about the ones that may not work. Software produced in the above-mentioned manner helps us reduce risk in our user stories and enabled the team to discover the right solutions using collaboration, constructive discussion, frequent experimentation, and compromise. In an informal sense, a lot of people happen to be using spikes without even realizing it! As long as you are trying to identify the unknown unknowns, have short feedback cycles, and try to determine technical and functional risks, you are doing agile. Spikes will help us in situations where we are not certain about the requirements and if there are a lot of unknowns and answers that need answers.

Effective project management is essential in software development. Jira’s Epics provide a powerful solution for managing complex software projects, and understanding how to use them can make all the difference. In this article, we’ll dive deep into the technical aspects of utilizing Epics in the Jira workflow, exploring the advanced features and Jira best practices that can streamline your software development process. So, let’s delve into the intricacies of agile project management in software development and take your workflow to the next level. Example of an Epic In essence, an Epic is a collection of user stories that groups them together into one valuable item. This helps the team, Project Managers, and Stakeholders see the bigger picture and the overall strategy of the project without needing to dive into the details. Let’s say you run a general goods store. There are dozens of daily activities you need to keep tabs on: keeping the inventory in check, making sure new products are labeled properly on the shelves, cleaning the aisles, etc. These are your “stories.” Putting all of them into one gargantuan to-do list doesn’t make a lot of sense as you’ll end up with a lot of checklist items of various value and complexity. This will make prioritization and even simple analysis of the workload way more challenging than it needs to be. However, if you group them together using a common denominator, you’ll have a much more manageable list. In this case, related tasks like an inventory check, ordering a new delivery, and paying the vendor will become an Epic for your procurement process. You can then use the newly created Epics to prioritize your work based on the following factors: The impact an Epic has on your business. The effort or the amount of work you’ll need to complete the tasks. The risks that are associated with Epic like, for example, the risk of not having full information, the risk of being a bad market fit, or the risk of not meeting regulations, etc. Any dependencies with other tasks or Epics. An example that’s closer to software development can involve the addition of Augmented Reality functionality to a mobile app of a beauty product vendor. You’ll need the involvement of multiple people working on various tasks to accomplish your goal. Therefore it would make sense to group them together into an Epic. What’s the Right Size for an Epic? The appropriate size for an Epic is somewhat of a hot topic in the development community. You won’t find the “correct” answer in the Scrum Guide or in any other reference material. I’ve heard arguments that one Epic should be doable in one Sprint, and I’ve also heard that Epics can take as long as several years. In both cases, the justification was something along the lines of, “Hey, it works for our team; therefore, it is a good practice.” In my experience, several years is a very long time to complete an Epic. This timeframe is closer to themes and initiatives in terms of volume and complexity. A single Sprint time frame doesn’t make too much sense to me, either. This is enough time to make a feature, and a feature is indeed composed of multiple stories, but I don’t believe Epics should be feature-sized. I’m more inclined to agree with Mr. Chris Belknap and his estimation of how big an Epic should be: A theme is a multi-year endeavor. Epics take from six months to a year. Features take around three months. And stories take one Sprint or less. That said, at the end of the day, the “correct” size of an Epic is whatever works for you and your organization. The key is making sure that everyone, including the stakeholders, managers, and team members, understands what an Epic is in your case. Difference Between Epics, User Stories, Themes, and Initiatives By default, Jira has three elements to its hierarchy: Epics, Issues (Stories), and Subtasks. You can add additional layers to this functionality with Themes and Initiatives. The latter is only available for Jira Premium or third-party add-ons. Initiatives Initiatives are like epics for other epics, providing a strategic bird’s eye view for overseeing multiple company projects. For instance, an initiative could aim to boost a certain project’s market share in Spanish-speaking countries, such as an e-commerce store. This initiative would then be broken down into smaller projects like establishing connections with new vendors, investing more in advertising and marketing, or developing a mobile app for the store. Themes Themes are labels used to group work by categories in Jira. For example, a theme might involve adding a Spanish localization to reach a new market. Epics Epics serve as a project management tool to break down complex work, prioritize tasks, plan increments, and track progress among one or more teams working on the project. Epics are commonly used by developers to define project features. For instance, when creating an e-commerce website, account management, shopping cart functionality, and PayPal integration could be considered Epics. Each task required to launch the website becomes an issue or story associated with these Epics. It’s important to note that an Epic does not necessarily represent the entire project, as large projects are often divided into multiple Epics. For instance, filling website pages with content or improving SEO could be separate Epics in the e-commerce website example. Issues Issues refer to different types of tasks like Bugs or Stories, which form smaller features within an Epic. In this regard, a feature is the smallest element of your product that the customer can use or interact with to gain value. For instance, a customer logging into your product is a feature that can have multiple stories: log in with email, log in with social media, etc., whereas the login, password reset, and deleting an account would form an “Account Management” Epic together. Pro tip: You can use a Jira Checklist to refine your requirements through a more detailed decomposition of tasks. They can be also helpful when you have some research items, as you will have a list of items that specifies the things you want to check. Subtasks Subtasks are a way to segment work and further breakdown issues in Jira. How to use Jira subtasks? If there’s a story for deleting an account, subtasks could include creating a confirmation screen, sending a verification email, performing background clean-up according to GDPR rules, and ensuring adequate test coverage. How Are Epics Used in Agile? The Agile approach to Project management encourages teams to break down their work into manageable segments or Sprints. This approach helps with prioritization and makes sure developers are lean enough to incorporate feedback and respond to change. Epics are an element of the hierarchy that’s designed to organize the smallest pieces of work and track progress at a somewhat larger scale. Their role in Agile can be broken down into three parts: Break down the project to make the work more manageable. Align the stakeholders with the product and your vision. Highlight dependencies. These goals are achieved when Epics are visualized on a roadmap. This roadmap is similar to a Gantt chart but simpler. It offers a high-level overview of the scope by showing you the Epics (1), associated stories (2), and the time frame. You can also clearly see dependencies (3) on the roadmap. Check out this guide that’s dedicated to the Jira roadmap to learn more. Jira extends your abilities for management and planning with a wide selection of accessible reports. The three that will help you with managing work and Epics are: 1. Burnup Report This report shows the actual number of story points that were burned during a Sprint versus the scope of work that indicates the total number of story points that must be completed. 2. Velocity Report The velocity report compares your commitment or the amount of work that was present when the work began VS the work that has been completed. 3. Cumulative Flow Diagram The Cumulative flow diagram shows you all of the tickets based on the workflow status. You can use this to learn more about potential bottlenecks in your processes; for example, if too many tickets are piling up with the ready-for-QA status, perhaps you need more quality assurance engineers, etc. How To Create a New Epic Creating a new Epic in Jira is actually quite easy. You need to open the Roadmaps interface in your Jira and click the Create Epic button. You can then add new stories to your epic by clicking on the “+” button and using the drag-and-drop interface to adjust the time frame. How To Structure an Epic The tricky part is that most of the project planning work needs to be done before you even think about opening Jira. Our team uses the BRIDGeS framework for multi-context analysis. This planning stage can take some time, and it will require involvement from the whole team, but the entire process can be broken down into 4 major elements: 1. Problem Description Conduct a brainstorming session to identify key subjects and their descriptors. Ensure that all team members have a thorough understanding of the context before moving forward. 2. Prioritization Exercise Prioritize benefits, risks, and issues to focus on the most important tasks during the Solution Stage. This will prevent time wastage on less critical tasks. 3. Solution Variations Generate potential high-level solutions that address the benefits, risks, and issues identified in the Problem Space. 4. Solution Breakdown Break down the high-level solution into smaller, manageable bodies of work. These will become your list of Epics that are already designed within a roadmap-like implementation plan. Translate this plan into Jira. You can learn more about the framework in more detail from this guide to project management in Jira. Tips and Best Practices for Jira Epics Lastly, here are some handy tips for working with Epics and Roadmaps in Jira. Build Epics around OKRs or Objectives and Key Results. This way, the team will know what needs to be done and why. Define the completion of an Epic as well as the Definition of Done and Acceptance Criteria beforehand. You can also use checklist templates to help with automating this process. Don’t make your Epics too big. There is always the temptation of adding new tasks to an Epic simply because it’s already there. Close your Epics when they are actually done rather than when all of the tasks are closed. It is ok to leave open issues in an otherwise completed Epic if they’ve lost their relevance or have been deprioritized. Revise the roadmap on a regular basis. My team has a practice of revisiting the roadmap on a weekly basis. This helps us communicate and visualize blockers in a timely and efficient manner. Be realistic with your scope. Having more tasks than your team can realistically deliver will cause fast burnout, and it will make the working process much harder than it needs to be simply due to the need to juggle tasks. Clearly outline your dependencies. This will make prioritization much simpler, and the bigger picture will be more visible to the stakeholders. Take a clear look at issues without Epics during your backlog grooming sessions.

Dependency Poker is an Agile game — similar to planning poker — that enables teams to identify and manage dependencies in the development process. It can be utilized in Backlog Refinement or SAFe's PI Planning to enhance collaboration and reduce project risks. The Cards To play Dependency Poker, your team must create or obtain cards representing different types of dependencies. These are used in the first step to identify dependencies between software components or features. The second set of cards, strategy cards, are used to find effective solutions for managing dependencies and mitigating risks. 1. Dependency Cards In the paper "A Taxonomy of Dependencies in Agile Software Development," dependency categories were identified. The list describes different types of dependencies that can affect the completion of work in a software development project. These include Requirements, Expertise, Task Allocation, Historical, Activity, Business Process, Entity, and Technical Dependencies. In unFix, Planning and Environment dependencies are added. Self-printed Cards from unFix 2. Dependency Breaker unFix provides a list with 20 Dependency Breaker: Block, Throttle, Prioritize, Visualize, Flag, Measure, Automate, Standardize, Redesign, Decouple, Toggle, Contain, Coordinate, Attend, Reteam, Rotate, Swarm, Volunteer, Formalize, and Self-Service. Dependency Basher Cards 3. Best Practice Card Sets The Dependency Breaker cards from Unfix are a popular and widely used set of dependency cards that represent the different types of dependencies that can exist between software components or features. The Game To start the game, the team needs to understand the different types of dependencies by explaining Dependency Poker dependency type cards to each other. The perfect time to perform Dependency Poker is during SAFe's PI Planning, Scrums Backlog Refinement, or during Workshops. Placing all Cards on a to-be-Refined Backlog ItemThe team then places all(!) of the Dependency Cards on the next backlog item with the highest order. The team can then work together to remove the cards that are not relevant or that have been resolved already by using consensus-based decision-making to ensure that all team members have a shared understanding of the dependencies involved in the development of the backlog item. Clustering the DependenciesIn the second step of Dependency Poker, the team clusters dependencies together to understand their interconnections and develop strategies to manage them more effectively. Different team members may have different views on dependencies, and identifying clusters helps identify potential risks and dependencies that may have been overlooked. Finding a SolutionAfter clustering dependencies in Dependency Poker, the team finds and commits to strategies to handle them. Each participant uses his/her set of strategy cards and throws them on the cluster of dependencies to discuss which strategies are most effective. The goal is to agree on a shared strategy and commit to implementing it. Dot voting can be used to identify the best options, and the team should document these for further analysis. This step ensures that the team has a shared understanding of dependencies and a plan to address them, improving collaboration and reducing project risks. Analyzing the identified dependencies and strategies can provide valuable insights into how to optimize your business agility. By reviewing the strategies that the team has committed to, you can determine if they are effective and if there are any additional steps that could be taken to improve the management of dependencies. The growing Dependency Poker website provides a wealth of resources, including experience reports and artifacts, to help teams improve their dependency management process. By utilizing these resources and continuously evaluating and improving their approach to handling dependencies, teams can increase their agility, reduce project risks, and deliver successful outcomes.