SCRUM Quality, Planning, and

Completion: The Definition of Done

As a product evolves from a high level vision to more detailed requirements, the team will
establish a Definition of Done. This ensures transparency and a shared product vision, as well
as that the team understands the work and can set realistic goals as features are about to be
developed.

In this course, you'll learn the concepts associated with defining done, determining the
appropriate amount of detail for the level of planning, and the relationship between definition
of done and quality, empiricism, and the sprint goal.

Table of Contents
1. Course Overview
2. The Five Levels of Planning
3. Evolution of Product Scope
4. Definition of Done in Product Development
5. The Definition of Done and Product Quality
6. Variations of Defining Done
7. Creating a Definition of Done
8. The Definition of Done and the Sprint Goal
9. The Definition of Done and Empiricism
10. Course Summary

Course Overview
[Video description begins] Topic title: Course Overview. [Video description ends] Hi, I'm
Barb Waters. I'm a certified Scrum Master and PMI, Agile certified practitioner and I have
over 20 years of experience managing projects and implementing process improvements for
Fortune 500 companies. During my career, I've observed and [Video description begins]
Your host for this session is Barbara Waters. She is a Technical Instrutor. [Video description
ends] participated in Scrum across a range of different organizations with the goal of
maximizing value to the customer at the end of each sprint.

In this course, we will explore the definition of done. As a product evolves from a high level
vision to more detailed requirements, the team will need to establish transparency and a
shared product vision. This ensures that the team understands the work, and can set realistic
goals as features are about to be developed. This course presents the concepts associated with
defining done, determining the appropriate amount of detail for each level of planning, and
the relationship between the definition of done and quality, empiricism, and the sprint goal.

The Five Levels of Planning

[Video description begins] Topic title: The Five Levels of Planning. Your host for this session
is Barb Waters. [Video description ends] There are five commonly recognized levels of
planning. The highest level of planning is when the Product vision is being developed. Once
there is an established product vision, the Scrum Team can develop the Product roadmap,
which helps to prioritize the requirements that must be developed first, and which ones can be
added later. In the next level of planning, the product roadmap can be placed into a schedule.

This is known as Release planning. Here, the team gets a general idea of when new
functionality will be released, with each release the product becomes more robust. Product
requirements are subject to change as the product backlog is refined. This brings us to
Iteration planning, where the team really focuses on what will be developed and delivered in
just the next few weeks. And finally, we have Daily planning which brings the team together
and allows them to address work in progress, where things stand, the next small increment of
work, and to identify impediments.

At each level of planning, the work becomes more granular and focused. At the higher levels
of planning, we don't include the specifics of the product just for certain milestones have to
be met. For instance, we may commit to a frequency of product release and place those dates
on a calendar, but it isn't until the iteration level, where we really start to have discussions
about the definition of done. In order to understand the concept of the definition of done, it
helps to know the basic framework for Scrum product delivery.

The framework includes different types of Scrum meetings also known as ceremonies or
events. The product backlog is maintained by the product owner who serves as the voice of
the customer and prioritizes requirements based on value. During the sprint planning meeting,
all members of the scrum team will play a part. The Scrum Team, which consists of the
Scrum Master, the development team, and the product owner, will determine what the goal is
for the next sprint or iteration. A certain number of user stories will be selected to go into the
next sprint.

It's up to the development team to then identify and estimate the tasks that are necessary to
produce the functionality for those user stories. Although the product backlog has already
been prioritized, conversations during the sprint planning meeting may lead to changes to the
backlog. Once an agreement is reached regarding which user stories will be selected for the
next sprint or iteration, the Scrum Team will need to discuss acceptance criteria and a
definition of done. Once an agreement is reached regarding which user stories will be
selected for the next sprint or iteration, the Scrum Team will need to discuss acceptance
criteria and a definition of done so that everyone can agree when the product increment meets
the team shared vision.

