7 important software engineering meetings you actually need

Software projects have many different stages, from planning to development to deployment and beyond.

Each of these stages entails a particular set of milestones, and reaching each milestone is accompanied by meetings.

However, not all meetings are created equal, so it’s important to know which ones are worth your time and which ones you should avoid.

Here are seven important software engineering meetings you should actually have.

The project kick-off meeting is one of the key meetings in every software development project.

As its name suggests, it’s the first meeting that takes place at the beginning of a project. 

Thus, it’s the first opportunity for the stakeholders and the developers to get together to discuss the details of the project.

The goal of this meeting is to ensure that all stakeholders have a shared understanding of the project so that there are no ambiguities that could result in delays and extra costs down the line. 

That’s why Didier Caroff, VP Engineer at Akeneo, notes that projects should not start before everyone sits down together for the kick-off meeting. He says:

Therefore, it’s essential to bring all involved to the kick-off meeting so that project owners, developers, and clients can align visions and get answers to their questions.

At this stage in a project, multiple kick-off meetings may be necessary to ensure that everyone fully understands its details and requirements.

For example, Brett Harned, digital project management consultant and founder of the Digital PM Summit, in the following YouTube video, offers insight into how he runs several kick-off meetings, starting at the 1:46 mark.

He usually holds two such meetings: an internal one for his team, where everyone learns about the upcoming project, and another external one with clients, in which they discuss further details.

Harned conducts them separately because he thinks that the internal kick-off meeting is a great opportunity to assemble the team and explain how they will interact with the client.

After this initial discussion, they all then have a kick-off meeting with external stakeholders where they further discuss how to move the project forward.

During kick-off meetings, several topics are typically discussed, and some of them you can see listed in the picture below.

The topics vary from project to project and may include: the project’s goals, scope, budget, timeline, deliverables, milestones, client expectations, project roles and responsibilities, etc.

The main takeaway here is that the purpose of the kick-off meeting is to ensure everyone involved in the project is on the same page—from both a strategic and tactical perspective—and the meeting helps everyone establish a clear sense of direction and expectations.

In scrum, the sprint represents a period of time during which certain tasks should be completed.

However, before you can start with your sprint, it’s important to lay the groundwork—decide how long the time box will be and what will be developed based on the backlog of work that needs to be completed.

In other words, you need to conduct an interval planning meeting—also known as a sprint planning meeting.

That being said, it’s clear that the interval planning meeting should be held at the very beginning of each sprint, as the picture below illustrates.

There are two primary purposes of interval planning: to select the most important user stories from the backlog for development in the sprint and to set up a plan for how they’ll be completed.

That’s why this kind of meeting includes all members of the team—product owners, business analysts, developers, testers, and so forth—who provide input on which items are high priority and how they should be addressed.

For example, the chart below shows how you can organize user stories from the backlog by their priority.

The ones that are of high priority—shown in darker blue and at the top of the chart—should be implemented first. 

Others, shown in lighter blue and placed lower on the chart, are less important but still need to be completed eventually.

Interval planning also consists of creating an initial estimate of the amount of time it’ll take to complete these tasks. 

While it’s important to get a plan in place, according to Dave West, CEO at Scrum.org, you shouldn’t spend too much time worrying about the details—that will just slow the process.

In other words, instead of creating an overly detailed sprint plan that includes every minute of the upcoming work, you should focus on defining user stories and only create a sprint backlog large enough for teams to get started.

That will allow developers to get into action quickly, which is the whole point of scrum. 

Technical meetings play an important role in the development process.

They’re held throughout the lifecycle of a software project, usually in situations where a complex development task must be carried out, or technical issues require more thought.

Mario Fernandez, a software engineer at Meta, has an interesting way of describing this kind of meeting:

During the technical meeting, the team leader and developers get together to discuss what is technically the best way to solve an issue.

Once the developers have laid out their vision of how to tackle the problem, they discuss different ways to implement the solution.

GitLab, an open-source software development platform, livestreams some of their meetings and makes them available for public viewing.

Luckily for us, we can now get a glimpse of what takes place in their technical meetings, thanks to the YouTube video below.

In the video, we can see the developers discussing their current project status and the technical issues they’re dealing with.

This meeting helps avoid misunderstandings, confusion, or miscommunication between the team members.

It also ensures that everyone is aligned with how things should work from a technical standpoint.

Moreover, it shows us that, roughly, technical meetings should consist of three main stages:

As you can see, a technical meeting is basically a brainstorming session that helps developers to figure out the best possible solutions to complex technical problems.

It helps identify the most efficient way to implement new features and resolve any conflicts that may arise during development.

Therefore, they should be held regularly throughout the project so that developers can ensure everything is running smoothly.

A daily standup meeting, or daily scrum, is a short meeting—typically 15 minutes or less—in which team members check in with each other to assess progress on tasks, identify roadblocks, and discuss how they can help each other move the project forward.

The objective of the daily standup meeting is to keep everyone focused on the same goal, as defined in the Scrum guide:

You might initially think that committing to a meeting every day is the opposite of efficient.

But the daily standups, with a clear, concise agenda, can be more efficient than other formats.

However, in order for this to happen, you have to meet one prerequisite.

They should be brief, focused discussions—after all, they’re called standups for a reason. 

They should be short enough that everyone should be able to remain standing for the duration of those meetings.

