Given the meeting has acceptance criteria, when the last acceptance criteria is meet, then the meeting ends

In my last post, I talked about the utility of defining a meeting as a user story, using the classic ‘As a {who}, I want to {outcome} so that {purpose}’ to convey the meeting’s purpose for existing, what it should achieve, and who benefits. Leveraging this format clearly informs the audience of the important details and also
sets a clear vision for you as the meeting organizer.

We can take the analogy a step further and add an additional tool common to user stories - acceptance criteria. Just like in a user story, a meeting acceptance criteria defines the conditions for when the meeting is over. When all of the conditions have been met, the meeting is over. Too often, meetings run to fill the time allotted. Having clearly defined acceptance criteria for their ending gives a framework for the meeting leader or team to call the meeting early.

The format in which you write the acceptance criteria can vary. You can try the ‘Gerkin’ format like that I used above that follows the ‘Given - When - Then’ syntax. While this format works well for development user stories, I find it challenging to adapt for a meeting. Instead, I prefer to think of the acceptance criteria for a meeting like a checklist. Once each bullet in the checklist has been completed, the meeting can be considered done and the attendees can move on with their day.

Examples

Here are a few examples for a few common meetings:

Daily Standup

• Everyone has discussed their plan for the day
• All impediments that have been identified have a plan to discuss or resolve
• The sprint board has been updated to match the current state

Sprint Review

• Team shares the outcome of the sprint
• Any functional demos are shared
• Any feedback is captured or a plan for discussion has been agreed upon

One on One

• All current prerformance and improvement goals have been discussed
• Any feedback for maanger or team member has been shared

Final thoughts

Just as there are many ways to craft a user story, there are many ways to craft a meeting invite. Don’t get caught up in the nuances of the format, nor with following the analogy of a user story meeting to the full extent. The analogy itself should provide value, and so long as the acceptance criteria is clear and helps us determine if the meeting is over and if it completed its outcome, then the analogy has served its purpose.

If you haven’t tried this technique, test it out with your next meeting and see if it helps you convey the purpose and outcome to the meeting attendees, keeps the meeting on track, and provide a clear signal that it is over.

As a meeting organizer, I want to provide meeting attendees with a clear, concise statement of our purpose and outcome, so that they understand the purpose and importance of the meeting

If you were to perform an audit of the meetings on your calendar, how many of them would have an agenda and a description? Of those that did have a description and agenda, how many of them provide a clear indication of the outcome of the meeting, who benefits from the meeting, and the clear steps we’ll follow along the way?

If you’re like me, most of the meetings on your calendar fail to meet these criteria. Sometimes, that’s because we’re busy and juggling multiple priorities. Other times, it’s because we didn’t put the preparation in for the meeting.

Meetings are painful, but they don’t have to be. Better meetings starts with preparation. And you can showcase your preparation to the attendees with the first thing they will see about the meeting: the meeting invite.

The best way I’ve found to capture the outcome and other important details of a meeting is to frame it like a user story, as suggested by Matt Philip and others over a decade ago. The user story format is one that most teams are familiar with and if it captures enough background and context for development of complex software, can we make it work for complex, collaborative meetings?

The basic user story format is:

As a {Who}, I want to {Outcome}, so that {Purpose}

Who

In our meeting as a user story, who could refer to 2 different groups; the group of attendees or the group that ultimately benefits from the meeting in the first place.

The simplest approach is to find a name to call the group of attendees. This is simple when we’re working with a development team. The next level approach, and a powerful technique, is to consider and name who benefits from the meeting. The audience benefits in some fashion, but who else beyond the audience? Leadership and stakeholders can benefit, but where possible, I like to consider the meeting from the customer’s perspective and frame the meeting in terms of how it benefits them.

Outcome

When we’re done with this meeting, what will we have achieved together? Sometimes, this is framed more of an output, such as a list of activites This approach has its place, but where possible I try to capture how we’re impacting the ‘who’ with the work that we are doing. Try to consider beyond the superficial surface activities if you can - those can always be captured further down in the description of the meeting.

Purpose

Purpose is the ‘so what’ portion of the user story. Why does this meeting matter? As an attendee, why do I care about the outcome and the person who benefits from it? This isn’t the same as ‘what’s in it for me’, but really more what’s in it for the borader organization. How does what we do in this meeting and achieving the outcome help us collectively achieve a broader goal?

Examples

Here’s a couple examples for a few common meetings:

Daily Standup

• As a team, we want to review what we accomplished yesterda, what we plan to accomplish today, and what blockers we have so that we can stay aligned on the goal for the team’s sprint.

