Agile is a mindset and there is no such thing as “doing agile.” The agile mindset is based on the Agile Manifesto, which reads:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The Agile Manifesto is the foundation of the agile mindset. Agile is a mindset which values people, functional work products, stakeholder collaboration, and adapting to change.
Within the umbrella of agile sit multiple methodologies through which to collaborate and function as a team, all with the agile mindset and manifesto in mind. Of these methodologies, the most widely used in software development is Scrum.
If you have worked on a team that has talked about “Scrum events,” “sprints,” “backlog grooming,” and “sprint reviews,” it’s likely you have worked with a team that was attempting to operate using the Scrum methodology. Remember, agile is a mindset, Scrum is a methodology.
The Scrum methodology is defined in the Scrum Guide, which was last updated in late 2020 by Ken Schwaber and Jeff Sutherland, who are considered the founding fathers of Scrum. This article leverages the 2020 Scrum Guide and focuses specifically on the Scrum events while providing some tips and tricks for leveraging Scrum in your organization.
Personally, I have leveraged the Scrum methodology across many different types of teams and contexts, from Salesforce development to training content creation.
I’ve implemented Scrum and conducted training sessions with numerous teams, many with globally dispersed contributors. If you’re new to Scrum, you might want to start with a more thorough understanding of the methodology in this article, the full guide to Scrum. Let’s jump in!
What Are Scrum Events?
Scrum events (sometimes called Scrum ceremonies) are important events or elements of the Scrum methodology which follow the agile mindset and are often used in software development or iterative-type projects.
There are five specifically-defined Scrum events:
- The sprint
- Sprint planning
- Daily Scrum
- Sprint review
- Sprint retrospective
Scrum events are not just meetings for the sake of having meetings. Rather, these Scrum events provide the framework for teams to get work done in a structured manner, help to set expectations, empower the team to collaborate effectively, and ultimately drive results.
If they’re not managed appropriately, however, they can overwhelm calendars and drown out the value they are intended to provide.
Scrum itself, like the Scrum events, is intentionally lightweight and simple. Scrum is easy to learn, but it can be difficult to master. It is intended to provide a framework for cross-functional teams to solve complex problems.
Simply put: Scrum is a methodology or process through which to exercise the agile mindset. If this is lost on you, scroll back up to the top of the article and read about the root of agile and agile as a mindset. Then come back here.
Learn more in our video guide:
The Scrum Roles
Before we get too far, let’s quickly review the three Scrum roles.
- The product owner: This role represents the client and the business in general for the product on which they’re working. They own the backlog and determine the priority of work items for the development team. They make executive product decisions on a daily basis. They’re translating customer needs into actionable work items for the dev team.
- The Scrum master: Scrum masters are accountable for ensuring the team has what it needs to be successful, including a clear understanding of the Scrum process. They are a coach, counselor, advocate, impediment-remover, facilitator, and mediator all rolled into one. Scrum masters are accountable for establishing Scrum as defined in the Scrum Guide, but they are not project managers (beware any leader that believes these are the same role!)—they are not responsible for the work product. Also, a Scrum master is not necessarily an individual person or a full time job! Read more about Scrum masters vs project managers here.
- The development team: This is a group of cross-functional team members all focused on the delivery of working software or the desired output of the team. It is the singular noun for any developers, designers, QA, and other technical roles that must collaborate on the actual development of a product. Ideally, this group of 5-9 people is fully dedicated to one Scrum team. In reality, and especially at agencies, it might look a little bit different. The development team should be self-organizing and motivated to provide value, and with proper facilitation by a Scrum master and product owner, they can be.
Each of these roles have unique participation in each of the Scrum events. When facilitated effectively, the Scrum events will empower each person in their role to have a great opportunity for success.
The 5 Scrum Events Made Simple
In this article, we will unpack the five Scrum events and ceremonies, delving into their purpose, attendees, and tips and tricks to make them most effective. The five Scrum events are:
Of special note, every single one of these events is time-boxed, intentional, and in service to the overall Scrum team. In other words, they exist to make delivering outcomes possible.
Note: Conducting these events in isolation won’t automatically make your team agile, nor will it ensure your team is operating in the Scrum methodology. In order to effectively run Scrum, these events must be a part of a larger, well-understood, and articulated process.
They should facilitate conversations within the agile team to get things done. And what kind of project manager doesn’t like to get things done?
The Sprint
What Is A Sprint?
A sprint in Scrum is a fixed length of time (usually one month or less) where ideas are turned into value. The sprint is the heartbeat of Scrum. Sprints occur consecutively, one after the other, until the product is complete (or without end). Often, teams measure their future in sprints.
What’s Its Purpose?
The purpose of the sprint is to time-box work time and get teams to deliver against commitments. Sprints allow goals to be set that are shorter-term, but incredibly solid. During a sprint, nothing should change that would endanger the sprint goal.
Teams commit to delivering a specific set or sets of work at the beginning of the sprint and they work tirelessly to complete that goal throughout the sprint. At the end of the time-box, the team gathers to review their work and determine what to work on during the next sprint, based on a prioritized backlog from the product owner.
The sprint keeps the team on-task, but allows for course correction or changes sprint-to-sprint. Sprints enable predictability by ensuring that what the development team commits to will either be done or reviewed in a short period of time. With sprints, the “we’ll see when it happens” goes away. We know when things will happen because they are either committed to or not committed to in the sprint.
Who’s In Attendance?
The entire Scrum team—the product owner, development team, and Scrum master.
How Long Does It Last?
A sprint is anywhere from 1 to 4 weeks, no longer. This limitation allows teams to get moving and deliver incremental progress rapidly, but without driving people crazy.
When I implement Scrum with a new team that is not doing software development, I often start with 1 week sprints as we can generally plan 1 week ahead of time. There is also a natural cadence to the 1 week sprint, as it aligns with the work week.
More advanced teams, especially those delivering software, will often run 2 week sprints, which allows for more innovation and testing during the timebox. If starting anew, I suggest trying 2 week sprints and seeing how it goes for a few iterations before revising.
Are There Any Helpful Tips?
- Sprints are not the enemy, nor are they specifically a motivator. Do not try to hassle or coax people to do things because of the sprint itself. Instead, motivate people towards achieving the sprint goal and delivering a product increment.
- Consider when your sprint is going to start and stop. A sprint should start just after the last sprint stops, literally within hours. The time between sprint stop and start should simply be time for your sprint review, retrospective, and sprint planning; then it all starts again!
Anything Else?
Sprints cannot be made longer or shortened. A sprint can only be canceled if the sprint goal becomes obsolete. Only the product owner has the authority to cancel the sprint.
Sprint Planning
What Is A Sprint Planning Meeting?
Sprint planning is the Scrum event designed to make sure the team is prepared to get the right things done every sprint.
What’s Its Purpose?
This Scrum meeting happens at the beginning of a new Scrum sprint and is designed to allow the product owner and development team to review the prioritized product backlog. Through a series of discussions and negotiations, the team should ultimately create a sprint backlog that contains all items they are committing to complete by the end of the sprint.
This, plus a summary of what will be delivered, is called the sprint goal. The sprint goal should be a shippable increment of work, meaning it can be demonstrated at the end of a sprint. It needs to be agreed upon by the entire team.
Here’s an example of a sprint goal: Implement a customer feedback system integrated with customer success case management. The sprint associated with this sprint goal would include multiple epics and stories that contribute to achieving the implementation of a customer feedback system that is integrated with customer success case management.
The product owner is responsible for having the prioritized product backlog ready for review before sprint planning begins. This means adding acceptance criteria, requirements, and necessary details for the development team to accurately estimate the level of effort (often in story points).
The product owner also needs to be able to clarify any questions or assumptions that the development team has about the work. Only then can the development team accurately forecast the amount of work they can accomplish during the sprint.
Who’s In Attendance?
The Scrum team—the product owner, development team, and Scrum master.
How Long Does It Last?
The length of most Scrum events is related to the length of the sprint. In terms of sprint planning, it should last 2 times the length of the sprint (in hours). For example, if your sprint is 2 weeks long, the sprint planning event should last no longer than 4 hours. For a 1 week sprint, it should last no more than 2 hours.
Are There Any Helpful Tips?
- Epics and user stories can be broken up into smaller tasks & assigned during sprint planning so that everyone knows what they’re held accountable to.
- Encourage the team to sketch out tasks, bugs, and any item that requires it during this scrum meeting. It should be an extremely collaborative event.
- Once a sprint goal is set, it should not be interrupted by competing work. However, the product owner can cancel the sprint if the goal is no longer relevant to the product or goals of the business.
- Stick to your timebox. Keep your eye on the clock, and once you’re at time, stop.
- Be sure to keep in mind any time off, vacations, holidays, or other scheduling details during the sprint to accurately reflect the amount of work that can be accomplished.
- Similarly, try to have a measure of the team’s velocity before sprint planning begins, assuming you have been operating in the Scrum methodology for some time.
- Anything that didn’t get done in the last sprint but was committed should be placed back into the backlog and considered for an upcoming sprint, based on the priority assigned by the product owner.
- Remember: You’re planning for a sprint, not a marathon! Try not to get sidetracked by items that haven’t been determined ready by the product owner.
Anything Else?
Sprint planning allows the scrum team to answer the questions, “What can be delivered in this next sprint? And how will we accomplish that work?” It helps provide predictability and creates a collaborative environment to arrive at the goal for each sprint.
Sprint Planning Templates
In the DPM Membership templates library, you’ll find a pre-made agenda, checklist, and email that you can download and tweak to fit the sprint planning needs of your team. This will speed up your prep time and set you up for a productive and useful sprint planning session.
Daily Scrum (Daily Stand-up Meeting)
What Is A Daily Scrum Meeting?
The daily Scrum is the team’s chance to get together, celebrate recent accomplishments, define a plan for the day’s work, and identify any blockers.
What’s Its Purpose?
This Scrum event provides a frequent and regular opportunity for the team to get together and communicate individual progress toward the sprint goal. It’s not a status update.
Instead, it should illuminate any impediments the team is having. The Scrum master is responsible for clearing these roadblocks for the development team so they can focus on delivering the work identified in sprint planning.
The daily Scrum is more than just a status update; the team meets for a pulse check that should illuminate any impediments that are slowing the team’s progress.
During the daily Scrum, each member of the development team should briefly answer the following questions (often considered a template):
- What did you do yesterday?
- What will you do today?
- Are there any impediments in the way?
Each participant in this Scrum meeting should be listening to each other and remain present through the entirety of the meeting. Oftentimes, members of the development team will identify opportunities to work together during the day based on commentary during the daily Scrum.
Who’s In Attendance?
The Scrum master and the development team. The product owner is an optional attendee. On occasion, outside stakeholders can be invited to listen in to the daily Scrum.
How Long Does It Last?
This one’s short! It should last no more than 15 minutes. Easier said than done.
Are There Any Helpful Tips?
- The Scrum master is responsible for keeping pace on this quick Scrum meeting. Consider setting a timer!
- Hold the meeting at the same time each day of the week (typically in the mornings), and do what you can to make this as routine for the Scrum team as possible.
- If your team is distributed, leverage video conferencing software so the team can still see each other.
- For live stand-ups, consider throwing a ball around the room to indicate who should be speaking at any given time.
- If (or truthfully when) something comes up in this meeting that warrants a longer conversation, encourage the team members to sync up as soon as the daily Scrum wraps up to determine when they want to collaborate. It could be immediately after the meeting or later in the day. Again, let them self-organize.
- There are tools and Slack integrations that allow stand-ups to happen asynchronously. While those can be helpful in certain circumstances, it is encouraged that these meetings happen in person or over a video call.
- The daily stand-up should not be canceled if a leader or Scrum master cannot attend—the meeting is not for them, it is for the team; have the daily scrum.
- The tone should be light and fun, but with a focus on collecting and communicating information.
Anything Else?
Alternatively named the daily stand-up or Scrum meeting, this quick pulse check should set up the team well for the day. Don’t let it eat up too much time or it will have the opposite effect.
This meeting enables the team to be in sync and build trust with each other. Let the team hold each other accountable for achieving their commitments on a daily basis.
Sprint Review
What Is A Sprint Review Meeting?
The sprint review is the Scrum event where all work completed during the sprint can be showcased to the stakeholders.
What’s Its Purpose?
At the conclusion of each sprint, the sprint review provides a platform for the development team to showcase all of the work that has been completed. This allows stakeholders to see things sooner than later and inspect or adapt the product as it emerges.
Sprint reviews can be conducted in a casual “Demo Friday” nature or can be set up to be more structured. This all depends on several variables of the Scrum team, such as product life cycle and release planning.
Most importantly, all of the work showcased during this time should be fully demonstrable and meet the definition of done that the team has agreed to. The team should feel empowered to show off the work they’ve been able to complete over the course of the sprint.
It should not feel like they are on trial or defending the work they’ve done or are at-risk of being picked apart by stakeholders at the sprint review. Rather, the content of the meeting should focus on the business value being delivered through product development.
Who’s In Attendance?
The Scrum team—product owner, development team, and Scrum master. It will also typically include a mixture of management, outside stakeholders, customers, and even developers from other projects. In terms of who needs to be there, this Scrum event is more fluid than the others.
The product owner and Scrum master should be discussing who ought to be involved prior to the sprint review and work to ensure they’re in attendance.
How Long Does It Last?
1 hour per week of the sprint. As an example, a 2 hour sprint review should be scheduled for a 2 week sprint.
Are There Any Helpful Tips?
- The Scrum master typically assumes any administrative duties, ensuring meeting rooms are booked, additional presentation aids are available (like white boards or flip charts, for example), and that the meeting is appropriately timeboxed. Consider providing refreshments as well.
- Actionable feedback received during the sprint review should be converted into new product backlog items for later prioritization and discussion.
- Preparing for this meeting is a good idea! Since stakeholders from outside the Scrum team are often in attendance, be sure to build in any rehearsal time or other preparation necessary to set the team up for success.
- Focus the sprint review around user experience and business value. It should not feel like the development team is just proving that things work.
- The product owner should be asking questions to the stakeholders, gathering feedback, and also providing answers to any that arise.
- As a product owner or stakeholder, be careful not to start picking apart the good work of the development team publicly, even if it's not quite right, as this can significantly impact motivation and cause fear of future sprint reviews. The team was delivering against requirements set forth by the product owner. If the requirements were not right or were not well enough explained to get the desired results, mention this to the product owner so it can be handled in a retrospective or sprint planning to get a better result next time!
Anything Else?
Alternatively named the sprint demo, this Scrum event helps to build trust across stakeholders and the Scrum team.
It is the most direct way for early and frequent feedback to be collected and eventually added to the product backlog. Do everything you can to let the team shine and celebrate success both along the way, and at the sprint review itself.
Sprint Retrospective
What Is A Sprint Retrospective Meeting?
The sprint retrospective is the final Scrum event in the sprint sequence that allows the team to look back on the work that was just completed and identify items that could be improved based on their experiences in the previous sprint (now closed).
What’s Its Purpose?
After a sprint review has been conducted, the Scrum team needs to have the opportunity to reflect on the work that was just showcased and discuss ways in which to improve both the output and the process.
The sprint retrospective is that meeting. It gives the Scrum team a platform to discuss things that are going well, things that could go better, and some suggestions for changes.
Some common questions asked are (often considered a template):
- What went well over the last sprint?
- What didn’t go so well?
- What could we do differently to improve?
Ultimately, this Scrum event should provide a blameless space for members of the team to provide their honest feedback and recommendations for improvements. It should drive change.
All actionable feedback should be collected and assigned in the same way as other epics or stories so that members of the Scrum team understand who is responsible for what and when the changes will be implemented.
Work items that come up as a result of a retrospective are to be included in sprint planning and committed like all other work items.
Agile is all about constant improvement, and this event is specifically designed to help the scrum team better.
Who’s In Attendance?
The Scrum master and the development team. The product owner is an optional attendee. There should be no outside stakeholders involved in the retro (this is super important!!).
How Long Does It Last?
Typically, sprint retrospectives should last no more than 1.5 hours for a two-week sprint. If your sprints are a month, the retro should last no longer than 3 hours.
I personally facilitate retrospectives that average 30 to 75 minutes. When working with partially remote or fully distributed teams, I leverage active collaboration tools such as Mentimeter or Confluence to get folks to participate without having to unmute and share their voice widely. This is especially effective for global teams.
Are There Any Helpful Tips?
- Focus on continuous improvement and gather information that is based on facts, not just feelings.
- Keep things novel, and consider different ways to engage the team during this Scrum meeting. There are a host of resources out there that provide examples to make these meetings more effective. One example can be found here.
- Generate meaningful insights from the conversation. If you sense there’s more to be said between the lines, encourage team members to go deeper.
- If a suggestion for improvement is brought up, ask other members of the Scrum team if they all agree. If so, identify how that recommendation will be brought to life.
- Create a space where the conversation more easily flows. If colocated, consider bringing in food, colored markers, sticky notes, and other things to encourage participation. If meeting in virtual space, you might even try festive virtual backgrounds to change things up a bit and engage folks in a different-than-usual way.
- Over time, revisit previous suggestions to determine whether the team should keep doing them.
- Build the team’s ability to self-organize.
Anything Else?
Be sure to create an environment of psychological safety. This is not a blame game. These meetings often illuminate recommendations to be better and mitigate risk moving forward. As a Scrum master, be sure to coach the team to provide honest feedback & be respectful throughout the course of the event.
Why Are Scrum Events Important?
Scrum events are the heartbeat of the Scrum methodology. Without the events, Scrum can very quickly become a very hard-to-follow and messy process. Especially important with new teams, I encourage folks to implement Scrum as it is written in the Scrum Guide, run a few sprint iterations and then determine what needs to be adapted to best-fit the team.
Note: You’ve probably noticed we didn’t talk about a sprint board (sometimes called a Kanban board, but that’s a whole separate discussion) in this article at all. That’s because it's not a core element of any of the Scrum events. Sprint boards are excellent tools to use in each event, but they are not a required element.
Handy-Dandy Comparison Chart
Pressed for time? Check out this brief chart to compare and contrast each Scrum event.
What Do You Think?
Regardless of which project management tool you use or the product on which you’re working, these Scrum events are designed to deliver results. I’ve found that these meetings certainly provide structure and go well when the team is all bought in with a shared understanding of what each scrum event is for. Again, Scrum is just a framework to use to help deliver software in an agile fashion.
Every team is different, though, and there is no perfect process. The simplest advice I’ve heard is to keep the principles in mind! Think of your sprint events as a product: keep iterating & improving.
Looking for software specific to Scrum? Start with this list of the best Scrum tools. Feel free to leave a comment below on your experiences running Scrum events, and let’s learn from one another.
4 Comments