Meetings are an inevitable part of creating an awesome product. The Scrum methodology has a set of meetings that were designed to help a team be productive, working on the most relevant, prioritized requests and features first.

Short Term Planning Meetings

There is a different set of meetings used for short term planning as opposed to long term planning. These are the meetings that are used for short term planning.

Standups (or Daily Scrums)

Frequency: Daily, (Near) Start of Day
Duration: 15 minutes
Purpose: Brief status/update meeting
Attendees: ScrumMaster, Team Members, Product Owner (if invited)

Standups are used as brief status/update meeting where all of the team members -- including the ScrumMaster (SM) and Product Owner (PO), if the PO is invited -- give an update. The update should answer three questions:

1. What did you accomplish yesterday?
2. What will you work on today?
3. Do you have any blockers/impediments, concerns, comments/questions, or announcements?

(Note: We modified the last question to fit our team. The original questions is: do you have any blockers?)

This meeting should not focus on the details or things that haven't been accomplished. Doing so may lead to tangents that can put the 15-minute timebox into jeopardy. To help facilitate a speedy meeting, it's recommended that people stand during the meeting.

Blockers/impediments, concerns, comments/questions and announcements should be brought up, but kept as sidebar conversation topics after the meeting.

Announcements can be anything that will affect someone's schedule, such as: "I'm leaving early today"; "I'll be taking a long lunch today"; "a blog post needs to be published today"; "a stakeholder asked to meet today, but still working out the details"; etc. This allows the team a chance to re-evaluate their plans for the day if the news affects them.

Tips:

At the start of the meeting, before anyone has given an update, we do a few things that help us plan our day better:

• Review the calendar for meetings and deadlines so that we know what we need to prepare for.
• Announce news that might affect someone's plan for the day -- such as designs being finalized.
• Review project burndown chart(s).
• Note stagnant pull requests and blocked items.

Backlog Grooming (or Backlog Refinement)

Frequency: Once a Sprint, Before Next Sprint
Duration: 30-45 minutes
Purpose: Confirm clear acceptance criteria and prerequisites
Attendees: ScrumMaster, Team Members (Leads Only), Product Owner

(Note: Project leads need to attend [e.g. the lead designer, the lead QA engineer, the lead developer, etc.])

Backlog Grooming meetings were developed by teams frustrated with having to spend too much time in Sprint Planning meetings. This meeting allows for the leads of the project to work with the SM and the PO to get a set of clear acceptance criteria and prerequisites (e.g. designs, wireframes, decisions, permission/access, etc.) for one to two sprints worth of tickets.

Estimating does not happen during this meeting. This meeting is focused on getting the details on what the team is building, not how the team will build it.

Not all scrum teams find the Backlog Grooming meeting to be a necessity. Though, more and more scrum teams are saying that this meeting is an integral tool in running a smooth scrum cycle. We highly recommend it.

Tips:

• Set deadlines for having prerequisites accomplished and set expectations that if they are not resolved by the given deadline the dependent item would need to wait for the next sprint to be resolved.
• If the PO is not able to make the meeting or if the PO was not invited, compile a list of questions/requests from the project leads and send it to them after the meeting via email, or another form of communication.
• Plan this meeting a couple of days before the end of the sprint so that team members have some time to accomplish action items that may arise from the meeting.

Sprint Demo (or Sprint Review)

Frequency: Once a Sprint, End of Sprint
Duration: Varies
Purpose: Demo and approve work that was completed during the sprint
Attendees: ScrumMaster, Team Members, Product Owner, Stakeholders (if invited)

(Note: If not all the team can attend the meeting, the team leads should at least attend.)

During this meeting, the team demos the work that was completed during the sprint to the PO and the stakeholders. This is the time when the PO signs off on features or flags a feature as incomplete. Also, this is when stakeholders are able to give feedback on the project. With that said, remember that it's the PO's responsibility to organize and prioritize all of the stakeholder's feedback.

The duration of the meeting depends on how many features were in the sprint and how long it takes to demonstrate that all the acceptance criterion for the features have been met. The time-box can range from 15 minutes to 60 minutes.

Tips:

• It is recommended that the team members demonstrate the features, but as long as SM is knowledgeable about the use and configuration of the feature they can present it as well.
• In the begin of a project, the demo might consist of presenting content model documents, sitemap diagrams, etc.

