scrum sps practice test
Scaled Professional Scrum
Question 1
Scenario B: Six Team Nexus with complex dependencies
A six team Nexus is developing a complex product, with different parts of the product that only
certain Scrum Teams can work on. In fact, there are some highly specialized individuals outside
the Nexus that are required for some of the work. In past Sprints the Nexus encountered
challenges dealing with the many dependencies between Scrum Teams.
Which of the following practices could this Nexus try in order to conduct Nexus Sprint Planning
more effectively?
(choose the best two answers)
- A. Ensure all Scrum Teams and outside experts are available during the Nexus Sprint Planning event and have a way of quickly communicating with each other. They should try to be together in the same room or use technology that makes it seem as if they are in the same room.
- B. Plan one Scrum Team's Sprint at a time before moving on to the next team. This way you can account for time zone differences and can communicate dependencies across all teams.
- C. Have the Nexus Integration Team select the work for each of the individual Scrum Teams. This allows the Nexus Integration Team to control the dependencies.
- D. Visualize the known dependencies in the Product Backlog for all to see. As Scrum Teams select work for the Sprint, they can easily check for any dependent work and communicate with other teams.
Answer:
AD
Explanation:
The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum Teams within a
Nexus for a single Sprint 1
. To do this effectively, the Nexus needs to have a clear understanding of
the dependencies between the teams and the work items, and to communicate and collaborate with
each other and any outside experts as needed. Therefore, the best practices for this Nexus are:
A . Ensure all Scrum Teams and outside experts are available during the Nexus Sprint Planning event
and have a way of quickly communicating with each other. They should try to be together in the
same room or use technology that makes it seem as if they are in the same room. This practice
enables the Nexus to have a shared understanding of the Product Backlog, the Product Goal, and the
Nexus Sprint Goal, and to resolve any issues or questions that may arise during the planning.
It also
allows the Nexus to leverage the expertise of the outside specialists who are required for some of
the work 2
.
D . Visualize the known dependencies in the Product Backlog for all to see. As Scrum Teams select
work for the Sprint, they can easily check for any dependent work and communicate with other
teams. This practice helps the Nexus to identify and manage the dependencies between the teams
and the work items, and to optimize the flow of value delivery.
It also supports transparency and
alignment within the Nexus 3
.
The other two practices are not effective for this Nexus because:
B . Plan one Scrum Team’s Sprint at a time before moving on to the next team. This way you can
account for time zone differences and can communicate dependencies across all teams. This practice
is not optimal because it does not allow the Nexus to plan the Sprint as a whole, and to adjust the
work allocation and sequence based on the dependencies and the Nexus Sprint Goal.
It also creates
delays and inefficiencies in the planning process, and reduces the collaboration and feedback
opportunities among the teams 4
.
C . Have the Nexus Integration Team select the work for each of the individual Scrum Teams. This
allows the Nexus Integration Team to control the dependencies. This practice is not consistent with
the Nexus framework, which states that the Nexus Integration Team does not select the work for the
Scrum Teams, but rather facilitates the integration and delivery of the work done by the Scrum
Teams.
It also undermines the self-organization and empowerment of the Scrum Teams, and reduces
their ownership and accountability for the work 1
.
Question 2
Scenario B: Six Team Nexus with complex dependencies
A six team Nexus is developing a complex product, with different parts of the product that only
certain Scrum Teams can work on. In fact, there are some highly specialized individuals outside
the Nexus that are required for some of the work. In past Sprints the Nexus encountered
challenges dealing with the many dependencies between Scrum Teams.
Some individual Scrum Teams in this Nexus have said that they do not see how the work they
are doing is contributing to the product's progress. What is the best remedy for this situation?
(choose the best answer)
- A. During Nexus Sprint Planning, have all the teams plan the Sprint together in one room, so they can see what other teams are working on.
- B. During Nexus Sprint Planning, ensure that all Scrum Teams understand the Nexus Sprint Goal.
- C. Ask the Scrum Master to explain to the teams that the Product Owner can choose which features to work on, as she has the final say.
- D. During Nexus Sprint Planning, ask each Scrum Team to create a Sprint Goal that describes the purpose of the Sprint.
Answer:
B
Explanation:
The best remedy for this situation is to ensure that all Scrum Teams understand the Nexus Sprint
Goal. The Nexus Sprint Goal is a commitment that describes the purpose that will be achieved by the
Nexus during the Sprint. It aligns with the Product Goal and provides coherence and focus for the
work of the Scrum Teams.
By understanding the Nexus Sprint Goal, the Scrum Teams can see how
their work contributes to the product’s progress and value delivery 1234
.
The other answers are not effective for this situation because:
A . During Nexus Sprint Planning, have all the teams plan the Sprint together in one room, so they
can see what other teams are working on. This answer is not sufficient because it does not address
the root cause of the problem, which is the lack of a clear and shared purpose for the Sprint. Having
all the teams plan the Sprint together may help them coordinate their work and identify
dependencies, but it does not necessarily help them understand how their work relates to the
product’s progress and value.
C . Ask the Scrum Master to explain to the teams that the Product Owner can choose which features
to work on, as she has the final say. This answer is not helpful because it does not foster
collaboration and alignment among the Scrum Teams. It also undermines the self-organization and
empowerment of the Scrum Teams, and reduces their ownership and accountability for the work.
The Product Owner is responsible for managing and ordering the Product Backlog, but the Scrum
Teams are responsible for selecting and delivering the work for the Sprint.
D . During Nexus Sprint Planning, ask each Scrum Team to create a Sprint Goal that describes the
purpose of the Sprint. This answer is not optimal because it does not ensure that the Scrum Teams
have a common objective and direction for the Sprint. Each Scrum Team may have a different Sprint
Goal that may or may not align with the Nexus Sprint Goal and the Product Goal. This may lead to
confusion, inconsistency, and sub-optimization of the product delivery.
Question 3
The purpose of the Nexus Sprint Backlog is:
(choose the best two answers)
- A. To make the work of the Nexus Integration Team transparent.
- B. To provide a view of dependent Product Backlog items in a Sprint.
- C. To visualize all Product Backlog items.
- D. To make dependencies transparent to the Scrum Teams.
Answer:
BD
Explanation:
The purpose of the Nexus Sprint Backlog is to provide a view of dependent Product Backlog items in
a Sprint and to make dependencies transparent to the Scrum Teams
. The Nexus Sprint Backlog is a
composite of the Product Backlog items from the Sprint Backlogs of the individual Scrum Teams, and
it is used to highlight dependencies and the flow of work during the Sprint. It is updated throughout
the Sprint as more is learned
21324354
.
The other answers are not correct for the following reasons:
A . To make the work of the Nexus Integration Team transparent. This answer is not accurate because
the Nexus Sprint Backlog does not only show the work of the Nexus Integration Team, but also the
work of all the Scrum Teams in the Nexus. The Nexus Integration Team is responsible for facilitating
the integration and delivery of the work done by the Scrum Teams, but it does not select or assign
the work for them
.
C . To visualize all Product Backlog items. This answer is not true because the Nexus Sprint Backlog
does not contain all the Product Backlog items, but only the ones that the developers in the Nexus
believe are necessary to achieve the Nexus Sprint Goal. The Product Backlog is the single source of
requirements for the product, and it is managed and ordered by the Product Owner
.
Question 4
True or False: All Scrum Team members must attend the Nexus Daily Scrum.
- A. True
- B. False
Answer:
B
Explanation:
The answer is false because not all Scrum Team members are required to attend the Nexus Daily
Scrum.
According to the Online Nexus Guide1
, the Nexus Daily Scrum is an event for appropriate
representatives from individual Scrum Teams to inspect the current state of the Integrated Increment
and to identify integration issues or newly discovered cross-team dependencies. The appropriate
representatives are those who can best collaborate and communicate the progress and impediments
of their Scrum Teams, and who can make and influence decisions regarding the integration and
delivery of the product.
The number and selection of the representatives may vary depending on the
context and needs of the Nexus 234
.
The Nexus Daily Scrum does not replace the Daily Scrum of each
Scrum Team, which is still held by all the Developers of the team to plan their work for the day 5
.
Question 5
Which statements are true regarding using Scrum for large-scale product delivery?
(choose the best two answers)
- A. Splitting a team member's time between multiple Scrum Teams is often less productive than focusing that team member on a single team's Sprint Backlog.
- B. Scrum requires all team members work full time on a single team.
- C. Changes to the core Scrum framework are needed to be successful with Scrum at large-scale.
- D. A well-structured and refined Product Backlog can minimize and often eliminate dependencies between multiple Scrum Teams working together on a product during a Sprint.
Answer:
AD
Explanation:
The true statements regarding using Scrum for large-scale product delivery are:
A . Splitting a team member’s time between multiple Scrum Teams is often less productive than
focusing that team member on a single team’s Sprint Backlog. This statement is true because
splitting a team member’s time between multiple teams can cause context switching,
communication overhead, coordination challenges, and reduced commitment and accountability. It
can also reduce the team’s ability to self-organize and deliver a potentially releasable product
increment at the end of each Sprint. Therefore, it is recommended that team members focus on one
team’s Sprint Backlog and work as a cross-functional and cohesive unit
1122
.
D . A well-structured and refined Product Backlog can minimize and often eliminate dependencies
between multiple Scrum Teams working together on a product during a Sprint. This statement is true
because a well-structured and refined Product Backlog can help the Product Owner and the Scrum
Teams to identify and prioritize the most valuable and feasible work items, and to decompose them
into smaller and independent pieces that can be delivered by one or more teams. This can reduce
the complexity and risk of integration and dependency management, and increase the flow and
quality of value delivery
3344
.
The other statements are false for the following reasons:
B . Scrum requires all team members work full time on a single team. This statement is false because
Scrum does not prescribe how team members allocate their time or effort. Scrum only defines the
roles, events, artifacts, and rules that guide the empirical process of product development. However,
as mentioned above, it is often more productive and effective for team members to focus on one
team’s Sprint Backlog and avoid splitting their time between multiple teams [5].
C . Changes to the core Scrum framework are needed to be successful with Scrum at large-scale. This
statement is false because Scrum is a lightweight and adaptable framework that can be applied to
any complex product development context, regardless of the size or scale. Scrum does not need to
be changed or modified to be successful at large-scale, but rather scaled up or down according to the
needs and goals of the product organization. There are various frameworks and approaches that can
help scale Scrum, such as Nexus, LeSS, SAFe, and Scrum@Scale, but they all adhere to the core
principles and values of Scrum [6] [7].
Question 6
A Nexus Daily Scrum:
(choose the best two answers)
- A. Provides a single meeting where all Scrum Teams can update the Sprint Backlog.
- B. Is the same as a Scrum-of-Scrums.
- C. Provides input into each Scrum Team's individual Daily Scrums to help them better plan their days work.
- D. Is only for the Nexus Integration Team to plan their work for the next 24-hours.
- E. Is an opportunity to make integration issues transparent.
Answer:
CE
Explanation:
The best answers for this question are:
C . Provides input into each Scrum Team’s individual Daily Scrums to help them better plan their days
work. This answer is correct because the Nexus Daily Scrum is an event that helps the Scrum Teams
in a Nexus to coordinate their work and identify any integration issues or dependencies that may
affect their progress toward the Nexus Sprint Goal. The appropriate representatives from each Scrum
Team attend the Nexus Daily Scrum and share relevant information and feedback that can help their
teams plan their work for the next 24 hours
112233
.
E . Is an opportunity to make integration issues transparent. This answer is also correct because the
Nexus Daily Scrum is an event that enables the Scrum Teams in a Nexus to inspect the current state
of the Integrated Increment and to make any integration issues or newly discovered cross-team
dependencies transparent. The Nexus Daily Scrum also provides a forum for the Scrum Teams to
collaborate and resolve any integration challenges or impediments that may arise during the Sprint
112244
.
The other answers are not correct for the following reasons:
A . Provides a single meeting where all Scrum Teams can update the Sprint Backlog. This answer is
not accurate because the Nexus Daily Scrum is not a meeting where all Scrum Teams update the
Sprint Backlog, but rather an event where appropriate representatives from each Scrum Team
inspect the Integrated Increment and identify integration issues or dependencies. The Sprint Backlog
is updated by each Scrum Team during their own Daily Scrum, which is a separate event from the
Nexus Daily Scrum
1155
.
B . Is the same as a Scrum-of-Scrums. This answer is not true because the Nexus Daily Scrum is not
the same as a Scrum-of-Scrums, which is a common practice for coordinating multiple Scrum Teams
that is not part of the Scrum framework. The Nexus Daily Scrum is a specific event defined by the
Nexus framework, which is a minimal extension of Scrum that enables multiple Scrum Teams to work
together on a single product. The Nexus Daily Scrum has a clear purpose, structure, and outcome
that differs from a Scrum-of-Scrums
112233
.
D . Is only for the Nexus Integration Team to plan their work for the next 24-hours. This answer is not
correct because the Nexus Daily Scrum is not only for the Nexus Integration Team, but also for the
appropriate representatives from each Scrum Team in the Nexus. The Nexus Integration Team is a
special Scrum Team that facilitates the integration and delivery of the work done by the other Scrum
Teams, but it does not plan the work for them. The Nexus Daily Scrum is an event that helps all the
Scrum Teams in the Nexus to coordinate their work and identify any integration issues or
dependencies
1155
.
Question 7
Four teams in a Nexus typically integrate their work only once, late in the Sprint. The teams
report that it takes many hours or days to integrate their work, which delays the Sprint's end. To
address this issue, which of the following would help?
(choose the best answer)
- A. Integrating more frequently.
- B. Doing more acceptance testing.
- C. Doing more exploratory testing.
- D. Using Behavior-Driven Development.
- E. Investing in more Requirements Traceability.
- F. All of the above.
Answer:
A
Explanation:
The best answer for this question is A. Integrating more frequently. This answer is correct because
integrating more frequently can help the Scrum Teams in a Nexus to detect and resolve integration
issues or dependencies earlier and faster, and to deliver a potentially releasable product increment
at the end of each Sprint. Integrating more frequently can also reduce the complexity and risk of
integration, and increase the quality and feedback of value delivery
112233
.
The other answers are not correct for the following reasons:
B . Doing more acceptance testing. This answer is not sufficient because doing more acceptance
testing does not address the root cause of the problem, which is the late integration of the work.
Acceptance testing can help to verify the quality and functionality of the product increment, but it
does not ensure that the integration is done early and often. Moreover, doing more acceptance
testing may consume more time and resources, and delay the delivery of the product increment
44
.
C . Doing more exploratory testing. This answer is not helpful because doing more exploratory testing
does not solve the issue of the late integration of the work. Exploratory testing can help to discover
and learn more about the product increment, but it does not guarantee that the integration is done
smoothly and quickly. Furthermore, doing more exploratory testing may introduce more uncertainty
and variability, and hinder the delivery of the product increment
55
.
D . Using Behavior-Driven Development. This answer is not relevant because using Behavior-Driven
Development does not directly affect the integration of the work. Behavior-Driven Development is a
technique that can help to define and communicate the expected behavior and outcomes of the
product increment, but it does not ensure that the integration is done frequently and effectively.
Additionally, using Behavior-Driven Development may require more collaboration and coordination,
and complicate the delivery of the product increment [6].
E . Investing in more Requirements Traceability. This answer is not useful because investing in more
Requirements Traceability does not improve the integration of the work. Requirements Traceability is
a practice that can help to track and document the origin and evolution of the product requirements,
but it does not ensure that the integration is done timely and efficiently. Also, investing in more
Requirements Traceability may increase the overhead and bureaucracy, and slow down the delivery
of the product increment [7].
F . All of the above. This answer is not correct because none of the above answers are effective for
addressing the issue of the late integration of the work. As explained above, each of the above
answers has its own limitations and drawbacks, and does not directly or sufficiently help the Scrum
Teams in a Nexus to integrate their work more frequently and successfully. Therefore, the best
answer is A. Integrating more frequently.
Question 8
During Cross-Team Refinement, the ordered Product Backlog (1 through 9) is mapped out so
the Nexus can visualize dependencies. For example, PBI 5 for Team Orange is dependent on
Team Red completing PBI 1.
All else being equal, which PBI is most concerning?
(choose the best answer)
- A. PBI 2, because it has the most dependencies.
- B. PBI 1, because it is on the top of the Product Backlog.
- C. PBI 1, because it is the first piece of work with a dependency.
- D. PBI 2, because there is a dependency with a different team on work that occurs within the same Sprint.
Answer:
D
Explanation:
PBI 2 is the most concerning because it involves a cross-team dependency within the same Sprint,
which can create challenges and risks for the integration and delivery of the product increment.
According to the Online Nexus Guide1
, dependencies should be minimized or eliminated as much as
possible, and if they exist, they should be made transparent and resolved as early as possible.
Cross-
team dependencies within the same Sprint can cause delays, conflicts, rework, and waste, and
reduce the quality and value of the product increment 234
.
The other answers are not correct for the following reasons:
A . PBI 2, because it has the most dependencies. This answer is not accurate because PBI 2 does not
have the most dependencies, but only one dependency with PBI 1 from Team Red. PBI 3 has the
most dependencies, as it depends on PBI 1, PBI 2, and PBI 4. However, PBI 3 is not as concerning as
PBI 2, because its dependencies are not within the same Sprint, but across different Sprints.
This
means that PBI 3 can be refined and planned in advance, and the teams can coordinate and
communicate their work more effectively 5
.
B . PBI 1, because it is on the top of the Product Backlog. This answer is not relevant because the
position of PBI 1 on the Product Backlog does not indicate its level of concern, but its priority and
value. The Product Backlog is ordered by the Product Owner based on various factors, such as
business value, risk, complexity, and dependencies.
PBI 1 may be on the top of the Product Backlog
because it is the most valuable or urgent item, or because it is a prerequisite for other items, but it is
not necessarily the most concerning item 6
.
C . PBI 1, because it is the first piece of work with a dependency. This answer is not true because PBI
1 is not the first piece of work with a dependency, but the first piece of work that other items depend
on. PBI 1 does not have any dependencies itself, but it creates dependencies for PBI 2, PBI 3, and PBI
5.
Therefore, PBI 1 is not as concerning as PBI 2, because it does not depend on any other item, and it
can be completed independently by Team Red 5
.
Question 9
Scenario A: Nexus Sprint Review with Five Scrum Teams
There are five Scrum Teams working on a product. During the Nexus Sprint Review, the teams
present the results of the Sprint. After introductions, each team takes time to present their work
for inspection by individually showing the new features they have built. They are not using a
shared environment. The stakeholders do not provide much feedback. The event ends and
people filter out of the room.
Since teams are not using a shared environment, what is likely?
(choose the best two answers)
- A. The Sprint is too short.
- B. The Nexus has not yet reached the integration phase.
- C. There is no single Integrated Increment.
- D. The Nexus Integration Team is lacking or nonexistent.
Answer:
CD
Explanation:
According to the Nexus Guide1
, the Nexus Sprint Review is an event where the Nexus presents the
Done Integrated Increment that was built over the Sprint and collects feedback from the
stakeholders. The Integrated Increment is the combined work of all the Scrum Teams in the Nexus
that meets the Definition of Done. The Nexus Guide also states that 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.
In the scenario, the teams are not using a shared environment, which implies that they are not
integrating their work frequently and effectively. This means that there is no single Integrated
Increment that can be inspected and adapted by the stakeholders. This also suggests that the Nexus
Integration Team is lacking or nonexistent, or that it is not fulfilling its role of facilitating integration
and resolving dependencies. Without a Nexus Integration Team and a shared environment, the
Nexus cannot deliver a valuable product Increment that meets the Product Goal.
The Sprint length and the integration phase are not relevant to the scenario. The Sprint length is
determined by the Nexus based on the complexity and uncertainty of the product, and it should be
less than a month. The integration phase is not a separate phase in Nexus, but a continuous activity
that happens throughout the Sprint. Therefore, A and B are not correct answers.
Question 10
The Scrum Teams in a Nexus find they have simply too much work each Sprint to do to deliver
a valuable and useful Increment. What could they try to improve their ability to produce an
Increment for the next Sprint?
(choose the best answer)
- A. Reduce the amount of work that the teams pull into the Sprint.
- B. Ask the Nexus Integration Team to extend the Sprint to allow more time for integration.
- C. Reduce the number of Scrum Teams to reduce complexity.
- D. Add another Scrum Team to the Nexus to increase capacity.
Answer:
A
Explanation:
The best way to improve the ability of the Scrum Teams in a Nexus to produce an Increment for the
next Sprint is to reduce the amount of work that the teams pull into the Sprint. This will allow the
teams to focus on delivering a high-quality and valuable product Increment that meets the Definition
of Done and the Product Goal. Reducing the amount of work also reduces the complexity and
dependencies among the teams, which makes integration easier and faster.
The other options are not advisable for the following reasons:
Asking the Nexus Integration Team to extend the Sprint to allow more time for integration is not
consistent with the Scrum principles and values. The Sprint length should be fixed and consistent
throughout the product development, and it should be less than a month. Extending the Sprint
would compromise the feedback loop, the transparency, and the adaptability of the Nexus
.
Reducing the number of Scrum Teams to reduce complexity is not a viable solution, as it would also
reduce the capacity and the productivity of the Nexus. The number of Scrum Teams in a Nexus
should be based on the size and the scope of the product, and it should not exceed nine teams
.
Reducing the number of teams would also disrupt the existing team dynamics and collaboration.
Adding another Scrum Team to the Nexus to increase capacity is not a good idea, as it would increase
the complexity and the dependencies among the teams. Adding another team would also require
more coordination and communication, which would consume more time and resources. Moreover,
adding another team would not necessarily increase the value or the quality of the product
Increment
.
Question 11
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)
- A. Assign as many Product Owners as needed to communicate expectations and requirements to the Scrum Team.
- B. One Product Owner responsible for each product. Each of these Product Owners may delegate work as needed, but they remain accountable for the value delivered by their product.
- C. One Product Owner responsible for all five products. This Product Owner may delegate work as needed, but the Product Owner remains accountable for the value delivered.
- D. One primary Product Owner and one Product Owner for each product. The primary Product owner delegates all accountability for delivering value to the Product Owners for each product.
Answer:
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.
Question 12
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)
- A. The Nexus Integration Team should be responsible for integrating the work of these two Scrum Teams.
- B. Reorganize these two Scrum Teams so that one is responsible for development and one is responsible for integration.
- C. Merge the two Scrum Teams together.
- D. Ensure the appropriate representatives from both teams are present during Cross- Team Refinement.
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.
Question 13
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)
- A. Feature teams have less communication overhead.
- B. With feature teams, it is easier to calculate the productivity per team.
- C. You cannot do Scrum without feature teams.
- D. When making this change, it helps to have support from the organization.
- E. Productivity may decrease when making this kind of change.
Answer:
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.
Question 14
How should multiple Scrum Teams deliver a valuable and useful Increment in a Sprint?
(choose the best answer)
- A. Each Scrum Team delivers done Increments of its own area of responsibility. These Increments are integrated into a whole product during stabilization prior to release.
- B. Each Scrum Team provides a unique done Increment that includes the team's added functionality.
- C. Each Sprint, all Scrum Teams complete work that integrates with all of the other work from other Scrum Teams on the initiative.
- D. Functionality not integrated with the work of other Scrum Teams may be delivered as unintegrated Increments to demonstrate the value created by the Scrum Teams unable to completely integrate their Increments.
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.
Question 15
True or False: A Nexus Integration Team is accountable for ensuring that a Integrated
Increment is produced at least once a Sprint.
- A. True
- B. False
Answer:
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.