The events in Scrum includes:
- Sprint
- Sprint planning
- Daily scrum
- Sprint review
- Sprint Retrospective
Sprint
Sprint is a period of time wherein all tasks of Scrum take place, including: planning, execution, collaborating, resolving difficulties, reviewing and improving. All tasks are expected to take place in a specific time frame in order to reach a certain goal of value transferring at the end of each period.
The mechanism of minimizing the scope of work into a single sprint helps the Scrum group becomes capable of continuously transferring value and receive feedback from customers (or end-users) to adjust the direction for the future.
Each sprint can be considered a small project with the length of 1-4 weeks, depending on the context, the project’s particularities and feedback information requirements. Particularly, a project with a lot of volatilities tends to have a shorter Sprint. On the contrary, an “unpredictable” project that has no pressure on product release progress may have a longer Sprint.
The shorter the sprint is, the more pressure there can be and the management through event interactions tends to take larger proportion.
Each Sprint has a clear goal that must be built into the Sprint. Having a blueprint and a flexible plan beforehand will navigate the development progress.
Internally, repeating a discipline involving many important things in the form of a clearly structured set of imperative events could help the team build, maintain, and improve its ability to collaborate internally as well as with customers, thus increase efficiency through time.
Cancel a Sprint
A Sprint might be canceled if the goal is no longer relevant, or in other words, not providing value. It’s usually the case when a company changes its business direction or the technology changes.Â
A Sprint can be canceled before the period ends. Only the Product Owner has the authority to cancel the Sprint.
However, due to the relatively short duration of each Sprint, canceling a Sprint would waste resources, as people have to spend time and effort planning a new Sprint. Sprint cancellation usually causes some damage to the Development team and it happens very rarely.
When the Sprint is canceled, the finished product parts will be reviewed. If certain parts of the work are transferable, the Product Owner can approve. Incomplete Product Backlog categories will be re-evaluated and returned to the Product Backlog for further development. The work done there will quickly expire and must be regularly re-evaluated.
Sprint planning

Time: at the beginning of a Sprint
Duration: 2 hours corresponds to 1 working week of Sprint. For example, with a 1-month Sprint, the time frame is about 8 hours. The time spent on two parts of the event is equal.
The Product Owner may be absent but should always be available to assist the Development Team to clarify items when needed.
Sprint planning is divided into two parts:
Part 1: Select the to-dos in the Sprint
Part 2: Decide the method to complete all previously selected tasks
Part 1: Select the to-dos in the Sprint
– The results of selecting the tasks to do in the Sprint are:
+ Sprint Goal: A Sprint Goal is a short description of the expected results to be achieved after the Sprint ends, serves as a guide for the Development Team during the Sprint and helps the team make reasonable decisions to achieve the goal.
+ A list of Product Backlog items selected for development during the Sprint.
– Process:
* The Product Owner presents the goal he wants to achieve this Sprint.
* The Product Owner clarifies the top items in Product Backlog (the highest priority items) so that the team has a better understanding of those. The Product Owner needs to make it clear that the number of Product Backlog items is larger than the number of item that the Development Team can complete in a Sprint (this number is based on the previous Sprints or based on experience).
For example, if it is estimated that the group is capable of doing 5 items, then at least the whole group must thoroughly understand roughly 8 or more items. That helps the team have enough information to make accurate selection decisions for this Sprint. Usually, these items have been thoroughly analyzed and clarified a few Sprints before through smoothing the Product Backlog, so the work in this section doesn’t take too long.
* The team will work together to figure out what to do in the Sprint.
* Based on the Sprint Goal and the current capacity, the Development Team selects the items that they believe can be accomplished in this Sprint, starting with the top items in the Product Backlog. The Development Team uses the average production rate in the past and the team’s capabilities in the current Sprint to decide which Product Backlog items to deploy in this Sprint.
The Development Team needs to discuss with the Product Owner if they want to select some low priority items at the bottom of the Product Backlog (usually happens when there is a dependency or match with the items selected by customers).
* At the end, the Development Team and the Product Owner agree on the Sprint goal and the list of items to be delivered during this Sprint.
Part 2: Decide the method to complete all previously selected tasks
Part two of the Sprint Planning session aims to answer the question: How to complete the selected tasks? The result of this part is the Sprint Backlog.
The Sprint Backlog is the work sheet used by the Development Team during the Sprint, consisting of the selected Product Backlog items and the worklist corresponding to each of those Product Backlog items.
The development team starts to design the system and makes a to-do list. For each item in the list, the team will split them up into specific tasks and estimate the effort (in hours or points, which will regularly be adjusted by the Development Team during the implementation process) to complete each task. The tasks are usually small enough to complete in a day or less.
The total effort for all items on the Sprint Backlog is used by the team to track the Sprint progress. This value is immediately updated to the Sprint Backlog and is also used to create a Sprint Burndown chart to track Sprint progress. After each business day, members will simultaneously update the Sprint Backlog and the Burndown chart with the new values.
Example: Burndown Chart in Sprint 5 by the LAI AliExpress Review team: More work completed than originally planned.
In case the amount of work is too much or too meager, the Development Team can talk to the Product Owner to remove or add other items. In part 2, the Development Team may need more support from outside of the team to analyze and estimate the work better.
Longer-term planning
In Scrum, Sprint planning is too short, which is not good enough for planning.
Planning can take place at many different levels. Sprint planning for Development Teams is a new thing.
In addition, longer-term planning tasks, such as: Release Planning, Portfolio Planning or Product Strategy still need to be effectively executed at higher levels of the organization.
Product planning is usually delegated to the Product Owner. This plan will rely heavily on estimating the size of the Product Backlog items, calculating the speed of completing work by the Development Team, as well as considering business priorities for the under-development products. Once the estimated work for each item has been completed, the team predicts how quickly a meaningful release can be done based on its speed.
- Daily Scrum
The Daily Scrum takes place at a regular daily basis, at a fixed location and time frame. It is a short exchange session that does not last more than 15 minutes.
The purpose is to help the Development Team synchronize works and plan for the next working day.
Roles of members in the Daily Scrum:
> Development Team members must fully participate and answer these 3 questions:
- What have I done from the previous Daily Scrum until now to help the Development Team achieve the Sprint Goal?
- What will I do from now to tomorrow to help the Development Team move towards the Sprint goal?
- What obstacles am I facing that are preventing the team from achieving this Sprint Goal?
> Scrum Master:
- Ensure favorable conditions for the Development Team to conduct the event such as: location, time frame, ensuring synchronous coordination in work instead of getting caught up in other issues.
- Observe throughout the meeting to feel the atmosphere and potential problems. These issues will be noted and can be managed in the Obstacle List and resolved gradually.
> The Product Owner and some others may attend but do not play any role in this event.
- Sprint Review
The Sprint Review is an audit and adaptation of the under-construction products. At the end of the review, the product path and Product Backlog can be better adapted to the new development situation.
Time: After the Sprint deployment ends.
Duration: 1 hour corresponds to 1 working week of Sprint
Purpose: to check the growth achieved in the previous Sprint
All participants are completely free to ask questions and contribute their ideas. Participants include:
- Development Team
- Product Owner
- Scrum Master
- Others: Customers, users, stakeholders, etc.
During the Sprint Review:
+ Development Team and Product Owner talk to each other to learn about the situation, take note of each other’s recommendations.
+ The Product Owner learns and understands the situation of the product and of the Development Team.
+ Development Team learns and understands the situation of the Product Owner and the market.
Contents of the Sprint Summary:
- Product Owner presents Sprint Goal
- Development Team presents completed results
- Directly use the product

