Scrum changed the word role for accountability. The reasoning was they wanted to make it very clear that scrum roles are not job titles or job description. The word role is not necessarily wrong.
The Scrum Team
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner and the Developers. Within a strong team, there are no sub teams or hierarchies. It’s a cohesive unit of professionals focused on one objective at a time, the Product Goal. We have one team focused on one product.
Its critically important characteristics are:
Cross Functionality
It means that the Scrum Team has all the skills, all the competencies to create a usable increment, every sprint without depending on help outside the team, without depending on other professionals.
Remember the concept incremental development and that the purpose of the sprint is to produce a usable increment or increments. This is how we achieve the Goal.
Multiple Increments may be created within a Sprint. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
To achieve this we need efficiency, we need cross-functional teams.
You can also hear the terms:
Feature Team -> they can create an increment without relying on outside help.
Component Team (bad term) -> they cannot create an increment by themselves, they rely on passing the work to the next team.
Cross-functionality refers to the entire Scrum Team and not to any individual member. We do not expect a developer to be cross-functional.
Self-Management
A self-managing team decides who does what, when and how they are empowered by the organization to manage their work. It has limits. It does not mean that the team can ignore the organization and do whatever they want. We still need to coordinate with other teams inside the organization. We still need to contribute to high level organizational goals. They do not have to report the problem to a manager who is outside the Scrum Team and wait for an answer.
Being self-centered does not mean that the team can decide which Scrum Events to perform or which to skip. We’re not allowed to skip some events and remove accountability. The Scrum Framework is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.
The Scrum Master
The Scrum Master is a leader and a facilitator, which has to be proactive. He’s accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
How he serves the Scrum Team
- Coaching the team members in self-management and cross-functionality
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scru Team’s progress
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox
How he serves the Product Owner
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concide Product Backlog items;
- Helping establish empirical product planning for a complex environment;
- Facilitating stakeholder collaboration as requested or needed;
How he serves the Organization
- Leading, training, and coaching the organization in its Scrum adoption.
- Planning and advising Scrum implementations within the organization.
- Helping employees and stakeholders understand and enact an empirical approach for complex work.
- Removing barriers between stakeholders and Scrum Teams.
The Scrum Master is not a project manager. He doesn’t manage people. He doesn’t have the authority to hire or fire people, or tell the developers what to work on and how to do it.
The Scrum Master is a “manager”. He manages or facilitates the process, not the people. The Scrum Master is the Process Authority. He makes sure that all members, as well as outside the team, understand the Scrum Framework in general and its practices, rules, and values. He is considered a coach of the team. The Scrum Master causes the removal of impediments, such as ineffective communication between Developers and the Product Owner.
The Scrum Master is accountable for the Scrum Team’s effectiveness.
The Product Owner
Scrum Guide Definition
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal.
- Creating and crearly communicating Product Backlog items.
- Ordering Product Backlog items.
- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
Expand on concept
The Product Owner is the value maximizer. They maximize the value that’s being delivered. This value may not only be financial, but also societal (non-profit organization).
Product owners are concerned with economics. When you talk value, they always have the return on investment. For example, to execute a one month sprint, the company or organization expenses. The Product Owner is accountable for effective product management.
The Product Owner is the main person, not the only one, but the main person who communicates with stakeholders. He makes sure key stakeholders participate in the Sprint Review event. This event is designed to collect feedback, but stakeholders can also share valuable, important information.
The Product Owner is one person, not a group of people or a committee. There’s always one product owner per product, even if multiple teams are working on that product. Only the Product Owner has the authority to cancel the Sprint. They must be available to clarify questions the developers may have during the sprint. If the Developers don’t understand an item, they come to the Product Owner.
Changing the scope to add or remove stories, the best way is made collaboratively between the Product Owner and the Developers.
Product Backlog
The Product Owner owns the product backlog, which is one of the scrum artifacts. To maximize the value the product delivers, the Product Owner orders the items in such a way what they believe would bring the most value, to the top of the product backlog. Because the developers select items from the top of the Product Backlog to the Sprint Backlog and then they create usable increments. The only way to deliver value is when we release the increment.
Releases
Scrum does not tell us when to release. The entire team collaboratively decides when to release. Multiple increments may be created within a Sprint or an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Refinement
The Product Owner as well as the Scrum Team does Product Backlog refinement, which is the act of breaking down and further defining for the items into smaller, more precise items. This is not an event. It is an ongoing activity where the team members analyze details such as description, order and size.
Product Goal
The goal is a commitment for the Product Backlog. It’s a long term objective for the whole team. The Product Owner is accountable for the Product Backlog and the Product Goal. It helps the Scrum Team stay focused. It’s not recommended to have multiple product goals at the same time.
Sprint Planning
During this event, the whole Team crafts a goal that guides the developers during the Sprint. The Product Owner is the leader who seeks feedback from key stakeholders because the Sprint Review event is not just a demo of the product.
The Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint backlog.
- Instilling quality by adhering to a Definition of Done.
- Adapting their plan each day toward the Sprint goal.
- Holding each other accountable as professionals.
Expand on concept
A developer is so, without regarding the scope of his work. A developer could be, for example, a marketing professional who writes marketing copies. Developer is anyone who gets value from Scrum. (researchers, analysts, scientists…).
The Developers are the people who create a usable increment. They collaborate with the Product Owner during the Sprint, planning to select items from the Product Backlog to be put in the Sprint Backlog. The Sprint Backlog artifacts contain a commitment, which is the Sprint Goal, which is mandatory. This is what helps Developers stay focused during the Sprint.
The Developers decide how much work to be included in the Sprint Backlog. They make the Sprint forecast because they do the work and know best. The Product Owner helps by explaining and clarifying the Stories. The Developers are responsible for the sizing of the stories. One technique for this is using Story Points, which is a relative unit of measurement.
Before, they set the Definition of Done. Now the whole Scrum Team does it. Having a Definition of Done is mandatory.
If a story is too big and we cannot fit it into one sprint, we have to break it down. We have to refine it. No one else tells the Developers how to turn Product Backlog items into Increments of value.
There’s no longer a size for the Developers. Typically 10 or fewer people. If teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams.