Scrum is a methodology designed to help product teams produce better products. Often times, you hear Scrum and Agile used interchangeably, but that’s not the correct way to think about. Agile is a philosophy that contains a set of principles or beliefs to produce working software. Scrum is how you create products using the Agile philosophy. Let’s take a look at Scrum in more detail.
Sprint Planning
Sprint planning is where it all begins. To be clear, this event happens before every sprint. For my team specifically, we operate in 2-week sprints that kick off every other Tuesday. Typically, we will hold the sprint planning meeting the Thursday prior to the Tuesday sprint kick off. This gives us time to think about which stories need to be placed in the next sprint, and which engineers will work on them. That’s the whole goal of sprint planning – making sure you’re ready for the upcoming sprint kickoff. In our team, it’s typically only product management and the lead engineer that are a part of this meeting. The engineers don’t need visibility to the story level details until they are ready to be consumed.
Sprint
The sprint is where the work gets done. Each organization will take a different approach to the duration of their sprints. Like I mentioned above, my team uses 2-week sprints. On sprint-kickoff Tuesday’s, the whole team gathers on a meeting. We talk about stories that we want to accomplish in the upcoming sprint, make sure each user story has story points assigned to it, and assign it to an engineer. Over time, a team will know about what their velocity is, making it easier to assign the correct amount of story points to each team member. The goal for each engineer is to create a working,, tested piece of software by the end of the sprint. This means the user stories are typically written so that it includes both front-end and back-end work. That’s not always possible, but that is the goal.
Daily Scrum
Each day, the team gathers for 15 minutes, typically in the morning, to go over three things:
- What did they accomplish yesterday?
- What do they plan to accomplish today?
- What blockers are they facing?
These questions may seem like micromanaging, but that’s not the intention. In order to work well as a team, you need to know what others are doing. Often times, the exact issue you fixed last week is what another team member is running into this week! They could bang their head against the wall for a couple days trying to figure it out, or you could just set up a meeting with them right after scrum to show them how to resolve the issue. One thing worth mentioning is that problems aren’t meant to be solved during scrum. The only goal is to bring them up so that they can be addressed in a future time slot if necessary.
Sprint Review
Sprint review occurs on the final day of the sprint. For my team, this is the Monday preceding the next sprint kickoff. The goal during the sprint review meeting is to get a demo from each of the engineers. Ideally, they’ve each produced a working, tested piece of software. The team wants to see it! Product managers and other stakeholders get the chance to ask questions and provide feedback. It’s important to remember to celebrate the wins, because a lot of hard work has gone into the completion of a story.
Sprint Retrospective
The retro occurs directly after the sprint review ceremony. This is a time for the team to decompress and get reflective. The goal is to talk about what went well, what didn’t go well, and set a goal that will improve the team over the next sprint. During the time period where you’re talking about what went well, it’s important others chime in on tasks where they received help. No one wants to brag, but everyone enjoys being recognized, so make sure to do that! Also, when the team begins discussing what didn’t go as well, speak about the issue itself, not the person. If the issue really does boil down to an individual not contributing as expected, that conversation is better left for a one on one with their manager. While the team is together, don’t make conversations about individuals if they are struggling.
Wrapping it up
That’s a wrap! I hope you enjoyed learning a little more about the Scrum methodology. My team has been using it for 2 years now, and it seemed like a lot up front while we were all learning, but I can confidently say it is now helping us develop better products. There are many software methodologies out there, so I’d love to hear your team’s approach if you use something other than Scrum. Comment below!
