What is a Retrospect Sprint Meeting?

How is the Retrospect Sprint Meeting related to the ‘inspect-adapt’ aspect of Scrum?

The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework

and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated

or moderated by the Scrum Master. It is recommended, but not required for the Product Owner

to attend. One team member acts as the scribe and documents discussions and items for future

action. It is essential to hold this meeting in an open and relaxed environment to encourage full

participation by all team members. Discussions in the Retrospect Sprint Meeting encompass both

what went wrong and what went right. Primary objectives of the meeting are to identify three

specific things:

1) Things the team needs to keep doing: best practices

2) Things the team needs to begin doing: process improvements

3) Things the team needs to stop doing: process problems and bottlenecks

These areas are discussed and a list of Agreed Actionable Improvements is created.

Other tools used in the Process of Retrospect Sprint are:

1. ESVP

2. Speed Boat

3. Metrics and Measuring Techniques

4. Scrum Guidance Body Expertise

The outputs of the Retrospect Sprint are:

1. Agreed Actionable Improvements

2. Assigned Action Items and Due Dates

3. Proposed Non-Functional Items for Prioritized Product Backlog

4. Retrospect Sprint Log(s)

5. Scrum Team Lessons Learned

6. Updated Scrum Guidance Body Recommendations

How to identify risk?

Risk is defined as an uncertain event that can affect the objectives of a project and may contribute to

its success or failure. Risks with a potential for positive impact on the project are called opportunities,

whereas threats are risks that could negatively impact a project. Managing risk must be done

proactively, and it is an iterative process that should begin at project inception and continue throughout

the life of the project. The process of managing risk should follow some standardized steps to ensure

that risks are identified, evaluated, and a proper course of action is determined and acted upon

accordingly.

Risks should be identified, assessed, and responded to based, primarily, on two factors: the probability

of an occurrence and the probable impact in the event of the occurrence. Risks with a high probability

and impact rating should be addressed before those with a lower rating. In general, once a risk is

identified, it is important to understand the basic aspects of the risk with regard to the possible causes,

the area of uncertainty, and the potential effects if the risk occurs.

Difference between Risks and Issues

Risks are the uncertainties related to a project that could significantly alter the outcome of the project

in a positive or negative way. Since risks are future uncertainties, they have no current impact on the

project, but could have a potential impact on the future. The following are some examples of risks:

• Even after extensive training, the customer service representatives might not be ready to take

orders on the go-live date.

• The painting crew might be delayed due to heavy rain, which could negatively impact the

project schedule.

Issues are generally well-defined certainties that are currently happening on the project: so there is no

need for conducting a probability assessment as we would for a risk. Issues must be dealt with. Some

examples of issues include the following:

• Funding is not approved.

• Requirements are unclear.

Risks, if not addressed in time, may become issues. The goal of risk management is to be prepared, with

plans in place to deal with any risks that may occur.

Risk Attitude

Stakeholders include all people or organizations impacted by the project as well as those that have the

ability to impact the project. It is important to understand the risk attitude of the stakeholders. Risk

attitude is influenced by the following three factors:

1. Risk appetite: refers to how much uncertainty the stakeholder or organization is willing to take

on.

2. Risk tolerance: indicates the degree, amount, or volume of risk stakeholders will withstand.

3. Risk threshold: refers to the level at which a risk is acceptable to the stakeholder organization. A

risk will fall above or below the risk threshold. If it is below, then the stakeholder or organization

is more likely to accept the risk.

Essentially, the risk attitude of the stakeholders determines how much risk the Stakeholders consider

acceptable, and hence when they will decide to take actions to mitigate potential adverse impacts of

risks. Therefore, it is important to understand the tolerance levels of the stakeholders in relation to

various factors including cost, quality, scope, and schedule.

Utility Function is a model used for measuring stakeholder risk preference or attitude toward risk. It

defines the stakeholders’ level or willingness to accept risk. The three categories of Utility Function are

the following:

1. Risk Averse: Stakeholder is unwilling to accept a risk no matter what the anticipated benefit or

opportunity.

2. Risk Neutral: Stakeholder is neither risk averse nor risk seeking, and any given decision is not

affected by the level of uncertainty of the outcomes. When two possible scenarios carry the

same level of benefit, the risk neutral stakeholder will not be concerned if one scenario is riskier

than the other.

3. Risk Seeking: Stakeholder is willing to accept risk even if it delivers a marginal increase in return

or benefit to the project.