This becomes very important at the end of the sprint. The Scrum Team will determine if the
increment of work meets requirements and is considered done based on the criteria
established during sprint planning. The product is also demonstrated for key stakeholders
during the sprint review. So the success of a sprint really relies on a proper definition of done.
In order to understand the concept of definition of done, it helps to know the basic framework
for Scrum product delivery.

The framework includes multiple levels of planning and each level of planning includes
specific types of Scrum Meetings, also known as ceremonies or events. Product backlog is
maintained by the Product Owner who serves as the voice of the customer and prioritizes
requirements based on value. The customer's needs are described in the form of user stories.
For example, as a customer of ABC company, I would like to be able to keep my credit card
information stored in the system, so that when I check out I can easily purchase my items.
The Product Owner will take this and many other user stories and determine which of these
stories to develop first.

From this point the Scrum Team will participate in the sprint planning meeting. This is the
first event in the scrum product development cycle. During the sprint planning meeting, all
members of the scrum team will play a part. Note that the Scrum Team means everyone
including the Scrum Master, the Development Team and the Product Owner. The
development team consists of only the programmers or developers who are self organized
and highly productive. The development team is part of the Scrum Team and it's important to
recognized the distinction between these two teams.

Evolution of Product Scope

[Video description begins] Topic title: Evolution of Product Scope. Your host for this session
is Barb Waters. [Video description ends] In this video, we'll describe how the Product scope
evolves throughout the project lifecycle. Now that we've discussed the Scrum team's
processes for product development, we'll explore the scope of the product. The product scope
includes the features or characteristics of a product. In Scrum, the product will evolve and
become more robust with every iteration or sprint.

This course will take us through that product evolution, moving through the levels of
planning and prioritizing and decomposing the work, until the product features become
specific enough to create a definition of done. For now, we'll start at a higher level with a
minimum viable product or a minimum marketable feature. We're at a high enough level that
the big picture of our product covers three to six months worth of work. Story mapping,
originally introduced by Jeff Patton is a powerful visual way to plan Agile projects. A story
map shows the sequence of actions that a customer takes from start to finish in order to
complete a task.

It's a series of actions that the customer will need to take at a minimum in order to use your
service. If we're a video streaming service, the actions that would go into the user experience
might include logging into the system, performing a search, selecting a movie, confirming
payment, and then beginning to watch the movie. A story map generally serves as the
backbone of all product development. No matter how many features we add to the product
over time, we have to start somewhere and story mapping gives us that starting point.

The customer journey makes up the top row of a story map called the backbone. It gives us a
high level understanding of what the system does and how the end user interacts with the
system. The next row of the story map is called the walking skeleton. And it's considered the
minimum working version of the system that can provide value to a user. It also provides
end-to-end functionality. So while the product doesn't provide all of the bells and whistles
yet, it at least provides the ability to complete a function from start to finish. As we move
from top to bottom in a story map, additional rows include functionality that can be added in
future iterations to make the product more robust.

And of course, the user stories in these lower rows can be changed and reprioritized as
needed. So story mapping helps us to prioritize what to build first, to plan our releases at a
high level, and to continue to prioritize the product backlog. In our story map, the customer at
a minimum needed to be able to login to the system, perform a search, select a movie,
confirm payment information, and then begin watching the movie. In subsequent releases, we
can add more and more functionalities so the product become more robust.

For instance, in the next release, the user may be able to save a list of movies that they plan to
watch next. And in a release after that, perhaps the user can be alerted if a new release meets
their search preferences. The product owner will ultimately decide based on the budget,
customer needs, and a cost benefit analysis whether a product will keep being developed or
when development is complete.

Definition of Done in Product Development

[Video description begins] Topic title: Definition of Done in Product Development. Your host
for this session is Barb Waters. [Video description ends] In this video, we'll describe how the
Definition of Done is used in Product Development. It's important to manage stakeholder
engagement throughout a project. This includes setting Realistic expectations and
maintaining Strong communication. After the product vision has been agreed upon, there still
may be Differing ideas about the product and how it will look and function.

