User Stories Foundations Certificate Exam – Quiz 01

The INVEST criteria are essential for creating effective user stories in Agile development. The criteria ensure that user stories are Independent (self-contained and not dependent on others), Negotiable (open to discussion and changes), Valuable (providing value to the customer), Estimable (able to be estimated in terms of effort), Small (manageable in size), and Testable (able to be tested against defined criteria). These principles help maintain the quality and clarity of user stories, facilitating better communication and project management.

Planning Poker is a collaborative estimation technique commonly used in Agile frameworks like Scrum. It involves the entire team discussing and providing their estimates for a user story using cards with predefined values (typically Fibonacci sequence). This method promotes discussion and consensus, helping to uncover assumptions and ensuring a shared understanding of the user story. Dot Voting and T-shirt Sizing are also useful techniques but may not provide the same level of detailed discussion and consensus as Planning Poker. The Delphi Method is more suitable for expert opinion aggregation and is less commonly used in Agile practices.

Acceptance Criteria are specific conditions defined for each user story, detailing what needs to be done for the story to be considered complete and acceptable. They provide a clear definition of what the user story should achieve. The Definition of Done (DoD), on the other hand, is a standardized checklist that applies to all user stories in a project, ensuring consistency and quality across the board. The DoD typically includes criteria such as code reviews, testing, documentation, and deployment readiness. Both are essential for ensuring that user stories meet the required standards and deliver value to the customer.

User interviews are highly effective for gathering detailed and comprehensive user requirements because they allow direct interaction with the end users. During these interviews, stakeholders can ask specific questions, clarify ambiguities, and understand the users’ needs, preferences, and pain points in depth. This interaction leads to the creation of more accurate and relevant user stories, which can better address the real issues faced by the users. User interviews facilitate rich qualitative data collection, providing insights that other techniques like surveys and observation may not uncover.

Additionally, user interviews promote empathy and understanding between the development team and the users. By directly engaging with users, developers and product owners can gain a clearer picture of the context in which the product will be used, leading to better prioritization and refinement of user stories. While other techniques like brainstorming and surveys are useful, they may lack the depth and personal touch that user interviews offer, making the latter a superior choice for gathering comprehensive user requirements.

Balancing new features with technical debt is crucial for the long-term success of any project. By alternating between addressing technical debt and implementing new features, Maria can ensure that the platform remains stable and maintainable while still delivering value to stakeholders. This approach prevents the accumulation of technical debt, which can lead to increased maintenance costs and reduced productivity over time. It also ensures that user expectations for new features are met, maintaining stakeholder satisfaction.

Additionally, addressing technical debt incrementally allows the team to manage workload more effectively and avoid the significant disruptions that come with focusing solely on either new features or technical debt. This balanced approach promotes sustainable development practices, ensuring that the platform evolves healthily and remains scalable. Ignoring technical debt or delaying its resolution can lead to severe issues down the line, such as system failures or costly refactoring, making this approach the most prudent and effective strategy.

The primary role of the Product Owner in an Agile team is to prioritize and refine user stories. This involves ensuring that the most valuable and critical user stories are addressed first, aligning with the project’s goals and stakeholder needs. The Product Owner collaborates with stakeholders to gather requirements and translates them into clear and actionable user stories. By continuously refining the backlog, the Product Owner ensures that user stories are well-defined, estimated, and ready for development, thus maintaining a steady flow of work for the team.

Furthermore, the Product Owner plays a key role in balancing the needs and expectations of various stakeholders, making strategic decisions about what the team should work on next. This prioritization process helps in managing the scope and direction of the project, ensuring that the team focuses on delivering maximum value with each iteration. While the development team writes and tests user stories, and the Scrum Master ensures adherence to Agile practices, it is the Product Owner who provides the necessary vision and direction, making prioritization and refinement their primary responsibilities.

Splitting large user stories, or epics, by functionality is the most effective method as it allows teams to deliver incremental value to users. This approach focuses on breaking down the epic into smaller stories that each represent a piece of functionality that can be developed, tested, and delivered independently. By dividing the epic into functional components, the team ensures that each story remains small and manageable, adhering to the INVEST criteria. This helps in maintaining clarity, improving estimation accuracy, and enabling faster feedback from users.

