Photo by Olga Guryanova on Unsplash
Coming from a self-taught background, I had no idea what scrum was when I got my first developer job. All of a sudden, I was going to meetings called daily standups, which no one stood up in, and sprint retros. Of course, being the new guy on the team, full of imposter syndrome, and not wanting to look stupid, I just went along for the ride. It probably took a month before I figured out what each meeting was for and even longer to find good resources on why we have the meetings we do.
Luckily for you, I thought I would give a simple summary of what the meetings are for and why. For a deeper dive, I would recommend the Scrum book over at the Pragmatic Programmers. This is not an all-encompassing list of all the potential meetings, but it hits the major ones you will likely see as a developer.
Daily Standup
Sometimes called daily scrum, it is supposed to be a quick meeting where team members give a status report and plan. This meeting should be fast enough that no one should need to sit down. Some good advice I got from someone once was that a good stand-up should have 3 sentences: What you did, what you are doing, and any future issues or blockers.
Backlog Refinement
Sometimes called Backlog Grooming (though the term is losing favor due to negative connotations the term grooming has come to represent) is where you go over the work that needs to be done. This is the time to verify what is required in a story. What are the requirements that satisfy this work, and how you know you are done?
This is also typically when you put story points to the work. Story points are used to give your best judgment of how big of work each story takes. There are different tools to help, like poker planning and Fibonacci numbers. Other teams try to use T-shirt sizing, small or medium or extra-large. Whatever method is used, it is used to benefit the next meeting we will talk about.
Sprint Planning
Sprint planning is the process of deciding which items in the backlog your team is committing to completing this sprint. A sprint can be any arbitrary time frame, but two weeks seems to be the most typical length. This is where the story points from the Backlog refinement come in. By pre estimating your work, you can make reasonable judgments on what amount of work you can get done in a typical sprint, based on history.
It’s also an opportunity to have a conversation. If too many things are expected, that can reasonably be finished. This is the time to prioritize and set expectations of how long something will take.
Sprint Retro
Sprint Retro is a great time to take a step back. And review how the previous sprint went. This is a good time to pause and reflect. What went well and what didn’t and how do we do more went well in the future and less of what didn’t. This is not a time to point fingers or blame (in fact, there never is a good time for that). Retros are for objectively looking back and making course corrections so that the team can keep moving in the right direction.
These are the most important meetings you should know about as someone starting fresh in this industry. There are ceremonies and patterns that I would highly recommend you check out in the Pragmatic Programer’s link above.