One stakeholder's opinion of Done may be different than that of another stakeholder. And
that's a problem. The definition of Done should not be based on opinions. It should be an
objective measure based on set criteria. The gap between what a stakeholder thinks is being
developed and what the project team plans to develop is known as the Gulf of Evaluation.
This gap is not intentional and there are tools to help reduce it. Like wireframes or
prototypes, that give the customer an opportunity to see a mocked up version of the product
and to elicit feedback.

One of the Scrum pillars is transparency. And practicing transparency means working with
stakeholders and other team members to reach a shared vision of the product and to maintain
that shared vision even as the product changes and evolves. An important part of creating a
product vision is to interview stakeholders and learn their points of view. The problem is that
stakeholders have different opinions and points of view. This often becomes clear as you
interview stakeholders and realize that no product could possibly ever meet the requirements
of all of your stakeholders.

It follows that common saying, you can't please all of the people all of the time. So what can
you do to let all stakeholders know that you do value their opinion, but you won't be able to
deliver on all of their requests? We can start by collecting requirements from individual
stakeholders and groups through brainstorming sessions, or by receiving feedback during
sprint reviews. Once we've collected requirements, then it's helpful to prioritize them by
value. Tools such as via feature or dot-voting are just a few examples of how stakeholders
may collectively decide to prioritize features.

Ultimately, it's the product owner's responsibility. But it's helpful for all teams to understand
how requirements are collected and how consensus is reached. A product vision statement
doesn't just describe the product's features. It also focuses on how a product will add value. It
should motivate the development team and help them to envision the final product. The
product vision is a compelling statement about why you're building a product, the benefit the
product brings, who you're building it for and why you are uniquely positioned to develop it.

A product vision also describes how a project can capitalize on opportunities and fulfill the
goals of a business case. A product vision should provide all of the stakeholders including the
development team with a common understanding of what's required without limiting that
team's creativity in finding solutions.

The Definition of Done and Product Quality

[Video description begins] Topic title: The Definition of Done and Product Quality. Your
host for this session is Barb Waters. [Video description ends] The Definition of Done has a
close relationship with Quality. The definition of quality is the degree to which a set of
inherent characteristics of an object fulfills requirements. So in order to ensure quality is met
in the deliverable, we have to start by planning it in. The definition of done should be
developed through a thoughtful conversation among all Scrum team members.

This conversation happens during sprint planning, and it continues every day during the
Scrum or daily stand up if the team needs to clarify requirements. During the sprint review,
the Scrum team will use this definition of done to assess the quality of the product increment.
And it isn't unusual to miss the mark on quality the first time or even the first few times. This
is normal, and a sign that teams must expand their definitions of done to become more
objective and thorough over time. There are two quality related questions that the
development team should consider.

Are we making the right product? And are we making the product right? The team can be
sure they're making the right product if there's transparency or a common vision for the
product. The Scrum team can set acceptance criteria for each user story. Acceptance criteria
is measured from the user's perspective, and is usually created right along with the user story.
For example, here's a user story. As a viewer, I would like to be able to search movies by
rating so that I know which movies are appropriate for children.

The acceptance criteria may state any movie in the family genre can not have a rating other
than G, which the Motion Picture Association states is intended for all audiences. So the user
story explains the need, and the acceptance criteria adds some clarification about how to
ensure the need is met. Now let's explore the second question. Are we making the product
right? This question is related to the quality, benefits, and value of the product. The Scrum
team will generally have a more comprehensive definition of done, which if fulfilled, means
that the product is being made correctly or right.

