8 must-have software engineering meetings

Software developers have a lot on their plate. Attending too many meetings and that too without any agenda can be overwhelming for them.

The meetings must be with a purpose, help the engineering team to make progress, and provide an opportunity to align their goals, priorities, and expectations.

Below are eight important software engineering meetings you should conduct timely.

Must-have software engineering meetings

There are various types of software engineering meetings. We’ve curated a list of must-have engineering meetings along with a set of metrics.

These metrics serve to provide structure and outcomes for the software engineering meetings. Make sure to ask the right questions with a focus on enhancing team efficiency and align the discussions with measurable metrics.

Daily standups

Such types of meetings happen daily. These are short meetings that typically occur for 15 minutes or less. Daily standup meetings focus on four questions:

  • How is everyone on the team progressing towards their goals?
  • Is everyone on the same page?
  • Are there any challenges or blockers for individual team members?

It allows software developers to have a clear, concise agenda and focus on the same goal. Moreover, it helps in avoiding duplication of work and prevents wasting time and effort.

Metrics for daily standups

Check-ins

These include the questions around inspection, transparency, adaption, and blockers (mentioned above), hence, simplifying the check-in process. It allows team members to understand each others’ updates and track progress over time. This allows standups to remain relevant and productive.

Daily activity

Daily activity promotes a robust, continuous delivery workflow by ensuring the active participation of every engineer in the development process. This metric includes a range of symbols that represent various PR activities of the team’s work such as Commit, Pull Request, PR Merge, Review, and Comment. It further gives valuable information including the type of Git activity, the name and number of the PR, changes in the line of code in this PR, the repository name where this PR lies, and so on.

Daily activity
Work in progress

Work progress helps in understanding what teams are working on and objective measures of their work progress. This allows engineering leaders and developers to better plan for the day, identify blockers in the early stages, and think critically about the progress.

Work in progress

Sprint planning meetings

Sprint planning meetings are conducted at the beginning of each sprint. It allows the scrum team to decide what work will they complete in the upcoming iteration, set sprint goals, and align on the next steps. The key purpose of these meetings is for the team to consider how will they approach doing what the product owner has requested.

These plannings are done based on the velocity or capacity and the sprint length.

Metrics for sprint planning meetings

Sprint goals

Sprint goals are the clear, concise objectives the team aims to achieve during the sprint. It helps the team understand what they need to achieve and ensure everyone is on the same page and working towards a common goal.

These are set based on the previous velocity, cycle time, lead time, work-in-progress, and other quality metrics such as defect counts and test coverage.

Sprint - carry over

It represents the Issues/Story Points that were not completed in the sprint and moved to later sprints. Monitoring carry-over items during these meetings allows teams to assess their sprint planning accuracy and execution efficiency. It also enables teams to uncover underlying reasons for incomplete work which further helps identify the root causes to address them effectively.

Developer workload
Developer workload

Developer Workload represents the count of Issue tickets or Story points completed by each developer against the total Issue tickets/Story points assigned to them in the current sprint. Keeping track of developer workload is essential as it helps in informed decision-making, efficient resource management, and successful sprint execution in agile software development.

Planning accuracy

Planning Accuracy represents the percentage of Tasks Planned versus Tasks Completed within a given time frame. Measuring planning accuracy helps identify discrepancies between planned and completed tasks which further helps in better allocating resources and manpower to tasks. It also enables a better estimate of the time required for tasks, leading to improved time management and more realistic project timelines.

Planning accuracy

Weekly priority meetings

Such types of meetings work very well with sprint planning meetings. These are conducted at every start of the week (Or can be conducted as per the software engineering teams). It helps ensure a smooth process and the next sprint lines up with the team’s requirements to be successful. These meetings help to prioritize tasks, goals, and objectives for the week, what was accomplished in the previous week, and what needs to be done in the upcoming week. This helps align, collaborate, and plan among team members.

Metrics for weekly priority meetings

Sprint progress

Sprint progress helps the team understand how they are progressing toward their sprint goals and whether any adjustments are needed to stay on track. Some of the common metrics for sprint progress include:

  • Team velocity
  • Sprint burndown chart
  • Daily standup updates
  • Work progress and work breakup
Code health

Code health provides insights into the overall quality and maintainability of the codebase. Monitoring code health metrics such as code coverage, cyclomatic complexity, and code duplication helps identify areas needing refactoring or improvement. It also offers an opportunity for knowledge sharing and collaboration among team members.