Furthermore, splitting by functionality allows the development team to prioritize and work on the most critical aspects of the epic first, ensuring that essential features are delivered early. This incremental approach facilitates continuous delivery and integration, which are key principles of Agile methodologies. While other methods like splitting by user roles, acceptance criteria, or user journeys can be useful, they may not always result in deliverable increments of value, making functionality-based splitting the most practical and efficient method.

Introducing a Definition of Ready (DoR) is an effective practice to ensure that user stories are well-defined and understood by the team before they start working on them. The DoR is a set of criteria that a user story must meet to be considered ready for development. These criteria typically include having clear acceptance criteria, sufficient detail, and appropriate size, ensuring that the story is actionable and can be completed within a single sprint. By implementing the DoR, David can help the team avoid vague and incomplete user stories, reducing the likelihood of rework and delays.

Additionally, the DoR facilitates better planning and estimation during backlog refinement meetings. It ensures that the team has all the necessary information to understand the scope and requirements of each story, enabling them to provide more accurate estimates and plan their work effectively. This practice enhances communication and collaboration between the Product Owner and the development team, leading to higher quality user stories and a more efficient development process. While practices like ATDD, continuous integration, and TDD are valuable in their own right, they do not specifically address the issue of vague and incomplete user stories as directly as the DoR.

The Development Team is primarily responsible for ensuring that user stories meet the Definition of Done (DoD). The DoD is a shared understanding within the team of what it means for a piece of work to be complete. It includes criteria such as code quality standards, testing requirements, documentation, and other necessary steps to ensure that the work is fully finished and potentially shippable. The Development Team collectively owns the process of meeting the DoD, as they are the ones performing the actual work and ensuring it meets the agreed-upon standards.

Ensuring user stories meet the DoD is crucial for maintaining high-quality deliverables and avoiding technical debt. It promotes accountability and transparency within the team, as everyone understands the criteria that must be met before a user story can be considered done. While the Product Owner, Scrum Master, and stakeholders play important roles in the Agile process, it is the Development Team that is directly responsible for the execution and completion of work items. This responsibility includes adhering to the DoD, which helps maintain the integrity and reliability of the product being developed.

The acceptance criteria component of a user story defines the specific conditions that must be met for the story to be considered complete. Acceptance criteria are a set of statements that outline the requirements and boundaries of a user story, providing clear guidance on what needs to be achieved for the story to be accepted by the Product Owner. These criteria ensure that both the development team and the stakeholders have a shared understanding of the expected outcome, reducing ambiguity and increasing the likelihood of delivering a product that meets the user’s needs.

Acceptance criteria play a crucial role in ensuring the quality and completeness of user stories. They act as a checklist that guides the development team during implementation and helps in writing test cases for validation. By having well-defined acceptance criteria, the team can ensure that all necessary conditions are met before the story is marked as done, thus adhering to the Definition of Done (DoD). This practice not only improves the accuracy of the work but also facilitates better communication and collaboration among team members and stakeholders, leading to more successful project outcomes.

The MoSCoW prioritization technique is effective for balancing high-priority features and technical debt in the backlog. MoSCoW stands for Must have, Should have, Could have, and Won’t have, and it helps in categorizing user stories based on their importance and urgency. By using this method, Lisa can prioritize essential features that must be implemented to meet stakeholder needs while also addressing technical debt that could impact the system’s long-term health and maintainability. This balanced approach ensures that critical functionalities are delivered without compromising the system’s overall stability and performance.

MoSCoW prioritization facilitates effective decision-making by providing a clear framework for evaluating the importance of each user story. It enables Lisa to communicate the rationale behind prioritization decisions to stakeholders and the development team, fostering transparency and alignment. Additionally, by categorizing technical debt as “Must have” or “Should have,” Lisa ensures that the team addresses these issues in a timely manner, preventing potential disruptions and technical challenges in future iterations. This technique is particularly useful in Agile environments where continuous delivery and iterative development are key principles.

The main benefit of using story points instead of time-based estimates is that story points focus on the relative effort and complexity of user stories rather than absolute time. Story points allow the team to estimate how challenging a story is compared to others, considering factors such as complexity, risks, and unknowns. This approach helps in providing a more consistent and objective measure of work effort, which can be particularly useful in Agile environments where variability and unpredictability are common. By focusing on relative effort, teams can better manage their workload and plan sprints more effectively.

