In the previous section, I introduced you to the fundamental concepts of the Scrum team’s nature and roles. In this section, we’ll learn more about Scrum events, artifacts, and the definition of “done.”

5. Scrum events

Regulated events in scrum create consistency, reducing meetings that are not defined in scrum. All events have a clear timeframe, i.e. a maximum time period has been specified for each event. When a sprint begins, its duration is fixed and cannot be reduced or increased. The remaining events can be terminated whenever the event’s purpose is met, ensuring that an appropriate amount of time is used without waste. All other events are included in a sprint. Each scrum event is a formal opportunity to test and fine-tune. These events are specifically designed to ensure transparency and inspection. Without these events, not only will there be less transparency, but also less opportunity for inspection and adjustment.

5.1 Sprint

The sprint is at the heart of Scrum. Each Sprint has a timeframe of one month or less (typically two to four weeks) in which an increment of the product is completed, usable, and deliverable. The timeframe of each sprint is consistent throughout development. When a sprint ends, a new sprint begins immediately.
Meetings are held during a sprint, including a sprint planning meeting, a daily meeting, a sprint review meeting, and a sprint retrospective meeting.

During a sprint

• Make no changes that will jeopardize the sprint’s objectives.
• Quality objectives should not be compromised.
• The Product owner and the Development team can clarify and renegotiate the scope of the project. Each Sprint can be viewed as a mini-project that lasts no more than a month. Sprints, like projects, must accomplish something. Each sprint should have a clear goal of what to build, as well as a flexible blueprint and plan for building it, as well as work and output.
  A sprint lasts no longer than one month. When a sprint lasts too long, the definition of what is being built changes, and complexity and risk increase. Sprints enable predictability by ensuring that they are checked and adjusted at least once a month as they progress toward the sprint goal. Sprint also caps the risk cost at one month.

Cancel a sprint

A sprint is canceled before the sprint time frame expires. Only the Product Owner has the authority to cancel a sprint, though this authority can be influenced by stakeholders, the Scrum team, or the Scrum master.
If the Sprint Goal becomes obsolete, the Sprint is canceled. This can occur when the company’s business direction changes, as well as when market or technological conditions change. However, because a Sprint is so short-lived, canceling it is rarely a good idea.
When the Sprint is canceled, the Product Backlog entries that have been completed will be reviewed. If the work is deliverable, the Product Owner will usually accept it. All unfinished Product Backlog items will be re-evaluated and returned to the Product Backlog.
Canceling a Sprint wastes resources because everyone must reassemble for another Sprint planning meeting to begin a new Sprint. As a result, Sprint cancellation has a significant impact on the Scrum team and occurs infrequently.

5.2 Sprint Planning meeting

The Sprint Planning meeting will schedule the work completed during the Sprint. This plan is created with the help of all Scrum team members.
Sprint planning is limited to a maximum of eight hours per Sprint per month. The event is usually shorter for a shorter Sprint. The Scrum Master ensures that the event runs smoothly and that attendees understand what it is all about. The Scrum Master will coordinate and guide the Scrum Team to ensure that the meeting is completed within the time frame specified.
Sprint planning addresses the following issues: What can be accomplished in the next Sprint? What steps must be taken to achieve the handover goal?

What need to be done in this Sprint ?

The Sprint Planning meeting will schedule the work completed during the Sprint. This plan is created with the help of all Scrum team members.
Sprint planning is limited to a maximum of eight hours per Sprint per month. The event is usually shorter for a shorter Sprint. The Scrum Master ensures that the event runs smoothly and that attendees understand what it is all about. The Scrum Master will coordinate and guide the Scrum Team to ensure that the meeting is completed within the time frame specified.
Sprint planning addresses the following issues: What can be accomplished in the next Sprint? What steps must be taken to achieve the handover goal?

How will the chosen task be completed?

