Many describe Scrum as a product development strategy based on flexible work processes that enable quick and agile delivery, especially in a tech context. Typically, a project manager will receive notice from a business developer that a client is interested in moving forward on a project. Once a set of requirements is decided, the project manager gathers together a development team and gets started on the workflow. But how is the Scrum team organized into roles and what are some of the activities included in the workflow?
This article will outline the three main roles of the Scrum team (Product Owner, Scrum Master, and Development Team) and describe key Events of the team’s production process. During the process of working on a Scrum project, the team uses a number of tools, or artifacts, that have values specific to the Scrum methodology. The Product Backlog and Sprint Backlog are stored as entries in the team’s project management software (or Enterprise Resource Planning [ERP] solution) and updated over the course of each Product Increment. Yet these aren’t the only elements involved in Scrum projects.
Scrum is all about flexibility. And learning about all of these Roles, Events, and Artifacts of Scrum will not only make the process more clear. It will also make Scrum even more efficient. Before wrapping up, we’ll discuss other Scrum Artifacts and explain how to make all these elements work together.
First, let’s talk about roles. If Scrum is referred to as “people-centric,” that might be because of the emphasis the methodology places on the division of labor. In other words, even though flexibility is prioritized, the distinction of who does what is still quite important. Scrum is centered around the Product Owner, Scrum Master, and Development Team.
The Product Owner is tasked with the decision of which features the team builds and in what order those features are created. This role is typically occupied by a single person and creates the initial product backlog working closely with the business and team. The Product Owner also decides when the product is ready to be shipped. Note that since it’s a Scrum project, the Product Owner will likely push for frequent delivery, as iteration is one of Scrum’s core values.
Throughout the production process, the Scrum Master acts as a coach who constantly looks for ways to make it more effective. The Scrum Master is, therefore, a kind of point person between the other team members and an enforcer of Scrum theory and rules. Because of this, they need to understand Scrum processes and be able to use team member resources as needed for sprints. The Scrum Master will also remove roadblocks or help in other ways to get work going when it’s slowed down.
The Development Team works together to create the product. They are the workhorses of the team and are responsible for the in-depth work on each task as defined in the Scrum backlog. The Development Team works on a pre-established set of user stories and tasks, but they also get to decide how to approach that work and are usually involved in estimating how much time each task should take. Development Teams come in many shapes and sizes, but with Scrum, they tend to be on the smaller side. Jeff Bezos suggests, for instance, the “two-pizza” rule—the team should be small enough to share two pizzas.
Scrum Events (aka Scrum Ceremonies)
Scrum consists of five important ceremonies: Sprint, Sprint Planning, Sprint Review, Sprint Retrospective, and the Daily Scrum. The Daily Scrum is a short meeting in which the team connects on the strategy for that day’s work. Typically, the team will review accomplishments or issues from the previous day to decide how to move forward. The Daily Scrum, or “Daily,” is is also often referred to as a Stand-up.
The Sprint is a specific period of time that can be as short as one week or as long as one month. During this period, the Scrum team works on the product or a section of the product by completing tasks or user stories. In order to map out what exactly the team works on, a Sprint Planning meeting is conducted in which the team decides on Sprint deliverables and work needed to meet those goals.
After a Sprint is complete the team will conduct a Sprint Review, during which time the team discusses challenges and the Product Owner offers feedback and suggestions for improvement. Often occurring after a major release or an initial Minimum Viable Product (MVP), a Sprint Retrospective is a more comprehensive review period for analysis of the Scrum process and workflow.
During Sprints, Scrum teams will use three important artifacts. The Product Backlog is a full list of the product requirements decided upon by the client and Product Owner. The integrity of this list is of great value because it is a master set of all the product requirements.
The Product Backlog is then translated into a set of tasks and user stories stored in the Sprint Backlog, or a set of work items that can be executed on by the team. The value of the Sprint Backlog is its consistency with the Product Backlog, but it’s translated for team execution. Finally, the Product Increment describes which of the Product Backlog items were completed during a Sprint. It’s valuable because it functions as a marker for the latest progress.
Other artifacts include the project burndown (a chart showing the current stage of the project against the delivery date), the scrum board (a visual display of all the tasks and user stories sorted by progress), a program board and a release plan.
Final Thoughts on the Scrum Framework
Together, Scrum Roles, Events, and Artifacts all contribute to making Scrum an effective and flexible methodology with values. Contact us today with your idea. We’ll use Scrum to make it a reality.