Code health
PR activity

Analyzing pull requests by a team through different data cuts can provide valuable insights into the engineering process, team performance, and potential areas for improvement. Software engineers must follow best dev practices aligned with improvement goals and impact software delivery metrics. Engineering leaders can set specific objectives or targets regarding PR activity for tech teams. It helps to track progress towards these goals, provides insights on performance, and enables alignment with the best practices to make the team more efficient.

PR activity
Deployment frequency

Deployment frequency measures how often code is deployed into production per week, taking into account everything from bug fixes and capability improvements to new features. Measuring deployment frequency offers in-depth insights into the efficiency, reliability, and maturity of an engineering team’s development and deployment processes. These insights can be used to optimize workflows, improve team collaboration, and enhance overall productivity.

Deployment frequency

Performance review meetings

Performance review meetings help in evaluating engineering works during a specific period. These meetings can be conducted biweekly, monthly, quarterly, and annually. These effective meetings help individual engineers understand their weaknesses, and strengths and improve their work. Engineering managers can provide constructive feedback to them, offer guidance accordingly, and provide growth opportunities.  

Metrics for performance review meetings

Code coverage

It measures the percentage of code that is executed by automated tests offers insight into the effectiveness of the testing strategy and helps ensure that critical parts of the codebase are adequately tested. Evaluating code coverage in performance reviews provides insight into the developer’s commitment to producing high-quality, reliable code.

Code coverage
Pull requests

By reviewing PRs in performance review meetings, engineering managers can assess the code quality written by individuals. They can evaluate factors such as adherence to coding standards, best practices, readability, and maintainability. Engineering managers can identify trends and patterns that may indicate areas where developers are struggling to break down tasks effectively.

Pull requests
Developer experience

By measuring developer experience in performance reviews, engineering managers can assess the strengths and weaknesses of a developer’s skill set, and understanding and addressing the aspects can lead to higher productivity, reduced burnout, and increased overall team performance.

Developer experience

Technical meeting

Technical meetings are important for software developers and are held throughout the software product life cycle. In such types of meetings, complex software development tasks are carried out, and discuss the best way to solve an issue.

Technical meetings contain three main stages:

  • Identifying tech issues and concerns related to the project.
  • Asking senior software engineers and developers for advice on tech problems.
  • Finding the best solution for technical problems.

Metrics for technical meeting

Bugs rate

The Bugs Rate represents the average number of bugs raised against the total issues completed for a selected time range. This helps assess code quality and identify areas that require improvement. By actively monitoring and managing bug rates, engineering teams can deliver more reliable and robust software solutions that meet or exceed customer expectations.

Bugs rate
Incident opened

It represents the number of production incidents that occurred during the selected period. This helps to evaluate the business impact on customers and resolve their issues faster. Tracking incidents allows teams to detect issues early, identify the root causes of problems, and proactively identify trends and patterns.

Incident opened
Time to build

Time to Build represents the average time taken by all the steps of each deployment to complete in the production environment. Tracking time to build enables teams to optimize build pipelines, reduce build times, and ensure that teams meet service level agreements (SLAs) for deploying changes, maintaining reliability, and meeting customer expectations.

Time to build
Mean time to restore

Mean Time to Restore (MTTR) represents the average time taken to resolve a production failure/incident and restore normal system functionality each week. MTTR reflects the team’s ability to detect, diagnose, and resolve incidents promptly, identifies recurrent or complex issues that require root cause analysis, and allows teams to evaluate the effectiveness of process improvements and incident management practices.

Sprint retrospective meetings

Sprint retrospective meetings play an important role in agile methodology. Usually, the sprints are two weeks long. These are conducted after the review meeting and before the sprint planning meeting. In these types of meetings, the team discusses what went well in the sprint and what could be improved.

In sprint retrospective meetings, the entire team i.e. developers, scrum master, and the product owner are present. This encourages open discussions and exchange learning with each other.

Metrics for sprint retrospective meetings

Issue cycle time

Issue Cycle Time represents the average time it takes for an Issue ticket to transition from the ‘In Progress’ state to the ‘Completion’ state. Tracking issue cycle time is essential as it provides actionable insights for process improvement, planning, and performance monitoring during sprint retrospective meetings. It further helps in pinpointing areas of improvement, identifying areas for workflow optimization, and setting realistic expectations.

