Scrum Roles Tutorial

3.1 Scrum Roles

Welcome to lesson 3 of Simplilearn’s Agile-Scrum training program. In this lesson, we shall introduce talk about the various roles that are required for Scrum. We shall understand what each role requires and what they contribute to the methodology.
Let us starts off by the agenda, in the next slide.

3.2 Agenda

Let us now look at the detailed agenda for this lesson. We start off by looking at the different stakeholders in a typical Scrum project. Then we understand the Product Owner role in detail. In the context of the Product Owner role, we shall learn how the Product owner prioritizes the requirements for a Scrum project.
We then look at the Scrum Master role and understand what a Scrum Master is supposed to do and also what he is NOT supposed to do. We look at the characteristics of a Scrum team and understand what makes the “self-managing”. The Scrum methodology has no explicit reference to the role of a “manager”. Let us spend some time talking about the manager role and what a manager should do to re-invent the role (manager 2.0).
Lastly, we talk about some other specialist roles that may be valuable in practice.
Now, we will get introduce with the Stakeholders first.

3.3 Stakeholders

Let us first elaborate on the term “stakeholder”. A stakeholder is anybody whose interest is (positively or negatively) impacted by the project or anybody who can influence the project (positively or negatively).
Obviously a lot of people would be stakeholders on a project. The team itself would be stakeholders. The team comprises of the developers, the scrum master and product owner. The management in the performing organization and the end user or customer organization is an important stakeholder.
The customers (people who pay for the system) are obviously very important stakeholders, as are the “end users” – the people who would end up using the system. If the project is being supported by external vendors or contractors, they become stakeholders too.
Another interesting set of stakeholders are people whose interests are displaced or affected by the project. These could be people whose jobs might be altered or impacted by the project, people who are transitioning out of a project.
Next we get to understand the Chicken and pig roles.

3.4 Chicken and Pig roles

The Scrum guide initially had a classification of stakeholders as “Pigs” or “Chickens”. Though this categorization has since been removed from the guide, it may be instructive to understand the intent behind it.
The story goes that a chicken and a pig were walking down a road when they saw a restaurant. The chicken asked the pig if they should open a restaurant. The pig asked “what would we serve”? The chicken replied “ham and eggs”. At this point, the pig thought about and said “I don’t think this is a good idea. In this venture, you would just be ‘involved’ (in providing the egg), whereas I would be ‘committed’ (become the meal itself).
This story illustrates the point that for every activity, there are people who are merely “involved” and people who are “committed”. In project management parlance, this is called the RACI. RACI expands into Responsible, Accountable, Concerned/Consulted and Informed. It is important to understand who wears which hat in the context of any activity.
For example, the Product Owner is “accountable” for the product backlog. Others like the team members may be responsible, concerned or informed, but ultimately it is the product owner who needs to make sure there is a well prioritized and clear backlog for the team to work on.
In the next slide, we will focus on the Management of stakeholders.

3.5 Management of stakeholders

As opposed to conventional projects, where stakeholder management would end up becoming a “manager” responsibility - Scrum teams are “self-managing”, which makes it incumbent upon every team member to have some insight into stakeholder management.
Stakeholder management means doing the following.
-Identifying the stakeholders, understanding what their stake is, what kind of stakeholders they are, etc.
-Assessing their knowledge and skills, which governs what they may be able to contribute to the project
-Analyze the project to make sure their needs and concerns are being addressed
-Get them “involved”. This is very important because once they are involved, their reservations if any will start to vanish.
-Getting their approval, sign-off as required and making sure they formally accept the project’s deliverables
-Establishing a rapport with them. Irrespective of whether you are dealing with a positive or negative stakeholder, there is no alternative to establishing a good relationship with the stakeholders. This is critical for smooth progress on the project.
-
-We will learn about the Scrum life-cycle in the next slide.

3.6 Scrum life cycle

Let us now look at the Scrum life-cycle view we saw earlier, to identify one of the most important roles there is in Scrum. This is the role of the Product owner, which is circled in the diagram shown.
As you can see in the picture, Product Owner drives the requirements for a team and is pretty much the “front-end” of the team for the external world. It is a very important role that has an external facing role as well as internal facing role.
Now, we will understand about the Product Owner.

3.7 Product Owner

Let us look at the Product Owner role in a little more detail. This is one of the most critical roles in Scrum. The Scrum Team comprises of the Product Owner, the Scrum Master and the developers. The job of the Product owner is to provide “direction” to the team.
The Product owner needs to tell the team what to do and what is the preferred order of priority in which it needs to be done. In short, for the team, the Product Owner is the proxy or representative of the customer, who is also authorized to take decisions on behalf of the customer.
In the next slide, we get to learn about the Product Owner’s role.