The Development Team decides how to build this functionality into a “Done” product within the Sprint after setting the Sprint goal and selecting the Product Backlog items for the Sprint. The Sprint Backlog consists of the Product Backlog items chosen for this Sprint as well as the delivery plan.
Typically, the development team begins by designing the system and the work required to turn the Product Backlog into a working product. Jobs can vary in terms of difficulty or workload. However, during the planning process, the development team plans enough work for the sprint to forecast what it believes it can accomplish in the upcoming Sprint. The Development Team’s planning work for the first days of the Sprint is decoupled at the end of this meeting, usually in units of a day or less. The self-organized development team works on the Sprint Backlog during Sprint planning as well as as needed during the Sprint.
The product owner can assist in clarifying the Product Backlog items that have been chosen. If the Development Team believes it has too much or too little work, it can renegotiate the selected Product Backlog items with the Product Owner. Others may be invited to attend for technical or service area advice by the development team.
By the end of the Sprint Plan, the Development Team should be able to explain to the Product Owner and Scrum Master how they plan to work as a self-organizing team to achieve the Sprint Goal.

Sprint Goal

A Sprint Goal is a set of Sprint objectives that can be met by implementing the Product Backlog. Sprint Goals allow the Development Team to be flexible in terms of the functionality deployed during the Sprint. Selected items in the Product Backlog serve a specific purpose, possibly as a Sprint Goal. Sprint goals can be any combination that causes the Development Team to collaborate rather than work independently.
The Development Team keeps the Sprint Goal in mind as it works. The team uses function and technology to achieve the Sprint Goal. If the work differs from what the Development Team desires, they will consult with the Product Owner during the Sprint to negotiate the scope of the Sprint Backlog.

5.3 Daily Scrum meeting

The Development Team’s Daily Scrum is a 15-minute time-frame event. Every day of the Sprint, there is a Daily Scrum. The Development Team intends to work there in the next 24 hours. This improves team interaction and performance by reviewing the previous day’s work and the Sprint’s upcoming work plan. To reduce complexity, daily Scrum is held at the same time and place every day.
The development team uses Daily Scrum to track progress toward the Sprint Goal and how work in the Sprint Backlog is being completed. The Development Team’s chances of meeting the Sprint Goal are increased by using daily Scrum. Every day, the Development Team should understand how it plans to collaborate as a self-organizing team to achieve the Sprint Goal and generate the Expected Product Growth at the end of the Sprint.
The Development Team determines the meeting’s structure, which can be carried out in a variety of ways as long as it focuses on progress toward the Sprint Goal. Some development teams will use questions, while others will have a more in-depth discussion. Here’s an example of what you could do:
What did I do the day before to assist the Development Team in meeting the Sprint Goal? What am I going to do today to assist the Development Team in meeting the Sprint Goal? Do I see any impediments or difficulties? The development team or team members usually meet immediately following the Daily Scrum to discuss details, adapt, or replace.
The Scrum Master ensures that the Development Team meets, but it is the Development Team’s responsibility to run the Daily Scrum meeting. The Scrum Master instructs the Development Team to hold daily 15-minute meetings.
The Development Team meets on a daily basis for Scrum. If others are present, the Scrum Master must ensure that they do not disrupt the meeting.
The daily scrum helps to improve communication, eliminate other meetings, identify development obstacles to remove, highlight and promote quick decision making, and raise the level of knowledge of the Team develop. This is a very important inspection and adjustment meeting.

5.4 Review meeting

At the end of each Sprint, a Sprint Review meeting is held to assess progress and adjust the Product Backlog as needed. The Scrum Team and stakeholders discuss what was accomplished during the Sprint during the Sprint review meeting. Attendees discuss what can be done next to optimize value based on that and any changes to the Product Backlog during the Sprint. The Growth product presentation is intended to solicit feedback from customers and foster collaboration. This is an informal meeting, not a status meeting.
Sprints have a four-hour meeting once a month. The event is usually shorter for a shorter Sprint. The Scrum Master ensures that the event runs smoothly and that attendees understand what it is all about. The Scrum Master will guide everyone involved in keeping the meeting on track and on time.
Sprint evaluation consists of the following components:

