What are Scrum Ceremonies and Artifacts?
A Beginner’s Look at Agile Scrum Methods

Agile team meeting on a board

1 in 6 IT projects go over budget by 200% — perhaps something similar has happened to you, too.

After all, managing complex projects with many moving pieces is no mean feat. If you’re not careful, one deadline slips and then another: the result being lost efficiency, direction, communication and, most importantly, money.

But that’s why so many tech teams turn to Scrum.

Simply put, Scrum is a framework built around various meetings, tools, and roles — helping colleagues structure their approach. The Scrum methodology helps combat scope creep, by breaking a project down into more manageable pieces; divided and assigned the most capable individual or team. Working together, Scrum teams can achieve more, in less time, and collaborate iteratively on all manner of tasks and projects.

At the heart of Scrum sits two key, but potentially confusing, concepts: Scrum ceremonies and Scrum artifacts. Not sure what these bits of terminology mean? No problem. We’ll break it all down in just a moment.

But before we do, it’s worth demystifying some other Scrum concepts, too.

Frequently used Scrum terms: what do they mean?

Below is a curated list of ‘must-know’ Scrum vocabulary — designed to get you up to speed, fast. But for more detail, be sure to check out the official Scrum Glossary for a more comprehensive set.

  • Scrum: a framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules.
  • Scrum Team: a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
  • Sprint: Scrum Event that is time-boxed to one month or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
  • Scrum Ceremonies: Events that take place at specific instances during a Sprint to ensure everyone is on the same page.
  • Scrum Artifacts: Key information that all stakeholders need for a common understanding of the product being developed.
  • Scrum Retrospective: Scrum Event that is set to a time-box of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.
  • Agile: An iterative project management method, based on regular collaboration between cross-functional teams.

These words should make more sense in context as we discuss them more throughout the rest of this guide.

A quick introduction to Scrum teams: who’s who?

To fully grasp how Scrum ceremonies and Scrum artifacts come together to facilitate efficiency in a Sprint, it’s good to brush up on the roles within a Scrum team.

The Scrum Master, Product Owner, and development team work together to ensure uninterrupted progress in the project and maintain value in the product.

Scrum Master

This is an individual well-versed in the workflows and processes inherent in Scrum. They’re responsible for making sure the entire team is on the same page regarding Scrum theory, practice, and rules.

A chain is only strong as its weakest link, and Scrum relies on cohesion between every team member. If someone doesn’t know precisely what’s in store and fails to uphold their responsibility, whether that be from a lack of communication or misunderstanding of expectations, it can throw off progress for the whole team.

Essentially, the Scrum Master facilitates — helping projects run smoothly.

Product Owner (PO)

The PO is there to represent the interests of customers and other stakeholders.

This role is responsible for owning the product backlog — a list of all the work that will be involved in delivering the final product (and something we’ll go on to discuss in more detail soon).

The Development Team

This is the team that gets the work done over the course of a Sprint.

Once outlines are established and a definition of done is agreed upon, they are essentially self-managed and responsible for delivering the goal of the Sprint. This may be an increment or final product.

The 5 Agile Scrum ceremonies

Now that you know the gist of how Scrum teams work, let’s get to the specifics of what we’re trying to answer in this article. What are the 5 Scrum ceremonies?

The basic answer is that Scrum ceremonies are just Scrum-talk for meetings.

These events are prescribed to avoid the need for meetings that fall outside of Scrum framework practice, and to create consistency.

Scrum ceremonies need to be clearly defined with specific goals, participants, and time constraints. The 5 Scrum ceremonies are:

  • Product Backlog Grooming
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint retrospective

Let’s dig deeper into what each Scrum ceremony involves, and how they’re so useful to product development teams.

1. Backlog Grooming

Product Backlog Grooming is unique in that it’s the only Scrum event that isn’t locked in to a specific frequency or time.

The purpose of backlog grooming is to allow the team to adjust and reprioritize tasks and objectives as necessary. At some point during a Sprint, the dynamics of the backlog may change, and this is when new items may need to be added, removed or reallocated to maintain efficiency.

Remember, the Scrum framework is agile in nature. So the PO needs to think on their feet and make sure the backlog remains organized, valuable and actionable.