Retrospect Scrum Project: The Lessons to be learnt

After a project is over, it is important that the Scrum team and the stakeholders look back and discuss the lessons learnt during the course of the project. This in itself is a process, called the Retrospect project, which comes right after the deliverables are shipped.
The Release phase emphasizes delivering the Accepted Deliverables to the customer and identifying, documenting, and internalizing the lessons learned during the project. In the Retrospect Project process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

Inputs

Scrum Core Team(s)

Chief Scrum Master

Chief Product Owner

Stakeholder(s)

Scrum Guidance Body Recommendations

In Retrospect Project process, Scrum Guidance Body Recommendations can include a repository of internal templates that support the future projects, and guidance for conducting the Retrospect Project Meeting. The guidance provided can relate to administrative procedures, audits, evaluations, and project transition criteria. Often, they also include how the organization will maintain the knowledge base of lessons learned and information from all projects.

Tools

Retrospect Project Meeting*

The Retrospect Project Meeting is a meeting to determine ways in which team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not Time-boxed and may be conducted in person or in a virtual format. Attendees include the Project Team, Chief Scrum Master, Chief Product Owner, and Stakeholder(s). During the meeting, lessons learned are documented and participants look for opportunities to improve processes and address inefficiencies.

Other Tools for Retrospect Project

Some of the tools used in the Retrospect Sprint process can also be used in this process. Examples include:

• Explorer — Shopper — Vacationer — Prisoner (ESVP) exercise
• Speed Boat
• Metrics and Measuring Techniques

Scrum Guidance Body Expertise

In Retrospect Project process, the primary responsibility of the Scrum Guidance Body is to ensure that the lessons learned in each project are not lost and are embedded in the organization. Also, there may be suggestions in the Scrum Guidance Body Recommendations concerning how the Retrospect Project meeting should be conducted.

Outputs

Agreed Actionable Improvements

Agreed Actionable Improvements are the primary output of the Retrospect Sprint process. They are the list of actionable items that the team has come up with to address problems and improve processes in order to enhance their performance in future Sprints.

Assigned Action Items and Due Dates

Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team. Each action item will have a defined due date for completion.

Proposed Non-functional Items for Program Product Backlog and Prioritized Product Backlog

When the initial Prioritized Product Backlog is developed, it is based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review or Retrospect Sprint Meetings. These items should be added to the Prioritized Product Backlog as they are discovered. Some examples of non-functional requirements are response times, capacity limitations, and security related issues.

Updated Scrum Guidance Body Recommendations

The self-organizing and empowered Scrum Team is expected to learn from any mistakes made during a Sprint – and these lessons learned help the teams improve their performance in future Sprints.. These lessons learned may also be documented in Scrum Governance Board Recommendations to be shared with other Scrum teams.

How does Scrum strike a balance between flexibility and stability?

Today almost all industries and markets are exposed to constant changes. Changes come in the

form of government policies, new tax rules, everyday advance in technology, consumer psyche,

product or service demand, media influence, social media trend, buying motivation and many

more. Whatever the reason, ‘Change’ has become an integral part of any business and Scrum helps

organizations become more flexible and open to change.

However, it is important to understand that although the Scrum framework emphasizes flexibility, it

is also important to maintain stability throughout the change process. In the same way that extreme

rigidity is ineffective, extreme flexibility is also unproductive. The key is to find the right balance

between flexibility and stability because stability is needed in order to get work done. Therefore,

Scrum uses iterative delivery and its other characteristics and principles to achieve this balance.

Scrum maintains flexibility in that Change Requests can be created and approved at any time

during the project; however, they get prioritized when the Prioritized Product Backlog is created or

updated. At the same time, Scrum ensures that stability is maintained by keeping the Sprint Backlog

fixed, and by not allowing interference with the Scrum Team during a Sprint.

In Scrum, all requirements related to an ongoing Sprint are frozen during the Sprint. No change is

introduced until the Sprint ends, unless a change is deemed to be significant enough to stop the

Sprint. In the case of an urgent change, the Sprint is terminated and the team meets to plan a new

Sprint. This is how Scrum accepts changes without creating the problem of changing release dates.

Scrum facilitates flexibility through transparency, inspection, and adaptation to ultimately

achieve the most valuable business outcomes. Scrum provides an adaptive mechanism for project

management in which a change in requirements can be accommodated without significantly

impacting overall project progress. It is necessary to adapt to emerging business realities as part

of the development cycle. Flexibility in Scrum is achieved through five key characteristics: iterative