• The Scrum Team (Product owner, scum master, development team) and key stakeholders invited by the Product owner are among those in attendance.
• The Scum master explains which items in the Product Backlog have been “completed” and which have not;
• The development team discusses what went well during the Sprint, any issues that arose, and how to solve them.
• During this sprint, the development team concentrated on presenting “done” work and answering questions about growth.
• The product owner discusses the Product Backlog, planning objectives, and possible delivery dates based on current progress (if necessary).
• The entire team discusses what to do next, and the review meeting provides valuable input into the Sprint Plan for the following Sprint.
• Examine how the market or product usability has changed. What is the most important thing to do next; and,
• Examine the time, budget, capacity, and market for the next product functionality or capability releases. The Sprint Review meeting produces the revised Product Backlog, which identifies potential Product backlog items for the next Sprint. The Product Backlog can also be adjusted as a whole to accommodate new opportunities.

5.5 Sprint Retrospective meeting

The Sprint Retrospective allows the Scrum Team to examine itself, what worked well and what did not work well in the previous sprint, and come up with a plan for improvement in the next Sprint.
This meeting follows the Sprint Review (Review meeting) and precedes the next Sprint Planning session. Sprints meet once a month for three hours. The event is usually shorter for a shorter Sprint. The Scrum Master ensures that the event runs smoothly and that attendees understand what it is all about.
The Scrum Master ensures that the meeting is constructive and fruitful. The Scrum master guides the team in keeping the meeting on track and on time. The Scrum Master attends the meeting in charge of the Scrum process as a team member.
Sprint Retrospective’s goal is to:

• Examine how the team worked during the previous Sprint (people, relationships, processes, and tools).
• Identify and organize what the team did well and what could have been improved.
• Make a plan to improve the team’s working style in order to achieve good results in the following sprints.
  The Scrum Master encourages the Scrum Team to improve and develop within the framework of the Scrum process in order to make the next Sprint more efficient and enjoyable. The Scrum Team intends to improve the product’s quality during each Sprint review by improving the work process or adjusting the definition of “Done,” as appropriate and not in conflict with the product standards or organization.
  The Scrum Team must decide what improvements it will make in the next Sprint at the end of the Sprint Summary. Making these changes in the next Sprint is a response to the Scrum Team’s inspection. While changes can be made at any time, the Sprint Summary provides a formal opportunity to focus on testing and adaptation.

Scrum Artifacts

Scrum artifacts represent work or value in order to provide transparency as well as the opportunity for inspection and correction. Scrum artifacts are specifically designed to maximize critical information transparency so that everyone has the same understanding of the product.

6.1 Product Backlog

The Product Backlog is a prioritized list of the essential features of the product. This is the only place where requests for changes to the product are made. The Product Owner is in charge of the Product Backlog, which includes the content, availability, and prioritization.
The Product Backlog is never finished. The first one specifies the basic requirements. The Product Backlog evolves in tandem with the product and the environment in which it will be developed. The Product Backlog is ever-changing in order to determine which products must be relevant, competitive, and useful. If a product exists, so does its Product Backlog.
The Product Backlog lists all of the features, functionality, requirements, enhancements, and fixes that will be included in future releases of the product. Product Backlog items have attributes such as description, order, estimate, and value. Product Backlog entries frequently include test descriptions that demonstrate the product’s completeness when “Done.”
As a product is used and adds value, and the market provides feedback, the Product Backlog expands and becomes more complete. Because requirements are constantly changing, the Product Backlog is a living document. Product Backlog changes may occur as a result of changes in business requirements, market conditions, or technology.
The Product Backlog lists all of the features, functionality, requirements, enhancements, and fixes that will be included in future releases of the product. Product Backlog items have attributes such as description, order, estimate, and value. Product Backlog entries frequently include test descriptions that demonstrate the product’s completeness when “Done.”
As a product is used and adds value, and the market provides feedback, the Product Backlog expands and becomes more complete. Because requirements are constantly changing, the Product Backlog is a living document. Product Backlog changes may occur as a result of changes in business requirements, market conditions, or technology. Product Backlog entries, on the other hand, may be updated at any time by the Product owner or at the Product owner’s discretion.
High-priority Product backlog items are frequently more clear and detailed than low-priority items. Greater clarity and detail lead to more accurate estimates; the lower the order, the less detail. The Development Team will refine the Product Backlog items chosen for the upcoming Sprint so that any one item can reasonably be “completed” within the Sprint timeframe. Items in the Product Backlog that the Development Team can “Done” during a Sprint are considered “Ready” for selection in Sprint Planning. Product Backlog entries typically achieve this level of transparency as a result of the aforementioned refining operations.
All estimates are the responsibility of the development team. The Product Owner can influence the Development Team by assisting them in understanding and making decisions, but the Development Team is responsible for providing the final estimate.
Track your progress toward a goal. The total amount of work remaining to achieve a goal can be calculated at any point in time. Every Sprint, the product owner keeps track of the total amount of work remaining (Review meeting). The product owner compares the amount of work left at the previous Sprint Review to gauge progress toward meeting time and goal completion. This data is made available to all stakeholders.
To forecast progress, various trend forecasting methods such as burn-downs, burn-ups, and cumulative flow charts have been used. They have proven to be beneficial. These, however, do not negate the importance of experimentation. It is impossible to predict what will happen in a complex environment in advance. Only what has occurred can be used to make future decisions.