How often backlog grooming takes place is entirely up to the team involved. It stands out as the only Scrum event that isn’t set in stone at the beginning of a Sprint — it could be at regular intervals or ad hoc.

2. Sprint Planning

According to the Scrum Guide, the work to be performed in the Sprint is outlined in the Sprint Planning session. This plan is created by the collaborative work of the entire Scrum Team.

Sprint planning is time-boxed to a maximum of 8 hours for a 4-week Sprint. And the Scrum Master is responsible for ensuring the attendants understand its purpose and keep it within the time constraints.

There are two key questions to ask during Sprint Planning:

  • What can we deliver in the upcoming Sprint?
  • How will we achieve this?

To answer, the development team will figure out what functions or features will need to be developed — deciding which items from the product backlog should be actioned now.

The team identifies a Sprint goal during Sprint planning, too. The Sprint goal is what will be achieved at the end of the Sprint, and the PO is responsible for monitoring which items from the backlog will go toward achieving this specific Sprint goal.

3. Daily Scrum

The development team will meet for a quick 15-minute event every day of the Sprint to plan the work that will take place over the next 24 hours. This is the function of the Daily Scrum.

This gives an opportunity to examine the work that took place since they last met, and to optimize what’s coming in the short term.

As per the Scrum Guide, the Daily Scrum structure looks something like this:

  • What did I do yesterday that helped the Development Team meet the Sprint goal?
  • What will I do today to help the Development Team meet the Sprint goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint goal?

This structure encourages the development team to continue to work as a self-organizing, cohesive unit and improves the likelihood of the Sprint goal being achieved.

The Scrum Master ensures the meeting is held, but the development team takes the reins. The primary goals are to allocate work, identify impediments, and promote agile decision making.

Sprint artifact diagram

4. Sprint Review

This is an informal meeting, taking place at the end of the Sprint. The focus is on examining the increment (deliverable) and receiving feedback from stakeholders.

During this Scrum event, the backlog is also adjusted according to what was achieved during the Sprint. The Sprint review is typically a maximum of 4 hours for a month-long Sprint.

The agenda tends to go as follows:

  1. The Scrum Team, including key stakeholders, are invited by the PO
  2. The PO summarizes which backlog items are done
  3. The development team talks about what went well and what challenges arose
  4. The development team also presents the completed work in more detail and answers questions
  5. All participants contribute to what will be done next
  6. Review of marketplace for the product
  7. Review of timeline, budget, and capabilities.

While this might seem like a long-winded list at first, it’s designed for clarification on everything that took place during the Sprint. It also provides valuable input toward the next Sprint planning event, too.

5. Sprint Retrospective

The Sprint retrospective is something of a self-examination conducted by the Scrum team.

Of the 5 Scrum ceremonies, this one is more a combination of the personal and professional progress from the last Sprint. The Sprint retrospective is typically a time-boxed 3 hour event.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools
  • Identify and order the major items that went well and potential improvements
  • Create a plan for implementing improvements to the way the Scrum Team does its work

The goal is to identify potential improvements for the upcoming Sprint on a deeper level. The emphasis being an organized chance for the team to examine and implement change. To do so, you need to ask the right questions. Take a read of our blog post "23 Questions To Ask During A Sprint Retrospective" before you move on.

Scrum Artifacts list

Scrum artifacts provide information that all members of a Scrum team need to know to understand the product, the plan, and the tasks involved in development.

In other words, Scrum artifacts present key information in a transparent way so everyone is on the same page!

And while Scrum artifacts are not limited to the ones mentioned in this article, we’ll be giving a brief summary on some common artifacts, focusing on (in our opinion) the 3 most important:

  • Product Backlog
  • Sprint Backlog
  • Product Increment

You’ll probably recognize these from the explanations of Scrum ceremonies above, so this section will shed more light on precisely the meaning behind them.

1. Product Backlog

The product backlog is absolutely essential to the effectiveness of a Scrum team and the overall product’s success.

It’s a complete, ordered list of everything that the team knows will be needed for product development. The Product Owner is in charge of the creation and moderation of the backlog.

It’s important to acknowledge that the backlog is never technically “finished”. As long as a product exists, so does its backlog.