product development, Time-boxing, cross-functional teams, customer value-based prioritization, and

continuous integration.

Scrum follows an iterative and incremental approach to product and service development, making it

possible to incorporate change at any step in the development process.

Advantages of Using Scrum listed

Scrum methodology 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.

	Scrum	Traditional Project Management
Emphasis is on	People	Processes
Documentation	Minimal—only as required	Comprehensive
Process style	Iterative	Linear
Upfront planning	Low	High
Prioritization of Requirements	Based on business value and regularly updated	Fixed in the Project Plan
Quality assurance	Customer centric	Process centric
Organization	Self-organized	Managed
Management style	Decentralized	Centralized
Change	Updates to Productized Product Backlog	Formal Change Management System
Leadership	Collaborative, Servant Leadership	Command and control
Performance measurement	Business value	Plan conformity
Return on Investment	Early/throughout project life	End of project life
Customer involvement	High throughout the project	Varies depending on the project lifecycle

Can you skip Release Planning in Scrum?

The answer to this question is No. Release planning is a very important part of the Scrum process. In this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.

Release Planning Sessions

Release Planning Sessions are conducted to develop a Release Plan. The plan defines when various sets of usable functionality or products will be delivered to the customer. In Scrum, the major objective of a Release Planning Meeting is to enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing – so that they can align with the expectations of the Product Owner and relevant stakeholders (primarily the project sponsor).

Release Planning Schedule

A Release Planning Schedule is one of the key outputs of the Conduct Release Planning process. A Release Planning Schedule states which deliverables are to be released to the customers, along with planned intervals, and dates for releases. There may not be a release scheduled at the end of every Sprint iteration. At times, a release may be planned after a group of Sprint iterations are completed. Depending on the organization’s strategy, Release Planning sessions in projects may be driven by functionality, in which the objective is to deliver, once a predetermined set of functionality has been developed, or the planning may be driven by date, in which the release happens on a predefined date. The deliverable should be released when it offers sufficient business value to the customer.

How is Change management embedded into the Scrum Framework?

Depending on the industry and type of project, the priority of features and requirements for a

project may remain fixed for significant durations of time, or they may change frequently. If project

requirements are generally stable, there are typically only minor changes made to the Prioritized

Product Backlog throughout development, and Scrum Teams can work sequentially completing

requirements that will provide maximum customer value as prioritized in the Prioritized Product

Backlog. The length of the Sprint is usually longer, 4 to 6 weeks, in such stable environments.

If project requirements change throughout the project, for example due to changed business

requirements, the same method continues to be effective. Before beginning a Sprint—during the

Create Prioritized Product Backlog or Groom Prioritized Product Backlog processes—the highest

priority requirements in the Prioritized Product Backlog are typically selected to be completed in

that Sprint. Because changes have been accounted for in the Prioritized Product Backlog, the team

only needs to determine how many tasks they can accomplish in the Sprint based on time and

resources provided. Change management is executed in the ongoing processes of prioritizing and

adding tasks to the Prioritized Product Backlog.

If there is a Change Request that may have significant impact on a Sprint in progress, the Product

Owner, after consultation with relevant stakeholders, decides whether the change can wait until

the next Sprint or represents an urgent situation which may require ending the current Sprint and

starting a new one.

Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint

begins. If the required change is so important that the results of the Sprint would be worthless

without it, then the Sprint should be terminated. If not, then the change is incorporated into a later

Sprint.

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint

begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and

has spare capacity to implement additional User Stories, the team can ask the Product Owner which

additional User Stories should be included in the current Sprint.

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their

work and effort. An additional benefit is that the team does not have to worry about managing

changes once they start working on a Sprint. This is a big advantage of the Scrum framework when

compared to traditional project management.

Because changes are not allowed during a Sprint, the impact and frequency of expected changes

may have an impact on the decision related to the length of the Sprint when it is determined during

the Conduct Release Planning process.

If project requirements are generally stable and major changes are not expected in the near future,

the Length of a Sprint may be set to be longer, 4 to 6 weeks. This provides stability to the Scrum

Team members to work on the Prioritized Product Backlog requirements for lengthy periods of time

without having to go through the Create User Stories, Approve, Estimate and Commit User Stories,

Create Tasks, Estimate Task, and other related processes that are conducted for every Sprint.

However, if project requirements are not very well defined or if significant changes are expected

in the immediate future, the Length of Sprint may be relatively shorter, 1 to 3 weeks. This provides