This format lists outputs instead of outcomes. A next level user story for a daily standup would be

• As a team, we want to ensure we are aligned on our plan for the day so that we can monitor our progress on our sprint goal and pivot if necessary.

Sprint Review

• As a stakeholder, I want to review the Team’s progress, provide feedback, and adjust the backlog so that we ensure we’re developing the most valuable solution for our customers.

One on One

• As a team member, I want to meet with my manager to discuss current challenges, understand priorities, and talk about career advancement, so that I can grow and better serve the organization and customer.

Closing thoughts

Writing meeting descriptions in the user story is just the first step. A user story ussually contains acceptance criteria which further defines what is in scope for the user story. We can apply this to our meetings too, giving ourselves and the attendees a clear defintion of when the meeting is over. Approaching a meeting like a user story can help keep a meeting on point while giving us a clear purpose and outcome to work towards.

POWER through meeting preparation

Museum curators are responsible for collecting artifacts and the information behind them, caring for the artifacts and the stories behind them. Museum curtors then find a creative way to share the story.

As a meeting facilitator, we too are responsible for collecting and caring for information while finding a way for our meeting attendees to interact with the information, all in service to a purpose and outcome. Key to caring for this information is preparing for the meeting. In doing so there are 5 key items to preparation, captured in the acronym POWER

• Purpose - Why does this meeting exist?
• Outcome - What outcome are we working towards?
• who -who benefits from this meeting and who is necessary
• Execute -How to execute the meeting to accomplish the outcome?
• Role -what role do I play in this meeting?

This is a start to coneting a better meeting. To learn more, check out my deck on Curating Better Meetings, which I presented at Cincy Deliver on July 26th, or stay tuned her for more on how to prepare and execute great meetings.

Effective meetings require preparation and forethought from the organizer

Ask any Software Engineer what they’re least favorite part of their job is, and on that list will be meetings. Meetings are crucial to bring people together to collaborate, share information, or make decisions, but are universally loathed.

How can we make meetings better? The key is proper preparation. For novel, important meetings, I will devote anywhere from 1 to 3 times the length of the meeting to prepare for it. So, for a 1 hour meeting, I’ll prepare anywhere from 1 to 3 hours. I don’t follow this rule for recurring meetings, but I do spend some time preparing for each meeting. When establishing a recurring meeting or a novel meeting, I’ll pause to consider 5 important elements: the meeting’s purpose, the outcome, who needs to be involved and who benefits from the meeting, how I will execute the meeting, and the role I will play in the meeting.

Purpose

First I consider why the meeting exists in the first place. What larger purpose does the meeting play? What would happen if the meeting didn’t occur at all? When we rush through scheduling meetings, clarifying the purpose the meeting serves is often the first thing we neglect. But if you want the meeting to be valuable, you need to clarify the value it provides both for your attendees and for your self.

Outcome

Second I consider what outcome does this meeting need to achieve? Is this an informational sharing meeting? Are we introducing a new change? Are we collaborating on a solution? Or are we making a decision? These are a few of the common outcomes I encounter, but there are many more. Be concrete in what outcome the meeting should achieve, that way you and the attendees know when the meeting is over. Otherwise, with an unclear outcome, the meeting risks filling all of the space we allot for it.

Who

Next I consider who benefits from this meeting. Who is the chief benefactor for this meeting? If the purpose and outcome are clear, who benefits from the meeting should be obvious. As a facilitator, it is helpful for me to keep the benefactor in mind as I hold the meeting to center myself and consider how they would think of the progress we are making.

Also part of ‘who’, I consider who needs to attend this meeting. Who has the information we need in this meeting? Who needs to be present to hear the information? Who must make the decision? Understanding the purpose and outcome first helps us consider who is necessary for the meeting so we can limit the attendee list to the smallest group possible while still achieving the outcome.

Execute

With the outcome and the attendee list formulated, I then consider how I will execute the meeting. If collaboration is necessary, how will we engage all of the attendees? What is the journey that I and the attendees must take together in this meeting to ensure we reach the end of the meeting and achieve our objective? What conversations, questions, or decisions need to be made along the way, and how do I best support the group for those discussions?

Role

Finally, I consider what my role is in the meeting. As the organizer of the meeting, am I in a pure ‘facilitator’ role, or is there some secondary role that I may play, such as coach? What else must I do to prepare for the role(s) that I will be playing? What dangers may I encounter with the role(s) I am playing and if I am playing multiple roles, what confusion or problems may that cause?

Conclusion

