In this shorter video, I’d like to give you a visual overview of Scrum, what it includes, what it doesn’t include, and also help you connect the dots between all of the Scrum elements.

If you are new to my channel – Hey, I’m Daria. I’m a Professional Scrum Trainer and a practicing Scrum Master with over 8 years of hands-on experience in Scrum Teams.

Anyway, what is Scrum?

Scrum is an Agile framework.

Agile, in turn, is a mindset – a different way of working.

Scrum lives under the Agile umbrella, right next to other Agile frameworks and methods, such as Kanban, Extreme Programming, Disciplined Agile, SAFe, and more.

Some frameworks are considered “more” Agile than others, but Scrum has been proven to help teams and companies become more Agile.

What is included in Scrum?

Scrum has several must-have elements: there are 3 accountabilities, 5 events, and 3 artifacts with their 3 commitments.

Accountabilities include a Product Owner, a Scrum Master, and Developers.

Events include Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Sprint itself.

Artifacts are the Product Backlog with its commitment to the Product Goal; the Sprint Backlog with its commitment to the Sprint Goal, and the Increment with its commitment to the Definition of Done.

How are they all connected? 

It all starts with a customer need that we are trying to fulfill with our product.

This is where the Product Owner comes in. Their objective is to create a product that customers love by understanding what will bring the most value.

With this information from the marketplace, the Product Owner can create a clear Product Goal the team will strive to achieve.

And based on this Product Goal they will be able to define what actually needs to get done in order to create value for the customers.

This information is collected inside the Product Backlog.

The Product Backlog is the collection of everything that needs to be worked on in the product. It may be features and functionality, defect fixes, technical debt, non-functional requirements, and more.

With enough work defined in the Product Backlog, we can start our Sprints.

The first meeting (or event in Scrum terms) that happens in a Sprint is the Sprint Planning event.

During this meeting, the team discusses three key topics: why the Sprint is important; what the team will work on; and how they are going to get it done.

The first thing identified is the Sprint Goal – the ‘Why’. The whole team collaborates on creating an achievable and challenging goal.

Based on the goal, the team will start taking work from the Product Backlog into the Sprint.

The Product Owner gives the team clear guidance on what needs to be done, while the Developers estimate the work and decide how much of it can be taken into the Sprint.

Then Developers collaborate to create a plan of work – the ‘How’.

The result of the Sprint Planning is the Sprint Backlog – a collection of why what, and how for the Sprint.

And so the work starts.

Developers are accountable for building the product aligned with the company’s quality standards.

Developers include not only software engineers but anyone who is needed in order to build a functional product increment. This may be coders, testers, designers, writers, and more.

In order to keep track of their progress, Developers meet every workday in a Daily Scrum.

They inspect their progress and create a plan for the day together in order to get closer to their Sprint Goal.

For every Sprint the team must create a Done Increment of working usable or potentially releasable product.

Everyone involved has a clear understanding of what ‘Done’ means thanks to the Definition of Done.

As the Sprint ends, the team holds the Sprint Review.

Sprint Review is the second to last meeting in the Sprint and should usually happen on the last day of the Sprint.

The team invites the customers and stakeholders who have an invested interest in the product to show them the Done Increment.

During this meeting, the team usually discusses what was done, what issues they encountered, what is the overall progress toward the Product Goal as well as demonstrate the completed work and collect customers’ feedback.

The purpose is to update the Product Backlog based on what is discussed in the Sprint Review in preparation for the next Sprint.

The last event that happens in the Sprint is the Sprint Retrospective.

In this meeting, the Scrum Team discusses what went well and what they can improve next Sprint to become more effective, achieve higher goals, resolve issues, communicate better, and improve product quality.

The meeting is usually facilitated by the Scrum Master, however, can be facilitated by anyone else on the team.

The Scrum Master’s role during the Sprint is to overlook the process in order to establish proper Scrum implementation and help the team become more effective.

This often involves teaching, coaching, and facilitation.

In the Retrospective, the team usually decides on one or more improvements to implement next.

This concludes the Sprint and the cycle can begin again starting with Sprint Planning.

In order to keep the Product Backlog up-to-date and properly ordered, the team conducts the Backlog Refinement activity every Sprint.

That concludes this short overview of the Scrum framework.

Practices that are not Scrum

There are many things, that are seen as Scrum rules or are associated with Scrum, are not required by Scrum.

I’d like to quickly go over them here:

• Story points is a complimentary practice that Scrum does not require. You can watch my video on velocity called “That’s NOT how you measure velocity” to learn more
• The three questions of the Daily Scrum are not actually part of Scrum – it used to be a recommendation that was now completely removed from the Scrum Guide. There are much more productive ways to run a Daily Scrum and I have a video about that called “Best way to run the Daily Scrum“.
• Burndown charts and Scrum or Kanban boards are not required in Scrum. They are not even mentioned in the Scrum Guide. But these are very useful for some teams. I have a video explaining some useful graphs to use in Scrum called “Useful graphs metrics for Scrum Teams | Jira Reports“.
• Backlog Refinement is a mandatory meeting happening every week. While the act of refining the Product Backlog is required in Scrum, the framework doesn’t specify how it should be done. There is no official meeting dedicated to Backlog Refinement. Watch my video called “Backlog Refinement – How and Why” to learn to do it effectively.
• The Definition of Ready is not something you must have. It’s not similar to the Definition of Done that is actually mandatory to have. The Definition of Ready can be a good practice to use, but it is not a required one, and in fact, if misused can be highly damaging. I discuss the Definition of Done in my video, “Definition of Done VS Acceptance Criteria“.

I hope that this video gave you a good visual overview of the Scrum framework and helped you connect the dots between all the different elements.

Do you still have a question about Scrum? Please share it in the comments