Story points also help in improving the accuracy of estimates over time as the team calibrates their understanding of what different point values represent. This calibration process, combined with the team’s velocity (the rate at which they complete story points), allows for more reliable sprint planning and forecasting. Moreover, using story points encourages discussions about the nature of the work and the challenges involved, fostering better collaboration and understanding within the team. This leads to more accurate and meaningful estimates, ultimately enhancing the team’s ability to deliver high-quality products efficiently.

The “INVEST” acronym in the context of user stories stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These criteria are essential for creating effective user stories that are clear, manageable, and actionable. Independence ensures that each user story can be developed and tested without depending on other stories, promoting flexibility and parallel work streams. Negotiability highlights that user stories are not contracts but starting points for discussions and refinement. Value ensures that each story delivers a benefit to the user or the business, justifying its inclusion in the product backlog. Estimability indicates that the team can approximate the effort required to implement the story. Keeping stories Small makes them easier to manage and complete within a single iteration. Finally, Testability ensures that the story can be validated through acceptance tests to confirm it meets the requirements.

By adhering to the INVEST criteria, Agile teams can create user stories that facilitate better planning, development, and collaboration. These criteria help ensure that user stories are clear and actionable, reducing ambiguity and potential misunderstandings. When user stories meet these criteria, it becomes easier to prioritize them, estimate the effort required, and integrate them into the development process, ultimately leading to more efficient and effective delivery of valuable software.

To improve the clarity of acceptance criteria, Sarah should implement the SMART criteria, which stands for Specific, Measurable, Achievable, Relevant, and Time-bound. Using the SMART criteria ensures that acceptance criteria are well-defined and clear, reducing the chances of misinterpretation. Specific criteria leave no room for ambiguity, providing clear and detailed requirements. Measurable criteria enable the team to verify if the criteria have been met. Achievable criteria ensure that the goals are realistic within the given constraints. Relevant criteria keep the focus on the necessary and valuable aspects of the user story. Time-bound criteria provide a clear timeframe for when the acceptance criteria should be met.

Applying the SMART criteria to acceptance criteria helps create a common understanding between the Product Owner, development team, and stakeholders. This practice ensures that everyone is aligned on what needs to be achieved for a user story to be considered complete. Clear and well-defined acceptance criteria also facilitate the creation of test cases and validation processes, enhancing the overall quality of the product. By using the SMART criteria, Sarah can ensure that the user stories are implemented accurately and meet the desired outcomes.

In an Agile team, the Product Owner is primarily responsible for writing and refining user stories. The Product Owner acts as the bridge between stakeholders and the development team, ensuring that the user stories accurately reflect the needs and priorities of the business. They are responsible for gathering requirements from stakeholders, translating them into user stories, and prioritizing them in the product backlog. This role involves continuous collaboration with both the development team and stakeholders to refine and clarify the user stories, ensuring that they are actionable and meet the INVEST criteria.

The Product Owner’s responsibility in writing and refining user stories is crucial for maintaining a clear and prioritized product backlog. This process involves regular backlog refinement sessions, where the Product Owner works with the development team to break down large stories, add acceptance criteria, and ensure that the stories are ready for upcoming sprints. By actively managing the backlog and refining user stories, the Product Owner helps the team stay focused on delivering high-value features and meeting the project goals. This collaborative approach ensures that user stories are well-understood and that the team can effectively plan and execute their work, leading to successful project outcomes.

The primary purpose of backlog refinement, also known as backlog grooming, in Agile is to ensure that user stories are ready for future sprints. This process involves reviewing and revising the items in the product backlog to keep them up-to-date and prioritized according to their value and relevance. During refinement sessions, the Agile team discusses user stories in detail, breaks down large stories into smaller, manageable ones, and clarifies any ambiguities. This helps in creating a well-defined and prioritized backlog, ensuring that the stories are actionable and align with the project’s goals.

Refinement also includes adding detailed acceptance criteria to user stories, estimating the effort required, and addressing any dependencies or risks associated with the stories. By regularly refining the backlog, the team can maintain a flow of ready-to-work items, making sprint planning more efficient and effective. This continuous process helps in adapting to changing requirements and priorities, ultimately leading to the successful delivery of valuable increments of the product.

