Shared Roles in Scrum Teams: Real-Life Challenges and What Works

In this section, we will look focus on Shared Roles in Scrum Teams: Real-Life Challenges and What Works. We will explore how the value delivery gets impacted when one person takes on more than one Scrum Role within a Scrum Team. This article is part of an ongoing series on real-life scenarios that many Scrum Teams face.

“We are a small team, so one person needs to take up multiple roles. We do not have a budget for a dedicated Scrum Master (or a dedicated Product Owner)”

This is one of the most common statements I hear. Especially when organizations start their Agile journey. On the surface, it does sound practical. Why not optimise for efficiency? Why not reduce overhead? After all, if someone has the bandwidth, why not let them wear multiple hats?

However, in reality, role sharing in Scrum often creates more challenges than it solves. The issue is not a matter of capability—it is a conflict of accountability.

How do the three Roles (or Accountabilities as stated in the Scrum Guide) Interact

The people in the boat in the above diagram represent a Scrum Team. The rowers symbolize the developers. They work in sync to move the product forward through their collective effort.

The Product Owner stands at the back with the rudder, setting direction and ensuring the team is heading toward the right outcomes. His focus is always on the Value

At the front, the drummer, represents the Scrum Master. He is maintaining rhythm and helping the team stay aligned and effective. He is the facilitator who helps the Scrum Team become more effective

Success for the Scrum Team depends on coordination among the three roles. Success comes when direction, facilitation, and execution come together, the team moves faster and with greater purpose.

Below, I have described some common questions around role sharing—and what typically unfolds.

1. Can the Scrum Master and Product Owner Be the Same Person?

In one organization, I worked with a team where the same individual was acting as both Scrum Master and Product Owner. Initially, it seemed efficient—one person managing both delivery and process.

However, during Sprint Planning, this person consistently pushed the team to take on more work. In Retrospectives, when the team raised concerns about overload, the same person facilitated the discussion.

Over time, the team stopped speaking openly.

Snehamayee’s perspective

While the Scrum Guide does not explicitly forbid this, in practice, this combination rarely works well. The accountabilities of a Scrum Master and a Product Owner are fundamentally different. The Scrum Guide says that

• The Product Owner is accountable for maximizing product value
• The Scrum Master is accountable to help the Scrum Team become more effective

When the same person plays both roles, they need to balance conflicting priorities.

Impact:

• Reduced transparency
• Limited psychological safety – Product Owner is the Value Mximizer. In that role the often
• biased decision-making.

What can be done?
Keep these roles separate. Even in smaller setups, this separation creates balance and enables better team dynamics.

2. Can the Scrum Master Also Act as a Developer?

In another team, the Scrum Master was also a senior developer. During the Sprint, he was deeply involved in coding critical features.

When impediments arose, they often remained unresolved for days—not because they were complex, but because the Scrum Master was busy with delivery work.

Daily Scrums became quick updates rather than meaningful conversations.

Snehamayee’s perspective
This setup is more workable than combining Scrum Master and Product Owner roles, but it still creates tension.

The Scrum Master role requires availability and focus. When combined with development work, facilitation and coaching often take a back seat.

Impact:

• Delayed impediment resolution
• Reduced focus on team improvement
• Scrum events becoming less effective

What we can do?
This model can work temporarily, especially in smaller teams. However, it requires conscious effort to ensure that Scrum responsibilities are not neglected.

3. Can the Product Owner Also Act as a Developer?

I once worked with a technically strong Product Owner who also contributed to development. Initially, this helped speed up delivery.

However, over time, a pattern emerged. Backlog refinement became less structured, stakeholder conversations were delayed, and priorities were not always clear.

The Product Owner was simply too busy writing code to focus on product direction.

Snehamayee’s perspective
While this setup may seem efficient, it often impacts the quality of product ownership.

The Product Owner’s role requires continuous engagement with stakeholders, clarity on priorities, and proactive backlog management.

Impact:

• Backlog items lack clarity
• Stakeholder alignment weakens
• Product decisions get delayed

What can be done?
A Product Owner with technical skills can support the team when needed, but their primary focus should remain on product value and direction.

4. One Person Supporting Multiple Teams as a Scrum Master or a Product owner

In a scaled setup, I worked with a Product Owner who managed the backlog for three teams working on the same product. Initially, there were concerns about bandwidth.

However, over time, this setup created better alignment across teams. Priorities were clearer, and duplication of work reduced.

Similarly, a Scrum Master supporting two teams helped bring consistency in practices and improved cross-team collaboration.

