Installment Three: SCRUM Roles

At last we are on the final installment in this SCRUM series, so far we have covered SCRUM methodology as well as the ceremonies of SCRUM. Now we are going to go over a seemingly basic topic, SCRUM roles. These explanations are going to be the final piece in this software engineering method.

The product owner or product manager: The product managers has various responsibilities in SCRUM. One of these responsibilities is doing the initial prioritization of the story backlog. I talked about what a story backlog in the last article if you missed it. The product manager is also the ONLY “go between” between the SCRUM team and the corporate level. This is a necessary form of mediation in order for upper corporate management to not continuously dump work on the SCRUM team. The product manager is present at the sprint planning meeting and is the only one who is allowed to present the team work. Once the SCRUM team reaches their maximum point velocity for work in a given sprint the product manager can not try to push any more work upon them. The product manager also has to be available during this meeting and throughout the week to answer any questions about stories and the tasks that stories are split into. The product manager also conveys the needs of the customers and works with the stakeholders in order to clearly establish expectations for a sprint. It is preferable that a product manager is not a coder so that they never feel obligated to pitch in on the coding while neglecting their own work.

The SCRUM Master: The SCRUM master is a PEER position, not a boss. SCRUM teams should eventually become self organizing but all teams need a little help. The SCRUM master runs daily SCRUM meetings and tries their best to remove and impediments that a team member may be facing. The SCRUM master also leads the retrospective meeting at the end of a given sprint and the discussion on what improvements could be made. A good SCRUM leader will put the needs of their team over their desire to directly participate. They will also recognize when the team does not need as much guidance and will adjust their leadership style to allow the team to have more shared autonomy. SCRUM masters often code, but don’t have to. If they do code they need to find a balance between completing their own tasks and keeping open communication with their team.

The team member: The rest of a SCRUM team is composed of team members, duh. Team members are programmers, testers, and whatever else is necessary for software to run smoothly. Team members are the AUTHORITY for how work gets done and how long stories will take. This is because no one knows the work better than the people who complete it. Team members also must have the “not my job, the job mentality”. For example if a java coder completed their tasks very quickly because there was not many java tasks in a given sprint, they are expected to step up and run testing. Overall a SCRUM team member needs to be flexible and willing to take on any problems thrown their way.

That wraps up this series! If you learned anything, I hope that you learned that SCRUM is actually very simple. It quite literally sounds like common sense, I know when I read “The Elements of SCRUM” by Chris Sims and Hillary Johnson the whole time I was just thinking “duh”. Well I highly doubt anyone read any of these because SCRUM is definitely a niche topic that seems boring to high schoolers, but if you did make it this far then congratulations!