Meeting preparation is crucial in setting the ground work for a successful meeting. Preparation will give you, as the meeting organizer, increased confidence stepping into the room that you’re meeting for the right reasons and working towards the proper outcome. For the next meeting you organize, consider POWERing through the preparation to make it a better meeting.

A Metric without context is just a number

In the 21st century, metrics are king. What organization isn’t informed or focused on metrics, relying on them to keep score, identify problems, and implement solutions? Metrics allow you to ask better questions, but they require interpretation. A metric without any context is just a number. One cannot make a decision knowing only a metric and without any other information.

For instance, if you were car shopping and all you knew was Car A had a highway fuel mileage of 32 while Car B had a highway fuel mileage of only 25? With just that information, would you be willing to buy Car A? Hopefully not, especially when I tell you Car A is a 1978 Ford Pinto.

If I said a particular scrum team had a velocity of 9, what use is the number alone? What’s the first thing that comes to mind when we consider that team? Do you, (like me) immediately jump to a conclusion? A better approach is to consider what questions to ask, questions that put the number into context such as

• How many people are on the team?
• How long has the team existed in it’s current form
• What’s the seniority of the team?
• How does the team point stories?

The answers to these questions may spawn other questions. For instance, if I respond to the last question that each story is pointed as a 1 and the team follows a “No Estimates” approach, you’ll want to know more and consider asking for additional metrics, such as cycle time and cummulative flow to further dig into how the team is perforiming.

Intuition and context play a huge role with metrics. Metrics should not replace smart people with their intuition nor should we rely solely on our intuition and observations alone. For those on-the-ground working the code, their intuition will point out where the problems lie. Sometimes these problems are obvious in the metrics. For many of the teams I work with, there is a bottleneck in delivery right after development completes. I see it each day looking at our Kanben board and from our conversations. The metrics also back up my observations, though it doesn’t come across as a large of a problem in the metrics as my intuition says it is.

Metrics also help us see patterns we have not seen before. Paired with our observations, metrics may help us articulate a challenge in ways to influence leadership action. Metrics, paired with intuition and context, can help spur leadership into action. Metrics help us see the consequences of a problem and consequentially, the benefit of fixing the issue.

Whether you rely on intuition first or metrics first, remember that they are stronger together. While some leaders may be influenced by observations and gut-drawn conclusions on their own, most will want to understand the numbers, not just for themselves but also for their leaders.

Prioritize your wildfires or your entire organization will burn

In spring 2023, thousands of wild fires raged in Canada. Across much of North America, skies were covered in a haze and the smell of burnt wood lingered in the air. With so many fires and so few firefighters, tough decisions had to be made to determine which fires would be controlled and which would be allowed to progress unchecked.

Not all fires are the same. Some occur in remote regions, making fighting them difficult. Also, due to their remote nature, their impact to human life is minimal. Still other fires occur near population centers and risk lives and property damage.

Wildfires are a naturally occurring phenomnon. Many are caused by lightning strikes. Still others are caused by careless
activity of humans. Environmental conditions and climatic trends play a huge role, as well as land management practices.

Organizations encounter their own types of wildfires. When was the last time you had a panicked email from a colleague, a last minute project request from your boss, or a meeting appear on your calendar with short notice? All of these are organizational wildfires, requiring you and your colleagues to respond quickly or face consequences. Just like a real wildfire, the consequences will vary. If you don’t respond to that panicked email, nothing may happen. Or a deal could be lost. Reputations impacted. Or not responding quickly may mean your team has to work a long evening or weekend.

Organizations will have problems and the organization’s culture comes out in how it responds to them. Do you respond quickly and with overwhelming force to each one? Or, are you more selective, choosing which ones to let smoulder while you forcus your efforts on the more critcal and impactful issues? Be careful the precedence you set with your leadership, as your people will look to you on how to respond to these problems. If you respond to every single problem with the same intensity, you risk burning yourself out as well as your team.

Just like wildfires have both natural and human based sources, organizational wildfires have different sources. There will always be problems that occur. Some problems are unavoidable. Yet others are completely avoidable. Next time you resolve a wildfire, consider if the problem could have been avoided, either through improved risk management, improved training, better expectation setting, or some other means.

Remember, only you can prevent organizational wildfires.

A good Scrum Master is far more than just a servant leader and agile expert

After years of being a Scrum Master and watching other Scrum Masters at work, there are a number of traits that the best Scrum Masters share. These traits make the Scrum Master effective at serving the team and organization in their agile journey.

