Category: Uncategorized

Scrum is an agile project management and completion framework. It was originally developed for software development, but can be applied to any project that requires a collaborative and iterative approach. The Scrum framework is based on a set of values, principles, and practices, which are used to guide the team’s work. In 2023, organizations are increasingly adopting agile methodologies such as Scrum to manage their projects and achieve better results. However, implementing the Scrum framework in a large organization can be challenging and requires careful planning and execution.  To effectively implement Scrum in a large organization, it is essential to educate the organization about Scrum, identify a Scrum team, define the product backlog, establish clear roles and responsibilities, plan and conduct sprint reviews and retrospectives, use tools to support Scrum, communicate effectively, and continuously improve the Scrum process.  This article will explore each of these steps in detail and provide guidance on how to effectively implement the Scrum framework in a large organization in 2023. What is scrum framework? Scrum is a popular framework for Agile software development that is designed to help teams work together more efficiently and effectively. The Scrum framework is based on the Agile Manifesto, which emphasizes collaboration, flexibility, and customer satisfaction. The key components of the Scrum framework include: Scrum team: A self-organizing team that includes a Product Owner, Development Team, and Scrum Master. Product Backlog: A prioritized list of product features, requirements, and tasks that need to be completed. Sprint: A fixed time-boxed period (usually 2-4 weeks) during which the team completes a set of product backlog items. Sprint Planning: A meeting at the start of each sprint during which the team selects a set of product backlog items to work on. Daily Scrum: A brief daily meeting during which the team discusses progress, plans for the day, and any issues or roadblocks. Sprint Review: A meeting at the end of each sprint during which the team presents the completed product backlog items to stakeholders. Sprint Retrospective: A meeting at the end of each sprint during which the team reflects on the previous sprint and identifies ways to improve their processes. The Scrum framework is designed to be flexible and adaptable, allowing teams to respond quickly to changes and feedback from stakeholders. By following the Scrum framework, teams can deliver high-quality software products that meet the needs of their customers in a timely and efficient manner. Scrum framework for large organizations Scrum is a popular Agile framework that is widely used in software development projects. It emphasizes collaboration, iterative development, and frequent feedback to deliver high-quality products. However, when it comes to large organizations, implementing Scrum can be challenging due to the complexity and scale of the projects. To address these challenges, several variants of Scrum have been developed, including Less, Kanban, and Scaled Agile Framework (SAFe). Large-Scale Scrum (LeSS): Large-Scale Scrum (LeSS) is a variant of Scrum that is designed for organizations with more than one Scrum team working on the same product. LeSS combines multiple Scrum teams into one product development effort, allowing them to work together as a single unit. The LeSS framework is based on the same principles as Scrum, including frequent feedback, iterative development, and continuous improvement. Kanban: Kanban is a visual project management framework that is designed to help teams manage their workflow more efficiently. Unlike Scrum, Kanban does not prescribe specific roles or ceremonies. Instead, it focuses on visualizing work, limiting work in progress, and managing flow. Kanban is particularly useful for organizations that have a lot of work in progress at any given time. Scaled Agile Framework (SAFe): Scaled Agile Framework (SAFe) is a comprehensive framework that is designed to help large organizations implement Agile practices at scale. SAFe provides a set of guidelines and practices for coordinating multiple Agile teams working on the same product or project. SAFe includes several layers of planning, including portfolio planning, program planning, and team planning. SAFe also provides guidance on how to align the work of multiple teams and manage dependencies between them. Tips for Successful Scrum Implementation in Large Organizations Implementing Scrum in a large organization can be challenging. Here are some tips for successfully implementing Scrum in large organizations: Establishing a common goal: It’s important to establish a common goal that is aligned with the organization’s strategic objectives. This will help ensure that all teams are working towards the same objective and will help in breaking down silos. Building cross-functional teams: Scrum emphasizes the importance of cross-functional teams. It’s important to build teams that include members with different skill sets, backgrounds, and experiences. This will help in ensuring that the teams can work together effectively and deliver high-quality products. Providing adequate training: Scrum requires a new way of working, and it’s important to provide adequate training to all team members to ensure that they understand the Scrum framework and its principles. This will help in ensuring that everyone is on the same page and is working towards the same goals. Facilitating effective communication: Effective communication is critical for successful Scrum implementation. It’s important to create an environment that encourages open and honest communication, and that allows team members to share ideas and collaborate effectively. Breaking down silos: Silos can be a major obstacle to successful Scrum implementation. It’s important to break down silos and encourage cross-functional collaboration. This can be achieved by establishing a common goal, building cross-functional teams, and providing adequate training. Leveraging technology: Technology can be a powerful tool for successful Scrum implementation. There are many tools available that can help in managing Scrum artifacts, tracking progress, and facilitating communication. Measuring success: It’s important to measure success to ensure that the Scrum implementation is achieving the desired outcomes. This can be achieved by establishing key performance indicators (KPIs) and tracking progress against these KPIs. Implementing scrum framework in large organizations Implementing the Scrum framework in large organizations requires careful planning and execution. Here are some steps you can take to effectively implement Scrum in