The characteristics of a Product Backlog are:

  • It’s dynamic. It shifts in accordance with what the product needs to remain 'appropriate, competitive, and useful'
  • It's comprehensive. The backlog includes all information related to features, functions, requirements, enhancements, and fixes for the product
  • It’s meticulous. List items are attributed descriptions, orders, estimates and values

The Product Backlog is referred to as a ‘living artifact’ because it is constantly evolving and growing as the product gains value and changes with the market. Higher value items are far more detailed than lower value items, and these are prioritized by the PO.

A board with product backlog notes

2. Sprint Backlog

While the Product Backlog applies to the product as a whole, and follows it throughout its lifetime, the Sprint Backlog consists of preselected items (from the Product Backlog) that will apply to an upcoming Sprint.

The goal in mind is predicting how much of a workload — i.e. how many and what value items — will contribute to a successful Sprint goal.

The Sprint Backlog is solely managed by the development team, and is detailed enough to be used in daily Scrums, while being modified on an ongoing basis to suit Sprint goals.

Also, it’s flexible.

Much as the Product Backlog is a ‘living artifact’, the Sprint Backlog is too. When a new task emerges, it needs to be added to the Sprint to-do list. This, alongside an estimate of the relevant workload, will help teams understand what needs doing, when, by who and for how long.

The Spring Backlog may look very different from week to week, as a result. Fail to keep the Sprint Backlog up to date? Chances are you’ll creep off scope, off timeline and off budget very quickly indeed!

3. Product Increment

Often referred to as just ‘increment’, this applies to all Product Backlog items completed during the most recent Sprint, and the total value of all increments in previous Sprints.

Put simply: an increment is work that is complete. You can think of it as a step towards your vision or goal, as well.

Of course, the increment must meet the Scrum team’s definition of done and must be in usable condition regardless of whether or not the PO decides to release it.

Additional Agile Scrum artifacts

Alongside the 3 artifacts described above, the following 4 tools are also essential for Scrum framework success:

  • Product Vision: This defines the entire long-term goals of the product.
  • Sprint Goal: Maintains clarity and outlines expectations during a Sprint.
  • Definition of Done: An agreed-upon criteria for when work is finished.
  • Burn-Down Chart: A graph or chart displaying the projects progress over time.

The benefits of using Scrum (and why you should try it today)

There’s a reason why 97% of companies now use Agile development methods, like Scrum.

The benefits are self-evident when teams begin to work better together — with higher productivity, better cohesion and transparency, and a more organized approach to product development.

But when using Scrum practices in particular, teams expect to see:

  1. Greater productivity. The Scrum framework helps teams to focus on high-value tasks, doing all the stuff that matters, and none of the stuff that doesn’t.
  2. Better quality. When teams are aligned, everyone knows the value and purpose of each increment. This results in higher quality work; mistakes are avoided, and team morale is at a high.
  3. Faster and more consistent product releases. Avoid running over-time and over-budget! The Scrum framework keeps you on track — tweaking, honing and improving your workflows as you go.
  4. Easier management of project complexities. Too often, team projects can feel like spinning plates. Take the difficulty out of complex projects, and enjoy the process for what it is: a creative challenge.
  5. Adaptability and ability to predict changes. There’s a reason why we call it Agile working. When you work iteratively, in cycles, your team is more receptive and aware of change — both internally and externally. With each Sprint, you can update your course; avoiding nasty surprises at launch.
  6. More cohesiveness and morale. Communication is great for team dynamics. With Daily Scrum meetings, everyone sees the role they play in delivering an increment. That transparency is highly motivating, which leads to...
  7. Total customer satisfaction. Happy workers = happy customers. And when a product team has focused and really worked together to bring a feature to market, it shows in the final outcome.

Ready to embrace Scrum and all its benefits? Join EasyRetro today!

Whether you’re trying Scrum for the first time, or you’re a seasoned Scrum pro, there’s a place in your Agile toolkit for EasyRetro.

EasyRetro makes regular Sprint retrospective sessions more interactive, productive and fun Our intuitive tool has helped hundreds of businesses make retrospectives something to look forward to. Could yours be next?

Click here to start your 14-day free trial!