3.8 Product Owners role

Here are some of the ways in which the Product owner executes their role of providing direction to the team.
-The Product owner manages the projects RoI and risk. By managing the RoI, they make sure that the team’s effort is invested in the right features in the product which provide the maximum proportionate return. The Product owner also tries to balance the RoI with the risk of putting features into a product. The team gives the product owner information about the cost of features and the riskiness of the features.
-The Product owner is responsible to take inputs from everybody who has a say in determining the product’s direction – or in other words, anybody who can provide requirements to the team. The inputs could come from (among others): the team, customers, end users, subject matter experts, customer support teams, etc. These inputs then get translated into a list of “backlog” items for the team. The backlog is nothing but a collection of things that the team could do for the product, which could be of value to the stakeholders.
-The Product owner has to also assign a priority order to the items in the backlog.
-The Product owner determines the overall release plan with the help of the team. The plan needs to take into consideration the business case, technical and logical dependencies, and other factors.

3.9 roduct Owners role

Let us continue to explore the tasks that a product owner performs.
-The Product owner manages all communication with the external stakeholders about the roadmap and release plans. This does NOT mean nobody else in the team can talk to stakeholders – it only means only the Product owner is authorized to provide any kind of commitment to the external world about what the team is likely to do in the coming weeks and months.
-The Product owner is an important participant in many of the Scrum meetings and rituals. For example, in the release and Sprint planning, they provide the requirements, priorities and answer questions about the requirements. During the Sprint review, they validate that the team has build the product correctly based on the requirements given. They also collect all the feedback received from other stakeholders and determine if the feedback can be considered as future enhancements.
-In general, the Product owner needs to be “available” to the team for clarifying requirements, answering questions, and providing feedback on whatever is being built or thought about.
We will look at Prioritizing in the next slide.

3.10 Prioritization

Prioritizing the backlog of requirements is a key function of the product owner. Prioritization is needed because it is important to keep the team focused on the most important things. For any project, the time and money (budget) available to the team is limited. By getting their attention focused on the most important things, the Product owner helps aligns the team’s work with the priorities of the business.
Further, focus results in higher productivity and better quality because the team is not confused and not working on too many things at a time. Prioritization has to be based on customer value, i.e. at any point in time, try and do what will result in most value to the customer.
Customer value can manifest itself in any of the following ways.
-New revenue: If a new product or revenue results in creating a new customer base that brings in a new revenue stream. For example if a billing software being used for a telecom company may (with few modification) be also used for utility companies – resulting in a new revenue stream.
-Incremental revenue: If a new product or feature results in getting additional revenue from existing customers. For example, addition of a module in a banking or ERP application may result in additional users and therefore additional revenue from the existing customers.
-Operational efficiency: Sometimes a product or a feature may not necessarily have revenue implications, but it might result in operational efficiencies and cost savings. For example, software for internal consumption that results in streamlining existing processes might result in cost savings.
-Catch-up: Sometimes a product or feature may be justified simply as a part of “hygiene factor”, i.e. it is expected by the customers (perhaps because a competing product already has it) and therefore it is required to be introduced.
Whenever a product owner requests for a new product or a feature, he has to be clear about what the primary driver is and this often drives the prioritization decisions.
We now cross over to the next slide where we learn about the Cost-benefit analysis.

3.11 Cost Benefit Analysis

The Cost-benefit analysis behind a product or a feature is important to define the potential RoI and the business case.
The steps in building a business case are as follows.
-Determine the time frame for the analysis. For instance, most projects may require an initial investment that repays itself over a period of time. It is important to focus on the forecast time frame when the investments are made and the returns accrue.
-Forecast the investment needed and the recurring (e.g. maintenance) costs
-Forecast the financial benefits that might accrue from the feature
-Then use time value of money techniques to come up with financial measures. Some of the measures that might be useful are as follows.
oPayback period: the amount of time it takes for recovering the money invested
oNet Present Value: The present value of the benefits (value expressed in today’s terms)
oInternal rate of return: The rate of return inherent in the project, i.e. the rate at which the present value of benefits balances out the present value of costs.
Next, we look into Prioritization based on value and risk.

3.12 Prioritization based on Value and Risk

