Scrum Events Flashcards
What is the purpose of the Sprint Goal?
The Sprint Goal is a core concept in Scrum, and it plays a crucial role in guiding the work of the Scrum Team during a Sprint, which is a time-boxed development iteration in Scrum. The Sprint Goal is a concise, clear, and measurable objective or target that the Development Team aims to achieve by the end of the Sprint. It helps provide focus and direction to the team’s work during the Sprint. Here are some key points about the Sprint Goal:
Purpose: The Sprint Goal is designed to provide a unifying purpose for the work conducted during the Sprint. It gives the team a shared understanding of what they are trying to accomplish and why.
Set at Sprint Planning: The Sprint Goal is typically defined during the Sprint Planning meeting, which is held at the beginning of each Sprint. The Product Owner, Scrum Master, and Development Team collaborate to establish the Sprint Goal based on the highest-priority items from the Product Backlog.
Guides Prioritization: The Sprint Goal helps the Development Team select the right Product Backlog items to work on during the Sprint. It guides their prioritization and ensures that the work aligns with a common objective.
Adaptive: While the Sprint Goal provides a clear direction, it’s not set in stone. If circumstances change during the Sprint (e.g., new information, emerging requirements, or unexpected issues), the Sprint Goal can be adjusted with the consensus of the Scrum Team.
**Measurable: **A well-defined Sprint Goal should be measurable so that the team can determine whether it has been achieved by the end of the Sprint. This measurability helps in assessing progress and success.
Communication: The Sprint Goal is communicated to all relevant stakeholders, including the Scrum Team, Product Owner, stakeholders, and sometimes even the end-users. It promotes transparency and shared understanding of the Sprint’s purpose.
Motivation: Having a clear Sprint Goal can be motivating for the Development Team. It provides a sense of purpose and accomplishment when the goal is met by the end of the Sprint.
Sprint Review: During the Sprint Review meeting at the end of the Sprint, the team demonstrates the work completed and discusses whether the Sprint Goal was achieved. This provides an opportunity for feedback and alignment with stakeholders.
Iterative: The Sprint Goal evolves from Sprint to Sprint as the product is developed incrementally. It should be aligned with the product’s overall vision and roadmap.
In summary, the Sprint Goal serves as a focal point for the Development Team’s work during a Sprint. It helps them understand what needs to be accomplished and why, fostering focus, collaboration, and transparency within the Scrum Team. The successful achievement of the Sprint Goal is a key indicator of the Sprint’s success.
Determined during Sprint Planning.
What is Technical Debt and how is it managed in Scrum?
Technical debt is a concept in software development that refers to the implied cost of additional work that arises when code or system design is expediently implemented in the short term rather than following best practices for long-term maintainability, scalability, or reliability. This metaphorical “debt” occurs when development teams make deliberate trade-offs, often for the sake of meeting tight deadlines or shipping features quickly, but those trade-offs result in suboptimal or less maintainable code.
Here are some key points to understand about technical debt:
Types of Technical Debt:
Code Debt: This involves writing code that may not be well-structured, documented, or optimized. It can result in hard-to-maintain, error-prone software.
Design Debt: This pertains to architectural or design choices that are made hastily and might not be scalable or extensible. It can lead to limitations in future development efforts.
Testing Debt: Skipping or insufficient testing can lead to undetected bugs and quality issues, accumulating over time.
Documentation Debt: Poor or lacking documentation can hinder understanding and maintenance of the codebase.
Infrastructure Debt: Neglecting to update or modernize the underlying infrastructure, libraries, or technologies can lead to security vulnerabilities and performance problems.
Accumulation Over Time: Just as financial debt accumulates interest over time, technical debt accumulates “interest” in the form of additional effort required for maintenance and future development. As the debt grows, it can slow down development, increase the likelihood of defects, and decrease the team’s productivity.
Awareness and Management: It’s crucial for development teams and stakeholders to be aware of technical debt and actively manage it. This includes recognizing when shortcuts are taken, acknowledging the trade-offs, and making deliberate decisions about when and how to address the debt.
Paying Down Technical Debt: Paying down technical debt involves allocating time and resources to refactor, improve, and optimize code, designs, or processes. This can be done incrementally over multiple sprints or as dedicated “cleanup” efforts.
Balancing Act: Development teams often face a balancing act between delivering features quickly and managing technical debt. Sometimes, it’s necessary to accumulate some technical debt to meet business deadlines, but this should be a conscious decision, and a plan to address it later should be in place.
Impact on Agility: Excessive technical debt can hinder an organization’s agility and ability to respond to changing requirements. It can lead to a vicious cycle of increased maintenance and reduced innovation.
Communication: Open and transparent communication within the development team and with stakeholders is crucial when dealing with technical debt. Discussing the trade-offs, risks, and plans for addressing the debt helps maintain alignment and expectations.
Tools and Metrics:There are tools and metrics available that can help identify and quantify technical debt within a codebase. These tools can assist in prioritizing which areas of debt to address first.
Addressing technical debt is an ongoing process in software development. It requires a balanced approach that considers both short-term business needs and the long-term sustainability and maintainability of the software. Properly managed technical debt can lead to more efficient development, higher product quality, and reduced risks over time.
What is the purpose of and the elements of the Sprint Retrospective
The Sprint Retrospective is a crucial event in the Scrum framework that occurs at the end of each Sprint. Its purpose is to provide the Scrum Team (including the Product Owner, Scrum Master, and Development Team) with an opportunity to reflect on the Sprint and identify ways to improve their processes, collaboration, and overall effectiveness. Here’s an overview of the Sprint Retrospective:
- Time-boxed - 3 hours for monthly Sprint
- Reflect on Sprint
- Safe Environment
* 3 Key questions: - What went well during the Sprint
- What didn’t go well
- What can we improve for the next Sprint
What is the purpose of and the elements of the Sprint Review?
- Presentation of all potentially shippable release to the PO and stakeholders.
- PO presents the Sprint goal.
- Devs should completed work.
- Discussion and feedback
- PO shares Product Backlog and next set of ordered PBIs.
- Decide if Sprint Goal was achieved.
- 2 hours for 2 week Sprint
Sprint Goal Details
- Created during Sprint Planning
- Plan to complete the work.
- Dev team sets the tasks: < 1 day per task
- Must be communicated to and understood by the entire team
- Evaluated during Sprint Revew
What is the purpose of a Sprint Goal Reassessment?
If it becomes clear during the sprint that the team cannot complete all the planned work, the Scrum Team, particularly the Product Owner and the Development Team, should assess whether the Sprint Goal can still be achieved with the work that remains. The Sprint Goal represents the objective or outcome that the team is working towards during the sprint.
What are the rules around Sprint Termination Definition & Guidelines?
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
Any incomplete work from the Sprint is returned to the Product Backlog, and the Development Team, in collaboration with the Product Owner, determines what to do with it. This work may be reprioritized for future Sprints, redefined, or discarded.