And that the product meets quality standards. The benefits of having a clear and concise list
of criteria to consider something done is that it guides the activities of the team and helps to
limit misunderstandings and conflict, and it also limits the cost of rework. Let's make a side
by side comparison of Acceptance criteria and the Definition of Done. Acceptance criteria is
specific to a user story and it ensures that when the user story is developed, that there will be
new functionality that meets the user's needs.

The definition of done is used by the development team, and it's a much more comprehensive
list of criteria that applies to all work, including the work that the customer may not even see
or know about. It includes both technical and non-functional requirements. And it ensures
that the team has objective metrics for what it means to be done. When we have
conversations with our team about the definition of done, we might assume the purpose of
defining done is so that we don't accidentally leave anything out.
But a good definition of done also protects us from accidentally building too much into the
product. We naturally want to please the customer and end users. And you'll often hear things
like let's give 110%, or let's go above and beyond, or go the extra mile. This is considered
gold plating in product development and it should be avoided. It's important to carefully
define the product increment that will be created in this sprint and then commit to it. If we try
to add extra features, the team can lose transparency, and if it takes extra time, it can
jeopardize the sprint goal. Delivering exactly what we promised is good enough and a sign
that we do understand the product requirements.

Variations of Defining Done

[Video description begins] Topic title: Variations of Defining Done. Your host for this
session is Barb Waters. [Video description ends] There's a difference between meeting the
definition of Done and whether the product owner decides that the product is Potentially
Releasable or shippable. The definition of done is created by the Scrum Team during sprint
planning. Ideally when a product increment meets the definition of done, the product owner
should also be able to release it.

However, sometimes there's a disconnect where the definition of done has been met, but the
product isn't releasable. When this happens, the Scrum Team should use their retrospective to
determine where the gaps in understanding are and to continuously improve their definitions
of done during planning. Since the goal is to continuously deliver value to the customer, if a
team is frequently finishing sprints only to discover that the product increment is not
deliverable, the team will need to work together to improve the outcomes for future sprints.

Products that are potentially releasable share some common characteristics. First, they must
be complete according to the acceptance criteria and definition of done. This includes any
related work. For instance, any instructions that the user would need in order to understand
the product would need to be included or release notes to accompany an update. Potentially
releasable products must also be well tested. The team wants to avoid any escape defects
which are those discovered by the customer or end users.

And finally, the product increment should be deliverable right now. Not one more thing
should stand in the way of shipping the item, and the product owners should be able to do so
if they want to. There are reasons that a product could be done but not yet shippable.
Sometimes there are costs associated with releasing a new product increment. This could
involve marketing expenses, additional customer support demands, and how responsive the
customers are to updating to the latest increment or upgrading their existing products.

So the market is a factor in the decision to release. That's why Scrum always uses the term
potentially releasable. And teams may find that they rarely release a product after every
single sprint. Now we'll explore a term called the definition of ready. Unlike the definition of
done, the definition of ready is utilized during sprint planning rather than at the sprint review.
The definition of ready is a term that some teams use to indicate that a user story is ready to
pull into the next sprint.

A user story should meet certain criteria that all of the team can agree on, such as the
INVEST criteria. INVEST means that the user story is independent, negotiable, valuable,
estimable, small, and testable. All of the work should be identified, including new
functionality, testing, and known defects that were carried over from the previous sprint. The
team capacity should be known, so that the work doesn't exceed the team's availability on the
schedule. And finally, all of the tests and criteria should be well defined.

A definition of ready can help to hold all team members accountable and to reduce rework
from lack of communication. It can also prevent the team from bringing too many story
points into the sprint, only to find out that the goal was unrealistic. A definition of ready can
help to hold all team members accountable and to reduce rework from lack of
communication. It can also prevent the team from bringing too many story points into the
sprint, only to find out that the goal was unrealistic.

The definition of ready can serve as a handy checklist to make sure work has been properly
evaluated before the start of a sprint. But I'd like to add a word of caution. Scrum relies on
small cycles of work. Plan-do, check-act and then do it all again. If teams place a definition
of ready between stages of development by saying, for instance, this product must be
completely designed before we begin developing, then the team has actually embraced a
traditional project management approach.

