Meeting Mayhem

Getting Your Meetings Under Control

Though I have lots of articles in the queue for this site and not near enough time to write them, yet sometimes it seems that the same people versus process topic comes up over and over with different people in a short space of time and for some reason, in the last seven days, meetings have been that topic! I have had lots of questions are about how to run better meetings, evaluating the cost of a meeting and even more about how to have less of them! Agile is a communication based way of getting things done, meetings are needed but right meetings are required! So I am going to run with it!

Note: This article is about non-agile specific meetings, though some of the items below can be applied to iteration planning, iteration reviews, backlog grooming, etc. that is not the focus of this article; it is to help you improve all of the OTHER meetings that happen during the course of a project.

The two main questions that I get regarding meetings in an agile environment are:

  • Is there such thing as an “agile” meeting?
  • Should I put meetings into the backlog with the rest of the users stories?


Is there such thing as an “agile” meeting?

So, is there? Can there be such a thing as an “agile” meeting? The simple answer is yes. The most challenging part of the process is to get some ground rules in place that can allow it to happen.

The first step is to think of ALL meetings as “stand-up style,” no matter what type of meeting it is. In your stand-up the ground rules are understood by all participants and if adhered to, the meeting almost always: has all of the right people present, stays on target, people get the information they need, off-topic discussions are held for later, and more often than not, it ends early! How do you apply this format to the rest of your meetings?

  1. Create an agenda and send it out with every meeting request. This helps everyone understand, in advance, what the meeting is about and help you figure out if they are the best “right person” to attend. Include any documents required for review that will be discussed at the meeting.
  2. Create a list of “working agreements” or team guidelines that all attending agree to abide by.
  3. Consider the “cost” of the meeting. Balance the information to be gathered with the work that will not be done by the attendees at the meeting. It is worth it?
  4. Create a place to save off-topic items for later discussion. This helps you keep the meeting on topic.
  5. Set a list of “exit criteria.” This is your meeting’s “definition of done”. When you achieve this list, end the meeting!

1) Create an agenda and send it out with every meeting request.

An agenda does not have to be the length of “War and Peace” to be worth writing, the best agenda’s are short, sweet, one line summaries of the item to be discussed. Single topic focused when you can but shared impacts/issues when you can’t, or even an overarching theme such as “team resources”. Think about writing your agenda items just like a user story, who it is for, with criteria for understanding what it is including your requirements (e.g. read the attached design document before the meeting). Doing this in advance of the meeting also helps you fully understand what needs to be talked about and ensure to invite the right people to the meeting. Having a preset agenda helps keep the meeting on track, just like in your stand-up, it is easy to call “rabbit hole” when non-agenda items are thrown into the discussion. This leads to the final issue, making sure the right people are in the room. Do not waste the time of others if the primary decision maker or the topic expert cannot attend the meeting; this just results in wasting time in the first meeting and having to have a second one!

2) Create a list of “working agreements” or team guidelines that all attending agree to abide by.

This is a small thing that can have a big impact on the success or failure of your meetings. Have you ever been in a meeting where the most important person to the success of the meeting came 15 minutes late? Or sat through a meeting where everyone was checking their phones and not focusing on the needed discussion, asking and re-asking questions that had already been covered? A “working agreement” or team guidelines is a list of things you all agree to that will help focus the meeting and spend less time in them. A sample of these might include:

  1. The meeting starts on time.
  2. We follow the agenda.
  3. If anyone arrives late, we do not back track on the agenda, that person will get an update after the meeting ends.
  4. No laptops unless you are the meeting scribe/note taker.
  5. No phone use and set to mute during the meeting. If you get a call you cannot ignore, step outside to take the call.
  6. Agreements and outcomes are documented and sent to the attendees to ensure accuracy.
  7. All off-topic/”rabbit hole” items go into a “parking lot” for future discussion.
  8. When the exit criteria are met, the meeting is over.

3) Consider the “cost” of the meeting.

Each meeting you have has an associated cost in terms of the dollars it costs for each person to attend, especially if you have to fly them in, as well as the much harder to measure “work not getting done” while they are in the meeting and the follow-up they may need to do after the meeting. While you may not have a real per hour cost, you can set an average general cost for each person invited to help you set a baseline of value. Let’s say $30 per hour for each team member, $40 for each lead, $50 for each manager. You send out a meeting request that has 5 team members, 2 leads and a manager and that ONE hour of meeting just cost the project $280 plus the cost of the work not being done. Intangible yes but a cost of having them at the meeting.

While it is true that the attendees are going to “get paid” that in salary or per hour whether they are in the meeting or not, having a way to place a value on the time used up by meetings is a great way to help reduce arbitrary meetings and having meetings for meetings sake. You know the ones you sit in and know there are so many more valuable things you could be doing with that time. Just another way to improve the perception of value when deciding having that meeting is more important than the dollars and the work not getting done price.

