5 Kinds of meeting I learned about when I joined Tech

Hey fellow developers and developers in the making (or developings) ??

The cornerstone of corporate communications is meetings, and while the word is often casually thrown around, it usually comes with an agenda. Especially in the tech world, there are some standard procedures and meetings that developers frequently log into.

1. Stand Up ??

When we hear "stand-up," we might think of a bar or an open mic with people laughing at lame yet relatable jokes. But no, that's not what stand-up means for devs. A stand-up is a regular meeting where teams update their progress on tasks, identify blockers, and discuss how to plan work around them. Stand-ups can be daily, weekly, or even on an as-needed basis. Even discussing work during tea breaks is often considered a stand-up ?.

2. Sprint Planning

This process varies for almost every organization and team. In sprint planning, teams following Agile methodologies sit down with their Sprint Master (aka the timeline watchdog) and discuss the work to be done in a sprint. A sprint is a time duration within which a tested feature or update is provided as a release. Most sprints are calculated on a weekly basis.

Managing sprints is a true art and takes practice to master. However, like any craft, they are always imperfect. It's the Sprint Master's job to consider any delays or blockers while planning a sprint.

3. Backlog Grooming

Building on the previous process, before sprint planning, tasks are created and kept in a backlog storage of whatever digital tool is being used. The backlog is a store of all tasks that need to be done for a new project, with each task representing a feature or a subset of a bigger feature.

The tasks to be completed in a sprint are then picked from the backlog and put into each sprint. The backlog grows as more features are added to the software or as the testing team reports more bugs ??.

With a growing backlog, there is a need to groom it. Grooming often involves removing tasks that are deprecated, combining multiple tasks with a common objective into one, tracking how long tasks have been in the backlog, and creating a resolution strategy for minimizing the backlog.

4. Timeline Estimation

When a new project comes around, the first task is listing out all workable and interactive features and then planning a phased release process and the respective timeline. With most organizations adopting Agile processes, software is no longer built in one long haul but is broken down into phased releases, with each release containing a new workable, tested feature that builds on the previous release.

Estimating the timeline for each release is the central tenet of true Agile methodology and requires foreseeing almost all worst-case scenarios. The golden rule of timeline estimation is to follow Murphy's Law:

"Anything that can go wrong will go wrong."

Timelines presented via Excel sheets display the number of hours required to complete a feature. Each phase's timeline also contains a buffer period during which the app goes through rounds of testing and bug fixes. This is communicated to project/product managers and is more often than not susceptible to change.

5. Code Reviews ??

The most dreaded meeting any junior developer logs into is a code review. This is where teams go through a mountain of pull requests, testing them and then reviewing the code. This review process is supposed to provide constructive feedback, discuss common coding patterns and conventions to maintain clarity in the codebase, and identify better solutions to frequent problems. All this happens if the team is organised ??.

To conclude, these are some of the common meetings I have been a part of, along with some unexpected lessons I have learned. Feel free to share your own experiences in the comments section.