SAFe (Scaled Agile Framework) certification is a highly sought-after program for individuals who work with or within organizations that use SAFe methodology for their software development and project management. One of the key components of the SAFe methodology is PI Planning, which stands for Program Increment Planning. PI Planning is a critical aspect of the SAFe framework and is used to align and synchronize multiple agile teams that are working on the same program or project. It involves a two-day event in which teams come together to plan and prioritize their work for the upcoming program increment. The SAFe certification program, offered by Scaled Agile, Inc., provides individuals with the knowledge and skills necessary to successfully implement and manage the SAFe framework, including PI Planning.  The program includes multiple levels of certification, including SAFe Agilist (SA), SAFe Practitioner (SP), SAFe Scrum Master (SSM), SAFe Product Owner/Product Manager (POPM), and more.Achieving SAFe certification requires passing an exam and completing training or experience requirements. This certification is an excellent way to demonstrate expertise in the SAFe framework and PI Planning, and it can help individuals advance their careers in software development and project management. Let’s explore some information on SAFe 5.1 Certification SAFe 5.1 is a version of the Scaled Agile Framework that was released in 2020. SAFe 5.1 builds on the previous versions of SAFe, with updated guidance and best practices for scaling agile practices in larger organizations. SAFe 5.1 certification is the current version of the SAFe certification program, which is designed to validate the knowledge and skills of individuals who work with or within organizations that use the SAFe 5.1 methodology for their software development and project management. The SAFe 5.1 certification program includes multiple levels of certification, including SAFe Agilist (SA), SAFe Practitioner (SP), SAFe Scrum Master (SSM), SAFe Product Owner/Product Manager (POPM), and more. Each certification requires passing an exam and completing training or experience requirements. The SAFe 5.1 certification program is intended for individuals who are involved in agile projects or initiatives at the enterprise level, including project managers, program managers, release train engineers, business analysts, developers, testers, and other roles. SAFe 5.1 certifications can help individuals demonstrate their knowledge and expertise in the latest version of SAFe methodology and can enhance their career prospects in the agile software development industry. What is PI Planning? PI (Program Increment) Planning is a key event in the Scaled Agile Framework (SAFe) methodology. It is a two-day planning event that happens at the beginning of each Program Increment, which is a time-boxed period of 8-12 weeks in which a set of related features are developed and delivered. During PI Planning, the agile teams in a SAFe organization plan and coordinate their work for the upcoming Program Increment. The purpose of PI Planning is to ensure that all the teams are aligned on the goals and priorities for the upcoming Program Increment and have a clear plan for how they will deliver the required features. During the event, teams review and refine the Program Backlog, which includes the features, epics, and user stories that need to be delivered during the upcoming Program Increment. They also estimate the effort required for each item on the backlog and plan the work that needs to be done to complete each item. PI Planning typically involves a large number of people, including product owners, scrum masters, development team members, and stakeholders from the business and technical teams. The event is facilitated by a Release Train Engineer (RTE), who helps to keep the planning on track and ensures that everyone is aligned on the goals and priorities. At the end of the PI Planning event, each team should have a clear plan for how they will deliver the required features and should be aligned with the other teams on the overall goals and priorities for the Program Increment. This helps to ensure that the agile teams in a SAFe organization are working towards a common goal and can deliver high-quality products and services in a timely and efficient manner. SAFe 5.1 Establish the Context for PI Planning In SAFe 5.1, establishing the context for PI (Program Increment) Planning is an important step in preparing for a successful planning event. Here are some of the key activities involved in establishing the context for PI Planning: Benefits of Establishing the Context for PI Planning Establishing the context for PI (Program Increment) planning is an essential step for any organization looking to implement Agile methodologies. By setting the stage and aligning stakeholders with a shared understanding of goals, priorities, and constraints, establishing context can bring several benefits to the PI planning process, including: Establishing context for PI planning can help to ensure that everyone involved is working towards the same goal and can improve the effectiveness and efficiency of the planning process. Conclusion SAFe 5.1 is a version of the Scaled Agile Framework that provides guidance and best practices for scaling agile practices in larger organizations. SAFe 5.1 certification is a program that validates the knowledge and skills of individuals who work with or within organizations that use the SAFe 5.1 methodology for their software development and project management. One of the key events in SAFe 5.1 is PI (Program Increment) Planning, which is a two-day planning event that happens at the beginning of each Program Increment. During PI Planning, the agile teams in a SAFe organization plan and coordinate their work for the upcoming Program Increment, ensuring that everyone is aligned on the goals and priorities for the period. Establishing the context for PI Planning is an important step in preparing for a successful planning event. This includes setting the PI objectives, preparing the program backlog, inviting the teams and stakeholders, defining the planning agenda, and preparing the necessary infrastructure. PI Planning FAQs What is the role of the Release Train Engineer (RTE) in PI Planning?  The Release Train Engineer (RTE) is responsible for facilitating the PI Planning event and ensuring that it runs smoothly and