* Notes:
- Do not present features that are not “completed”.
- Responses given – Product Backlog can be re-prioritized.
- The Product Owner should use acceptance testing techniques to evaluate features.
- Product demo is a content of the Sprint Review session. In addition, there is an equally important content that is discussion and collaboration among the participating members.
- Sprint Retrospective
Time: End of Sprint, right after the Sprint Review and before the next Sprint Planning session.
Duration: 45 minutes corresponds to 1 working week of Sprint. For example, with a 2-week Sprint, the time frame is about 1 hour 30 minutes.
Purpose (according to the Scrum Documentation):
- How was the last Sprint audit in terms of people, relationships, processes, and tools.
- Identify the sequence and arrange things that worked well and things that need improvement.
- Make a plan to improve the way the Scrum Team works.
Participants:
- The development team and the Scrum Master are required to participate.
- The Product Owner may or may not be involved.
- People invited by the Scrum Master to contribute ideas to the team.
The Scrum Master strives to guide the team through each step of the improvement activity, has an improvement method, and comes up with a SMART improvement plan.
There should be 1 person in the support role for the Sprint Retrospective. This person can be the Scrum Master or someone from outside the team (a common practice is to exchange between Scrum Masters).
[picture]
[Key activities in the Sprint improvement session
– List the things that have been done well
– List the things that have not been done wellÂ
– Provide some improvement actions
– Improvement plan for next sprint]
Practically, Sprint Improvement sessions should be placed in a closed cycle: Plan – Do – Check – Act, which is a Kaizen continuous improvement process. Specifically, once an improvement plan is in place, the Scrum Team needs to put it into action in the next Sprint, then track whether the improvement is effective, test in the next Sprint and adapt. Therefore, one of the focuses of the improvement meeting is to check whether the previous improvement plan worked, and how to correct it. To do this, the Scrum Team can maintain an Improvement Log (Kaizen Log) to track how well each improvement is performing over time. This document should be maintained and updated regularly by the Scrum Master, and can serve as input for more systematic improvements and replication to other teams.
In an organization with an effective knowledge management system, these improvements can be classified and shared widely (in the form of wikis, blogs or inside news) to spread the initiative at a larger scale.
Continuous improvement activities are most effective when they become habits of individuals and groups and become the culture of the organization.
Sprint improvement techniques:
Glad – Sad – Mad (most commonly used)
SpeedBoat
Start – Stop – Continue
5whys
Lean Coffee
* Reference source: The Scrum Handbook