Team velocity

Team Velocity represents the average number of completed Issue tickets or Story points across each sprint. It provides valuable insights into the pace at which the team is completing work and delivering value such as how much work is completed, carry over, and if there’s any scope creep. It helps in assessing the team’s productivity and efficiency during sprints, allowing teams to detect and address these issues early on and offer them constructive feedback by continuously tracking them.

Team velocity
Work in progress

It represents the percentage breakdown of Issue tickets or Story points in the selected sprint according to their current workflow status. Tracking work in progress helps software engineering teams gain visibility into the status of individual tasks or stories within the sprint. It also helps identify bottlenecks or blockers in the workflow, streamline workflows, and eliminate unnecessary handoffs.

Throughput

Throughput is a measure of how many units of information a system can process in a given amount of time. It is about keeping track of how much work is getting done in a specific period. This overall throughput can be measured by

  • The rate at which the Pull Requests are merged into any of the code branches per day.
  • The average number of days per week each developer commits their code to Git.
  • The breakup of total Pull Requests created in the selected time.
  • The average number of Pull Requests merged in the main/master/production branch per week.

Throughput directly reflects the team’s productivity i.e. whether it is increasing, decreasing, or is constant throughout the sprint. It also evaluates the impact of process changes, sets realistic goals, and fosters a culture of continuous improvement.

Work in progress

CTO leadership meeting

These are strategic gatherings that involve the CTO and other key leaders within the tech department. The key purpose of these meetings is to discuss and make decisions on strategic and operations issues related to organizations’ tech initiatives. It allows CTOs and tech leaders to align tech strategy with overall business strategy for setting long-term goals, tech roadmaps, and innovative initiatives.

Besides this, KPIs and other engineering metrics are also reviewed to assess the permanence, measure success, identify blind spots, and make data-driven decisions.

Metrics for CTO leadership meeting

Investment and resource distribution

It is the allocation of time, money, and effort across different work categories or projects for a given time. It helps in optimizing resource allocation and drives dev efforts towards areas of maximum business impact. These insights can further be used to evaluate project feasibility, resource requirements, and potential risks. Hence, allocating the engineering team better to drive maximum deliveries.

Investment and resource distribution
DORA metrics

Measuring DORA metrics is vital for CTO leadership meetings because they provide valuable insights into the effectiveness and efficiency of the software development and delivery processes within the organization. It allows organizations to benchmark their software delivery performance against industry standards and assess how quickly their teams can respond to market changes and deliver value to customers.

DORA metrics
Devex score

DevEx scores directly correlate with developer productivity. A positive DevEx contributes to the achievement of broader business goals, such as increased revenue, market share, and customer satisfaction. Moreover, CTOs and leaders who prioritize DevEx can differentiate their organization as an employer of choice for top technical talent.

One-on-one meetings

In such types of meetings, individuals can have private time with the manager to discuss their challenges, goals, and career progress. They can share their opinion and exchange feedback on various aspects of the work.

Moreover, to create a good working relationship, one-on-one meetings are an essential part of the organization. It allows engineering managers to understand how every team member is feeling at the workplace, setting goals, and discussing concerns regarding their current role.

Metrics are not necessary for one-on-one meetings. While engineering managers can consider the DevEx score and past feedback, their primary focus must be building stronger relationships with their team members, beyond work-related topics.

  • Such meetings must concentrate on the individual’s personal growth, challenges, and career aspirations. Discussing metrics can shift the focus from personal development to performance evaluation, which might not be the primary goal of these meetings.
  • Focusing on metrics during one-on-one meetings can create a formal and potentially intimidating atmosphere. The developer might feel judged and less likely to share honest feedback or discuss personal concerns.
  • One-on-one meetings are an opportunity to discuss the softer aspects of performance that are crucial for a well-rounded evaluation.
  • These meetings are a chance for developers to voice any obstacles or issues they are facing. The engineering leader can then provide support or resources to help overcome these challenges.
  • Individuals may have new ideas or suggestions for process improvements that don’t necessarily fit within the current metrics. Providing a space for these discussions can foster innovation and continuous improvement.

Conclusion

While working on software development projects is crucial, it is also important to have the right set of meetings to ensure that the team is productive and efficient. These software engineering meetings along with metrics empower teams to make informed decisions, allocate tasks efficiently, meet deadlines, and appropriately allocate resources.