In Agile software development, the “Definition of Done” (DoD) is a shared understanding of what constitutes a completed and acceptable piece of work. It provides a clear and concise definition of the minimum level of quality that is expected for any given product backlog item or user story. The DoD helps to ensure that all team members have a common understanding of what is expected to be delivered and what constitutes a potentially shippable product increment. The DoD typically includes a list of specific criteria that must be met for a product backlog item to be considered done. This may include acceptance criteria, technical standards, quality standards, and any other relevant requirements. By having a well-defined DoD, the team can focus on delivering a consistent level of quality and minimize the risk of misunderstandings or scope creep. In Agile software development, the Definition of Done is typically defined and agreed upon by the entire team, including the product owner, developers, testers, and any other relevant stakeholders. The goal is to have a shared understanding of what constitutes a completed and acceptable piece of work, so everyone should have a say in what is included in the DoD. However, the ultimate responsibility for defining the Definition of Done rests with the product owner, who represents the stakeholders and makes decisions about the product backlog. The product owner works with the rest of the team to ensure that the DoD accurately reflects the stakeholders’ expectations and the team’s understanding of what is required to deliver a high-quality product. The Definition of Done in Agile software development is a collaborative effort between the product owner and the rest of the team, with the ultimate responsibility resting with the product owner. Why should product managers care about the definition of done? Product managers should care about the Definition of Done (DoD) in Agile software development because it directly impacts the success of their product. The DoD provides a clear and concise definition of what constitutes a completed and acceptable piece of work and helps to ensure that the team is delivering high-quality work that meets the needs of the stakeholders. Here are a few specific reasons why product managers should care about the DoD: Definition of done vs. acceptance criteria in agile In Agile software development, the Definition of Done (DoD) and acceptance criteria are related but distinct concepts. The Definition of Done is a shared understanding of what constitutes a completed and acceptable piece of work. It provides a clear and concise definition of the minimum level of quality that is expected for any given product backlog item or user story. The DoD sets a standard for the quality of work that is expected and helps to ensure that all team members have a common understanding of what is expected to be delivered. Acceptance criteria, on the other hand, are specific, measurable, and verifiable conditions that a product backlog item must meet to be considered complete. Acceptance criteria are used to determine whether a user story has been successfully implemented, and help to ensure that the team is delivering work that meets the stakeholders’ needs. In other words, acceptance criteria are a subset of the Definition of Done. The acceptance criteria provide a more detailed and specific understanding of what is expected for a given user story, while the DoD sets a general standard for the quality of work that is expected for all user stories. How to create a definition of done for your feature, project, or task in 5 steps? Creating a Definition of Done (DoD) for a feature, project, or task in Agile software development can help to ensure that the team is delivering high-quality work that meets the needs of the stakeholders. Here are five steps to creating a DoD: Conclusion In conclusion, ensuring that your Definition of Done (DoD) is meeting business goals is critical for the success of your product and project in Agile software development. By defining the minimum level of quality that is expected for any given product backlog item or user story, the DoD provides a shared understanding of what constitutes a completed and acceptable piece of work. To ensure that your DoD is meeting business goals, it is important to involve relevant stakeholders in the process of creating the DoD and to have a clear understanding of the objectives of the DoD. It is also important to define the scope of the DoD, develop a list of specific, measurable, and verifiable criteria, and have all relevant stakeholders agree on the DoD. Finally, it is important to regularly review and update the DoD to ensure that it continues to meet the evolving needs of the stakeholders and the business. By following these best practices, you can help to ensure that your DoD is aligned with your business goals and that your team is delivering high-quality work that meets the needs of the stakeholders. FAQs Q1: How can I enforce the Definition of Done within my development team?  A:Enforcing the Definition of Done within a development team requires a commitment to following the definition and holding team members accountable for meeting its criteria. This can be achieved through regular reviews and retrospectives, as well as clear communication and training on the importance of following the definition. Additionally, incorporating the Definition of Done into the development process, such as by using it as a criteria for accepting work into the next phase of the project, can help to reinforce its importance. Q2: How is the definition of done updated? A:The definition of done is updated as needed to reflect changes in the development team’s practices or the requirements of the stakeholders. It may be updated during backlog refinement or as part of the team’s ongoing improvement efforts. All team members and stakeholders should be involved in the review and update process. Q3:  What are some best practices for creating an effective definition of done? A: Best practices for creating an effective definition of done include

