Scrum Events - Scrum Framework

Scrum Events allows teams and organizations to iteratively and incrementally deliver valuable products of “Done” working releasable software within a Sprint. Key Scrum Events are Sprint, Sprint Planning, Sprint Goal, Daily Scrum, Sprint Review & Sprint Retrospective.

Scrum defines five Scrum Events or Scrum Ceremonies, The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. As per the Scrum guide, Sprint is also considered as an event that is a container of the above four events.

Scrum Events – Sprint

Scrum Teams work in short timeframes called sprints. It is the heart of Scrum with short regular iterations with a time-box of 2 to 4 weeks. Sprints happen one right after the other, with no breaks, to maintain a steady project cadence. A new Sprint starts immediately after the conclusion of the previous Sprint.

Uncertainty can impact sprint length as it can come in a variety of forms: Requirements are not well defined; technology is new and potentially risky; an algorithm or interface may be difficult to implement. Similarly, stakeholder engagement and the timelines for the product release to market can impact the sprint length. Also when a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. The team should agree on the length of the Sprint, taking the size and complexity of the project into consideration. So below are a few key factors that are considered during deciding on sprint length.

The level of uncertainty over the technology to be used by the scrum team while developing the work product.
The risk of being disengaged from the stakeholders during the execution of the work product.
The ability and timeline to go to market with the product release.

Key features of a sprint

Time-boxed
Establishes a WIP Limit
Forces Prioritization
Demonstrates Progress
Avoid Unnecessary Perfections
Motivates Closure
Improves Predictability
Short Duration
Ease of Planning
Fast Feedback
Improved Return on Investment.

A few benefits of consistent sprint lengths are

It helps to establish a consistent pattern of delivery.
It helps the team to objectively measure progress.
It provides a consistent means of measuring team velocity. Velocity is a measure of the amount of work a Team can tackle during a single Sprint.

Each sprint begins with a plan and ends with a review of the work completed and an additional review of the way in which the team worked together.

During each sprint, the entire Scrum Team works together to complete one or more increments of a larger overall product or project. Each completed increment must be potentially releasable, meaning that it could theoretically be delivered as-is. In other words, each increment must be fully tested and fully approved by the end of the sprint.

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. A burndown chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.

Cancellation of Sprint

The Product owner is responsible for canceling the Sprint under the influence of the stakeholder, developers, or the Scrum Master.

The Sprint cancellation can be done before the time-box is completed.
It can also be done when the Sprint goal becomes obsolete. This might occur if the company changes direction or if the market or technology conditions change

When a Sprint is canceled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.

Scrum Events – Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. Sprint Planning is a time-boxed meeting, usually fixed to 8 hours for a one-month Sprint, or shorter for Sprints of less than a month. This planning is done by the whole scrum team collaboratively.

There is no pre-requisite for a sprint planning scrum team prefers to have “ready” items at the top of the Product Backlog before Sprint Planning, which is done through Product Backlog refinement. However, nothing stops our flow of Sprints, and for example, they do not delay the Sprint because the items are not ready. In such cases, the “unready” items would not be selected for the Sprint and refined during the Sprint. “Ready” items are those that are clear, and small enough to fit into one Sprint.

Sprint Planning answers the following:

Why is this Sprint valuable?
What can be done with this Sprint?
How will the chosen work get done?

The first part of this meeting addressed below mentioned items

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog. It provides guidance to the Developers on why it is building the Increment.

The second part of this meeting addressed below mentioned items

The Developers work to forecast the functionality that will be developed during the Sprint. By collaborating with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal. If a sprint needs to be reprioritized in hurry for any reason then the whole scrum team is involved during reprioritizing because together they can consider both business value and feasibility of delivering increment without impacting Sprint Goal.

The third part of this meeting addressed below mentioned items

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. The Scrum Team may also invite other people to attend this meeting to provide technical or domain advice. If the work turns out to be different than the Developers expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Sprint Goal

