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

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.

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.

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.

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.

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.