Introduction Backlog refinement is a regular activity in Agile software development and agile scrum methodology where the development team and product owner review, prioritize, and update the items in the product backlog to ensure that it remains relevant and up-to-date. The goal of backlog refinement is to ensure that the backlog items are well-defined, understood, and ready for development.  It involves clarifying requirements, breaking down larger items into smaller ones, and re-prioritizing items based on changing priorities and dependencies. The outcome of backlog refinement is a prioritized, refined backlog that the development team can use to guide their work. What is a product backlog? A product backlog is a prioritized list of features, enhancements, and requirements that a product owner wants to build or improve in a product. It serves as a roadmap for the development team, providing a clear understanding of what needs to be delivered and in what order. A product backlog is a flexible tool that is updated and refined regularly to reflect changes in priorities, requirements, and market conditions.  The items in the product backlog are typically ranked based on their priority, with the most important items at the top and the least important items at the bottom. The development team uses the product backlog to plan and execute work, delivering the most valuable items first and ensuring that the product meets the needs of the stakeholders. Overall, the product backlog is a critical component of Agile product development and is essential for delivering high-quality, valuable products to the market. Example of a Product Backlog: Note: This is just an example, and the items in the product backlog will vary depending on the specific needs and requirements of the project. The backlog is a living document that is regularly reviewed, updated, and prioritized during backlog refinement sessions. Benefits of backlog refinement Backlog refinement provides several benefits to the software development process, including: Bcklog refinement helps to ensure that the development team is working on the most valuable items, delivering the best possible outcome for the stakeholders, and improving the overall efficiency of the development process. How to refine a backlog? Here are some steps to refine a backlog in Agile software development on universal agile: What to avoid with backlog refinement? Here are some things to avoid during backlog refinement: The value of refining your backlog  Refining your backlog is a valuable process that helps to ensure that your development team is working on the most important and valuable items first. By clarifying requirements, prioritizing items, and regularly reviewing the backlog, you can ensure that the team is aligned on their goals and making progress towards delivering value to stakeholders.  The refinement process also helps to identify and address any challenges or obstacles that may arise, ensuring that the team can work efficiently and effectively. By taking the time to refine your backlog, you can ensure that your development process is well-structured, focused, and delivering the outcomes that matter most. Conclusion Backlog refinement is a critical aspect of agile project management that helps teams prioritize and clarify their product backlog. By regularly reviewing and updating the backlog, teams can ensure that they are focused on delivering high-value features and capabilities, and are aligned with their goals and objectives.  The refinement process also helps teams to identify and address any roadblocks, risks, and uncertainties, and to adjust their plans accordingly. In short, backlog refinement is an ongoing process that helps teams to maintain their focus and momentum, and to deliver a successful product. FAQs Q1: What are the outputs of backlog refinement? A: The outputs of backlog refinement may include updated user stories or product backlog items, refined acceptance criteria, estimated effort or complexity, prioritized backlog, and a better understanding of dependencies or technical considerations. Q2: How long does backlog refinement usually take? A: The duration of backlog refinement varies depending on the size and complexity of the product backlog, the number of participants, and the level of detail needed. It may take from 1-2 hours for a small team to several days for a larger or more complex product backlog. Q3: How does backlog refinement differ from sprint planning? A: Backlog refinement and sprint planning are two different meetings in the agile development process. Backlog refinement is focused on preparing the product backlog items for the upcoming sprints or iterations, while sprint planning is focused on selecting the items from the product backlog that will be worked on during the upcoming sprint. Q4: What is the role of the product owner in backlog refinement? A: The product owner is responsible for leading the backlog refinement sessions and ensuring that the product backlog is well-defined, prioritized, and ready for implementation. The product owner is also responsible for making decisions about the backlog items and ensuring that the development team has a clear understanding of the user stories and acceptance criteria. Q5: How does backlog refinement contribute to agile development? A: Backlog refinement is an essential part of the agile development process, as it helps ensure that the development team is working on the most important items and that the product backlog is well-defined and ready for implementation. It also helps identify and address potential roadblocks early in the development process, which reduces waste and improves overall efficiency. Q6: How does backlog refinement support continuous improvement? A: Backlog refinement supports continuous improvement by providing opportunities for the development team to review and refine their processes and identify areas for improvement. It also helps ensure that the product backlog is constantly evolving to meet the changing needs of the users and stakeholders. Q7: How can backlog refinement be adapted for remote teams? A: Backlog refinement can be adapted for remote teams by using video conferencing tools, collaboration software, and other online tools to facilitate discussions and document changes to the product backlog. It is important to ensure that all team members have access to the necessary technology and that communication and collaboration are emphasized to overcome potential barriers

Introduction Agile frequently starts with small teams that are committed to making unique contributions to the total.Long-lasting cross-functional teams that are committed to delivering value in a certain value stream or set of value streams become necessary eventually. Delivering value that scales at the corporate level requires the formation of Agile Release Trains (ARTs), teams made up of numerous Agile teams aligned to a common objective. The Scaled Agile Framework is used by the Agile Release Train, a super-group comprising many Agile teams. One must deploy the SAFe® framework in their organisation thoroughly if they want to take full advantage of the ART’s potential. Without SAFe, the agile trains cannot run. The Agile Release Train is one of the numerous terms and approaches to investigate inside the Agile world. You might be curious as to if the ART’s goal is to encourage teamwork and force participants to adhere to a shared release schedule. Or a strategy for bringing together various teams for a sprint schedule? Or a means of providing value while deciding which features would be used? Exists a primary job that must perform all the duties, similar to the RTE Agile? In this blog of Universal Agile, we’ll do our best to respond to all of these queries. Definition of Agile Release Train (ART) Let’s begin by defining the Agile Release Train. An Agile Release Train is a group of Agile teams that collaborates on a long-term plan designed to help agile teams self-organise, as well as plans that the teams commit to and work on together. All value streams are organised and carried out via the SAFe Agile Release Train. They collaborate with the client to produce solutions that are as valuable as possible. They cooperate to attain a single objective, making sure to do everything within the time frame allotted. They’ve got: An ART can have a total of 50–125 members who would collaborate on the same goals and initiatives. The PI and its relationship to the ART would now be the topic of discussion. PI is another term for “programme increments.” The PIs assist in developing the timebox. The cadence is used, and: The PI is responsible for delivering the work. Every train is assigned a unique mission that continuously defines, develops, and tests the capabilities. It is completed for every iteration, not just one. The engineer of the release train manages everything. Key ART Principles Now that we are aware of what the agile release train’s primary function is: They facilitate team alignment. Even after the product is delivered, they continue to assist in managing all risks. They offer synchronisation and cadence at the programme level. These factors, as well as the acceptance and approval of the norms and guidelines that are consistently followed throughout, serve as the foundation for all of the principles. All teams must now validate these common operating principles and adhere to the same set of instructions. These guidelines have been approved by the entire team and distributed to the agile train release. All of this is completed during the 2-day PI planning period. Investigate the ART Principles: 1. The timetable is set The ART keeps to a regular schedule and is prompt. A feature can be added to the following schedule if it doesn’t make the release schedule it is supposed to be in. 2. An incremental system change every two weeks Every two weeks, new system increments are delivered by all ARTs. The System Demo is used to evaluate these increments. 3. Applying synchronisation Teams on the Agile Release Train follow synchronised timetables that frequently have a same start and finish date and can span anywhere from 8 to 12 weeks. 4. The Train Travels at a Known Speed The amount of features that can be supplied in a single PI may thus be easily estimated, to put it simply. 5. Agile Groups Agile teams use a variety of built-in quality methods, including Kanban, Scrum, XP, and others, and are, in theory, in line with the Agile manifesto. 6. Committed Folks The passengers on the ART are committed to the train, regardless of their particular roles and tasks. 7. PI Planning in Person The Agile Release Train often holds monthly, in-person meetings as part of PI planning events. 8. Planning and innovation (I&P) IP iterations usually come after the conclusion of a programme increment in order to allow for an estimated guard band and to provide time for planning, innovation, and other activities. 9. Examine & Adjust (I&A) At the conclusion of a PI, an Inspect & Adapt event also happens along with IP iterations. Through problem-solving workshops, solutions are examined and assessed, and any modifications that are necessary are planned for. 10. Create on Demand, Release on Cadence With the application of this idea, a solution is released on time even though research and development may have erratic timelines. An Agile Release Train’s Structure (ART) A number of Agile teams work together as the Agile Release Train to complete a variety of activities, including designing, testing, and developing solutions as well as deploying, releasing, and operating them. Depending on their choices, these teams use a variety of Agile techniques. These include Extreme Programming (XP), Scrum, and Kanban, among others. Scrum Master and Product Owner are two distinct responsibilities that are part of every Agile team. Agile Release Trains are by nature cross-functional and structured around developmental value streams. The following SAFe® rules on team composition are put into effect to make sure that the flow of value is not impeded: Temporal and synchronic relations The servant leader is a release train engineer, in case you were wondering. The chief scrum master would be the servant-leader. They are not like the typical scrum masters, yet they have the upper hand. You are aware that while the release train engineer, or RTE, would manage all the teams, the scrum masters would direct and control one team at a time.  The release train engineer and the scrum masters would