John should encourage his team to use Planning Poker for more accurate and collaborative estimations. Planning Poker is a consensus-based technique used to estimate the effort or complexity of user stories. Each team member uses a deck of cards with values (often based on the Fibonacci sequence) to independently estimate the size of the story. After revealing their estimates simultaneously, the team discusses the reasoning behind their choices, addressing any discrepancies and gaining a shared understanding of the story’s scope. This collaborative process promotes engagement from all team members and leads to more reliable estimates by leveraging the collective knowledge and experience of the team.

The use of Planning Poker also helps in identifying potential risks, dependencies, and complexities that may not have been initially apparent. Through open discussion and negotiation, the team can arrive at a consensus estimate that reflects a comprehensive view of the story’s requirements and challenges. This approach not only improves the accuracy of the estimates but also fosters team collaboration and alignment, contributing to better planning and execution of the sprint.

When dealing with large user stories, also known as epics, the recommended technique is to split the story into smaller, more manageable ones. This process, often referred to as story slicing, involves breaking down a large and complex user story into several smaller stories that can be completed within a single sprint. By doing so, the team can deliver incremental value to the customer and maintain a steady flow of work. Splitting stories also allows for more accurate estimation, better planning, and increased focus on specific features or functionalities.

Smaller stories are easier to understand, estimate, and test, reducing the risk of delays and misunderstandings. They also provide more opportunities for feedback and iteration, enabling the team to refine and improve the product incrementally. This practice aligns with Agile principles of delivering small, frequent releases and responding to change. Effective story splitting ensures that each smaller story remains valuable and independent, contributing to the overall product goals while keeping the development process manageable and predictable.

The INVEST criteria are essential in ensuring that user stories are of high quality and clear. The acronym INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Adhering to these criteria ensures that each user story is well-formed and actionable. For example, stories need to be independent to avoid dependencies that can complicate scheduling and delivery. They must be negotiable, meaning they should be flexible enough to be discussed and adjusted based on feedback from the team and stakeholders. By being valuable, the story ensures it delivers something of importance to the customer or user.

Moreover, making stories estimable allows the team to gauge the effort required accurately. Keeping stories small ensures they can be completed within a single sprint, maintaining a steady flow of deliverables. Lastly, stories need to be testable to verify that the desired functionality works as intended. By adhering to the INVEST criteria, teams can create clear, concise, and actionable user stories that align with Agile principles, facilitating smoother planning, execution, and delivery processes.

Sarah should use user personas and story mapping to ensure that the user stories are clear and meet the team’s expectations. User personas help in understanding the different types of users who will interact with the product, providing insights into their needs, behaviors, and goals. By creating personas, the team can ensure that user stories are tailored to the specific requirements of each user type, making them more relevant and understandable. Story mapping, on the other hand, is a visual technique that helps in organizing and prioritizing user stories. It involves arranging user stories in a sequence that reflects the user’s journey, ensuring a logical flow of features and functionalities.

Using these techniques, Sarah can create a shared understanding among the team members about who the end-users are and how the product will serve their needs. This shared understanding is critical for writing clear and concise user stories that are easy to comprehend and implement. Additionally, story mapping helps in identifying gaps and dependencies in the backlog, allowing the team to address them proactively. By incorporating user personas and story mapping into the story creation process, Sarah can enhance the clarity and effectiveness of the user stories, leading to better planning and execution during sprints.

Collaboration within Agile teams significantly improves the accuracy and relevance of user stories. When team members, including the Product Owner, Scrum Master, and Development Team, work together to create and refine user stories, they bring diverse perspectives and expertise to the process. This collaborative effort helps in identifying the true needs and expectations of the users, leading to more accurate and relevant stories. Additionally, collaborative discussions allow for the clarification of any ambiguities, ensuring that everyone has a shared understanding of the story’s requirements and acceptance criteria. This collective input helps in creating well-defined and actionable user stories that align with the project goals.

Moreover, collaboration fosters a sense of ownership and accountability among team members. When everyone contributes to the story creation process, they are more likely to be committed to delivering high-quality work. Collaborative practices such as backlog refinement meetings, story mapping sessions, and sprint planning foster open communication and continuous feedback, enabling the team to adapt and improve their stories iteratively. This iterative approach ensures that user stories remain relevant and aligned with the evolving needs of the users and stakeholders. Overall, effective collaboration enhances the quality of user stories and contributes to the success of Agile projects.

