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.
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.
These words should make more sense in context as we discuss them more throughout the rest of this guide.
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.
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.
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).
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.
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:
Let’s dig deeper into what each Scrum ceremony involves, and how they’re so useful to product development teams.
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.
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:
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.
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:
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.
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:
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.
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:
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 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:
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.
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:
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.
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!
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.
Alongside the 3 artifacts described above, the following 4 tools are also essential for Scrum framework success:
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:
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!