Note: This is Part 2 in the series of blog posts where we will talk about different facilitation techniques. If you haven’t read Part 1, we encourage you to read it first here – What is the most common meeting format, and how you can use that to have effective meetings? Our intention behind writing this series is that once you learn and apply these facilitation techniques, you will witness true collaboration. “True collaboration” means conversations in your meetings lead to new ideas or decisions. In short, the series of blog posts will help you make your meetings more effective. A successful meeting can only happen with preparation. Many times Scrum Masters are under the impression that if they are timeboxing the meeting or event, then the meeting or event is bound to meet its objectives. Well, nothing can be farther from the truth. Well, nothing can be farther from the truth. You don’t win an Olympic medal by just showing up. It would help if you prepared for it and, most of the time, prepared for years. Thankfully you don’t have to spend years preparing for your next 30 mins meeting. Nevertheless, depending upon what you are trying to achieve, the stakeholders involved, frequency of the meeting, a Scrum Master has to spend some time preparing for the meeting. It’s Show Time So, as a Scrum Master, you have prepared for your meeting enough. You have taken care of the logistics as well as supplies. It is now time to start your meeting. The very first thing that you do is greet each person individually. If the event happens face to face, you shake each person’s hand. Greeting each person helps establish a connection with the participants and sends a message that you respect each member and value their expertise and wisdom. Greeting each person is another instance where you practice “Respect”, one of the Scrum values. Lights, Camera, Action! To start the meeting, you first ask the team if they are ready to start. This simple question does lot many things. Ice-breaker or Check-in The objective here is:- Let’s talk about two techniques you can use as Ice-breakers or for Check-in in your Scrum events or meetings. Technique 1. Agreements This technique sets a tone and expectations near the start of the meeting. This activity also allows you as a Facilitator to create the right atmosphere or culture for the meeting. This technique also helps in creating a shared responsibility. The output of this technique is that it helps the participants know the boundaries of the meeting and acceptable behaviours. Here are the steps you can follow to execute this technique and achieve an agreement. Some suggestions for the list of agreements Technique 2. Fast Pass Fast Pass is an incredible technique to use at the start of the meeting. The method provides people who arrive early with something to do. You can use this technique to connect participants personally or through content related to the meeting. Here are some suggested questions to connect participants at a personal level: Below are some suggested questions to connect participants through content related to the meeting: Conclusion As Aristotle said, “Well begun is half done.”. Focusing on starting your meeting using a good check-in or ice-breaker goes a long way in ensuring the success of the meeting. You must pay attention to the Starting phase of the meeting to impress people with how the meeting went or what you achieved out of the meeting. Try the above techniques and share with us your favourite check-in techniques. Also, please share your experience when you tried any of the above methods.