Snehamayee’s perspective
This approach is often more effective than combining roles within a team.

When one Product Owner supports multiple teams, it strengthens product-level thinking. A Scrum Master across teams can identify systemic issues and address them more effectively.

Impact:

• Improved alignment across teams
• Consistent prioritization
• Better coordination

Some Points to keep in mind

• Beware of a too busy Scrum Master (or Product Owner). If we ask one person to be the Scrum Master (or the Product Owner) for too many teams, they become mere coordinators. It limits the value they add and the bandwidth they have for team members.
• Position an Experienced Person with proven credentials, Scrum Master and Product Owner, both are senior leadership roles – People take time to grow in these roles. If we ask someone inexperienced to function as a Scrum Master (Or a Product Owner) of multiple teams, we risk the role getting diluted
• Empower and Cross Train The Developers

Final Thoughts about  Shared Roles Among Strum Teams

Role sharing in Scrum is often driven by practical constraints. While some combinations may work temporarily, others introduce deeper challenges that impact team effectiveness.

From my experience, a few principles stand out:

• Avoid combining Scrum Master and Product Owner roles
• Be cautious when mixing Scrum roles with delivery responsibilities
• Prefer sharing roles across teams rather than combining them within a team

Ultimately, it is not about rigidly following rules, but about ensuring that each accountability is fulfilled effectively.

When roles are clear, teams collaborate better, decisions are more balanced, and delivery becomes more predictable.

The post Shared Roles in Scrum Teams: Real-Life Challenges and What Works appeared first on World Of Agile.

Early Warning Signs That Your Agile Metrics Are Not Set Right!

Setting up the metrics that help the Scrum Team can indeed be a very difficult job and, in this article, I want to write about some smells that you may observe. These smells are an early warning system or indications which tell you that your metric friend work needs some tweaking.

• Metrics That Take Time To Prepare If a Scrum Team needs time to prepare a set of metrics that usually is a Red flag indicating that the metrics are not coming from one place and need some collation effort. Such a collation effort does not add any specific value and should be discouraged. Also there is always and risk of such manually calculated metrics maybe based on somebody’s perception rather than an universally accepted single source of truth. Where possible it is a better idea to automate the Metrics calculation that way the team’s effort is not vested in calculating the metric.

• Teams Seem Hassled About Metrics / Teams cannot explain rationale Metrics are meant to help the Scrum Teams continually improve their performance. This purpose cannot be achieved if the teams are hassled about the additional burden metrics collection and tracking puts on them. If the Scrum Team is unhappy about some Metrics that they have to track or capture, it usually indicates that either the team does not understand why they are being asked to capture certain data or how the data is going to be used. In such a case being transparent with the Scrum Team about the rationale behind asking for this data helps the team to align better with the ask. Where possible enabling automated data capture also reduces the overhead the Scrum Team has to bear and that can further reduce their resistance.

• Metrics That Are Judgy /Random R-Y-G windows Purpose of metrics should be to help the script to continuously improve their performance. Often the Metrics are structured not as a way to improve the performance continually but to create arbitrary service level agreements which are tried to agile contacts. Many times such metrics have been created with artificial designed acceptable tolerance limits or random Red-Amber-Green ranges rather than tolerance limits which Scrum Teams can understand. In such a scenario Scrum Team might focus on representing data in such a way that their own performance falls into the desirable limit. This might defeat the very purpose of metrics which is to find out ways to improve not to judge a Scrum Teams’ performance.

• Metrics that create barriers Purpose of metrics is to enable the Scrum Team to inspect and adapt in such a way to continually improve its performance. This becomes difficult to achieve when there are Metrics which set team members against each other. Most efficient tester/ the developer with zero defects against his or her name/ star of the month may be some examples of such individual metrics. In such cases it is possible that such metrics create a hindrance for the Scrum Team to work as a single unit and encourage the team members to work as independent players since they want to protect their own metric level. We have to take similar care while we try to pitch 1 Scrum Team against another especially when these teams are working on the same product goal and the product backlog. Such Metrics that compare one team against the another may discourage collaboration among the teams which in the end might hamper the value delivered to the customer

The post Early Warning Signs That Your Agile Metrics Are Not Set Right! appeared first on World Of Agile.

 Figure 1 – Defining Your Metrics Framework

Setting up the metrics that helps Scrum Team can indeed be a very difficult job and, in this article, I will explore some things to keep in mind while you are setting up your Metrics