First, let’s set some basic assumptions. I assume every Scrum Master is familiar with the Scrum Guide. They should be able to facilitate the Scrum events, though to be a good Scrum Master, they should be able to facilitate any type of meeting (with some preparation). A Scrum Master should also be able to explain the reason behind why things are done in Scrum, in order to coach reluctant team members. The Scrum Master should know enough of Scrum to mentor the team on it.

Servant Leader

Servant Leadership has almost devolved into the cliche management terminology world, like ‘strategize’. Servant Leadership looks different to many people, but I prefer to return to the root of the concept, which was inspired from the short novel “Journey to the East”. In this novel, one person ‘serves’ a large group as they embark on a spiritual journey. One day, that person vanishes and the group falls apart. Only later does the protagonist of the story realize that subtle leadership that the ‘servant’ provided. Futurama captured this sentiment when they ended an episode with the quote “When you do things right, people won’t be sure you’ve done anything at all.”

A servant leader combines elements of both words. As aservant, they help the team by being available and helping when asked. But they are also a leader, and specifically help their team by serving them in things that fulfill their vision. A Scrum Master, as a servant leader, will help a team schedule and facilitate a design meeting if asked. A good Scrum Master will place boundaries on these asks. For instance, if asked to facilitate a discussion that would violate one of the core tenants of agile, they should instead coach the team on the importance of those ideas.

Coachable

A good Scrum Master is a coach. But to be a good coach, they first must be someone who can be coached. Not every person is open to being coached. Some become set in their ways. Others become so sure of themselves that they shut themselves off to learning. Still others will listen to books, videos, or blogs, but will resist in person coaching. In each situation, a person shuts themselves off from vital resources and potentials for growth.

Growth Mindset

A Scrum Master must have a growth mindset - the belief that they and those around them can grow and learn - that things can be better tomorrow than they are today. A Scrum Master with the opposite view, fixed mindset will struggle to help their team continuously improve, and may see an end to the team’s agile journey.

Observant

To counter resistance to change, I look for a Scrum Master to be observant. They should be able to pick up on subtle hints that things aren’t right and when the timing is appropriate, shine a light on the problem. Observational skills come in many forms - using metrics, reading body language, conversations with the team, and chatting with stakeholders. A good Scrum Master is always collecting data, data that they can later use to coach the team to improve further.

Drives relentless improvement

A good Scrum Master knows that a team’s growth never ends. They will always find ways to improve, even if the team has been together for a long time. They balance their own observations and those that the team identifies. A great Scrum Master may be so subtle in their sharing of their own observations that the team isn’t even aware that the observations came from the Scrum Master.

Emotionally Intelligent

A great Scrum Master is emotionally intelligent, knowing how to regulate their own emotions while observing the emotions of others. They use these skills to note when things are left unsaid. They help the team understand their own emotions and help them express those emotions and thoughts to stakeholders and leaders in constructive ways.

Agile Expert

A good Scrum Master will know Scrum inside and out, but will also know when to apply it and when it won’t work. They are aware of other agile frameworks, techniques, and tools and know when best to apply them. For instance, they know that Kanban works better for a production support team than Scrum.

Specialist

A Scrum Master beyond an entry level position should have their own area of mastery. This is an area where they possess more skills and knowledge than their peers. This may be based on their natural talents, like building teams or facilitating meetings. It could be from a skill in their previous job, such as software engineering, quality assurance, product ownership, or project management. Having a speciality can help the immediate team, but also the larger agile organization by bringing insight to share with other Scrum Masters.

Adaptable

Finally, a great Scrum Master should be adaptable. They should hone their style to the team, not force the team to work within the Scrum Master’s style. A great Scrum Master will also vary the level of their coaching and the type of coaching based on where the team is. An anti-pattern in Scrum Masters is the so- called ‘Scrum Mom”, a Scrum Master who does many things for the team so they don’t have to. This may be useful for a team brand new to Scrum, as it shows the team how to do Scrum. To a well-seasoned team, a Scrum Mom is a bottle neck and has become the lid on the team’s performance - they can’t do any more work than what the Scrum Master can do. A good Scrum Master must embody the very thing they are coaching their teams to do - agility itself.

Conclusion

In short, a good Scrum Master is a servant leader, can be coached, possesses a growth mindset, is observant, is relentless in their pursuit of improvement for the team, is Emotionally Intelligent, knows not just Scrum inside and out but also other agile frameworks and tools, they have their own area of competency, and are themselves adaptable.

If you’re looking to improve your own skills as a Scrum Master, consider how you rank on each of these attributes. Consider how well each of the areas describes you. Beyond that, how likely are you to act according to those descriptions? What’s the percentage of time you exhibit a growth mindset vs. a fixed mindset?