Scrum Masters who are new to the role often wonder how a Scrum Master is supposed to spend their time. The problem gets compounded when you are transitioning from a Developer Role. As a Developer, you have a list of items (Sprint Backlog or Product Backlog) from which you can pick and start working. On the other for a Scrum Master, you must constantly explore and figure out what you can do to make the team more effective. Let us go through what activities a Scrum Master will perform during the day. This Blog post will help you plan your day. Please let us know in the comments if we need to include any activity. Daily activities of a Scrum Master As a Scrum Master, you serve the Scrum Team, the Product Owner, and the Organisation. Therefore your activities must touch all three. A good reflection exercise is to check what activity you did for each of these during the day. For example, if you couldn’t find an activity for a Product Owner, a good question is, “Am I neglecting to serve the Product Owner?”. Your morning will start with casual conversations with team members. The conversations typically involve greeting and checking with team members about what’s happening in their lives and family. Overall this is how you get to know your team members better. Post the above conversations; you get to attend the Daily Scrum. Based on your observations and impediments shared by the Developers, you prepare a plan on which team members you wish to engage during the day and for how long. The planning will also involve scheduling problem-solving sessions. You might have blocked some time to prepare for forthcoming training, which you would have planned for the teams based on your team’s training needs. A good tip is to ensure that your training covers different aspects of Scrum, Lean Thinking, Flow Practices, etc. You should also prepare the Facilitation plan for the upcoming Scrum events. Your day will also include scheduled one-on-one Coaching Conversations with a Developer or a Product Owner. Your day could also include a one-on-one conversation with leaders. Remember, as a Scrum Master, you also serve the organisation. Depending upon the stage where your team is in their Agile Journey, you might have to facilitate many Scrum Events to ensure that the developer and product owner are learning from you. Many times a Scrum Master is asked to support another team which has just started adopting Scrum. In this situation, your calendar will have you facilitating many of this team’s Scrum events to ensure that things are running smoothly. The idea is that the new Scrum Team can drive these events themselves after a month or so. Your day also includes facilitating meetings across different teams to discuss dependency management or lessons learned. Don’t forget to include some time for reflection where you are jotting down your observations on different individuals, their behaviours, taking notes on the system’s voice, etc. Depending upon the culture and structure of your organisation, you might have to prepare reports to present team progress, impediments faced by the team, and request for help from the team at various executive forums. If your organisation has adopted an Agile Maturity assessment tool, then you have to plan for activities related to assessing the Scrum Team’s and organisation’s maturity. Once again, the idea is to coach the Scrum Team towards higher maturity levels. You will also have to work with businesses to coach them on Scrum and Agile ways of working. The work will involve spending time with the product owner and their colleagues from the business side. Scrum Team is also responsible for experimentation. As a Scrum Master, you might have to spend time mentoring them on experimentation. For example, are the teams doing any experiments, do their experiments have a clear hypothesis, etc.? The above list is by no means exhaustive. A Scrum Master day is very dynamic. As a Scrum Master, you must ensure that your day is guided by making the team effective and serving all three – Scrum Team, Product Owner, and Organisation. An excellent reference that talks about the list of thing that a Scrum Master must focus on is The Scrum Master checklist (https://scrummasterchecklist.org/). We intend to cover the above in a separate blog. Do let us know what activities you do as a Scrum Master in the comment section. Scrum Masters who are new to the role often wonder how a Scrum Master is supposed to spend their time. The problem gets compounded when you are transitioning from a Developer Role. As a Developer, you have a list of items (Sprint Backlog or Product Backlog) from which you can pick and start working. On the other for a Scrum Master, you must constantly explore and figure out what you can do to make the team more effective. Let us go through what activities a Scrum Master will perform during the day. This Blog post will help you plan your day. Please let us know in the comments if we need to include any activity. Daily activities of a Scrum Master As a Scrum Master, you serve the Scrum Team, the Product Owner, and the Organisation. Therefore your activities must touch all three. A good reflection exercise is to check what activity you did for each of these during the day. For example, if you couldn’t find an activity for a Product Owner, a good question is, “Am I neglecting to serve the Product Owner?”. Your morning will start with casual conversations with team members. The conversations typically involve greeting and checking with team members about what’s happening in their lives and family. Overall this is how you get to know your team members better. Post the above conversations; you get to attend the Daily Scrum. Based on your observations and impediments shared by the Developers, you prepare a plan on which team members you wish to engage during the day and for

I have observed while working with Teams that the Daily Scrum Event becomes a chore after a point. Team members settle down into a routine. Every team member answers the below three questions (or some variation) and moves on: 1. What did I do in the last 24 hours? 2. What am I planning to do in the next 24 hours? 3. Is there any blocker that is preventing me from achieving my plans? As a Scrum Master, you must consistently reinforce that each event in Scrum is an opportunity to inspect and adapt. As per Scrum Guide, Daily Scrum is an opportunity to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as necessary. In other words, the Developers must assess whether they are on track to achieving their Sprint Goal. Accordingly, they should add or remove items from their Sprint Backlog. The Daily Scrum is also a chance for them to adjust their plans for the next 24 hours. I have also observed that many Scrum Teams think Daily Scrum is a Status update meeting. If you also think this is the case, then either you don’t have information radiators or your information radiators are not working. What is the point of buying licenses for tools like JIRA etc., if they are not conveying the information needed? Here is an alternative format to make your Daily Scrum more effective The simple rule of 5 “You don’t need to prove to me that you’re busy. I know you’re busy”. ● Michael Pryor, Co-Founder of Trello Joel Spolsky created this method, Co-Founder of Trello when he was running Fog Creek (now Glitch) and StackExchange. He realized he could not answer the question of whether the team was working on the company’s big priorities. In the words of Joel himself: “I think a lot of times people are working on a long list of little things and don’t know what the company’s big priorities are either,” So what is this “Rule of Five” method? Joel realized that all he wanted to know from his team was a list of 5 things. These five things turned into the Rule of Five. Given below is the list of Five things which each team member must answer: 1. Two tasks they were currently working on. 2. Two tasks they plan to work on next. 3. One task that people might expect them to be working on but they weren’t planning on doing. What are the benefits of this “Rule of Five” method? ● The foundation of being Productive is staying focused. Focusing on just two tasks at a time helps the team members to go deeper into specifics. It also prevents others from asking questions not related to your current focus. ● It inherently produces a transparent roadmap. When you list the two tasks you will pick up next after you finish your current task, that’s an excellent personal roadmap or, at the very least, a good plan. ● It also increases team communication. When you mention one task that others expect you to work on but you don’t plan to work on and the reasons behind it, then it helps the rest of the team to understand why the task won’t be completed soon. Merge this “Rule of Five” method with an update to the Team’s Visual board. To make this “Rule of Five” method even more potent, align with Team’s Visual board. Each team member should have only two tasks in progress and two functions in the To Dos assigned to themselves. The method automatically keeps the Work in Progress limits in check. Once the team follows this discipline, the Team’s Visual board visually represents the big picture. We request Scrum Masters to practice this “Rule of Five” in their next Daily Scrum and share their experience with us in the comments section. You can read more about the “Rule of Five” method here – https://bit.ly/3vEWhxa. ‘

Introduction Agile sprints are a common method used in software development to deliver small, incremental updates to a product in a short period of time, typically one to four weeks. The goal of an agile sprint is to deliver a high-quality, usable product increment that meets the needs of the customer. One of the key agile principle in scrum is the importance of maintaining a sustainable pace. This means that the team should work at a pace that is sustainable over the long term and that allows them to consistently deliver high-quality work. In this blog, we will explore the benefits of working at a sustainable pace in agile sprints, the risks of not doing so, and strategies for maintaining a sustainable pace. What is a sustainable pace in Scrum? In Scrum, a sustainable pace refers to the pace at which a team is able to consistently deliver high-quality work over an extended period of time without burning out or becoming overwhelmed. This means that the team is able to maintain a constant level of productivity and focus, without experiencing dips in performance due to exhaustion or other factors. Maintaining a sustainable pace is important for the success and well-being of the Scrum team. It enables the team to consistently deliver high-quality work that meets the needs of the customer, and helps to prevent burnout and decreased morale among team members. To maintain a sustainable pace in Scrum, it is important for the team to properly plan and estimate their workload, take regular breaks and allow time for rest and recovery, delegate tasks properly, and communicate and collaborate effectively within the team. By following these best practices, the team can ensure that they are working at a pace that is sustainable over the long term. Importance of working at a sustainable pace in agile sprint Maintaining a sustainable pace in agile sprints is important for several reasons: Improved focus and productivity: Working at a sustainable pace allows the team to focus on their tasks and be more productive, as they are not feeling overwhelmed or burnt out. Greater consistency in delivery: Working at a sustainable pace enables the team to consistently deliver high-quality work on a regular basis, which is essential for meeting customer needs and maintaining their satisfaction. Higher quality of work: By working at a sustainable pace, the team is able to produce work that is of a higher quality, as they have the time and energy to focus on the details. Increased team morale and motivation: Working at a sustainable pace can have a positive impact on team morale and motivation, as the team is able to feel a sense of accomplishment and satisfaction from consistently delivering high-quality work. Working at a sustainable pace is essential for the success and well-being of the Scrum team. By implementing strategies to maintain a sustainable pace, teams can improve their focus, consistency, and overall quality of work. Risks of not working at a sustainable pace in agile sprint There are several risks associated with not working at a sustainable pace in agile sprints: Burnout and decreased productivity: If a team is working at an unsustainable pace, they may become exhausted and burnt out, leading to decreased productivity and a decrease in the quality of their work. Decreased quality of work: When a team is overextended and not able to focus on their tasks, the quality of their work may suffer. This can lead to errors and mistakes, which can have a negative impact on the overall product. Negative impact on team morale and motivation: Working at an unsustainable pace can also have a negative impact on team morale and motivation. When a team is constantly working long hours and feeling overwhelmed, they may become demotivated and less engaged in their work. This can lead to a decline in productivity and overall team performance. Strategies for maintaining a sustainable pace in agile sprint There are several strategies that a team can use to maintain a sustainable pace in agile sprints: Proper planning and estimation: Before the start of an agile sprint, the team should carefully plan and estimate the work that needs to be completed. This will help ensure that the workload is manageable and that the team is not taking on more than they can handle. Regular breaks and time for rest and recovery: It is important for the team to take regular breaks and allow time for rest and recovery. This can help prevent burnout and ensure that the team is well-rested and able to focus on their tasks. Proper delegation of tasks: To ensure that the workload is distributed evenly among team members, it is important to delegate tasks properly. This can help prevent one person from becoming overwhelmed and ensure that the team is working at a sustainable pace. Clear communication and collaboration within the team: Good communication and collaboration within the team is essential for maintaining a sustainable pace. By discussing workload and challenges openly, the team can identify and address any issues that may be causing them to work at an unsustainable pace. The 8th Agile Principle addresses keeping a sustainable pace The 8th Agile Principle is “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” This principle emphasises the importance of maintaining a sustainable pace in agile development. Working at a sustainable pace allows the team to consistently deliver high-quality work over the long term, without burning out or becoming exhausted. This enables the team to meet the needs of the customer on an ongoing basis and support the sustainability of the product. To adhere to this principle, it is important for the team to properly plan and estimate their workload, take regular breaks and allow time for rest and recovery, delegate tasks properly, and communicate and collaborate effectively within the team. By implementing these strategies, the team can ensure that they are working at a sustainable pace that allows them to maintain

Introduction The Certified Scrum Master (CSM) is a professional who has been trained and certified in the Scrum framework, a specific approach to project management often used in software development. Some outcomes that may be achieved through becoming a CSM include improved project delivery, better team collaboration, increased efficiency, greater customer satisfaction, and enhanced career opportunities. Improved project delivery: The Scrum framework emphasises the importance of rapid iteration and frequent delivery, which can help teams deliver projects more quickly and with higher quality. Better team collaboration: The Scrum framework emphasises the importance of cross-functional teams and regular communication, which can lead to better collaboration and teamwork among team members. Increased efficiency: The Scrum framework promotes transparency, accountability, and continuous improvement, which can help teams work more efficiently and effectively. Greater customer satisfaction:Teams may receive input from clients more regularly and utilise that data to make adjustments and improvements by adopting Scrum to deliver projects in tiny increments, which can increase customer satisfaction.. Enhanced career opportunities: Many organisations are looking for professionals with Scrum expertise, and becoming a CSM can open up new career opportunities and increase your value as a professional. How becoming a Certified Scrum Master helps you understand the principles, values, and practices of Scrum in greater depth? Scrum is a framework for managing complex projects that require frequent adjustments and adaptability. It is based on the principles of transparency, inspection, and adaptation, and is often used in software development and other project-based work. In Scrum, a project is broken down into small, iterative phases called “sprints.” Each sprint is a time-boxed period of typically one to four weeks during which a specific set of work is completed.  The work is defined in a prioritised list called a “product backlog.” The Scrum team is composed of a “Scrum Master,” who is responsible for facilitating the process and ensuring that the team follows the Scrum framework; a “Product Owner,” who represents the interests of the stakeholders and prioritises the product backlog; and the “development team,” who are responsible for completing the work. The Scrum methodology is created to be adaptive and flexible. The team holds daily meetings called “stand-ups” to discuss progress and any challenges they are facing. At the end of each sprint, the team reviews the work completed and plans for the next sprint in a meeting called the “sprint review.” The team also reflects on their process and identifies opportunities for improvement in a meeting called the “sprint retrospective.” Overall, Scrum is designed to help teams deliver high-quality products quickly and efficiently, by providing a framework for continuous improvement and adaptability. Enhanced ability to facilitate Scrum events and meetings Certified Scrum Master helps you develop the skills and knowledge to facilitate these events in a way that supports the team and the project. Scrum is a method for organising and finishing difficult tasks. It is based on the idea of iterative and incremental development, where a project is divided into small chunks called “sprints,” and each sprint is a self-contained iteration of work. Scrum events, or ceremonies, are regular meetings that help teams follow the Scrum process and stay on track. There are several types of Scrum events, including: Sprint planning: This is a meeting that occurs at the beginning of each sprint, where the team plans the work they will complete during the sprint. Daily stand-up: This is a daily meeting where team members quickly share what they worked on the previous day, what they plan to work on today, and any obstacles they are facing. Sprint review: This is a meeting that occurs at the end of each sprint, where the team demonstrates the work they have completed to stakeholders and discusses what went well and what could be improved. Sprint retrospective: This is a meeting that occurs at the end of each sprint, where the team reflects on the past sprint and identifies ways to improve their process for the next sprint. To facilitate these events effectively, a Scrum facilitator should: Make sure that everyone understands the purpose and goal of the event. Keep the discussion focused and on track, and encourage participation from all team members. Help the team identify and address any challenges or issues that arise during the event. Ensure that action items and next steps are clearly identified and assigned. Keep the event organized and efficient, and wrap up the event in a timely manner. Improved communication and collaboration skills It helps you communicate effectively with the team and stakeholders, and resolve conflicts and issues that may arise In the role of a Scrum Master, effective communication and collaboration skills are crucial for success. The Scrum Master is responsible for facilitating communication and collaboration within the Scrum team and with stakeholders. This includes facilitating meetings, helping the team to identify and remove barriers to progress, and mediating conflicts or issues that may arise. One way that becoming a Certified Scrum Master can help with communication and collaboration is by providing a common framework and understanding of the Scrum framework and its principles. This common understanding can help team members to more effectively communicate and collaborate with one another, as they all have a shared understanding of the goals and processes being used. In addition to providing a common framework, the Certified Scrum Master training also emphasizes the importance of effective communication and collaboration within the Scrum team. This includes skills such as active listening, facilitating group discussions, and conflict resolution. By learning and practising these skills, a Scrum Master can become more effective at facilitating communication and collaboration within the team and with stakeholders. The role of the Scrum Master as a facilitator and mediator is crucial for the success of a  Scrum team. By becoming a Certified Scrum Master and developing strong communication and collaboration skills, a Scrum Master can help the team to work effectively and efficiently towards their goals. Enhanced leadership skills with the role of the Scrum Master as a leader and coach As