4. General Scrum Concepts Flashcards
True or False: According to the Scrum framework, the Scrum components and rules for the project are chosen depending on the project’s specific characteristics.
False
Here’s why it’s false:
Uniform Application: Scrum is designed to be applied uniformly across different projects. It provides specific roles (Scrum Master, Product Owner, Developers), events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), artifacts (Product Backlog, Sprint Backlog, Increment), and rules (timeboxing, Definition of Done) that are meant to be implemented as described in the Scrum Guide.
Consistency and Transparency: By maintaining consistency in roles, events, and artifacts, Scrum ensures transparency and clear accountability within the Scrum Team and with stakeholders. This consistency helps in comparing and understanding progress across different projects and teams.
Flexibility within Framework: While Scrum provides a structured framework, it does allow for adaptation and flexibility within its boundaries. Teams can adjust certain practices or techniques to better suit their context, but the core framework elements remain consistent to maintain the integrity and effectiveness of Scrum.
Stability and Predictability: Following a standardized framework helps in stabilizing project management practices and making predictions about progress and outcomes. Deviating too much from the prescribed framework could undermine these benefits.
In essence, the Scrum framework provides a structured approach to managing complex projects, and its components and rules are designed to be applied uniformly across different projects to ensure consistency, transparency, and effective project management practices. Therefore, the statement that Scrum components and rules are chosen based on a project’s specific characteristics is false within the context of adhering to the Scrum framework as defined.
True or False: During Sprint Retrospective the definition of Done can not be reviewed and adapted.
False
Here’s why:
Purpose of Sprint Retrospective: The Sprint Retrospective is a key Scrum event where the Scrum Team reflects on their past Sprint and identifies improvements that can be made to enhance their effectiveness and efficiency.
Scope of Retrospective Discussions: The retrospective encourages open discussion among the Scrum Team members, including the Scrum Master, Product Owner, and Developers. It covers aspects related to processes, tools, communication, and collaboration to identify what went well and what could be improved.
Definition of Done (DoD): The Definition of Done is a crucial aspect of Scrum, defining the criteria that must be met for a Product Backlog item to be considered complete. It ensures transparency and shared understanding among the team and stakeholders about the quality of work expected.
Review and Adaptation: During the Sprint Retrospective, the Scrum Team can indeed review and adapt the Definition of Done. If team members feel that the current Definition of Done is inadequate or could be improved to better reflect the team’s capabilities or the product’s needs, they can propose changes.
Continuous Improvement: Scrum emphasizes continuous improvement, and the Sprint Retrospective is the primary forum where improvements, including those related to the Definition of Done, can be discussed, agreed upon, and implemented.
In conclusion, the Sprint Retrospective provides an opportunity for the Scrum Team to reflect on all aspects of their work, including the Definition of Done. They can review its effectiveness, propose changes if necessary, and adapt it to better meet their evolving needs and the expectations of stakeholders. Therefore, the statement that the Definition of Done cannot be reviewed and adapted during the Sprint Retrospective is false within the context of Scrum.
Scrum is a technique for developing complex products.
False
Here’s why:
Scrum as a Framework: Scrum is not just a technique but a framework for agile project management. It provides a structured approach to managing complex projects, focusing on iterative development, collaboration, and continuous improvement.
Who is responsible for quality?
The Scrum Team.
Here’s why:
Collective Accountability: In Scrum, quality is not the responsibility of a single individual but of the entire Scrum Team, which includes the Product Owner, Scrum Master, and Developers. This collective accountability ensures that everyone on the team is committed to delivering high-quality increments of work.
Definition of Done: The Definition of Done (DoD) is a key artifact in Scrum that defines the criteria that must be met for a Product Backlog item to be considered complete. The Scrum Team collaboratively defines and adheres to the DoD, ensuring that all work meets the agreed-upon quality standards.
Continuous Improvement: The Scrum framework emphasizes continuous improvement through regular inspection and adaptation. This includes reflecting on the quality of work delivered during Sprint Reviews and identifying improvements during Sprint Retrospectives to enhance future deliverables.
Role of the Developers: Developers within the Scrum Team are directly involved in the creation and implementation of Product Backlog items. They are responsible for instilling quality by adhering to the Definition of Done and ensuring that each increment is thoroughly tested and meets the required standards before being considered complete.
Overall Team Ownership: By assigning responsibility for quality to the entire Scrum Team, Scrum promotes a collaborative and cross-functional approach to achieving high-quality outcomes. This approach fosters teamwork, transparency, and a shared commitment to delivering value to stakeholders.
In conclusion, the Scrum Team, comprising all roles within the team, is collectively responsible for maintaining and delivering quality in the products or increments they develop. This shared responsibility ensures that quality is prioritized throughout the development process, from planning through to delivery and beyond.
Which two statements are correct about the number of Product Owners when there are three products being developed using Scrum?
-There can be a single Product Owner for all products;
-There can be a different Product Owner for each product
a. There can be a single Product Owner for all products.
* It is possible for a single Product Owner to manage multiple products. This might be suitable in cases where the products are closely related, and one person can effectively manage the priorities and vision for all products. This approach can also ensure a unified strategy and consistency across the products.
b. There can be a different Product Owner for each product.
* Each product can have its own Product Owner. This is often the case when the products are distinct and require individual focus and expertise. Having different Product Owners allows for dedicated attention to each product’s unique needs and stakeholders, which can lead to more effective product management.
These options highlight the flexibility in Scrum regarding how the Product Owner role can be allocated, depending on the specific context and needs of the organization and products.
In scaled Scrum, each Scrum Team demonstrates their individual Increment.
False
Here’s why:
Definition of Scaled Scrum: Scaled Scrum refers to the application of Scrum principles and practices across multiple teams working together on the same product or project. It is typically used when a single Scrum Team is insufficient to handle the complexity or scope of work required.
Integrated Increments: In scaled Scrum frameworks like Nexus (Scaled Professional Scrum), LeSS (Large-Scale Scrum), or SAFe (Scaled Agile Framework), there is an emphasis on creating a single integrated Increment that represents the combined work of all contributing Scrum Teams.
Collaborative Output: Each Scrum Team contributes to the overall Increment through their individual contributions and increments. However, the goal is to integrate these increments into a cohesive whole that meets the Definition of Done for the product as a whole, not just for individual teams.
Joint Demonstrations: During the Sprint Review or similar events, the focus is on demonstrating how the integrated Increment meets the agreed-upon goals and criteria. While individual teams may showcase their contributions, the emphasis is on showcasing the collective output and how it aligns with the overall product vision and objectives.
Alignment and Coordination: Scaled Scrum frameworks emphasize alignment, coordination, and collaboration among multiple teams to ensure that the integrated Increment meets customer and stakeholder expectations. This approach promotes a unified effort towards delivering value and reducing dependencies across teams.
In summary, in scaled Scrum environments, the focus is on demonstrating a cohesive, integrated Increment that represents the combined efforts of multiple Scrum Teams, rather than each team demonstrating their individual Increments separately. Therefore, the statement that “each Scrum Team demonstrates their individual Increment” in scaled Scrum is false because it does not align with the collaborative and integrated nature of scaled Scrum frameworks.
All of the following are possible inputs to Sprint Planning, EXCEPT:
Sprint Goal
The Sprint Goal is defined during Sprint Planning by the whole Scrum Team.
The Sprint Goal is not an input to Sprint Planning; it is an output. Here’s why:
Sprint Planning Process:
1. Inputs to Sprint Planning:
o Product Backlog: The list of all desired work on the project, prioritized by the Product Owner.
o Latest Product Increment: The most recent version of the product, showing what has been done so far.
o Projected Capacity of the Development Team: The team’s availability for the upcoming Sprint.
o Past Performance of the Development Team: Historical data on what the team has been able to complete in previous Sprints.
2. Outputs of Sprint Planning:
o Sprint Goal: A concise statement that defines the purpose of the Sprint. It provides guidance to the team on why they are building the Increment and what they hope to achieve.
o Sprint Backlog: A list of tasks and user stories that the team commits to completing during the Sprint.
During Sprint Planning, the team collaborates to define what can be done in the upcoming Sprint and how that work will be accomplished. They review the Product Backlog, discuss their capacity, and determine the Sprint Goal based on the highest priority items they plan to work on.
Why the Sprint Goal is not an Input:
* Creation During Planning: The Sprint Goal is created during the Sprint Planning meeting itself, based on the Product Backlog items selected for the Sprint. It encapsulates the main objective of the Sprint, derived from the items chosen for the Sprint Backlog.
* Guidance and Purpose: The Sprint Goal provides a shared understanding of the focus for the Sprint and serves as a guide for the team throughout the Sprint.
Which two of the following are correct about the whole Scrum Team role?
- Is responsible for setting the timeboxed duration of Sprints;
-Is responsible for composing the Sprint Goal
Setting the Timeboxed Duration of Sprints (Option b):
The Scrum Team, which includes the Product Owner, Scrum Master, and Developers, collaboratively decides on the timeboxed duration of Sprints during Sprint Planning.
While the Scrum Master typically facilitates the discussion and ensures that the team adheres to the Scrum framework’s guidelines (e.g., Sprints should typically be no longer than one month), the decision itself involves input from all team members.
This ensures that the Sprint duration is suitable for delivering a meaningful increment of work while balancing the team’s capacity and the needs of the product.
Composing the Sprint Goal (Option d):
The Sprint Goal is a concise summary of what the Scrum Team intends to achieve during the Sprint.
While the Product Owner contributes by articulating the business objectives and priorities, and the Scrum Master facilitates the process, the entire Scrum Team collaborates to define and agree on the Sprint Goal during Sprint Planning.
This collaborative effort ensures that all team members understand and align their efforts towards achieving the Sprint Goal, which helps focus the work during the Sprint on delivering a coherent increment of product functionality.
In summary, both options b and d correctly describe responsibilities that involve the entire Scrum Team working together collaboratively. Setting the timeboxed duration of Sprints ensures effective planning and delivery, while composing the Sprint Goal aligns the team’s efforts towards achieving a common objective within the Sprint. These responsibilities highlight the collaborative nature of the Scrum Team’s role in planning and executing Sprints effectively.
Product Backlog refinement is the act of breaking down and further defining Sprint Backlog items into smaller more precise items.
False
Product Backlog refinement is the ongoing process where the Product Owner and the Scrum Team collaborate to clarify and refine Product Backlog items. This involves adding detail, estimates, and order to items in the Product Backlog to make them ready for selection in upcoming Sprints. It focuses on ensuring that items are clear, understood, and appropriately prioritized based on the latest understanding of the product and its requirements.
On the other hand, Sprint Backlog items are derived from the Product Backlog during Sprint Planning. They represent the specific tasks and user stories that the Development Team commits to delivering during the Sprint. The act of breaking down and further defining these Sprint Backlog items into smaller, more manageable tasks occurs during Sprint Planning and throughout the Sprint as the team works on them.
Therefore, the correct understanding is:
* False: Product Backlog refinement is focused on preparing Product Backlog items for future Sprints, not on breaking down Sprint Backlog items.
When multiple teams are working on the same product, one person can be a Developer on more than one Scrum Team.
True
The statement “When multiple teams are working on the same product, one person can be a Developer on more than one Scrum Team” is true in the context of scaled Scrum frameworks like Nexus, LeSS, or SAFe. Here’s why this is the case:
Scaled Scrum Context:
In scaled Scrum environments, multiple Scrum Teams may collaborate on developing a single product or solution. This is typically done to handle larger projects or products that require more than one team to deliver.
Cross-Team Collaboration:
While each Scrum Team maintains its own Sprint Backlog and works independently to deliver increments of the product, there are often dependencies or shared components that require coordination across teams.
To facilitate this collaboration and ensure alignment, it is possible for a person (usually a Developer) to be a member of more than one Scrum Team simultaneously.
Role of the Developer:
Developers within Scrum Teams are responsible for delivering increments of potentially releasable functionality. If a product or project requires specialized skills or if there are dependencies that require close coordination, a Developer with specific expertise may contribute to multiple teams.
This helps in ensuring that knowledge and expertise are shared across teams, reducing bottlenecks, and improving overall collaboration and efficiency.
Management of Workload:
It is essential that if a person is assigned to multiple Scrum Teams, the workload and commitments are managed effectively. This includes ensuring that the individual’s capacity aligns with the expectations and commitments of each team.
Scrum Master and Team Dynamics:
The Scrum Master plays a crucial role in ensuring that cross-team collaboration is effective and that any potential conflicts or challenges related to shared resources are addressed promptly.
Teams also need to be mindful of potential overallocation of individuals and ensure that each team’s Sprint commitments are realistic given the shared resources.
In conclusion, in scaled Scrum environments, where multiple teams are working on the same product, it is indeed possible for one person, particularly a Developer, to be a member of more than one Scrum Team. This practice helps in managing dependencies, sharing expertise, and improving overall coordination across teams working towards a common product goal. Therefore, the statement is true within the context of scaled agile frameworks and their application in large-scale product development scenarios.
Which of the following are true?
- The Developers have a Daily Scrum;
- The Scrum Team delivers an Increment every Sprint;
- The heart of Scrum is a Sprint, a consistent duration of no more than one month
Which three statements are correct when four teams are working on one product?
- Each Scrum Team should have a separate Scrum Master;
- Each Scrum Team should have a separate Definition of Done;
- Each Scrum Team should have their own Sprint Backlog
The Product Backlog is baselined at the first Sprint.
False
Which two of the following are NOT allowed in Scrum?
- Sprint 0;
- Sprint dedicated to integration
Which of the following are true about the Definition of Done?
- It guides the Development Team in selecting how many Product Backlog items to select during a Sprint Planning;
- It is a checklist of the types of work that the Scrum Team is expected to complete to finish a product;
- It’s used to have a shared understanding of what it means for work to be complete, to ensure transparency