To show up as an expert, know your process and exude confidence in your skills

There’s a story of a carpenter who was called to fix a squeeky floor. Entering the room, he made a quick inspection, pulled out a hammer, and struck the timbers in a single stroke. He stood, tested the spot, and proved the squeek fixed. After short work, he charged $100 for his efforts. When pressed why it cost so much for such short work, the carpenter replied he charged $5 for swinging the hammer and $95 for knowing where to swing.

A YouTube channel called Druneo has a series of videos where they put drum experts to a daunting test. The setup is simple. Take a drum expert, a full drum set, and a song the drummer is unfimilar with and given them a few minutes to listen to the song once. Then they ask the expert to play the drums to the song.

One of my favorite videos is this video where Larnell Lewis, who is known for his work with Jazz and Jazz fusion bands, plays Metallica’s “Enter Sandman” after listening to it for the first time. Watching the video, he explains his process as he listens, working to understand the form of the song, the pacing, the rhythm, and the elements of the drum kit he needs to use, when to use them, and how. What just sounds like banging and clashing to me, an expert picks up on the nuances of drums or cymbals used and any flourishes used on the original track.

Watching a master of their craft at work is a special sight. Through years of experience, an expert has learned how to do their craft well and fast.

The drum experts on Drumeo aren’t flawless and would change their approach given a second or third run-through of the song. No one expects an expert to flawlessly execute, but an expert does have to exude confidence they can tackle any situation. The drum experts on Drumeo also exude confidence. They don’t fret about the situation they find themselves in, Instead, they approach the challeng with their skills and a practiced list of steps to prepare.

Are you an expert in your craft? How would you fare if you were placed into an unknown situation and tasked with executing your craft? Are you able to enter the situation and with disciplined, practiced preparation, exercise your skills and produce? If not, what do you need to practice in order to reach that level? Here you outlined foryourself the steps would you follow in order to prepare like a drum expert?

Experts dazzle us with their skills. If you aspire to be an expert, keep honing your skills until one day you dazzle someone else. Perhaps one day, someone will look at you the way you look at an expert today.

Follow a 2 to 1 ratio to prepare for successful Meetings

When in college, time management is crucial. For many students, college is a culture shock. It is the first time they are on their own. One has to learn how to manage their own time amongst the complexity of their classes.

To guide students through this, a common rule of thumb is to plan to study for a class 2 or 3 times the number of credit hours it’s worth each week. So a student taking a 3 credit hour class should study 6 to 9 hours a week on that class in addition to the class time.

This handy rubrick has stuck with me over the years. I apply this to any classes I take as an adult. As a meeting facilitator, I’ve taken the novel approach of applying this to meeting preparation. I’ve found a 2 to 1 ratio to be a useful guide to manage my time in preparing and summarizing meetings.

Applying the rule is simple. Take any meeting and consider how long the meeting itself is. Then I double the time and that is how long I should spend up front to prep for the meeting. So if I have an hour long meeting, I spend 2 hours preparing for it.

This preparation time includes

• solidifiying and recalling the meeting purpose
• finalizing the agenda
• considering how I want to show up for the meeting
• facilition methods I need to prepare
• consider any landmines I may face in the meeting
• setting up the physical or virtual space
• reserving time for follow up after the meeting

We can’t apply this role to every meeting we facilitate. If we did, we’d be limited to about 12 hourss of facilitated meetings a week if we did nothing else. If you are struggling in your facilitation, consider if more preparation would help and apply the 2 to 1 rule for your crucial meetings.

Being a Servant Leader is not about being a servant

Servant Leadership is a common strategy employed in software engineering departments. Popularized by the agile movement and the establishment of Scrum Masters and Agile Coach’s as servant leaders for a team or the organization, servant leadership aims to empower teams and aid them in service to the team’s goal. Originally coined by Robert Greenleaf in the 60’s and 70’s, many thought leaders such as Ken Blanchard and John C. Maxwell expanded on the concept. One of my favorite books on the subject, edited by Ken Blanchard and Renee Broadwell is Servant Leadership in Action which includes essays from dozens of leaders on different aspects of servant leadership.

One concept that is overlooked on the subject is the duality of servant leadership. Too often I see people dismiss or poorly implement servant leadership because they focus on the servant part and forget about the leadership piece. Being a servant is about taking orders, doing what is asked of you, and being a support to those around you. These individuals miss the aspects of leadership of having a vision, leading from out front, and being proactive. A servant leader. must serve, but they must also serve according to a vision. A servant leader must posses both sides to be a true, effective servant leader.