• Metrics Are Not About Keeping Things Green – In my experience I have seen quite a lot of Scrum Teams where the focus of metrics reporting is to show how what we are doing is working or in other words we are all green- this usually stems from metrics that are defined in agile contracts and are tied with payment for services rendered. This makes the Scrum Team focus on ensuring that there always seen green. In such a case the focus cannot be on what we need to do in order to improve. I usually guide the teams not to have these service level agreements in their Agile Contracts – I rather focus on having metrics that are measure the right things like value of work delivered. 

• Focus on End-to-End Metrics – It is usually a better idea to have metrics which measure the value end to end across the value chain rather than measuring value at interim points. To give an example, it is better to have metrics that capture into and time required for a feature rather than tracking time for a specific task like coding or testing. Another example can be, number of zero defects features delivered is a better Metrics than number of defects identified during testing phase. When defined in this manners Metrics encourage Scrum Team to work as a unit. It becomes a challenge to define such metrics in a multi-vendor scenario. 

• Measure Only What You Want to Improve – Metrics Should NOT be cast in stone – Often, I see very complicated and detailed metric structures that texts up a lot of time and energy for the Scrum Team to create and maintain the data. These metrics frameworks often are collecting data for it sake without a concrete plan of how the data will be utilised in order to help the Scrum Team to be more effective and efficient. Such metric frameworks make it difficult for the Scrum Teams to derive meaningful in inferences out of huge amount of data being collected. I have seen that it instead works better to have a smaller number of metrics that the Scrum Team has to track. This way the team can actually use the data being captured. Some of the most effective organisation and Scrum Teams are known to choose their focus for the upcoming period of 6 months to an year and then decide the metrics that will help them achieve their goals for the said period. This also aligns with the Scrum Value of Focus

• Avoid metrics that Compare one team or one person against another – Agile believes into collaboration. For a Scrum Team working collaboratively is the best way to ensure frequent delivery of valuable software. If the metrics are structured to measure an individual performance or productivity it may sometimes lead to people working against each other to protect their own Metrics level. It is a better idea to measure value delivered as the whole team. The same principal can be applied to creating a competition between the teams- for large products requiring many teams it can hamper the collaboration amongst Scrum Teams. It works better if the teams are measured against their own last performance and encourage to have a continuous improvement in their way of working rather than comparing against other teams.

• Trends Need To Be Monitored – NOT individual numbers – Sometimes a particular metric may show a bad value. This can happen because of multiple transient reasons and it may not be worth it to really worry about an isolated value or reading in a metric. It is much more useful to monitor the trends and analyze if the Scrum Team is going in the right direction.

The post Defining Your Metrics Framework appeared first on World Of Agile.

In the article before, we have discussed many metrics that can be used by the Product Owners or the Developers in order to help them generate value at a regular frequency and in a efficient as well as effective manner. However, one accountability that we have not yet discussed is the master of the scrum, our Scrum Master. Does this mean that Scrum Master does not have any metrics ? Or that the Scrum Masters performance can not be quanitified at all?

If that has to be true, then how will the Scrum Masters improve their own way of working and ensure more effective as well as efficient outcomes for the whole Scrum Team? 

In order to decide what metrics, the Scrum Master can track and use we need to consider the key accountabilities of Scrum Master as explained in the Scrum Guide. The Scrum Guide says, master is accountable to ensure that 

• The team continuously improves its effectiveness
• Developers are able to create high value increment that meet definition of done
• And the Scrum Team implements scrum the way it is defined.

Considering the about 3 asks from the Scrum Master, Scrum Master needs to track the trends in other metrics so that the Scrum Master can help Developers or the Product Owners to help improve their own ways of working.

Also, the Scrum Master is a coach for the Scrum Team and at such needs to ensure that the team is self-managed where the team is empowered, enabled and capable of taking decisions independently without excessive support from the Scrum Master. Scrum Master also ensures that the Scrum Team is implementing scrum the way defined in the guide and to do that scram master may track how the various Scrum Events and are the rules stated in the guide are being followed by the team not only in the words but also in the spirit that they are meant.

When considered in this perspective, it is the Scrum Master who is helping the Scrum Team and the rest of the organisation to create a metric framework that can act as a backbone which supports the Scrum Team to continually improve its way of working leading to better value delivered more frequently.

Below I have given some sample Metrics that can help the Scrum Master.

1. Number of times Scrum Master has to be the interface for the developers – with PO /With Organization
2. Team Independence
3. Over All team effectiveness – trends in other metrics
4. Metrics which are found useful by Scrum Team / Metrics which are found cumbersome

The post Agile Metrics and The Scrum Master appeared first on World Of Agile.

Within the Scrum Team the Product Owner and the Developers often have different focus and different perceptions on what do they mean by value or how to improve the effectiveness of their own work and that of the entire Scrum Team.

This means Developers and product on us need different set of metrics in order to be really effective and efficient.  A common anti pattern often seen in Scrum is to have a metrics framework that is generic and not tailored for the individual accountabilities. In my experience it is worthwhile to spend time and energy into deciding specific metrics for both these accountabilities.

Each team needs to define Metrics that help them inspect and adapt. Below I have given some metrics Product Owner as well as Developers can use

Measuring Value –

A Product Owner is tasked with maximizing value of the product and the most important metric from a Product Owners’ perspective will be those which has centred around the net value or the end value delivered to the final customer. Developers. on the other hand will see value of their work reflected into the quality of outcomes that they have achieved.

The table below shows some sample Metrics that can help the Product Owner and Developers measure “value”

Table 1 Scrum Metrics Around Value

Measuring Frequency –

Agile manifesto states the importance of delivering value early and in a continuous or frequent manner. 

To measure the frequency, a Product Owner will like to measure the frequency at which the Scrum Team is able to put the features or the work into hands of end user. However, Developers will want to measure the frequency at which they are able to turn out usable and useful increments. 

The table below shows some sample Metrics that can help the Product Owner and Developers measure “Frequency”

Table 2 Scrum Metrics Around Frequency

Measuring Day to Day Work

The Product Owner plays a critical role in order for the Scrum Team to be efficient and effective. Product Owner has to support the Developers and work as an integral part of the Scrum Team so that the increment created is of best possible value. Developers will want to ensure how they work together collaboratively and support each other while creating the increment. 

The table below shows some sample Metrics that can help the Product Owner and Developers measure “Day to Day effectiveness”

Table 3 Scrum Metrics Around Working Effeicently

Following are some of the articles on Agile Metrics

• Agile Metrics – Friend or foe
• What metrics should we focus on in Agile projects?
• Some sample Agile metrics
• Agile Metrics and Scrum Master
• Defining your own agile metrics framework
• Early warning signals of incorrect choice of metrics for your agile projects
• Velocity

The post Some Sample Agile Metrics appeared first on World Of Agile.

Can we use Traditional metrics as-is in Agile?

Figure 2 Traditional Metrics do not fit in Scrum

Traditional Metrics usually focus on measuring various aspects of planned versus actual. The idea is to track any variances against the detailed plan. They also measure quantum or size  of scope delivery. 

Intention of these metrics is to measure and showcase the efficiency of the delivery be it the schedule or cost adherence, Scope delivered or quality of the delivery.

Some of the usual metrics companies track are

1. Schedule Variance or Cost Variance
2. Size of work packets (KLOC / No of use cases / No of test cases etc)
3. Scope adherence – how we track Scope variance or rework and how we reduce the rework
4. Productivity  

The above metrics are set to track if we are delivering as per agreed plan. – But in Scrum and Agile the plans are changing often as we believe that while planning is indeed valuable – plans need to be updated often. Then these metrics to track against a plan do not seem relevant when plans are being updated very often.

Another key point missing in the above metrics is the focus on value – Agile Manifesto says that as agilists our highest priority is to deliver Valuable Software. The metrics listed above measure only “what work the team did” they do not measure “what Value was generated” – For a Scrum Team to ensure their effectiveness and efficiency we need metrics that can quantify the Value.

Do we need Metrics in Agile Projects?

We saw in earlier section that traditional metrics do not help when working in an Agile manner. The question then comes to mind is, do you really need metrics while working in Agile?

The answer is a definite yes – When done well, Metrics provide us with transparency by giving quantified information that does not depend upon individual perception. This quantified information helps us to inspect the work we are doing and the value we are delivering. The inspection then allows us to adapt our way of working to improve the value we deliver.

In other words, metrics help us to work in an empirical manner.

Figure 3 Why do we need Metrics in Agile?

What should we measure while working in Scrum?

In my experience there are 3 major dimensions where metrics provide us basis or the transparency to inspect and adapt

1. Value – Are we delivering Value? Scrum focuses on Value and our Product Owner is tasked in maximizing value of product. We need to have metrics that quantify and capture the value we have created. 
2. Frequency – Are we delivering value frequently enough so that we help our customers have competitive advantage? – Agile Manifesto tells us that we believe in continuous delivery of valuable products. 
3. Day to Day Metrics – These are the metrics which helps the Scrum Team to inspect and then adapt their way of working so that they become more effective and efficient.

