Scrum is perhaps the most recognizable of agile frameworks. Its name comes from the rugby ritual in which players all clump together to try and get the ball, although the better imagery for scrum is less the formation itself and more the team as a functional unit trying to get the ball down the field.
The rugby metaphor doesn't end there. In a scrum team, there are also multiple roles to play, much like a team has different positions. There is the product owner, scrum development team, and scrum master.
Let's now take a shift from the sports world to the code world to see how what these roles are and how they interact!
Scrum workflow
The main basis of a scrum team workflow is a sprint. As you learned in the previous chapter, a sprint is a defined period in which a set of tasks are supposed to be finished. These timelines are often either 2 weeks or 30 days.
At the beginning of a sprint, a team gets together to discuss what everyone can commit to and what should be done during the sprint itself. Each functionality within the sprint shouldn't just be preliminarily coded; it should be coded and tested. This encourages the breaking down of large functionalities into smaller iterations. Iterations are a major element of agile workflows, as you learned in the first chapter.
Scrum roles
There are three major roles in a scrum team: the Scrum Master, product owner, and the team.
Think of your overall scrum team like a cruise ship. The product owner is the captain of the ship, making sure the ship doesn't end up in Alaska if it was supposed to go to Hawaii. The scrum master is the ship's engineer, constantly greasing the gears and keeping the engines in tip-top shape. The team is the ship itself, the body that gets the product from point A to point B!
Scrum Master
Despite the intense name, a Scrum Master is not a boss or manager! They are there to facilitate the project and to get any potential obstacles out of the way. The Scrum Master's got an eye on all aspects of the project, including coding, testing, organizational, and human-level concerns.
For example, imagine a team embarks on a project together, but the project surpasses everyone's current technical levels. The Scrum Master will intervene and help the team break down the project into more digestible chunks suited to their abilities. Alternatively, if the team keeps forgetting the project schedule, the Scrum Master will buy a whiteboard or introduce a tool to help the team be more aware of the development schedule.
Product owner
A product owner is responsible for the product itself, often through managing tools called the product backlog and the product roadmap. The product backlog is the operations-level view of projects that should or are being built. The product roadmap is the strategic-level view of projects and their releases that involves a greater share of a company beyond the development team.
Depending on the team's organization, this role can often resemble more of a feature owner role. This is often someone who really depends on the project. For example, if there's a financial functionality at stake, the product owner might be the lead payments developer or even someone from the company's financial team.
Either way, the product owner often writes user stories, which are an effective way to maintain the user-focused mentality described in the preceding chapter on agility! They often take the following format:
As a _____ user, I want _____ so that _____.
By writing user stories, a product owner can more efficiently prioritize the product backlog during sprint planning meetings and elaborate the product roadmap.
A story goes through the following phases:
Proposal: one day, a person suggests a new feature.
Accepted: the Product Owner accepts the proposal and adds it to the backlog.
Estimated: the team estimates the size/workload of the story.
Ready: the story is written and estimated. It waits to be developed.
Ongoing: the team is in the process of developing it.
Finished: it's released!
The team
Lastly in the scrum process, but most importantly, you have the team! A team is going to build the features elaborated by the product owner while the Scrum Master gets all possible obstacles out of the way. Each member of the team likely has a specialty but should be able to jump in and help other team members as needed. We call this a cross-functional team.
Scrum is a great way of making general agile principles more concrete. Like other agile methodologies, teams can implement scrum 100% or simply adopt several principles from it. Just because it's a great option, it's not suitable for every team or product. Think about group projects you've worked on in school or at work; would they have benefited from this type of workflow?