This is a rather simplistic but highly effective method of prioritizing features. Every feature is ranked based on the customer value and the risk involved.
-The features that are high in terms of value delivered and have low risk would be done first.
-The features that are high in terms of value and high in terms of risk would be done next.
-The features which are low value and low risk would be done last.
-The features which are low value and high risk would not be done at all.
Let us now talks about prioritizing requirements: MoSCoW.

3.13 Prioritizing requirements MoSCoW

DSDM uses the MoSCoW framework to express the priority of requirements. A requirement may be expressed as Must (i.e. very high priority – almost non-negotiable), Should (i.e. high priority or highly desirable), Could (i.e. nice to have – good if present, but not mandatory) or Won’t (i.e. not required at this point in time).
At any point in time when you are planning for work being done in a time-box (time-box being either a Sprint or a Release), one needs to ensure that it is a combination of Must, Should and Coulds. The Musts should be given highest priority followed by the Shoulds and if anything needs to be deferred to the next time-box, it better be the Could’s or the Shoulds.
Now, we will look into a figure and discuss on another Prioritizing requirements: Kano model in the next slide.

3.14 Prioritizing requirements Kano Model

Professor Noriaki Kano came up with the Kano model of prioritization. It talks about three levels of requirements, which take the satisfaction of the customer from disappointed to not happy to immediate happiness to “delighted”. So two things impact the satisfaction level here and therefore have a bearing on prioritization decisions.
One is the existence of the features or otherwise. The other is the degree of implementation. If a feature is implemented for the namesake and really not functionally rich at all, the satisfaction level will be low. When it is fully implemented, then it will lead to a higher level of satisfaction. Some features lead to satisfaction up to a basic level, but do not go beyond it. Some features have a linear relationship with the satisfaction level – the more you implement, the higher the satisfaction. Other features have an exponential relationship, i.e. as you go on implementing those features; the satisfaction level climbs up exponentially.
We will continue looking at the Prioritizing requirements: Kano model, in the next slide.

3.15 Prioritizing requirements Kano model

According to the KANO framework that we just saw, the requirements could be classified as follows.
-Thresholds/MUST have’s: These are features required to have even a basic level of satisfaction. Without them, the product cannot be successful.
-Linear features: The more of these features you have, the better it is, as the customer satisfaction is linearly related to how many of these features you have managed to build.
-Exciters or Delighters: These features could be called “differentiators”, because they have the potential to really delight or excite the customer, and the product can become a premium or niche product.
We will now crossover to the next slide where we will understand Prioritizing requirements – relative weighting method.

3.16 Prioritizing requirements Relative weighting method

The relative weighting scheme is a simple model to arrive at the priorities and ranks based upon all the factors that impact priority that we have discussed so far.
Here is how this method works.
-You need to determine the value from the presence of the feature and also the negative impact that might be caused by the absence of the feature.
-It basically relies on expert judgment. It is an exercise that the product owner leads, but it supported by the team.
-Each feature gets a score (typically from 1 to 9) to rank it in terms of the following.
oBenefit from having the feature
oPenalty for not having the feature
oCost of producing the feature
oRisk incurred in producing the feature
-The priority and rank is then determined by dividing the value score (Benefit score + Penalty score) with the (Cost score + Risk score)
-You can optionally assign different weights to each of the scores to assign higher or lower importance to any of the four factors given above.
This results in a numerical value that would be fairly easy to arrive at and would be hopefully devoid of biases and prejudices.
Let us now learn about Scrum life-cycle.

3.17 Scrum life cycle

Let us go back to the Scrum life-cycle to understand now the role of the Scrum Master. The Scrum master is a very important member of a Scrum team and a good scrum master can really make a big contribution to the success of a team.

3.18 Scrum Master

Let us understand the Scrum Master role in detail. Clearly this is a very important role in Scrum.
The Scrum master helps the team achieve its goals by serving the team, protecting the team and helping the team in proper use of the methodology.
Who can be the Scrum Master of the team? If there is a project manager or coordinator in a matrix organization, who is already playing the role of coordinating across functions to get the project on course then such a person can become the scrum master (assuming this person does not have any reporting authority over the team).
It is important to understand that the line manager (one who has reporting authority over the team) should not become the scrum master. The reasons for this should become apparent as we discuss the Scrum master role in more detail.

3.19 What does a Scrum Master Do