This is also known as waterfall where one phase of work must be completed before the next
phase can begin. Sequential phases like this with stage gates or checkpoints are not agile. The
only time you might consider this is if you have product development work that crosses
teams, and there might be a good chance that another team won't be able to deliver to you in
time for your sprint, and you know this because they've let you down before.

Other than cases like this where you have unreliable external dependencies, your team should
be comfortable with overlapping work, and the idea that there will always be a bit of
uncertainty and discovery that can happen during a sprint.

Creating a Definition of Done

[Video description begins] Topic title: Creating a Definition of Done. Your host for this
session is Barb Waters. [Video description ends] In this topic, we'll go over the steps of
creating a Definition of Done. The definition of done should be created and agreed upon by
all members of the Scrum team. During sprint planning, the product owner with the help of
the other Scrum team members, will select user stories from the top of the product backlog
and determine what can reasonably fit into the time box for the upcoming sprint.

Creating a clear definition of done is important for delivering what the customer wants, and
also ensuring that quality is built in and meets a more comprehensive standard for all of the
work that goes into the product increment. It's fairly normal for a team just starting with
Scrum to miss some key details in the definition of done, resulting in a product increment
that's not potentially releasable. However, what the Scrum team decides to do with this
problem is what separates high performing teams from teams who struggle with meeting
sprint goals.

Teams need to find a way to be closer to done with each sprint based on lessons learned, and
constantly improve their sprint planning and creating the definition of done. So how does a
team improve their definitions of done? In order to help the Scrum team improve their
definitions of done, the Scrum master can facilitate an exercise. Even teams who are pretty
good at defining done may benefit from such an exercise if the product increment is different
this time or unique from other work they're used to.
This exercise can help the team to achieve transparency, which is a shared understanding of
the goal. Team members can have their own opinions about what it means to be done. And
this should be revealed and addressed in order to avoid misunderstandings. This exercise can
also encourage participation from team members who may not ordinarily speak up. The first
time the team performs the exercise, they may take a little longer because they may be
unfamiliar with the idea of naming every single component of done.

These may have always been assumptions, but now the team has to be more deliberate in
their process. That's okay, because it will actually save time later as the team gets better at
this process. Keep in mind that this exercise can be used for non-technical products too. Let's
say that human resources team is getting ready to onboard ten new employees in the next two
weeks. Their definition of done may include completed paperwork, a completed background
check, setting up the new employee with their ID badge, and explaining how to clock in.

The work is only done if the employee can arrive at work on the first day, enter the building,
and arrive at their work area without someone having to scramble and fix something because
someone didn't do their part. I've seen this scenario enough times to know that a definition of
done is helpful in any type of industry. When preparing for the meeting, the Scrum master or
facilitator may be able to save some time by listing in advance several obvious things that
should be included in the definition of done.

But the real work should be done together as a team. Ideally, the team can use sticky notes
that can be easily move around. In the first step, the team will Brainstorm ideas around the
question, what are the tasks that the team will need to complete in order for this work to be
done? Team members may ask for clarification on what it means to be done. The answer is
done. Not one more thing should have to be completed before this product is releasable. Start
with brainstorming, depending on your team size, you can have one scribe who writes one
idea per sticky note or a few scribes, but everyone should be able to participate in the real
time sharing of ideas.

Brainstorming is meant to stimulate creativity among team members. And all ideas, no matter
how wild they may sound, are welcome. Team members will feed off of one another's ideas,
and this exercise can be time blocked to about five minutes or so, but no more than ten
minutes. After brainstorming, there will be many sticky notes that must be categorized. The
team will need to decide what the categories are. A best practice is to use the customer
journey and the way that the work brings value to the customer. Once the team agrees on
categories, they can begin to sort the sticky notes into sections.

Again, this should be time blocked to about 10 to 15 minutes and not more. One way of
sticking to the time block is to minimize discussion. Team members can silently move the
sticky notes around without talking. If team members disagree and a sticky note keeps
shifting back and forth between two categories, they can be placed at the top of the columns
and discussed once the rest of the items have been sorted. After the sticky notes have been
sorted, the team can look for duplicates or organize the items together that are alike, which is
also known as Affinity Diagramming.

It will be necessary to discuss some of the items and that can be saved for the end of this step.
During the discussion, new sticky notes may be created to account for any gaps that the team
discovers. The team may be very surprised about how many steps are revealed in a true
definition of done. For instance, as our human resources department onboards new
employees, we may begin to realize just how intricate the process really is. Any little thing
that could impede a new employee from making it through the pre-employment steps, and to
their workstation on day one, needs to be documented and incorporated into the definition of
done.

The benefit of creating a definition of done goes well beyond not missing steps. It also
becomes a great source for communicating progress. When team members participate in the
daily standup, rather than saying, I'm almost done with that, they can actually refer to task
that indicate where they really are in the process. A definition of done strengthens
commitment of all team members, and makes it easier for them to express exactly where an
impediment may be occurring. It improves communication with stakeholders, and it can even
help to reduce technical debt because there are clear steps to be followed.

A good definition of done has a direct impact on meeting sprint goals. Creating great
definitions of done is an iterative effort. Teams will almost certainly struggle at first with
missing or incomplete work. Usually this means achieving the definition of done only
happened because the definition was poorly written in the first place. One symptom of poor
definitions of done is when the criteria has been met, but the product isn't usable and can't be
released. There will also be new or unfamiliar work that contains uncertain task and it may be
more difficult to define. Teams should work together to improve their definitions during the
sprint retrospective. It's everyone's shared responsibility and commitment that will make the
definition of done better and better.

The Definition of Done and the Sprint Goal

[Video description begins] Topic title: The Definition of Done and the Sprint Goal. Your host
for this session is Barb Waters. [Video description ends] Although the scrum guide does not
specifically define the relationship between the Definition of Done and the Sprint Goal. In
this topic, we'll examine this relationship and how a good definition of done is critical in
meeting sprint goals. A Missed sprint goal usually means that the product increment was
incomplete or that the team thought it was done, but it wasn't actually usable or releasable.

Team should work together to improve their definitions of done during the sprint
retrospective. One technique they can perform is a Root cause analysis to find the real cause
of the incomplete or incorrect work. Many things can cause a team to miss its sprint goal, not
understanding its Velocity and capacity, not having the Necessary skill sets, and attempting
to maintain a pace that is not sustainable are just a few reasons. Meeting goals is very
motivating for team members and likewise missing them can be very demotivating.

It isn't a good feeling and it isn't where team should be. It can stir feelings of distrust and fuel
conflict and blame. Achieving the sprint goal every time isn't actually good either because it
may indicate that the team is being too careful. But what about the team that misses its goals
regularly? One common corporate is the definition of done or a lack thereof. Without a clear
definition of done during planning, the Scrum team is already on a course to fail from the
very start. They'll have Unclear product requirements, not completely understanding how
they'll approach a user story.

And if they don't understand requirements, then they don't have a clear picture of the work
involved and often discover the actual volume of work too late in the sprint. When the
product owner has to run back and forth between the development team and the customer to
ask for clarification. If the team doesn't know all of the work, then they can't properly
estimate it. When the Scrum team wraps up sprint planning and begins development work
without transparency, they risk missing the sprint goal in a few ways.

They won't understand the type of work they're doing or the volume of the work. And
unfortunately, like an iceberg lurking under the surface of the water, the Scrum team will not
see the danger until they are right on top of it and the lack of understanding begins to reveal
itself. Scrum team shouldn't be too discouraged if they miss a spring goal from time to time.
It can be an indication that the team has stretch goals and is setting high expectations for
itself.