The post Metrics in Agile Projects – What Should We Focus On? appeared first on World Of Agile.

How to create a Metric framework for your Program – How to choose Agile metrics, How to derive value from your Agile metrics?

 

Metrics are hot topic of discussion with Agile Enthusiasts. Both sides are equally passionate in their belief. Some people Believe that everything that can be measured should be measured. These people believe in the adage, “only what gets measured, gets improved”.  They insist that measuring the work progress, helps people to keep on track, to ensure that we are working up to our potential. They also argue that Metrics help baseline and these baseline data helps stake holders know what to expect

Other side of the coin are those people who object to this very “base lining” as they believe the comparison leads to people focusing on Metrics rather than value …They argue that metrics add overheads and often can be manipulated to paint whatever picture you want to depict. Often metric frameworks become bloated and defy the principle of simplicity. These are the people who believe that traditional metrics have no place in scrum way of working

The debt will go on. However, we all know that Metrics will always be part of work management for us. We need to find out ways to set up metrics which are not very cumbersome but still help us to take decisions based on quantified data. In this section I am planning to discuss all about Agile Metrics – Some topics I have in mind are

1. Do Agile Projects really Need Metrics? If yes, why we can’t use the same old metrics that we have been using for ages?
2. Some metrics that are useful in Agile or Scrum way of working
3. Metrics and the Scrum Master
4. How to set up a lean but efficient Metrics Framework
5.  What are some potential pitfalls you are likely to encounter?

Of Course, Metrics can never be defined in isolation – they need to be thought in context with your Agile contracts as well as your own scrum implementation. I hope this section helps you set up metrics that are useful for your own projects and products

The post Agile Metrics – Friend or Foe? appeared first on World Of Agile.

Product Owner is the accountability in Scrum which Maximizes the value to the stakeholders using the bandwidth available to him/her via the Developers.
While the requirements can never be finalized in empirical work, one of the fundamental aspects of reducing wastage in Agile is to get the requirements ready for the developers “just in time” – not to early and not too late.
Product Owner’s role is to engage with the stakeholders and understand their needs and expectations. This involves

• Requirement elicitation techniques
• Need Analysis techniques
• Requirements classification techniques
• Collaborative Gaming techniques
• Requirements classification techniques
• Requirement Documentation techniques

Who does requirement elicitation in Scrum?

While the Product Owner remains accountable for requirements elicitation, rarely would a Product Owner have enough time to elicit it by himself/herself. Generally, Business Analyst does this (Business Analyst is called as Developer in Scrum) for the Product Owner. Elicitation techniques help people to understand the thoughts and feelings of participants, and to probe for more information.

Why is requirements elicitation different in Scrum?

In Scrum, requirement elicitation is an ongoing job. The Product Backlog emerges throughout the project. Therefore, doing too much of upfront elicitation is a lot of wastage. However, doing the requirements elicitation should ensure that the process is quick, and bureaucracy involved with signoffs and baselines should be avoided. At the same time, the process has to be fast. You cannot have huge documentations done in the form of a Functional Specification or Business Requirements Specification.

Requirements Elicitation Techniques

• Brainstorming technique
• Focus Groups
• Interviews
• Prototypes, simulations, demonstrations
• Wireframes
• Nominal group techniques
• Voting techniques
• User story splitting

Requirements Classification Techniques

• Idea / Mind mapping
• Affinity Diagrams
• Multi-criteria decision analysis
• Wideband Delphi

Collaborative Gaming Techniques

• Remember the future
• Prune the product tree
• Sailboat technique

User Role Modeling Techniques

• User Proxies
• User Persona
• Extreme Persona

Need Analysis Techniques

• Five Why techniques
• Cause and effect diagram
• Cause and effect matrix
• SWOT analysis
• Value Stream Mapping

Process Flow Techniques

• Process flow diagram
• User Cases
• Spaghetti diagram
• Swimlane flowchart
• SIPOC diagram

Requirements Documentation Techniques

• User Story
• Context Diagram
• Use Case Diagrams

Business Rules Formats

• Business Rules Catalogue
• Decision Trees

Data Formats

• Entity Relationship Diagrams
• Data Flow Diagrams
• Data Dictionary
• State Table and State Diagrams

Interface Formats

• Report Table
• System Interface Table
• User Interface Flow diagram

The post Generally Accepted Product Management Practices appeared first on World Of Agile.