Therefore, the following checklist can come in handy when you want to make sure that your standups are as short and efficient as possible.

During daily standups, three main questions should be answered: what has been completed since the previous meeting, what will be done until the next one, and how any obstacles will be overcome.

Answering these questions will help the team see progress and identify roadblocks that need to be addressed.

However, it’s important to note that many developers feel that standup meetings are a waste of time, as you can see in one post in the Quora thread below. 

Sure, it’s true that the daily scrum can become a burden when done incorrectly, providing little value to the team.

But if you watch for signs that your daily scrum meetings aren’t working well—such as disengaged developers when it’s not their turn to speak—you can address those problems before they get out of hand.

All in all, as a result of the daily standups, team members should have a good idea of the project status as well as any potential issues. 

And that is why it’s so important to conduct them regularly.

When your sprint starts nearing its end and the features you’ve been working on meet client requirements, you may decide to schedule a demo meeting, also known as a sprint review meeting.

Demo meetings are often the most critical events in a sprint because these are the very meetings where the progress achieved is demonstrated to clients and other important stakeholders.

To illustrate this, here’s an image that should make it easier to understand.

That means that the demo meetings will take place near the end of the sprint because, by that point, most of the work will most likely be done.

Additionally, the product owner and client will want to see the latest version of the software and evaluate whether it meets the requirements.

The demo meeting is also an opportunity for you to discuss with clients any concerns or issues they may have about what was delivered in the sprint and make sure that everyone remains on the same wavelength before moving forward into the next cycle of development.

An excellent demo meeting will usually have the following structure.

First, as the picture below shows, the product owner will initiate the meeting by welcoming all stakeholders and presenting the agenda.

The review starts with a demonstration of the incremental improvements made in the project.

Next, the product owner marks completed user stories as “done” and returns incomplete items to the product backlog.

Finally, the stakeholders give feedback regarding the backlog, and then the meeting enters the wrap-up phase.

This is just a short summary of how a demo meeting works, but you get the picture. 

The bottom line is that such meetings ensure that the team and stakeholders stay aligned on their goals and progress.

Retrospective meetings are a valuable tool that can be used to improve internal team processes.

These meetings are held at the very end of the sprint, after the sprint review meeting, and generally include all members of the team.

They’re used to provide an opportunity for the team to stop and reflect on both their individual role and the overall process of development.

This allows them to identify positive and negative aspects of the current sprint, with a specific focus on best practices to adopt and potential issues to address in the next sprints.

In other words, at its core, the retrospective meeting is all about improvement.

Or, as Esther Derby and Diana Larsen state in their book Agile Retrospectives–Making Good Teams Great, retrospectives help teams identify their weak spots and improve them.

In order to make the most of a retrospective meeting, you should cover four topics.

First, you should discuss what went well during the sprint. This helps the team focus on the good work they’ve done.

Second, you should discuss what didn’t go so well during the sprint. 

This isn’t about finding someone to blame for things that went wrong—it’s about identifying issues that can be addressed going forward.

Third, you should detect what could be done differently next time in order to improve your current process.

And finally, you should create actionable commitments for the team to complete in the next sprint.

There are many informal variations to this structure, with formats such as Keep, drop, start, The 4Ls, The three little pigs, and The team radar as some of the most popular.

However, whether you choose to use a more traditional or informal structure, the end goal should always be the same: identify what went wrong and how to do better next time.

One-on-one meetings with your developers are crucial, especially if you want to create a good working relationship.

These meetings can be a good opportunity to discuss projects and share ideas, but sometimes the best part is just talking to each other as colleagues.

In fact, according to a study, employees who have more frequent one-on-one meetings with their supervisors are less likely to feel disengaged at work.

These kinds of conversations help build trust and camaraderie, which create an environment where employees feel comfortable sharing their opinions, and the team can work together more efficiently.

There are innumerable ways to conduct one-on-one meetings with your developers, and finding just the right format can be challenging.

Kate, a business and technology writer at Jell points out that there is no single way to hold effective one-on-one meetings.

Although there is no one-fits-all solution here that would work best for all teams, a few guidelines can help you structure your one-on-ones to maximize their effectiveness.

For example, Anna Dziuba, VP of Delivery at Relevant Software, mentioned some of these guidelines in her blog post. 

She thinks that it is first and foremost important to plan your one-on-one meetings properly. For example, creating an agenda can keep the conversation focused. 

She also suggests that you make sure to talk about career development and take notes. Plus, you should never cancel them but rather reschedule if necessary.

Maybe the best advice on how to run effective one-on-ones comes from Ben Horowitz, a technology entrepreneur and co-founder of the venture capital firm Andreessen Horowitz.

According to him, in a one-on-one meeting, the manager’s job is to facilitate—not dictate—the conversation.

This is the place where developers can discuss all of those issues that don’t translate well into reports, emails, or other impersonal methods.

A meeting that gives your employees control of the pace and tone is a great way to hear them talk, share their concerns—and open up about what matters most.

When you’re working on a software development project, it’s crucial that you have the right meetings in place to ensure your team is productive and efficient.

In this article, we’ve covered seven meetings that you should schedule when working on a software development project.

These meetings will help you keep the project on track, identify any problems early enough that they’re easier to fix, and give everyone involved a clearer picture of what they’re working towards.