Mastering 7 Common Workplace Meetings [Part 2]

Welcome to part two of our deep dive into the 7 most common kinds of meetings and how you can master each to perform better in your workplace. If you are looking for part one, where we covered:

1. All hands meetings
2. Engineering meetings
3. Product meetings
4. Interdisciplinary team meetings

You can find it here.

The final three meeting types will all be viewed through the lens of the Agile framework, specifically SCRUM. With Agile’s focus on iterative development and fast movement, it can get confusing how traditional meeting rules apply to this particular class of project management. This article will aim to elucidate what it takes to make the most of these meetings and outline some best practices.

Standups:

Type: Team Cadence

Standups, in particular, are often quick morning or afternoon meetings between a team and its manager, product owner, or project manager. The purpose is to catch everyone up on the progress of every individual within the team, define what is being worked on that day, and move on your work clued in about your specific role. Any important and brief announcements are made, but other than that little else is discussed. The meetings are meant to be quick, straightforward and repetitive. Anything that requires additional lengthy explanation should be taken offline and discussed elsewhere so as not to take away too much of the team’s time.

Due to their nature, a standup has a standard well-known and practiced agenda that the team can go through quickly and without issue. Though standups are run differently in different organizations (and sometimes differently within separate teams within organizations!), the following is a quick and simple agenda to get your standup running, based on Atlassian’s Guide:

1. First, the (project) manager should go through any quick, but important, announcements that the whole team needs to know concerning the day ahead.
2. Next, go around in a circle and have each team member recount the following:
3. What did I do yesterday?
4. What am I working on today?
5. What issues are blocking my work?

If you have a physical or digital SCRUM board in your office space, it is a great idea to meet where everyone can see the board. This way, you can address specific stories and tasks and ensure that you are making progress.

That’s it! Remember that the shorter you can keep these meetings the better.

Refinements

Type: Planning

Refinements, or more formally - Product Backlog Refinements, are a kind of meeting not directly mentioned in the original Agile Manifesto, but can play an important and time saving role in a given team’s Agile process. It is usually the case that when confronted with a user story, a team member that could be responsible for its completion, does not understand the full scope of the problem and what it would take to provide a solution. It is only after spending a little bit of time digging into the problem does the scope become clear. If all team members understand this scope, you can create much better estimates of the effort required to complete the task.

Put simply, the Refinement meeting is meant to clear up any potential misunderstandings involved in completing a task, such as adding detail to the story, improving the acceptance criteria, and providing effort estimates.

These kinds of meetings should happen at most once a week or once a sprint cycle. A common error when running Refinements is to invite all team members to the meeting. This leads to a lot of time wasted since only a few key team members can produce the same results from a refinement without dragging the rest of the team away from their work. Generally only the following people should attend a refinement:

1. Product Owner
2. Scrum Master
3. The team member with the most relevant experience
4. The team member with the least relevant experience

The product owner and scrum master select the stories that would benefit from refinement, with the product owner maintaining their vision for the final product. The most experienced and least experienced team members - with respect to the technical requirements for completing the stories selected for refinement - are invited because they will provide different but necessary input into how the story can be better structured and the effort required to complete it.

The entire purpose of Refinements is to gather a strong understanding of user stories before sprint planning occurs, so that the whole team isn’t stuck trying to figure out the specifics of story completion when a small subset of the team can sort that out ahead of time.

Retrospectives

Type: Progress Check

The final kind of meeting that we will discuss in this article is the Retrospective. This meeting is a critical part of Agile methodology and ensures that teams, like their final products, are continuously improving. Retrospectives are team meetings that happen at regular intervals to discuss what is working well, what needs improvement, and how that improvement can be brought about. Retrospectives are often best to hold right at the end of a sprint cycle, to look back on everything that happened in the previous sprint.

Engaging in high quality retrospectives can take a team from good to great. If issues that a team is facing are continuously addressed and the team is consistently armed with the tools needed to complete their work effectively, you can expect to see high quality work across the board.

A usual template for retrospective meeting agendas is as follows:

1. Find the nearest whiteboard or surface that you can cover in sticky notes and separate it into three columns: What worked / what didn’t work / to be improved.
2. Hand out some sticky notes and markers to the team and allot some time to creating cards for each section.
3. One by one, go around the team and discuss your stickies.
4. Prioritize your stickies by importance. This can be achieved by voting or by seeing what stickies overlap in content.
5. Create and record an action plan for the next sprint. This step is critical. Retrospectives are only as useful as the insight that they produce, leading to requisite improvements in the next sprint. If you spend an hour in a Retrospective and leave without recording anything, chances are nothing will get done, and no improvements will be made. One common recommendation is to assign team members to be ‘in charge’ of certain improvements decided on during the Retrospectives, ensuring that something is done about them before the next Retro.

Despite the merits of Retrospectives, one of the common pitfalls of such meetings is that they can take much longer than expected if you don’t time box certain parts of the agenda. For this reason, you can use the agenda (with associated times) as a guide for running a great Retrospective provided here.

With that, we have covered some of the main meetings you might encounter in your workplace’s agile setup as well as looked into how to run (and participate in) these meetings correctly. I hope you have enjoyed this article and thank you for tuning in! We will be back next week with more meeting insights to help you on your journey of perfecting meetings.