Let us now understand what the scrum master is supposed to do. There are three primary functions of a scrum master.
-A Scrum master serves the team: Although the role is christened “Scrum Master”, this person is really the servant of the team. The Scrum master facilitates the interactions of the team by organizing the Scrum rituals and conducting the meetings. The Scrum master helps to remove the obstacles or blocks that the team members bring up during the daily stand-up meeting or any other forum. The scrum master really needs to have a “can do” attitude where they are ready to do whatever it takes to unblock the team and get things moving again.
-A scrum master protects the team. The team needs to be protected from interference or disturbance while they are busy doing the work needed for the project. The team also needs to be protected from conflicts between the stakeholders at various points in time. The scrum master needs to possess good soft skills in order to help the team tide over these.
- A scrum master is the team’s Scrum guru. He helps the team understand the methodology, resolves implementation challenges and coaches the team about the methodology. A scrum master would provide guidance to the team in terms of explaining and sharing best practices, providing templates for commonly used tasks, etc. The scrum master is also the “conscience keeper” of the team in terms of their adherence to Scrum practices. For this, the scrum master may audit the usage of the methodology in the team. The scrum master may also play the role of “stand in” product owner in case the product owner is not available (for instance is on vacation).
In the next topic we will dive deeper into scrum master and try to understand What the Scrum Master should NOT do.

3.20 What the Scrum Master Should NOT do

It is equally important to understand what the scrum master should NOT do.
-A Scrum master should not manage the team. If the scrum master is also the manager, the team would not be as comfortable voicing their concerns or blocking issues. The scrum master must be viewed as a friendly person who is out there to help.
-Scrum master should not direct the team. The team is self-managing and capable of directing its own effort.
-The scrum master does not assign tasks. The tasks are picked by the team members on their own.
-The scrum master does not “drive” the team. The team needs to be self-motivated to do whatever they need to do.
-The scrum master does not make decisions on behalf of the team.
-The scrum master does not over-rule the decisions made by the team.
-The scrum master does not direct product strategy. That is the function of the product owner.
Looking at this list, it is perhaps easier to understand why the team’s manager will not be an effective Scrum master and doing so would go against the spirit of having a self-managed team.

3.21 Scrum life cycle

Let us turn our attention back to the scrum life-cycle to focus for a moment on the Team. The Scrum team comprises of the developers, the scrum master and the product owner. We have already looked at the product owner and scrum master roles.
Now let us understand what the rest of the development team does.

3.22 The team aka Developers

Every member of the team in Scrum is called a “developer” because they ultimately contribute to product development, irrespective of whether they are coding or testing or writing documentation or maintaining databases or source code systems.
The team in Scrum should be small. Ideal team size as mentioned in the scrum guide should be 7 + or – 2. The team should be “cross-functional”, i.e. they must have all the skills necessary to complete the work needed. Also, the Scrum team needs to be self-managing, i.e. they take responsibility for making decisions – making commitments and making efforts to live up to their commitments.
Let us move on to the next slide and know about building a scrum team.

3.23 Building a Scrum team

So how does one go about building a scrum team? It is really no different from any conventional team building theory, with a few minor changes.
-A Scrum team will need to collaborate internally and externally a LOT more than conventional teams. This is driven by the fact that the team is essentially self-managing (there is nobody to TELL them what to do) and the fact that the need to deliver near releasable code every iteration will force them to collaborate a lot more. Therefore, naturally you would look for members who are good at team working and have good communication skills.
-There certainly is room for specialization, but Scrum teams will tend to be a lot more homogenous in their skill set. You will need developers willing to lend a hand to testers and you will need testers who can write code to intelligently execute and automate their tests.
-Last but not the least, you definitely need a highly motivated bunch of people who will make decisions, stand by their decisions and commitments and strive to meet their goals. This essentially means you need to coach the team to stand on their own two feet and then be in a position where you trust them to get the job done. They will definitely promote the right attitude. You also need to allow for the fact that they will not always be successful. So you need to make it “safe” for them to make honest mistakes – so long as they are learning from their mistakes and improving as they go along.
-Next we will discuss on Building empowered teams.

3.24 Building empowered teams

The key concept in self-management is “empowerment”. An empowered team is one that acts on its own AND with enthusiasm.
So empowerment is:
-Taking responsibility and ownership – not throwing the rule book out of the window
-Working towards the goals fairly independently – not necessarily always bypassing people who say NO
-A team that understands the reasons behind decisions, so that they can apply sound judgment in decision making – it is not about focusing only on the FUN parts of the job while ignoring the tough part
-It is about weighing the impact of decisions on stakeholders – not about unilaterally taking decisions and forcing them on others
-It is about making trade-offs while taking decisions – not ignoring the trade-offs and think with blinkered vision.
-
So empowerment does not mean:
•That the team can throw out the rule book and do whatever they please
•Ignore advise and directions and never take no for an answer
•Doing only the “fun parts” of the work and ignore the others
•Being given a carte blanche to make unilateral decisions, especially those that may potentially impact others
-
-In the next slide we take a look at the role of a manager.

3.25 Role of a Manager

If you look back at the Scrum life-cycle, you might notice that there is no explicit task assigned to a manager. The Scrum life-cycle does NOT mention the “manager” at all. Indeed the team in Scrum is supposed to be self-managing and there is the Scrum Master to support them. And then there is the Product owner who is supposed to provide guidance about requirements and prioritization. Indeed there is no role called manager that is mentioned in the guidelines at all. For many managers, this might trigger an identity crisis. What does a line manager do in Scrum – do they have a role at all?
We will now cross over to a new role for the manager.

3.26 Manager 2.0: A new role for a Manager

Quite contrary to the belief that Scrum makes the manager redundant, Scrum is so powerful that it liberates the manager from the rigmarole of day-to-day task management and lets him focus on the more strategic and fun parts of their work. Let us call this the new avatar of managers – Manager 2.0.
Such a manager could:
-Play a more active role in recruiting the right members for their teams
-Be the mentor/coach for their teams
-Try to build the right culture into their teams
-Help their teams understand the big picture – about the business, the strategic vision, etc.
-Focus on developing the right skills within their teams keeping in mind current and future requirements
-Administer a good rewards and recognition program to make sure the team feels motivated to do the right thing
-Use their clout and political connections to protect the team during tough prioritization calls
-Deal with issues that the team cannot resolve on their own and get escalated to the manager
-Keep abreast about the industry, the domain and trends within the business and technology shifts so that you are geared up to the future
-Represent the team at any external forums (such as Quality circles)
Think about it. As a manager, what would give you more satisfaction? Doing some of the things listed above or micro-managing the team and taking credit for their success? If you are able to spend the time you save in day-to-day task management (that you delegate to the teams), you will be able to do better justice to your jobs as manager which will help you in your future career growth.
Let us now discuss on some specialist roles in the next slide.

3.27 Some specialist roles you may want

Scrum refers to each team member as a “developer” and makes no distinctions.
Though, here are some specialists roles that you may want to have on your teams, depending upon what your specific challenges and issues are.
-Architect: A highly skilled techie, who is able to provide guidance about the technical roadmap for a product. An architect can take crucial technical decisions about the architecture, framework, model, schema, etc. and then also help the team achieve a correct implementation based on the overall technical vision. A Scrum architect would be expected to be more “hands-on” and would also get involved in things like code or design reviews, etc.
-
-Automated testers: Test automation is a critical success factor for a Scrum team. Without a solid backbone of automated tests in place, it is hard to get to the goal of near releasable quality at the end of each Sprint. This is where the automation engineer comes in. These people know the tools and frameworks and can quickly get to automate an existing suite of tests or provide a good architecture and approach for achieving a high level of test automation. They Helps in moving towards test-driven-development.
-
-
-Configuration management: A configuration manager, build and release manager etc. – all rolled into one is an excellent asset for a Scrum team. He can maintain the source code repository, automate the processes around code check-in and check-outs, production of builds, integration and automated sanity tests.

3.28 Quiz

Let us quickly test our understanding of this lesson through this quiz.
Who is the PIG stakeholder as far as the production of the product backlog is concerned?
A-Scrum Master
B-Customer
C-Product Owner
D-Architect
Answer is C: The Product owner has the A on the product backlog.
Which of the following is NOT good to include in the role definition of a Scrum master?
A-Ensure that the team delivers as per plan
B-Removing blocking issues for the team
C-Coach the team on scrum practices
D-Organize the Scrum meetings
Answer is A: B, C and D are all good things for the Scrum master to do. A amounts to directing as well as driving – which is not what you want the Scrum Master to do.
The leader of a self-managed team should:
A-Build the right team and trust them to get the job done
B-Listen to the team and always follow the team’s desires
C-Strive for consensus within the teams
D-Closely track what the team is doing
Answer is A: Self-management is all about building the right team and then empowering them to do.
In the middle of iteration, a team member is confused about how to test a particular requirement. Who in the Scrum methodology is responsible for solving the problem?
A-Scrum Master
B-Product Owner
C-Functional manager
D-Customer
Answer is B: The product owner determines what the acceptance criteria should be written.
We thus end this lesson on Scrum Roles. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers lesson four of this course which is about Scrum Ceremonies.
Happy learning!