Sprint Retrospective

Frequency: Once a Sprint, End of Sprint
Duration: 15-45 minutes
Purpose: Look back to determine how to improve
Attendees: ScrumMaster, Team Members, Product Owner (if invited)

The sprint retrospective gives the whole team a chance to look back at the sprint to determine what worked, what we could improve on and what we can try for the next sprint.

There are many retrospective formats that you can try with your team. The format that we are using right now is the I Like/ I Wish/ I Wonder format:

1. Go around the room, and have each member say a sentence (or two) that starts with I like..., I wish..., or I wonder.
2. Discuss each topic to determine if everyone agrees and/or to determine possible solutions to any problems brought up.
3. Repeat until there are no more items to discuss or when the time-box draws to a close.
4. Review the action items to implement for the sprint.

Regardless of what format you use, remember the goal of the retrospective: improve on each iteration through reflection.

Tip:

• Switch up the formats when the retrospective begins to feel unproductive.
• It's important that everyone's input is valued.
• Keep it respectful and result driven. Don't play the blame game.

Sprint Planning

Frequency: Once a Sprint, Before Sprint Begins
Duration: 30-60 minutes
Purpose: Estimate tickets and forecast the next sprint
Attendees: ScrumMaster, Team Members, Product Owner (if invited)

(Note: We adjusted the duration to suit our team's needs. We pulled out the time that would normally be used for the Backlog Grooming meeting goals. The official duration recommendation is 2 hours for every week in the sprint. Meaning that for a two-week sprint, you need a four-hour Sprint Planning meeting. )

If not all team members are able to attend, at least the project leads need to attend.

During this meeting, the team focuses on how to build the new feature(s) and how to resolve bugs, without getting into too many details. Though the team needs enough details to be able to estimate the features properly so that they can plan an accurate sprint.

An average sprint is two weeks. It's recommended to stick with the two-week length, though if your team and/or project needs a longer sprint length, go for it. Though keep in mind that it is not recommended that a sprint goes longer than four weeks.

If the team does not practice the Backlog Grooming meeting, the tasks that are done in that meeting are also done during the Sprint Planning meeting -- thus, the long timebox recommended by textbook Scrum.

The team members -- not the SM or PO -- decide what items go into the sprint forecast. They decided if it would be better to work on an item lower in priority if the prerequisites haven't been met for the next item on the Product Backlog.

Before starting the sprint, the team verifies that all the prerequisites have been accomplished and that the amount of work is in line with their velocity -- which we'll go over in the next installment of this series.

Tips:

• Don't get into too many details on how to implement a feature or request. Once the team starts to work on an item, the prescription for implementing it may not be the best solution.
• Don't fill the sprint up completely. Use your team's historical data to determine how much you should fill your sprint.
• When forecasting the sprint, remember to keep in mind past sprints (i.e. items added after the start of the sprint, QA time for the features, etc.) as well as the team's availability (e.g. vacations, commitments to other projects, company outings, training, internal company duties, etc.).

Long Term Planning Meetings

There are a couple of meetings that are set aside for planning long term.

Project Charting

Frequency: Start of Project
Duration: 30-60 minutes
Purpose: Get everyone on the same page for regarding the product expectations
Attendees: ScrumMaster, Team Members, Product Owner

Having a clear and simple value proposition for the success of the product that is understood and referenced by the whole team is crucial to the success of the project development.

During this meeting, the whole team works together to develop a charter for the project. Here are four techniques that your team can use to develop a charter:

1. Elevator Statement/Pitch ** A brief statement to position your product, which would explain it two minutes.
2. Vision Box ** Design a box highlighting 3-4 key features. Can be done even if the product won't end up shipping in a box.
3. Press Release Create a press release to introduce your product to the world.
4. Magazine Review What would a journalist say about your product in their magazine?

** there is debate on benefit / value these items bring to a charter.

Regardless of which technique you use, everyone should be able to agree and each team member should be able to access the project charter so that they can access it during project development.

Tips:

• Try out different formats if one doesn't seem to fit your team and/or project.
• Make the process fun and respectful.

Story-Writing Workshop (and Product Backlog Creation)

Frequency: Start of Project, Quarterly or Bi-Annually
Duration: 60-90+ minutes
Purpose: Determine (new) high-level features
Attendees: ScrumMaster, Team Members, Product Owner

(Note: The Product Backlog Creation meeting is not an official textbook Scrum meeting. It's a type of Story-Writing Workshop. We simply like to make the distinction between the very first Story-Writing Workshop meeting and the reoccurring ones.)

This meeting happens at the start of a project as well as once a quarter or bi-annually -- or whenever the PO and SM deem it necessary. Keep in mind that some of these meetings can last 4+ hours and you should consider everyone's energy level and focus when scheduling the meetings.

During this meeting, the whole team composes a list of the (new) high-level features of the product. Don't get into too many details with regard to acceptance criteria, but make sure to note any significant points so that you can reference them later. The list can be composed of features requested by the end-user, internal stakeholders, or the PO themselves.

Once the list is created, it's time to prioritize the list in a single column. Meaning, if only one feature was to be worked on at a time, in what order would the PO like them to be worked on. Though, this is done by the PO, outside of the meeting.

Tips:

• Write down everything that comes up. This is a brainstorming session so don't turn down an idea. Simply write it down and have it
• If new features are requested by stakeholders after this meeting, it's the PO's responsibility to work with the SM so that the team members can prioritize appropriately.
• If the meeting is going to last longer than 90 minutes, take a 15-minute break and continue in 90-minute increments and take a 30/60-minute break every two 90-minute sessions.

Top 3 Most Common Problems

Our meetings are not productive.

Meetings can be such a bore sometimes and people can lose interest, but if everyone understands the purpose (and importance), goal(s), and time restraints of each meeting, you're on the right foot to having a productive meeting.

Remember:

• Respect people's time by starting on time and ending early if possible.
• Most importantly, always have a goal/agenda prepared and shared before hand (with time restraints for each topic, if necessary).

If all else fails, talk about it during a retrospective. Have an open and honest conversation with the team and work together to determine a solution that works for all of you.

We're spending too much time in meetings and not enough time doing work.

We came across this issue ourselves. We resolved it by having an open and honest conversation during a retrospective. We came out with a few solutions that you can try if you'd like:

• We combined the standup meetings. So now we have one 15-minute company-wide meeting in the morning.
• We combined sprint planning meetings for smaller similar projects -- such as our small digital marketing projects -- so that in a 45-minute session we plan all of the sprints for those projects.
• We leverage the Backlog Grooming meeting and communication platforms -- such as Slack -- to constantly gather acceptance criteria. Doing so allows us to reduce the time-block for Sprint Planning meetings.
• We only have internal planning meetings in the morning, unless a client needs a time-slot in the morning so that we can focus on work in the afternoon.

Skipping the Demo, Retrospective, and/or Backlog Grooming Meetings

Each meeting is important. If you find that your team is skipping any of these meetings, it's time to take a close look at the reason why. Some teams skip because:

• They aren't productive. If the meetings aren't being productive, are the right people in the meetings? Are the goals and agenda items of the meeting clear?
• They take too long. If the meetings are taking too long, are you respecting the time-box? Are there meetings that you can reduce the time-box, but still be productive?
• Team members don't understand why it's needed. If team members don't understand why it's needed, make sure that they understand the importance of each meeting.
• Team members feel like they don't need to attend. If team members feel like they don't need to attend, make sure that their input is respected and valued. Also, make sure that their presence is actually needed.

In any of these cases, it's always a good practice to dig deeper and get to the fundamental reason why and talk about it with the team.

Summary

Meetings are inevitable. Embrace the purpose and importance of each of the Scrum meetings. Doing so will help you be more productive, working on the most relevant, prioritized requests and features first.

The short term planning meetings are:

• Standup (or Daily Scrums)
• Backlog Grooming (or Backlog Refinement)
• Sprint Demo (or Sprint Review)
• Sprint Retrospective
• Sprint Planning

The long term planning meetings are:

• Project Charting

• Story-Writing Workshop (and Product Backlog Creation)

  Don't skip the meetings -- adjust them to meet the needs of your team and/or project. If something doesn't seem to be working, have an open and honest conversation with the team to work towards solutions.

What's Next

The next installment we’ll be discussing estimation -- which will include user stories, story points, and velocity.

If you have any questions on the Scrum meeting or have suggestions for another series or installment leave a comment below. Also, if you have any other question regarding estimation, feel free to leave them below and we can address the in the next installment. Let’s share our knowledge.