6.2 Sprint Backlog

The Sprint Backlog is a collection of Product Backlog items chosen for the Sprint, as well as a plan for delivering the product and completing the Sprint Goal. The Sprint Backlog represents the Development Team’s prediction of what functionality will be implemented next and the work required to deliver that functionality as an increment.
The Sprint Backlog lists all of the tasks that the Development Team believes are required to meet the Sprint Goal. It includes at least one high-priority process improvement identified in the previous Retrospective meeting to ensure continuous improvement.
The Sprint Backlog is a detailed enough plan to show progress in the Daily Scrum. During the Sprint, the development team revises the Sprint Backlog, and the Sprint Backlog is updated. This happens as the Development Team works through the plan and learns more about the work needed to meet the Sprint Goal.
When a new task is required, it is added to the Sprint Backlog by the Development Team. When work is finished, the remaining work is estimated and updated. Elements of the plan that are deemed unnecessary are removed. During the Sprint, only the Development Team has the ability to change its Sprint Backlog. The Sprint Backlog is a very clear real-time visualization of the work that the Development Team intends to do during the Sprint, and it is solely the Development Team’s responsibility.
Track the Sprint’s Progress The total amount of work remaining in the Sprint Backlog can be calculated at any time during the Sprint. On a daily basis, the Development Team tracks total work remaining for each Daily Scrum session in order to predict the likelihood of meeting the Sprint Goal. The Development Team can manage its progress by tracking work remaining during the Sprint.

Definition of “Done”

When a Product Backlog item is marked as “Done,” everyone must understand what that term means. While this varies greatly between Scrum Teams, members must share a common understanding of what it means to get the work done in order to ensure transparency. This is the Scrum Team’s definition of “Done,” and it is used to track work completion and product growth.
The same definition will guide the Development Team in determining how many Product Backlog items to include in Sprint planning. Each Sprint’s goal is to provide deliverable increments of functionality that adhere to the current Scrum Team definition of “Done.”
For each Sprint, development teams add new features to the product. Because this growth is usable, the Product Owner can choose to release it right away. If the definition of “Done” for an increment is part of the development organization’s conventions, standards, or guidelines, all Scrum Teams must follow it to the letter.
If the development organization’s definition of “Done” is not a convention, the Scrum Team’s Development Team must determine the appropriate definition of “Done” for the product. If multiple Scrum Teams are working on a system or product release, the Development Teams from all Scrum Teams must define a consistent definition of “Done.”
Each increment is added to all previous increments and thoroughly tested to ensure that they all work together.
It is expected that as Scrum teams mature, their definition of “Done” will broaden to include more stringent criteria for higher quality. Any product or system should have a “Done” definition as the standard for any work done on it.
I have finished introducing part 2 and the final part of the Scrum overview above. Hopefully, after reading these two articles, you have a better understanding of scrum and can apply it to your project.