A company has five products and are using Scrum for product delivery. Which statements
represent the best option for how Product Ownership might be structured?
(choose the best two answers)
BC
Explanation:
The best option for how Product Ownership might be structured in a company with five products is to
have one Product Owner responsible for each product or one Product Owner responsible for all five
products. Both of these options are consistent with the Scrum Guide, which states that the Product
Owner is accountable for maximizing the value of the product resulting from the work of the Scrum
Team
. The Product Owner may delegate work as needed, but they remain accountable for the
value delivered. The Product Owner also provides clarity to the team about the product vision, goal,
and backlog
.
The other options are not advisable for the following reasons:
Assigning as many Product Owners as needed to communicate expectations and requirements to the
Scrum Team is not a good idea, as it would create confusion, inconsistency, and conflict among the
Product Owners and the Scrum Team. The Scrum Guide states that the Product Owner is one person,
not a committee
. Having multiple Product Owners for one product would compromise the
transparency, the alignment, and the decision-making of the Scrum Team.
Having one primary Product Owner and one Product Owner for each product is also not a good idea,
as it would create a hierarchy and a dependency among the Product Owners. The primary Product
Owner would have too much authority and responsibility, while the Product Owners for each product
would have too little. This would undermine the accountability, the collaboration, and the
empowerment of the Product Owners and the Scrum Teams.
Scenario C: Dependencies and Product Backlog items
During Nexus Sprint Planning, representatives from each of the 9-member Scrum Teams
identify many dependencies. This makes it hard for them to choose the work they could pull
into their individual teams for the next Sprint. No matter how they reorganize the Product
Backlog items, they continually find more or new dependencies.
What would you recommend to the two teams that are continually dependent on each other to
help them manage their work?
(choose the best answer)
D
Explanation:
The best way to help the two teams that are continually dependent on each other to manage their
work is to ensure the appropriate representatives from both teams are present during Cross-Team
Refinement. Cross-Team Refinement is an optional event in Nexus that allows the Scrum Teams to
collaborate and coordinate on the Product Backlog items that have dependencies or require
integration
. By having the representatives from both teams present during this event, they can
identify and resolve the dependencies, clarify the requirements, align the expectations, and plan the
work for the next Sprint. This will improve the transparency, the quality, and the value of the
Integrated Increment.
The other options are not advisable for the following reasons:
The Nexus Integration Team should not be responsible for integrating the work of these two Scrum
Teams, as this would create a bottleneck and a hand-off. The Nexus Integration Team is a specialized
Scrum Team that provides services and guidance to the Scrum Teams in the Nexus to ensure that the
Integrated Increment is produced every Sprint
. However, the Nexus Integration Team is not
accountable for the integration of the work of the individual Scrum Teams, as this is the responsibility
of the Scrum Teams themselves
.
Reorganizing these two Scrum Teams so that one is responsible for development and one is
responsible for integration is not a good idea, as this would create a silo and a separation of
concerns. The Scrum Teams in a Nexus should be cross-functional and self-organizing, meaning that
they have all the skills and abilities to deliver a potentially releasable product Increment every Sprint
. Separating the development and the integration tasks would compromise the collaboration, the
feedback, and the agility of the Scrum Teams.
Merging the two Scrum Teams together is not a viable solution, as this would create a large and
unwieldy team. The Scrum Guide states that the optimal size of a Scrum Team is between three and
nine members
. Merging two Scrum Teams together would exceed this limit and create challenges
in communication, coordination, and decision-making. Moreover, merging the two teams would not
necessarily eliminate the dependencies, as they may still exist within the larger team or with other
teams in the Nexus.
Currently, your Scrum Teams are organized to address a single functional (component) area of
the product. What should be considered when deciding to move away from such component
teams toward feature teams?
(choose the best three answers)
ADE
Explanation:
Moving away from component teams toward feature teams is a significant change that should be
considered carefully. Here are some of the factors that should be taken into account:
Feature teams have less communication overhead than component teams, as they are able to
deliver end-to-end customer features without relying on other teams or components
. This
reduces the complexity and the dependencies among the teams, and improves the transparency and
the feedback loop. Feature teams also foster more collaboration and cross-functional learning among
the team members, as they have to work on different aspects of the product
.
When making this change, it helps to have support from the organization, as it may require a shift in
the culture, the structure, and the processes of the company
. The organization should provide the
necessary resources, training, and coaching to the teams to help them adopt the feature team
model. The organization should also align its goals, incentives, and metrics with the feature team
approach, and remove any barriers or impediments that may hinder the teams’ performance
44
.
Productivity may decrease when making this kind of change, as the teams may face some challenges
and difficulties in the transition period
55
. For example, the teams may have to learn new skills,
technologies, or domains that they are not familiar with. The teams may also have to deal with
legacy code, technical debt, or integration issues that may slow down their delivery. The teams may
also experience some resistance or conflict from the existing component teams or stakeholders.
Therefore, the teams should expect some temporary setbacks and losses in productivity, and focus
on continuous improvement and adaptation.
The other options are not correct for the following reasons:
With feature teams, it is not easier to calculate the productivity per team, as productivity is not a
simple or straightforward metric to measure in software development [6]. Productivity depends on
various factors, such as the quality, the value, the complexity, and the customer satisfaction of the
product. Moreover, focusing on the productivity per team may create a competitive or individualistic
mindset among the teams, rather than a collaborative or collective one. The teams should focus on
delivering the best possible product Increment that meets the Product Goal and the Definition of
Done, rather than on maximizing their productivity [7].
You can do Scrum without feature teams, as Scrum does not prescribe any specific team structure or
organization [8]. Scrum only requires that the Scrum Team is cross-functional, self-organizing, and
accountable for delivering a potentially releasable product Increment every Sprint [9]. However,
feature teams are generally more aligned with the Scrum values and principles, as they enable the
teams to deliver customer-centric features faster and more frequently, and to respond to changes
more effectively [10]. Therefore, feature teams are recommended, but not mandatory, for Scrum.
How should multiple Scrum Teams deliver a valuable and useful Increment in a Sprint?
(choose the best answer)
C
Explanation:
The best way for multiple Scrum Teams to deliver a valuable and useful Increment in a Sprint is to
complete work that integrates with all of the other work from other Scrum Teams on the initiative.
This means that the Scrum Teams collaborate and coordinate their work to produce a single
Integrated Increment that meets the Definition of Done and the Product Goal. The Integrated
Increment is the combined work of all the Scrum Teams that is potentially releasable and provides
value to the customers and stakeholders
.
The other options are not correct for the following reasons:
Each Scrum Team delivering done Increments of its own area of responsibility and integrating them
into a whole product during stabilization prior to release is not a good idea, as it violates the Scrum
principles and values. The Scrum Guide states that the Scrum Team delivers a product Increment that
is usable and valuable at the end of every Sprint, not at the end of the release
. Delaying the
integration until the stabilization phase would compromise the transparency, the feedback, and the
adaptability of the Scrum Teams.
Each Scrum Team providing a unique done Increment that includes the team’s added functionality is
not a good idea, as it does not ensure that the product Increment is integrated and consistent across
the initiative. The Scrum Guide states that the product Increment is the sum of all the Product
Backlog items completed during a Sprint and all previous Sprints
. If each Scrum Team provides a
unique Increment, they may not be aligned with the Product Goal and the Definition of Done, and
they may create conflicts or dependencies with other Scrum Teams.
Functionality not integrated with the work of other Scrum Teams being delivered as unintegrated
Increments to demonstrate the value created by the Scrum Teams unable to completely integrate
their Increments is not a good idea, as it does not ensure that the product Increment is done and
valuable. The Scrum Guide states that the product Increment must be usable and meet the Definition
of Done
. If some functionality is not integrated with the work of other Scrum Teams, it may not be
usable or valuable to the customers and stakeholders, and it may introduce technical debt or quality
issues.
True or False: A Nexus Integration Team is accountable for ensuring that a Integrated
Increment is produced at least once a Sprint.
B
Explanation:
A Nexus Integration Team is not accountable for ensuring that an Integrated Increment is produced
at least once a Sprint. The Nexus Integration Team is a specialized Scrum Team that provides services
and guidance to the Scrum Teams in the Nexus to ensure that the Integrated Increment is produced
every Sprint
. However, the Nexus Integration Team is not accountable for the integration of the
work of the individual Scrum Teams, as this is the responsibility of the Scrum Teams themselves
.
The Nexus Integration Team helps the Scrum Teams to coordinate, coach, and supervise the
application of Nexus and the operation of Scrum, but it does not take over their work or
accountability
. Therefore, the statement is false.
What are three benefits of self-managing Scrum Teams?
(choose the best three answers)
BCD
Explanation:
Self-managing Scrum Teams are teams that internally decide who does what, when, and how, rather
than being directed by others outside the team
. Self-managing Scrum Teams have the following
benefits:
Increased self-accountability: Self-managing Scrum Teams are accountable for delivering a
potentially releasable product Increment every Sprint that meets the Definition of Done and the
Product Goal
. They are also accountable for following the Scrum values and principles, and for
inspecting and adapting their work and process
. By being accountable for their own decisions and
actions, self-managing Scrum Teams are more responsible, transparent, and quality-oriented.
Increased creativity: Self-managing Scrum Teams have the autonomy and the empowerment to
choose how best to accomplish their work, rather than being constrained by predefined methods or
instructions
44
. They also have the opportunity to experiment, learn, and innovate, as they are
encouraged to try new ideas and approaches to solve complex problems [5]. By having the freedom
and the support to be creative, self-managing Scrum Teams are more productive, adaptive, and
valuable.
Increased commitment: Self-managing Scrum Teams have the ownership and the involvement in
their work, as they are part of the planning, execution, and review of the product development [6].
They also have the trust and the collaboration among the team members, as they share a common
goal and vision, and respect each other’s skills and abilities [7]. By having the sense of belonging and
the teamwork, self-managing Scrum Teams are more motivated, engaged, and satisfied.
What is the purpose of Nexus Sprint Retrospective?
(choose the best answer)
D
Explanation:
The purpose of Nexus Sprint Retrospective is all of the above, meaning that it aims to:
Plan ways to increase quality and effectiveness across the whole Nexus. The Nexus Sprint
Retrospective is a formal opportunity for a Nexus to inspect and adapt itself and create a plan for
improvements to be enacted during the next Sprint to ensure continuous improvement
.
To inspect how the last Sprint went with regards to individuals, teams, interactions, processes, tools,
and its Definition of Done. The Nexus Sprint Retrospective follows the same format and principles as
the Scrum Team Sprint Retrospective, but at a larger scale. The Nexus inspects the aspects of the
product development that affect the Nexus as a whole, such as the collaboration, the integration, the
dependencies, the quality, and the value
.
To complement the Scrum Teams’ Sprint Retrospectives by using bottom-up intelligence to focus on
issues that affect the Nexus as a whole. The Nexus Sprint Retrospective does not replace the Scrum
Teams’ Sprint Retrospectives, but rather enhances them by using the input and output from the
individual teams to identify and address the shared challenges and opportunities
.
True or False: A Nexus Integration Team is responsible for actually doing the integration work
during the Sprint.
B
Explanation:
A Nexus Integration Team is not responsible for actually doing the integration work during the Sprint.
The Nexus Integration Team is a specialized Scrum Team that provides services and guidance to the
Scrum Teams in the Nexus to ensure that the Integrated Increment is produced every Sprint
.
However, the Nexus Integration Team is not accountable for the integration of the work of the
individual Scrum Teams, as this is the responsibility of the Scrum Teams themselves
. The Nexus
Integration Team helps the Scrum Teams to coordinate, coach, and supervise the application of
Nexus and the operation of Scrum, but it does not take over their work or accountability
.
Therefore, the statement is false.
True or False: Many Scrum Teams working on the same product create coordination
challenges that can be fully addressed by creating a communication plan.
B
Explanation:
Creating a communication plan is not enough to fully address the coordination challenges that arise
when many Scrum Teams work on the same product.
A communication plan is a document that
outlines the objectives, methods, channels, and frequency of communication among the
stakeholders of a project or product 1
.
While a communication plan is useful for ensuring clarity,
transparency, and alignment among the Scrum Teams and other parties involved, it does not address
other aspects of coordination, such as integration, dependency management, alignment of goals and
vision, and cross-team collaboration 2
.
To effectively coordinate multiple Scrum Teams working on the same product, a communication plan
should be complemented by other practices and frameworks, such as:
Nexus: Nexus is a framework for scaling Scrum that consists of three to nine Scrum Teams working
together to deliver an Integrated Increment every Sprint 3
.
Nexus provides roles, events, artifacts,
and rules that help the Scrum Teams coordinate, integrate, and align their work, while maintaining
the Scrum values and principles 4
.
Scrum of Scrums: Scrum of Scrums is a technique for scaling Scrum that involves a regular meeting of
representatives from each Scrum Team to share progress, identify dependencies, resolve issues, and
align on the product vision and goal . Scrum of Scrums helps the Scrum Teams communicate and
collaborate effectively, while minimizing the overhead and complexity of coordination .
Communities of Practice: Communities of Practice are groups of people who share a common
interest, skill, or domain, and who meet regularly to exchange knowledge, ideas, and best practices .
Communities of Practice help the Scrum Teams learn from each other, improve their skills, and foster
a culture of continuous improvement .
True or False: When multiple Scrum Teams are working together on the same product, each
team should maintain a separate Product Backlog.
B
Explanation:
When multiple Scrum Teams are working together on the same product, each team should not
maintain a separate Product Backlog. According to the Scrum Guide, the Product Backlog is the single
source of truth for the product, and it is owned and managed by the Product Owner
. Having
multiple Product Backlogs for the same product would create confusion, inconsistency, and
duplication among the Scrum Teams and the stakeholders. It would also compromise the
transparency, the alignment, and the value of the product development.
Instead of having separate Product Backlogs, the Scrum Teams should work from a common Product
Backlog that reflects the vision, the goal, and the priorities of the product
. The Product Owner
should collaborate and communicate with the Scrum Teams and the stakeholders to ensure that the
Product Backlog is clear, refined, and ordered. The Scrum Teams should coordinate and integrate
their work to deliver a single Integrated Increment that meets the Definition of Done and the
Product Goal every Sprint
.