stability to the Scrum Team members to work on shorter Sprints and deliver results, which can

be evaluated by the Product Owner and stakeholders at the end of the Sprint. This also provides

enough flexibility for them to clarify requirements and make changes to the Prioritized Product

Backlog at the end of each Sprint.

To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-
boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend

up to 6 weeks.

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any

revised estimates), and the status of higher priority requirements. Any new or revised User Stories

resulting from changes to business requirements, customer requests, external market conditions,

and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is grooming the Prioritized Product Backlog. To

ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next

two to three Sprints are refined into suitable User Stories, it is recommended that the Product

Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog

grooming. The Product Owner is responsible for adding and revising Prioritized Product Backlog

Items in response to any changes and is responsible for providing more detailed User Stories that

will be used for the next Sprint.

Grooming helps ensure that refining of requirements and their User Stories is done well in advance

of the Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of

stories that can be easily broken down into tasks and subsequently estimated. Grooming supports

and enhances the flexibility of the Scrum model by incorporating the latest business and technical

insights into future Sprints.

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during

Groom Prioritized Product Backlog process.

Although the Stakeholder(s) and the Product Owner have the final say on Prioritized Product

Backlog Items and whether to accept or reject any Change Requests presented during Demonstrate

and Validate Sprint, it is the Scrum Master’s responsibility to ensure that the requirements and

Acceptance Criteria are not altered during the Sprint Review Meeting for the User Stories completed

in the current Sprint. This prevents the rejection of completed User Stories based on the fact that

they do not meet newly changed requirements. If any requirements need to be changed, any

corresponding PBI needs to be revised to accommodate the modified requirements in a future

Sprint.

How does Scrum treat risk differently?

Scrum and most of the traditional project management methods define risk as ‘uncertain

event(s) that could positively or negatively affect the achievement of project objectives.’ Also,

risks are identified, assessed, planned for, and communicated continually.

In Traditional project management models, there is emphasis on detailed upfront planning to

identify, assess and determine risk responses for all project risks. During project execution, any

project team member can identify risks and the project manager or the project management

office/project support staff can update them in the risk log/register. The project manager

regularly monitors and controls all risks, and usually identifies specific individuals in the team to

take responsibility for different aspects of risks.

In Scrum, any Scrum Team member can identify risks and the Product Owner can update

the identified risks in the Risk Adjusted Prioritized Product Backlog. The Scrum principles of

Empirical Process Control and Iterative Development enable the Scrum Team to constantly

keep identifying risks and adding them to the Prioritized Product Backlog, where such risks are

prioritized with other existing User Stories in backlog, to be mitigated in subsequent sprints. The

Scrum Team has collective responsibilities for managing all risks for the Sprint.

How does Scrum deviate from tradition?

How does Scrum deviate from tradition?

The emphasis in traditional Project Management is to conduct detailed upfront planning for the project

with emphasis on fixing the scope, cost and schedule – and managing those parameters. Traditional

project management may at times lead to a situation where the plan has succeeded yet the customer is

not satisfied.

The Scrum Framework is founded on the belief that the knowledge workers of today can offer much

more than just their technical expertise, and that trying to fully map out and plan for an ever-changing

environment is not efficient. Therefore, Scrum encourages data-based, iterative decision making. In

Scrum, the primary focus is on delivering products that satisfy customer requirements.

To deliver the greatest amount of value in the shortest amount of time, Scrum promotes prioritization

and Time-boxing over fixing the scope, cost and schedule of a project. An important feature of Scrum

is self-organization, which allows the individuals who are actually doing the work to estimate and take

ownership of tasks.

Managing Changes through Prioritized Product Backlog Grooming

A typical Prioritized Product Backlog will contain all User Stories, their time estimates which also includes any revised estimates, and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is grooming the Prioritized Product Backlog to ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next two to three Sprints are refined into suitable User Stories. It is recommended that the Product Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog grooming. The Product Owner is responsible for adding and revising Prioritized Product Backlog Items in response to any changes and is responsible for providing more detailed User Stories that will be used for the next Sprint.

Grooming helps ensure that refining of requirements and their User Stories is done well in advance of the Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.

A Product Backlog Review Meeting (also referred to as a Prioritized Product Backlog Grooming Session) is a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.

It is important to note that any item in the Prioritized Product Backlog is always open for re-estimation until the Sprint Backlog is finalized in the Create Sprint Backlog process. After that, changes can continue to be made until immediately prior to the Sprint Planning Meeting, if required.