For teams who do miss spring goals for any reason, the Sprint Retrospective is an opportunity
to inspect and adapt. This means expanding the definition of done over time. So that it
includes more stringent criteria, that helps to increase transparency and achieve sprint goals.

The Definition of Done and Empiricism

[Video description begins] Topic title: The Definition of Done and Empiricism. Your host for
this session is Barb Waters. [Video description ends] Scrum is based on Three Pillars of
Empiricism- Transparency, Inspection, and Adaptation. Before we get into those, let's talk
about what empiricism is. Do you like spicy food? I thought I did, but now I'm not so sure.
I've met plenty of people who can tolerate much more spice in their food than I can.

You might be wondering what this has to do with empiricism. Actually a lot, how spicy you
prefer your food is a matter of opinion. We're all individuals, and that means there's a lot of
subjectivity when we evaluate what we like or don't like. This complicates things for a Scrum
team. So back to the definition of empiricism. Empiricism is a fact based, evidence based
approach that removes subjectivity from the process. This can be applied to product
development, or any situation where we're trying to be fact based versus opinion based.

For instance, in 1912, Wilbert Scoville developed the Scoville scale, which measures the heat
units of different types of chili peppers. This is an example of empiricism. Let's explore
empiricism in Scrum. Starting with transparency. The Scrum team can achieve transparency
by talking about product requirements in enough detail that there's no major variance between
what different stakeholders and team members envision about the product. The vision is
shared and the scrum team can create a definition of done that clearly outlines the checklist of
items that can be evaluated objectively.

The second Scrum pillar is inspection. During a sprint, the scrum team inspects its
productivity on a daily basis. During the daily scrum or stand up, they'll use a burndown chart
as evidence of progress. Another point of inspection is during the sprint review when the
development team demonstrates the increment of work to the customer. The product
increment is evaluated against the acceptance criteria and the definition of done, so that facts
and observation drive performance reporting. And finally, adaptation allows the team to
welcome change.

If there's variance between the plan and actual performance, no matter how small, the team
can react quickly and realign to the sprint goal before anything goes too far off track. And
during the Sprint Retrospective, the team has an opportunity to further adapt by improving
the definition of done. One of the scrum values is commitment. This means that the team
members are committed to supporting one another, to achieving the team's goals, and to the
product.

Scrum teams who are committed remove language from their vocabulary such as I'll try, or
we'll do our best. Once they agree to the work in an upcoming sprint, they won't back out or
complain later that the goal wasn't reasonable. Commitment by a Scrum team must be
collective. It doesn't work if some team members commit while others aren't so sure.
Everyone must be on board. Commitment also requires the team to succeed together or fail
together.

The definition of done is tricky. Teams usually won't get it right at first, so they need to avoid
blame and commit to improve. They'll use their Sprint Retrospectives to reveal hidden tasks
and make sure every bit of work is accounted for. They'll use their planning time to ask
questions and explore the work carefully so that the definition of done sets them on a path of
delivering a potentially releasable product increment at the end of the sprint.

Course Summary
[Video description begins] Topic title: Course Summary. [Video description ends] In this
course, we have explored the definition of Done and its importance in Scrum. We've
reviewed evolution of the product scope and the impact of definition of Done on product
quality. We also examined the steps to create a definition of Done and how it relates to the
sprint goal. Finally, we explored the three pillars of empiricism and how the definition of
Done helps teams to achieve transparency, inspection, and adaptability.

The next course is Scrum team velocity. The single most important metric of Scrum is team
velocity. In this course, you'll explore team velocity, including its purpose and benefits, and
how to implement it. You'll discover the role of the Scrum Master, how to find velocity
balance and calculate metrics, and how velocity burndown charts are created and managed
with Jira. Finally, you'll examine best practices for managing velocity with your team and
case studies where team velocity was effectively managed.