The Sprint Goal is the single objective for the Sprint. This is a commitment by the Developers but still, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. During the sprint, if the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

It provides guidance to the Developers on why it is building the Increment. It serves to promote self-management and creativity. It is created collaboratively by the whole scrum team during the Sprint Planning meeting.

Sample Sprint Goal: Develop the checkout process: pay for an order, credit/debit card checkout & shipping.

Benefits of Sprint Goal

Supports Prioritization
Creates Focus and Facilitates Teamwork
Helps Obtain Relevant Feedback
Makes it Easier to Analyze the Feedback
Supports Stakeholder Communication

To determine what the Sprint Goal should be

Why do we carry out the Sprint? Why is it worthwhile to run a sprint? What should be achieved?
How do we reach its goal? Which artifact, validation technique, and test group are used?
How do we know the goal has been met? For instance, at least three of the five users carry out the usability test successfully in less than a minute

Few things to consider during Sprint Goal creation

Is it S.M.A.R.T? (specific, measurable, attainable, relevant, and time-bound)?
Is it visible? e.g. Taskboard or Jira Dashboard etc.
Is it referred to frequently throughout the sprint? e.g. daily scrum purpose is to “inspect progress toward the sprint goal”.

Capacity-based sprint planning, also called Commitment-based Sprint planning, is based on the team’s available capacity (in hours) for the sprint and tries to fill that capacity effectively without overburdening or under-committing the team members.

Key benefits are

The capacity of the teams may vary from one sprint to another, depending on holidays, leaves, or other commitments. So, every sprint is not an average sprint.
The story points and the velocity are the two important measures over multiple sprints for estimating the release dates. But story points are found to be coarse-grained for planning the details of a two-week sprint. If you consider the hours, they are fine-grained enough and much useful for estimating concrete tasks.
Lastly, in Sprint Planning, the user stories allow the development team and the Product Owner to consider each story in detail to develop a shared understanding of the end product.

Velocity-based sprint planning uses velocity which helps the team to identify how much progress they can aim to make in a given sprint. Velocity is calculated by adding all the story points given to each user story that is completed by the end of the sprint. It measures output, but not the outcome.

Key benefits are

Accounts uncertainty in planning – Since the size of a user story is a mixture of effort and uncertainty this method takes uncertainty into account while planning.
Effective release planning – The detailed sizes of the stories can lead to a more value-added release planning with the identified dependencies/assumptions and their impact on the release flow.
Accounts overhead within the user story – velocity-driven commitment encourages the completion of the story in all aspects. When the team inspects to increase the velocity, they will point out the waste that is affecting the velocity most and the stakeholders can work on it.
Enforces a culture of honoring the commitment – After a few sprints of achieving the commitment, the team gets used to it and the culture causes the team to actively reduce waste or inspect their own development processes triggering continuous improvement.

Scrum Events – Daily Scrum

Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is normally a 15-minute meeting for the Developers. It is an opportunity to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. It improves communications, identifies impediments, promotes quick decision-making, and consequently eliminates the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of Sprint’s work.

It is held at the same time and placed each working day to reduce complexity. The Scrum Master ensures that the Developers have the meeting, but the Developers are responsible for conducting the Daily Scrum. They can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

The Daily Scrum is an internal meeting for the Developers. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Scrum Events – Sprint Review

Sprint reviews are held at the end of the Sprint to inspect the outcome of the Sprint and determine future adaptations. Primarily focused on the product being developed, specifically on the potentially shippable product increment created during the sprint. During the Sprint Review, the Scrum Team presents the results of their work to key stakeholders, and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Product Owner has the option to release any of the completed functionality.

The Sprint Review includes the following elements:

Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
The Developers discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
The Developers demonstrates the work that it has “Done” and answers questions about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Scrum Events – Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and plan ways to increase quality and effectiveness. Only the Scrum team attend this meeting.

This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

Scrum Guide: Click Here