4) Create a place to save off-topic items for later discussion.

If you have never used a “parking lot” during a meeting to save off-topic or great ideas that come up during a discussion, you need to start! This simple tool is a great way to ensure those ideas and issues are not lost, but also helps to respect a great idea showing up at a less than ideal time. Capturing inspiration is priceless and adding this to the meeting this will also reduce interruptions and off-topic rabbit holes. I have seen these done a number of ways and it is not about how it is done but rather what style works for your team or even the type of meeting you are in, so try a few and see what works for your team.

A few options are:

  • Use a white board and put the words “Parking Lot” over a section, have folks add items there as needed.
  • If you have a facilitator, they may be the scribe and write the ideas down for others. In this situation, make sure to confirm that it is written it to your requirements, wording, information, before moving on.
  • Provide a location in the room that is the designated “Parking Lot” and put post-its and pens on the table. As ideas come up, individuals right them down and either hand them to the meeting facilitator or put them in the parking lot themselves.

5) Set a list of “exit criteria.”

Just like you do with your user stories, create your meeting’s “definition of done” and put it up somewhere in the meeting room for everyone to see. Some facilitators use it as a checklist, a way to check in with attendees to ensure that all agree that that item has been covered and next-steps or action items are understood, before moving on. As soon as you check off everything on the list, ask the attendees if you have met the “definition of done” for the meeting. If they say “No,” ask what additional discussion is needed and cover those items. If they say “Yes,” the meeting is over and excuse them. The goal of this is to avoid “Parkinson’s Law” and allow the meeting discussion to fill the time allotted even though the exit criteria was met in the first 15 minutes!

One of the best outcomes I have seen from doing implementing this style of meetings is that the complaints about attending meetings starts to diminish because more people are in the meetings they should be in, not invited lurkers who feel they are just wasting time being there and they know that when the exit criteria is met, whether it take the allotted time or just 15 minutes, they can leave and get back to that user story they have in progress.

Should I put meetings into the backlog with the rest of the users stories?

There are a lot of opinions about turning meetings into user stories or as tasks in a backlog and the honest truth, is that this should be decided team-by-team unless there is an agreed upon standard set project wide that all team need to abide by. I say team-by-team is because teams function very differently and the need for deep dive type meetings can vary very widely even within the same team based on the features they are working. A lot of teams need to do deep dives into the architecture or design issues before they can fully understand what is to be built much less help review and breakdown users stories or write code. They need the time to understand what the technology is so they can move forward with the right “how”. This provides that flexibility to do so when needed and credit those meeting to the feature they are working on for velocity, cost, and overall effort.

The first step is to determine if there is criteria you want to use to measure if a meeting should be a user story or tasked into a feature’s user story. Some of the ones options that my different teams considered are:

  • The meeting requires more than 75% of the team. In this case the team could vary in size from 7 to 13 (with our remote team members) and with a meeting potentially taking 13 hours (a 1 hour meeting) or 26 hours (a 2 hour meeting) out of our total allotted working hours for an iteration the size impact is clear. This “size” of time usually became the deciding factor for a user story in its own right under the feature’s parent story since this meeting would contribute directly to the work needed to build that feature or functionality.
  • The meeting required “experts” or help from another team. Meetings with this requirement usually became user stories with each person attending having a task to attend. In these cases we used our agile software to add a task for each person attending so it showed up on that person’s task dashboard as a task for that sprint. A meeting request was also sent out but adding a meeting task reinforced that the individual was important to getting the work for that feature and the team needed them there. Cases where this would occur included asking a Product Owner from another team who had needed information on impact, needed art or creative resources or insights, or a domain expert that worked on the project but not with the team doing this work to understand external connections or dependencies.
  • Small meetings of 2-3 people were usually added as tasks to a story especially if those 2-3 were the people working on the story already. It just made more sense to the team that if the feature story was to get done and it was just a meeting with 2-3, it could be very focused and a task just ensured the discussion happened before the work got started.

If you track the time meetings take away from doing the actual work you can easily see how tracking it with the feature or theme can matter. Over the course of a project, teams working on complex implementations will need the time to ensure they understand what they are being asked to build and meetings will happen, a lot. This just gives you away to track the meeting hour(s) impact on the feature to get a true measure of how long it REALLY took to get it done.

Reducing meeting mayhem is 3 simple points:

  1. Reduce meeting “waste” by ensuring that you know what you need to talk about, who needs to talk about it and when you are done talking about it only makes every minute you spend in a meeting contribute to the success of your project rather than another hour in the day when they could have been doing “real” work.
  2. Make meetings matter to your team but also understand the cost of having that meeting and whether it is worth it to spend that currency.
  3. Meetings are a very important communication and face-to-face tool for agile success so improving how your meetings work and are tracked can only help you become more agile and more responsive to how your teams need to work to get things done.


Add a bit of agility to your meetings and things will move faster!

Leave a Reply

%d bloggers like this: