Scrum Roles

A Scrum Team consists of three roles:

  • Product Owner: 1 person, Full-time or part-time, Business oriented
  • Scrum Master: 1 person, Full-time or part-time, Scrum coach and facilitator
  • Development Team: 3 to 9 people, Full-time (recommended), Specialist

NOTE: It is possible for a single person to be assigned to more than one roles, but it is not recommended.

Scrum Team

About the Scrum Team:

  • There are only three roles in a Scrum and it is not allowed to define any other roles as it might harm the unity of the team.
  • The Scrum Team is a part of the performing organization,  the company which executes the project either for itself or as a contractor for an external customer.

The Scrum Team has two essential characteristics:

  • Self-organized: the Scrum Team manages its own efforts rather than being managed or directed by others, as opposed to the other traditional methods where management efforts and specialist efforts are separated and centralized.
  • Cross-functional: the Scrum Team has all the expertise and competencies needed to get the job done without any help from outside the team.

These two characteristics are designed to optimize flexibility, creativity and productivity, needed for the Agile environment of Scrum.

Product Owner

Product Owner descriptions:

  • The Product Owner is a business oriented person, whose aim is to maximize the product value and the work of the Development Team.
  • The Product Owners role belongs to one person from the performing organization rather than from the client.  
  • If there is a committee to handle the responsibilities of this role, there should still be only one person, the Product Owner, representing the committee.
  • They do not need to have application area knowledge of the project but focused on the business aspect and understand how the business operates.
  • The entire organization must respect the Product Owner decisions for the project to be successful and not even the CEO, should allow themselves to try to override those decisions.
  •  No one should tell the Development Team what item to deliver, except for the Product Owner who sets and orders the items.
  • A Product Owner’s decisions might be influenced by others, but he/she must have the final say.

Product Owner responsibilities:

  • The Product Owner is responsible for the Product Backlog. The Product Backlog is a prioritized list of items (aka stories or user stories) that the client expects from the project; this is the main planning tool in Scrum.
  • It is also the responsibility of the Product Owner to make sure that each item (user story) is easy to understand for the Scrum Team, and other stakeholders.
  • Product Owners understand the business, so they can rank each Product Backlog item based on its return on investment as well as any other factor they find suitable for the business point of view of the project. The items will be sorted based on their value, so the higher they are on the list, the sooner they will be developed by the Development Team.
  • Product Owners should communicate effectively with the customer (the inevitable success factor in every project management method), and use the information to keep the Product Backlog updated with all the changes.
  • They also measure the performance of the project, forecast the completion date, and make this information transparent to all stakeholders.
  • A Product Owner might delegate some of his/her responsibilities (such as preparing the list of items for the Product Backlog) to the Development Team, but stays accountable for them.

Scrum Master

Scrum Master description:

  • The Scrum Masters is a servant-leader for the Scrum Team, which manages the Scrum process rather than the Scrum Team.
  • It is possible for a single person to be both Scrum Master, and a member of the Development Team, although this is not recommended.
  • Being a Scrum Master of a project might not occupy 100% of the time of a person; in this case, the best solution is to assign that same person as the Scrum Master in more than one project, rather than making them a member of the Development Team.

Scrum Master responsibilities:

  • The Scrum Master helps coaching the Scrum Team and ensures that all Scrum processes are implemented correctly.
  • The Scrum Master is responsible for removing impediments to the Development Team, facilitating their events.
  • The Scrum Master helps the Product Owners too, by helping or consulting them on finding techniques, communicating information and facilitating related events.
  • The Scrum Master leads the organization in its effort to adopt Scrum helping those outside the Scrum Team understand the appropriate interactions with the Scrum Team to maximize the value created by the Scrum Team.

Development Team

Development Team description:

  • Members of the Development Team are application area experts.
  • They should be cross-functional, being able to implement all tasks for each Product Backlog item.
  • They are self-organized, finding their own way instead of receiving orders.
  • They are aligned with the goal of the project and should always work in a product-based way
  • It is highly recommended for members of the Development Team to work full-time on a single project, to stay focused and agile. The composition of the Development Team should not change so often. If there is a need to change team members, then this change should not happen during a Sprint and there will be a short-term decrease in productivity when the composition of the team changes.
  • Scrum is mostly effective when there are 3 to 9 Development Team members but for large projects, we can use a scaled model with multiple Scrum Teams. 3.5. Other Roles
  • All members should have the same role, and the same title: Development Team member.
  • Scrum is completely depended on collaboration and Product Owner. Development Team members should be united and completely aligned with the goal of the project.

Development Team responsibilities:

  • Members of the Development Team are responsible for delivering backlog items and managing their own efforts.
  • A task might be assigned to a single member throughout the Sprint, but the whole Development Team will be responsible and accountable for that task; no individual owns any task.
  • The Development Team delivers the final product of the project in step by step Increments, as defined in the Product Backlog.
  • Each Development Team member is responsible for all the outputs created in the Development Team, even though each of them might be focused on a specific set of tasks.

Other Roles

  • Other persons can also be involved but they are not considered internal to the project and should behave in certain way (e.g. respect how a Scrum project works)
  • When the project is not internal, the customer should be considered as another stakeholder and should understand/adopt the Scrum framework.
  • You may or may not have a separate customer, but you always have some external stakeholders (management, users, analytics…) and should consider them in your development style.

Scrum Events

There are just five events in a Scrum Project:

  • Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events, development effort, and the maintenance of the Product Backlog.
  • Sprint Planning: first event inside a Sprint where the Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them.
  • Daily Scrum: During the Sprint, the Development Team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum.
  • Sprint Review: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called Sprint Review (also known as Sprint Demo).
  • Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective.

Events description

  • The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed.
  • The events are designed to enable critical transparency, inspection, regularity and adaptation. We prefer to use these predefined meetings with fixed objectives and maximum durations instead of ad-hoc meetings, which most likely waste our time.
  • There is an essential concept in Agile methods, called time-box: a predefined fixed maximum duration of time. In order to maximize productivity, all of the Scrum events must be time-boxed.

Time-Box Concept

Time-Box description:

  • Time-box is an essential concept in Scrum.
  • A time-box is a fixed period of time in which we freeze the target and work with full focus on certain tasks or objectives.
  • Time-boxed events repeat many times, until the final goal of the project is achieved.
  • All the changes are applied only when one time-box is finished and we are ready to start the next one.
  • The duration of a time-box should be agreed upon and fixed.

NOTE: We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions. For example, we are not allowed to say that we have a lot to do this time, so let’s increase the duration for this particular case. What we are allowed to say is based on the previous ten time-boxes, we realized that the duration of our time-boxes is not suitable, and a 30% increase in duration might better fit our needs. So, let’s increase them from now.
Time-Box benefits:

  • Time-Box is our way of staying focused and getting things done in an ever-changing environment.

Sprint

Sprint description:

  • Each Scrum project delivers the final product after a number of cycles, which are called Sprints.
  • An Increment is the sum of all Product Backlog items completed so far in a project and this Increment keeps getting bigger after each Sprint.
  • An Increment is developed in each Sprint, which is a potentially releasable part of the final product.
  • An Increment is the updated version of the previous Increment with new features and functionalities, which may or may not be actually released (put into use), but should always be potentially releasable.
  • Customers usually request changes when they see the Increment (during the Sprint Review), and we note these new requests in the Product Backlog.
  • Sprint is a time-boxed event, with a fix duration (set at the beginning of the project and do not change it frequently or occasionally). Sprints are usually fixed for one month or less (usually 2 to 4 weeks) as any longer would increase risk and complexity,
  • The sprint goal is to deliver the final product item by item, inside the Sprints; we do not want to split a single Product Backlog item among several Sprints.
  • The Product Owner has the authority to cancel a Sprint, usually when the Sprit Goal becomes obsolete, due to changes in the Product Backlog, strategies or approaches. When a Sprint is cancelled, the items that are Done will be reviewed and accepted, and the rest of the items (not started or partly complete) will be put back into the Product Backlog to be done in the future.

Sprint rules:
Scrum have a set of constraints designed to make it possible to focus and get things done including:

  • The Sprint Backlog items should not be changed once the Sprint is started
  • The Sprint Goal should not be changed.
  • The composition of the Development Team should not change during a Sprint.
  • The Product Owner and the Development Team might try to clarify and re-negotiate the scope as more is learned about the items to be delivered, but will not change the Sprint Backlog.
  • Each item (story) in the Product Backlog should normally be completed in a single Sprint as this is much easier to manage.
  • The Product Owner and the Development Team select a number of items from the top of the Product Backlog, that have already been prioritized by the Product Owner, and aim to get them Done (100% complete).
  • The Sprint Backlog items should be completed matching the definition of Done when the Sprint is over, and create an Increment.
  • A definition of Done should be agreed at the beginning of the project, and no item should be identified as Done, unless it fits the definition (even if 99.999% completed) as it would not be part of the Increment and it would not be demonstrated to the customer at the Sprint Review.