The primary purpose of acceptance criteria in user stories is to ensure that the stories are both valuable and deliverable. Acceptance criteria serve as a set of conditions that a user story must meet for it to be considered complete and accepted by the product owner. These criteria provide a clear definition of what needs to be done, helping the development team understand the scope of work required. By outlining specific requirements, acceptance criteria help ensure that the delivered product meets the user’s needs and expectations. This clarity helps avoid misunderstandings and sets a shared understanding among team members, stakeholders, and product owners about what the completed story should look like.

Furthermore, acceptance criteria play a crucial role in facilitating testing and quality assurance. They act as a benchmark against which the functionality of the user story can be validated. When acceptance criteria are met, it signifies that the story’s functionality works as intended and fulfills the user’s needs. This process ensures that only fully functional and valuable features are included in the product increment. Additionally, having well-defined acceptance criteria helps in tracking progress and making informed decisions during sprint reviews and retrospectives, ultimately leading to a higher quality product and more satisfied users.

David should introduce Planning Poker to improve the accuracy of his team’s estimates. Planning Poker is an Agile estimation technique that involves team members assigning story points to user stories using a set of numbered cards. Each team member independently selects a card representing their estimate of the story’s effort, and all cards are revealed simultaneously. This method encourages open discussion and consideration of different perspectives, as team members explain their estimates and address any discrepancies. The collaborative nature of Planning Poker helps the team converge on a more accurate and realistic estimate by incorporating diverse viewpoints and leveraging collective knowledge.

Planning Poker also fosters a deeper understanding of the user stories among team members, as they discuss the intricacies and potential challenges associated with each story. This process helps identify hidden complexities and potential risks that might have been overlooked during initial assessments. By using Planning Poker, the team can achieve more accurate and reliable estimates, leading to better sprint planning and increased likelihood of completing the planned work within the sprint. Over time, the team’s estimation skills improve, resulting in more predictable and manageable workloads and enhanced overall performance.

The main advantage of splitting large user stories, or epics, into smaller, more manageable ones is that it allows for faster delivery of value. By breaking down epics into smaller stories, teams can deliver increments of functionality more quickly, providing tangible benefits to users and stakeholders sooner. This approach aligns with Agile principles, which emphasize delivering working software frequently and maintaining a continuous flow of value. Smaller stories are easier to estimate, develop, and test within a single sprint, enabling teams to release features iteratively and gather feedback early and often.

Moreover, splitting epics into smaller stories enhances the team’s ability to manage and prioritize work effectively. Smaller stories are more flexible and can be re-prioritized based on changing business needs or user feedback. This adaptability helps ensure that the most valuable features are developed and delivered first, optimizing the impact of the team’s efforts. Additionally, smaller stories reduce the risk of delays and bottlenecks, as they can be completed independently and in parallel by different team members. Overall, breaking down large user stories into smaller ones promotes incremental development, continuous improvement, and more responsive project management.

Acceptance criteria are critical for defining the conditions that must be met for a user story to be considered complete. These criteria specify the requirements and expectations that the story must fulfill from the perspective of the end-user or the product owner. Clear and well-defined acceptance criteria help ensure that the development team understands what is needed, which reduces ambiguity and aligns the team’s efforts with stakeholder expectations. By providing specific, measurable conditions, acceptance criteria enable the team to verify that the story’s functionality meets the desired standards and is ready for acceptance.

Moreover, acceptance criteria serve as a foundation for testing and validation. They provide a checklist that testers can use to determine whether the story’s implementation satisfies all required conditions. This practice not only improves the quality and reliability of the software but also facilitates smoother communication and collaboration among team members. When acceptance criteria are well-defined, the development process becomes more transparent and predictable, leading to higher-quality deliverables and increased satisfaction among stakeholders. Additionally, clear acceptance criteria help in managing scope and avoiding scope creep, as they set clear boundaries for what is included in the story.