The Situation Context Framework (SCF) is created by Agilist Scott Ambler  and Mark Lines in 2020. This framework defines contextual factors which need to be considered when you are defining a way of working for your team. The SCF is used to provide a base framework that will help you to design a way of working – WoW which will be suitable for the work or project you are undertaking

Key Areas to Consider while creating an Agile Team

When you initiate a team you need to identify key areas that will impact of your WoW, some of the important ones are described below:

Decide Team Composition

When you are trying to design a team composition you have several issues to consider. These issues will help you decide how best to organize your teams

• Will the team be made up of  people who have mostly specialized / individual skills like Business SMEs, Technical architects, UI/UX experts  and so on or will team members be more along the lines of T-skilled generalizing specialists?  DO you really need some niche skills that cannot be easily picked by other team members? Can you start with specialized roles but have internal cross skilling plans?
• What will be the team size? Do you need large teams?
•  Will the team be located in the same place or be in multiple locations – This will also impact your tooling strategy
•  Will they work for a single organization or several?

The choices you make will be driven by the situation that you face.

Decide Team Process Framework

 Similarly, you have several process-related issues to consider.  

• What way of working is most appropriate?  For example, will you take a generic agile approach?  Or a specified framework? A lean approach?  A traditional approach?  A hybrid approach?  
• Will your team be able to follow a light, goal-driven process or a prescriptive one?
•  Will your process be constrained by compliance to frameworks such as CMMI or ISO standards? Do you need to do certain legal compliances and documentation?

What tools are you going to use? 

Usually every modern project will benefit from an underpinning of technology framework to ensure smooth operations. These days there are ample tools in the market that will help you. Some key issues to consider when choosing tools are.  

• Are you open to using open source tools? Will you adopt open source tools, commercial tools, or a combination thereof?  Are there any organizational policies that impact usage of open source tools?
•  Will your tools be integrated or stand alone? 
•  Do you prefer to obtain tools from a single source whenever possible? Tools from a single platform usually will lead to better integration and less effort on customizations. Or will you go with the best suitable tools not worrying about the vendor? 
•  Will you host your own tool environment with your own infrastructure? Or you will go for an end to end dedicated hosting by vendor? Or will it be hosted externally via a SAAS-style approach? 
•  If hosted externally, where will your intellectual property (IP), be hosted? What are the precautions you need to take to protect your IP?

The post Setting Up Agile Teams for your Project/Team appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article with cover the Scaling Conetx and Some Basic Concepts like where scaling fits and how it works.

Let’s first understand what Scaling is?

As a word, Scaling means there are multiple teams working on a Product (Value Stream). 

Scaling Agile refers to the process where the established Agile methods (Scrum/Kanban) are applied to other layers of organization.

Look at the Matrix below to understand the layers of the organization. 

In any Project organization the ratio of Product and Teams is:

• 1 Team working on 1 Product
• 1 Team working on Many Products
• Many Teams working on 1 Product
• Many Teams working on Many Products 

The Matrix above shows the context of Product v/s Teams.

• When we define a Product – here we define an Independent Value Stream which makes sense from a market perspective.
• When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
• Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts. Scaling is out of scope of Scrum.
• “Many Products – Many Team” context is defined by portfolio management, which is out of scope for most of existing scrum frameworks – SAFe is one of the most prevalent scaling framework that helps with
• “One Team – Many Product” quadrant is for Staff Pools who do heterogeneous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

Context of Scaling and De-Scaling

When we think of larger products, we can think about descaling – that is, dividing the larger products first into smaller units of independent value streams (Products).

For the above product, the Scrum Context is that for each product (an independent value stream) there has to be a single product backlog, a single product owner and a single development team. Like the below diagram, each team works as an individual Scrum Team with their own “descaled” Product Backlog. There will have to be some considerations made to co-ordinate among the various dependent product backlogs. The diagram shows how the descaled products work.- Spotify is an example of framework which works on the principle of descaling

Context of Product Backlog and Product Owner

There is always a one to one relationship between a Product and Product Backlog and Product Owner. The context of the product backlog is shown below

The following structure where one is NOT OK. The accountability on the Product will go down if the following is implemented. It is better to descale the product instead of having a structure as shown below:

Context of a Product Owner and Development Team in Scaling

A Development team will always look up to Only one Product Owner.

A Development Team looking up to multiple PO means, the accountability is not central and conflicting decisions may come to the Development Team.

The post Scaling Context – Some Basics Concepts appeared first on World Of Agile.