Articles

Scrum Agile meetings are essential components of the Scrum framework, providing structured opportunities for collaboration, planning, and feedback within agile teams. These meetings include the Daily Stand-up, where team members discuss progress, obstacles, and plans for the day; Sprint Planning, where the team plans the work to be completed in the upcoming sprint; Sprint Review, where the team showcases completed work to stakeholders; and Sprint Retrospective, where the team reflects on the sprint and identifies areas for improvement.

Open communication and transparency play crucial role in Scrum projects. Unlike the popular view that most meetings are waste of time, Scrum lays a lot of emphasis on conducting highly focused, time-boxed and effective meetings to allow transparency and free flow of information.

In this article we are going to briefly look at some of the more important meetings in Scrum.

Prioritized Product Backlog Review Meetings

The Product Owner may have multiple and separate meetings with relevant Business Stakeholder(s), the Scrum Master, and the Scrum Team to ensure that he or she has enough information to make updates to the Prioritized Product Backlog. The intent of the Prioritized Product Backlog Review Meetings is to ensure that User Stories and Acceptance Criteria are understood and are written properly by the Product Owner so that they reflect the actual business stakeholder (customer) requirements and priorities; User Stories are understood by everyone in the Scrum Team; and that high priority User Stories are well-refined so that the Scrum Team can properly estimate and commit to such User Stories.

Sprint Planning Meeting

In Sprint Planning Meetings, the Scrum Team gets together to plan the work to be done in the Sprint. The team reviews the Estimated User Stories at the top of the Prioritized Product Backlog. The Product Owner is present during this meeting in case clarification of User Stories or priorities are required. To help ensure that the group stays on topic, this meeting should be Time-boxed, with the standard length limited to two hours per week of Sprint duration. This assists in preventing the tendency to stray into discussions that should actually occur in other meetings, like the Release Planning or Sprint Review Meetings. As part of this meeting the entire Scrum Team will commit to delivering a subset of User Stories from the Prioritized Product Backlog in the Sprint.

Daily Standup Meeting

The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. Team members assemble to report their progress in the Sprint and plan the day’s activities. The meeting duration is very short, and all members of the Scrum Team are expected to attend. In the Daily Standup Meeting, facilitated by the Scrum Master, each Scrum Team member provides information in the form of answers to three specific questions:

1. What have I done since the last meeting?
2. What do I plan to do before the next meeting?
3. What impediments or obstacles (if any) am I currently facing?

Sprint Review Meeting

The Scrum Core Team members and relevant Business Stakeholder(s) participate in Sprint Review Meetings to accept the deliverables which meet the User Story Acceptance Criteria and reject unacceptable deliverables. These meetings are convened at the end of every Sprint. The Scrum Team demonstrates the achievements from the Sprint, including the new functionalities or products created. This provides an opportunity for the Product Owner and Business Stakeholder(s) to inspect what has been completed so far and to determine if any changes should be made in the project or processes in subsequent Sprints. The Sprint Review Meeting is time-boxed to four hours for a one-month Sprint.

 Retrospect Sprint Meeting

The Retrospect Sprint Meeting is Time-boxed to one hour for each week of the Sprint duration. For example, for a four-week Sprint, the Time-box for the Retrospect Sprint Meeting should be four hours. This meeting is conducted as part of the Retrospect Sprint process. During this meeting, the Scrum Team gets together to review and reflect on the current Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. The team discusses what went well during the previous Sprint and what did not go well, the goal being to learn and make improvements in the Sprints to follow. Some improvement opportunities or best practices from this meeting could also be updated as part of the Scrum Guidance Body documents.

Scrum Agile framework serves as a roadmap for organizations seeking to embrace Agile principles and practices, providing a structured methodology for delivering high-quality products and services. Through its iterative and incremental approach, the Scrum Agile Framework empowers cross-functional teams to efficiently tackle complex projects, fostering transparency and accountability throughout the development process. The SBOK™ Guide meticulously outlines the roles, ceremonies, and artifacts that form the backbone of the Scrum framework, enabling teams to effectively plan, execute, and monitor their work. By embracing core principles such as self-organization, inspection, and adaptation, organizations can harness the full potential of the Scrum Agile Framework to drive innovation, respond to change, and deliver tangible business value. Thus, by leveraging the guidance provided in the SBOK™ Guide, organizations can embark on a transformative journey towards Agile excellence, positioning themselves for sustained success in today's dynamic business landscape.The Scrum Framework is a popular Agile methodology used in project management and software development. It is designed to help teams work together efficiently and effectively to deliver high-quality products. Scrum emphasizes iterative progress, collaboration, and flexibility, allowing teams to respond to changing requirements and feedback.

Scrum framework requires a change in mindset from traditional methods. The central focus has moved from scope in Waterfall methods to achieving maximum business value in Scrum. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Scrum, quality and constraints can be altered to achieve the main objective of attaining maximum business value.

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling. Changing requirements from customers have led to an increased pressure on businesses to adapt and change their delivery methods.

Scrum methods are more successful in the current market, which is marked by unpredictability and volatility. Scrum methods are based on inspect-adapt cycles as opposed to the command and control structures of the Waterfall method.

Scrum projects are completed in an iterative manner wherein the functionalities with the highest business value are completed first. Various cross-functional teams work in parallel across Sprints to deliver potentially shippable solutions at the end of every Sprint.

Because each iteration results in a shippable solution (which is a part of the overall product), there is a measurable objective that the team has to accomplish. This ensures that the team is progressing and the project will be completed on time. Traditional methods do not present such timely checks and, therefore, result in situations in which the team might get off schedule and end up with a lot of work toward the end.

As the customer regularly interacts with the team, the work completed is regularly reviewed; thus, there is assurance that the progress is per customer specifications. However, in Waterfall there is no such interaction as the work is carried out in silos, and there is no presentable functionality until the end of the project.

In complex projects, where the customer is unclear about what they want in an end product and functionality requirements keep changing, the iterative model is more flexible in ensuring that these changes can be included before the project is complete.

However, when completing simple projects with well-defined functionalities, and when the team has previous experience completing such projects (therefore, estimation would be accurate), the Waterfall method can be successful.

Given below is a table to get a better idea about the differences in Scrum and Waterfall.