Lisa should use the MoSCoW Method to prioritize user stories in the backlog effectively. The MoSCoW Method categorizes stories into four priority levels: Must Have, Should Have, Could Have, and Won’t Have. This technique helps product owners and teams make clear decisions about which features are essential for the product’s success (Must Have) and which can be deferred or are less critical (Should Have, Could Have, Won’t Have). By prioritizing stories based on these categories, Lisa can ensure that the most valuable and impactful features are developed first, aligning the development process with business goals and customer needs.

Additionally, the MoSCoW Method provides a structured approach to balancing customer needs with technical feasibility. It encourages discussions between stakeholders, product owners, and development teams to assess the importance and feasibility of each story. This collaboration helps identify dependencies, technical constraints, and potential risks early in the development process. By incorporating the perspectives of both business stakeholders and technical teams, Lisa can make informed prioritization decisions that optimize value delivery and ensure the project remains on track. This method also allows for flexibility, enabling the team to adapt to changes and refine priorities as new information emerges.

In an Agile team, the Product Owner is primarily responsible for defining and prioritizing user stories in the product backlog. The Product Owner acts as the voice of the customer and stakeholders, ensuring that the team focuses on delivering the most valuable features that align with business objectives. By clearly defining user stories and their acceptance criteria, the Product Owner provides the development team with a detailed understanding of what needs to be built and why it is important. This role involves ongoing collaboration with stakeholders to gather requirements, validate assumptions, and adjust priorities based on feedback and changing market conditions.

Furthermore, the Product Owner prioritizes the backlog to maximize the value delivered by the team. This involves assessing the relative importance and urgency of each user story, considering factors such as customer impact, business value, and technical dependencies. By maintaining a prioritized backlog, the Product Owner ensures that the team works on the most critical and high-impact items first, leading to incremental and iterative delivery of valuable features. This prioritization process is crucial for the Agile framework, as it supports continuous delivery, adaptability, and alignment with evolving business needs. The Product Owner’s decisions guide the team’s efforts, helping them stay focused and deliver meaningful results.

The INVEST criteria are essential for breaking down user stories into manageable, independent units that can be completed within a single iteration. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These criteria help ensure that each user story is well-defined and suitable for inclusion in an iteration. By adhering to these criteria, teams can create user stories that are independent and can be developed and tested without dependencies on other stories. This approach facilitates efficient planning and execution, as each story can be tackled in isolation, reducing complexity and enhancing clarity.

Furthermore, the INVEST criteria support effective backlog management and improve the overall quality of user stories. Stories that meet these criteria are more likely to provide clear value, be feasible to estimate, and be testable against defined acceptance criteria. This process helps prevent stories from becoming too large or vague, which can lead to issues with scope and delivery. By following the INVEST principles, teams can maintain a well-organized and actionable backlog, leading to more predictable and successful iterations.

Specific and measurable acceptance criteria are crucial for providing the development team with clear guidance on implementation. These criteria outline the exact requirements that must be met for a user story to be considered complete, reducing ambiguity and ensuring that the development team knows precisely what needs to be achieved. This clarity helps avoid misunderstandings and miscommunications, which can lead to incomplete or incorrect implementations. Specific criteria also make it easier to create comprehensive test cases, ensuring that the completed story meets the intended functionality and quality standards.

Additionally, well-defined acceptance criteria support effective validation and verification of the user story. By providing measurable outcomes and clear expectations, acceptance criteria enable testers to assess whether the story meets all required conditions. This process helps ensure that the final product aligns with stakeholder requirements and reduces the likelihood of rework or defects. Clear acceptance criteria contribute to a smoother development process, higher quality deliverables, and greater satisfaction among stakeholders.

To address the issue of large user stories impacting the team’s ability to complete them within sprints, Alex should use story mapping to break down these stories into smaller, manageable parts. Story mapping is a technique that helps visualize the user journey and identify the essential components of each user story. By breaking down large stories into smaller, more manageable units, the team can better estimate, prioritize, and complete each part within a sprint. This approach helps maintain the focus on delivering incremental value and ensures that stories are small enough to be addressed within the sprint’s time frame.

Additionally, using story mapping enhances the overall organization and clarity of the backlog. It allows the team to see the broader context of the user stories and their relationships, which aids in prioritization and planning. This method supports better backlog management by ensuring that user stories are appropriately sized and well-defined, leading to more effective sprint planning and execution. By adopting this technique, Alex can help the team manage their workload more efficiently and deliver higher-quality results in each sprint.