Articles

The Scrum Product Backlog is a crucial component of the Scrum framework, functioning as a dynamic, ordered list of everything that is needed to improve the product. Managed by the Product Owner, it includes user stories, bug fixes, and other work items prioritized based on their value and urgency.

The Program Product Owner develops the Program Product Backlog which contains a prioritized list of high level business and project requirements preferably written in the form of large Program Backlog Items. These are later refined by the Product Owners of individual projects as they create and prioritize Product Backlogs for their projects. These Prioritized Product Backlogs have much smaller but detailed User Stories that can be approved, estimated, and committed by individual Scrum Teams.

The Program Product Backlog is continuously refined by the Program Product Owner to ensure that new business requirements are added and existing requirements are properly documented and prioritized. This ensures that the most valuable requirements in meeting the program’s objectives are prioritized as high and the remaining are given a lower priority.

The Program Product Backlog created for the program presents a larger picture of all projects that are part of the program. Therefore, it can provide significant guidance regarding project goals, scope, objectives, and the expected business benefits.

Similar to the Project Product Backlog, the Program Product Backlog may also undergo periodic refining to incorporate changes and new requirements. Changes to the Program Product Backlog can result from changes in either external or internal conditions. External conditions might include changing business scenarios, technology trends, or legal compliance requirements. Internal factors affecting the Program Product Backlog could be related to modifications in organizational strategy or policies, Identified Risks and other factors. Changes in requirements in the Program Product Backlog often impact the Project Product Backlogs of underlying projects, so they should be taken into account during the Refine Prioritized Product Backlog process.

The Scrum Product Backlog is a crucial component of the Scrum framework, functioning as a dynamic, ordered list of everything that is needed to improve the product. Managed by the Product Owner, it includes user stories, bug fixes, and other work items prioritized based on their value and urgency.

The Program Product Owner develops the Program Product Backlog which contains a prioritized list of high level business and project requirements preferably written in the form of large Program Backlog Items. These are later refined by the Product Owners of individual projects as they create and prioritize Product Backlogs for their projects. These Prioritized Product Backlogs have much smaller but detailed User Stories that can be approved, estimated, and committed by individual Scrum Teams.

The Program Product Backlog is continuously refined by the Program Product Owner to ensure that new business requirements are added and existing requirements are properly documented and prioritized. This ensures that the most valuable requirements in meeting the program’s objectives are prioritized as high and the remaining are given a lower priority.

The Program Product Backlog created for the program presents a larger picture of all projects that are part of the program. Therefore, it can provide significant guidance regarding project goals, scope, objectives, and the expected business benefits.

Similar to the Project Product Backlog, the Program Product Backlog may also undergo periodic refining to incorporate changes and new requirements. Changes to the Program Product Backlog can result from changes in either external or internal conditions. External conditions might include changing business scenarios, technology trends, or legal compliance requirements. Internal factors affecting the Program Product Backlog could be related to modifications in organizational strategy or policies, Identified Risks and other factors. Changes in requirements in the Program Product Backlog often impact the Project Product Backlogs of underlying projects, so they should be taken into account during the Refine Prioritized Product Backlog process.

Product backlog refinement in Scrum involves several key steps to ensure clarity and prioritization. Initially, the product owner collaborates with the team to review and adjust backlog items, ensuring they are clear, concise, and aligned with the product vision. Next, they prioritize items based on value and dependencies, refining estimates and acceptance criteria as needed. Throughout this iterative process, stakeholders provide input to enhance understanding and feasibility. The goal is to maintain a dynamic backlog that reflects current priorities and evolves with feedback, fostering a shared understanding among all team members for efficient sprint planning and delivery.

What is a Sprint Backlog? Is it a baseline, a record or a report? Baseline is a project document, which, defines aspects of the project and, once approved, is subject to change control. It is used to measure a project’s actual performance as against planned targets. A record maintains information on the progress of the project. A report provides snapshots of the status of different aspects of a project at any given point of time or for a given duration.

To answer this question, we need to understand what a Sprint Backlog is, its purpose and composition. The Scrum Team creates the Sprint Backlog and Sprint Burndown Chart using the User Stories, and the Updated Task List during Sprint Planning Meeting. During Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed during the Create, Estimate, and Commit User Stories process, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Updated Task List to select the tasks they plan to work on in the Sprint, based on their skills, and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.

It is common practice in Scrum that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint, depending on their criticality, and urgency.

Another tool associated with the Sprint Backlog is the Sprint Burndown Chart. It is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

So, it is difficult to categorize the Sprint Backlog as a baseline, record or a report. And as Scrum professes minimum documentation, Sprint Backlog fulfills purposes of more than one project document. For more information on Scrum framework, you can read the Scrum Body of Knowledge (SBOK Guide). It can be downloaded for free in SCRUMstudy website: http://www.scrumstudy.com/download-free-buy-SBOK.asp

La gestión del backlog del producto de Scrum es un aspecto crucial del marco de trabajo de Scrum, que se centra en la organización sistemática y la priorización del trabajo de un proyecto. El Product Backlog, una lista dinámica y en evolución de todo el trabajo y las características deseadas para un producto, es gestionada meticulosamente por el Product Owner. Esta función implica refinar, actualizar y priorizar continuamente los elementos del backlog en función de los comentarios de las partes interesadas, los cambios del mercado y los aportes del equipo. Una gestión eficaz del backlog garantiza que el equipo de Scrum trabaje en las tareas más valiosas, alineando los esfuerzos de desarrollo con los objetivos comerciales y brindando valor incremental. Al mantener un backlog bien estructurado, los equipos pueden adaptarse a los requisitos cambiantes e impulsar el éxito del proyecto en un entorno ágil.

El propietario del producto del programa desarrolla el backlog del producto del programa, que contiene una lista priorizada de requisitos empresariales y de proyecto de alto nivel, preferiblemente redactados en forma de grandes elementos del backlog del programa. Los propietarios del producto de cada proyecto los perfeccionan más tarde a medida que crean y priorizan los backlogs del producto para sus proyectos. Estos backlogs del producto priorizados tienen historias de usuario mucho más pequeñas pero detalladas que los equipos Scrum individuales pueden aprobar, estimar y comprometer.

El propietario del producto del programa perfecciona continuamente el backlog del producto del programa para garantizar que se agreguen nuevos requisitos comerciales y que los requisitos existentes se documenten y prioricen adecuadamente. Esto garantiza que los requisitos más valiosos para cumplir con los objetivos del programa se prioricen como altos y que los restantes tengan una prioridad menor.

El backlog del producto del programa creado para el programa presenta un panorama más amplio de todos los proyectos que forman parte del programa. Por lo tanto, puede proporcionar una orientación significativa con respecto a las metas, el alcance, los objetivos y los beneficios comerciales esperados del proyecto.

De manera similar al backlog del producto del proyecto, el backlog del producto del programa también puede someterse a un perfeccionamiento periódico para incorporar cambios y nuevos requisitos. Los cambios en el backlog del producto del programa pueden ser resultado de cambios en las condiciones internas o externas. Las condiciones externas pueden incluir cambios en los escenarios comerciales, las tendencias tecnológicas o los requisitos de cumplimiento legal. Los factores internos que afectan al backlog del producto del programa pueden estar relacionados con modificaciones en la estrategia o las políticas organizacionales, los riesgos identificados y otros factores. Los cambios en los requisitos del Backlog del Producto del Programa a menudo afectan los Backlogs del Producto del Proyecto de los proyectos subyacentes, por lo que deben tenerse en cuenta durante el proceso de Refinar el Backlog del Producto Priorizado.

El Scrum Product Backlog es un componente crucial del marco de trabajo de Scrum y funciona como una lista dinámica y ordenada de todo lo necesario para mejorar el producto. Lo gestiona el propietario del producto e incluye historias de usuario, correcciones de errores y otros elementos de trabajo priorizados según su valor y urgencia.

El Propietario del Producto del Programa desarrolla el Backlog del Producto del Programa, que contiene una lista priorizada de requisitos de alto nivel del negocio y del proyecto, preferiblemente escrita en forma de grandes Elementos del Backlog del Programa. Estos son refinados posteriormente por los Propietarios del Producto de proyectos individuales a medida que crean y priorizan los Backlogs del Producto para sus proyectos. Estos Backlogs del Producto Priorizados tienen Historias de Usuario mucho más pequeñas pero detalladas que pueden ser aprobadas, estimadas y confirmadas por Equipos Scrum individuales.

El Propietario del Producto del Programa refina continuamente el Backlog del Producto del Programa para asegurar que se agreguen nuevos requisitos del negocio y que los requisitos existentes estén debidamente documentados y priorizados. Esto asegura que los requisitos más valiosos para cumplir con los objetivos del programa sean priorizados como altos y que los restantes tengan una prioridad menor.

El Backlog del Producto del Programa creado para el programa presenta un panorama más amplio de todos los proyectos que forman parte del programa. Por lo tanto, puede proporcionar una orientación significativa con respecto a las metas del proyecto, el alcance, los objetivos y los beneficios comerciales esperados.

De manera similar al Backlog del Producto del Proyecto, el Backlog del Producto del Programa también puede sufrir un refinamiento periódico para incorporar cambios y nuevos requisitos. Los cambios en el Program Product Backlog pueden resultar de cambios en las condiciones internas o externas. Las condiciones externas pueden incluir cambios en los escenarios comerciales, tendencias tecnológicas o requisitos de cumplimiento legal. Los factores internos que afectan al Program Product Backlog pueden estar relacionados con modificaciones en la estrategia o políticas organizacionales, Riesgos Identificados y otros factores. Los cambios en los requisitos en el Program Product Backlog a menudo afectan los Project Product Backlogs de los proyectos subyacentes, por lo que deben tenerse en cuenta durante el proceso de Refinar el Priorizado del Product Backlog.

El Scrum Product Backlog es un componente crucial del marco de trabajo de Scrum y funciona como una lista dinámica y ordenada de todo lo necesario para mejorar el producto. Lo gestiona el propietario del producto e incluye historias de usuario, correcciones de errores y otros elementos de trabajo priorizados según su valor y urgencia.

El propietario del producto del programa desarrolla el backlog del producto del programa, que contiene una lista priorizada de requisitos empresariales y de proyecto de alto nivel, preferiblemente redactada en forma de grandes elementos del backlog del programa. Estos elementos son refinados posteriormente por los propietarios del producto de proyectos individuales a medida que crean y priorizan los backlogs del producto para sus proyectos. Estos backlogs del producto priorizados tienen historias de usuario mucho más pequeñas pero detalladas que pueden ser aprobadas, estimadas y confirmadas por equipos Scrum individuales.

El Program Product Backlog es perfeccionado continuamente por el Program Product Owner para garantizar que se agreguen nuevos requisitos comerciales y que los requisitos existentes se documenten y prioricen adecuadamente. Esto garantiza que los requisitos más valiosos para cumplir con los objetivos del programa se prioricen como altos y que los restantes tengan una prioridad menor.

El Program Product Backlog creado para el programa presenta un panorama más amplio de todos los proyectos que forman parte del programa. Por lo tanto, puede proporcionar una orientación significativa con respecto a las metas, el alcance, los objetivos y los beneficios comerciales esperados del proyecto.

De manera similar al Project Product Backlog, el Program Product Backlog también puede someterse a un perfeccionamiento periódico para incorporar cambios y nuevos requisitos. Los cambios en el Program Product Backlog pueden ser resultado de cambios en las condiciones internas o externas. Las condiciones externas pueden incluir cambios en los escenarios comerciales, las tendencias tecnológicas o los requisitos de cumplimiento legal. Los factores internos que afectan al Program Product Backlog pueden estar relacionados con modificaciones en la estrategia o las políticas organizacionales, los riesgos identificados y otros factores. Los cambios en los requisitos del Backlog del Producto del Programa a menudo afectan los Backlogs del Producto del Proyecto de los proyectos subyacentes, por lo que deben tenerse en cuenta durante el proceso de Refinar el Backlog del Producto Priorizado.

The Scrum Product Backlog Management Certification equips professionals with essential skills to effectively manage and prioritize product requirements within Scrum projects. This certification focuses on mastering the art of maintaining a well-groomed Product Backlog, ensuring it remains transparent, prioritized, and aligned with business goals throughout the project lifecycle. Participants learn valuable techniques to refine backlog items, collaborate with stakeholders, and optimize the flow of work, thereby enhancing project agility and delivery. Ideal for product owners, Scrum Masters, and anyone involved in product development, this certification ensures proficiency in foundational Scrum practices essential for achieving project success.

The Program Product Owner develops the Program Product Backlog which contains a prioritized list of high-level business and project requirements preferably written in the form of large Program Backlog Items. These are later refined by the Product Owners of individual projects as they create and prioritize Product Backlogs for their projects. These Prioritized Product Backlogs have much smaller but detailed User Stories that individual Scrum Teams can approve, estimate, and commit.

The Program Product Owner continuously refines the Program Product Backlog to ensure that new business requirements are added and existing requirements are properly documented and prioritized. This ensures that the most valuable requirements in meeting the program’s objectives are prioritized as high and the remaining are given a lower priority.

The Program Product Backlog created for the program presents a larger picture of all projects that are part of the program. Therefore, it can provide significant guidance regarding project goals, scope, objectives, and the expected business benefits.

Similar to the Project Product Backlog, the Program Product Backlog may also undergo periodic refining to incorporate changes and new requirements. Changes to the Program Product Backlog can result from changes in either external or internal conditions. External conditions might include changing business scenarios, technology trends, or legal compliance requirements. Internal factors affecting the Program Product Backlog could be related to modifications in organizational strategy or policies, Identified Risks and other factors. Changes in requirements in the Program Product Backlog often impact the Project Product Backlogs of underlying projects, so they should be taken into account during the Refine Prioritized Product Backlog process.

Effective product backlog management is crucial for Professional Scrum Product Owners to ensure the successful delivery of valuable products. They possess a range of essential skills to manage the product backlog efficiently and maximize its effectiveness.

Firstly, Professional Scrum Product Owners excel in prioritization. They prioritize backlog items based on business value, user needs, and market demands, ensuring that the team works on the most valuable features first.

Secondly, they have strong stakeholder management skills. Product Owners actively engage with stakeholders, gather feedback, and communicate product priorities effectively. This collaboration ensures alignment with business goals and fosters trust and transparency.

Thirdly, they possess refinement skills. Product Owners continuously refine backlog items, breaking down epics into smaller, actionable user stories. This process involves clarifying requirements, estimating effort, and ensuring that backlog items are well-defined and ready for implementation.

Furthermore, Professional Scrum Product Owners are adept at adaptability. They embrace change and are responsive to evolving market needs and priorities. This agility allows them to adjust the backlog dynamically, reprioritize items as necessary, and seize opportunities for innovation.

Lastly, they leverage data-driven decision-making. Product Owners use metrics, user feedback, and market insights to inform their backlog management decisions. This empirical approach helps them validate assumptions, mitigate risks, and optimize the delivery of value to customers.

By honing these skills, Professional Scrum Product Owners optimize their backlog management practices, empower their teams to deliver high-quality products iteratively, and drive continuous improvement in agile product development processes.

Developing product backlog management skills is crucial for effective Agile product development. This skill set encompasses various tasks such as prioritization, refinement, and maintenance of the product backlog. Prioritization involves aligning backlog items with business goals and customer needs, ensuring the team works on the most valuable tasks first. Refinement entails breaking down user stories into smaller, actionable tasks and ensuring they are well-defined and estimable.

The Program Product Owner develops the Program Product Backlog which contains a prioritized list of high level business and project requirements preferably written in the form of large Program Backlog Items. These are later refined by the Product Owners of individual projects as they create and prioritize Product Backlogs for their projects. These Prioritized Product Backlogs have much smaller but detailed User Stories that can be approved, estimated, and committed by individual Scrum Teams.

The Program Product Backlog is continuously refined by the Program Product Owner to ensure that new business requirements are added and existing requirements are properly documented and prioritized. This ensures that the most valuable requirements in meeting the program’s objectives are prioritized as high and the remaining are given a lower priority.

The Program Product Backlog created for the program presents a larger picture of all projects that are part of the program. Therefore, it can provide significant guidance regarding project goals, scope, objectives, and the expected business benefits.

Similar to the Project Product Backlog, the Program Product Backlog may also undergo periodic refining to incorporate changes and new requirements. Changes to the Program Product Backlog can result from changes in either external or internal conditions. External conditions might include changing business scenarios, technology trends, or legal compliance requirements. Internal factors affecting the Program Product Backlog could be related to modifications in organizational strategy or policies, Identified Risks and other factors. Changes in requirements in the Program Product Backlog often impact the Project Product Backlogs of underlying projects, so they should be taken into account during the Refine Prioritized Product Backlog process.

In Agile Scrum, Product Backlog Items (PBIs) represent the essential features, enhancements, or fixes that contribute to the overall product development. Managed and prioritized by the Product Owner, PBIs are detailed descriptions of user requirements that drive the work of the Scrum Team. These items evolve and are refined throughout the project as new insights emerge or priorities shift, ensuring that the team focuses on delivering maximum value to stakeholders. The Product Backlog serves as a dynamic blueprint, guiding iterative development and enabling adaptability to changing market demands, ultimately facilitating the continuous enhancement of product functionality and customer satisfaction.

The Scrum Agile Backlog is a prioritized list of all the work that needs to be done to complete a project. It contains user stories, features, bug fixes, technical tasks, and any other work items necessary for delivering a product increment. The backlog is dynamic, evolving as requirements change or new insights emerge. It is managed and prioritized by the Product Owner, who ensures that the most valuable items are at the top.

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. The required features are described in the form of User Stories.

User Stories are specific requirements outlined by various business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria (also referred to as “Acceptance Criteria”), which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought.

Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories. If deliverables are accepted by the Product Owner, then the User Story is considered Done. A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working with User Stories.

Welcome to the article on refining and prioritizing the product backlog, a crucial aspect of agile project management. In this article, we delve into the inputs, tools, and outputs involved in this process, offering insights and strategies to effectively manage and optimize your product backlog. Whether you're new to agile methodologies or seeking to enhance your backlog management skills, this resource provides valuable information to streamline your product development journey.

Refine Prioritized Product Backlog

In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.

Inputs

Scrum Core Team

Each Scrum Team will have a designated Product Owner. Scrum Master is a facilitator and “supporting leader” who ensure that the Scrum Team is provided with an environment conducive to completing the project successfully. The Scrum Team, sometimes referred to as the Development Team, is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables.  Scrum Teams are cross-functional and self-organizing. The team decides the amount of work to commit to in a Sprint and determines the best way to perform the work. The Scrum Team consists of cross-functional team members, who carry out all the work involved in creating potentially shippable deliverables including development, testing, quality assurance, etc.

Prioritized Product Backlog*

The Product Owner develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of Epic(s), which are high level User Stories. The Prioritized Product Backlog is based on three primary factors: value, risk and uncertainty, and dependencies. It is also referred to as the Risk Adjusted Product Backlog since it includes identified and assessed risks related to the project. It also encompasses all Approved Changes that can be appropriately prioritized in the Prioritized Product Backlog.

Rejected Deliverables

In cases where a deliverable does not meet the Acceptance Criteria, it is considered a Rejected Deliverable. The Rejected Deliverables are normally not kept in a separate list. They simply remain in the Prioritized Product Backlog and don’t get marked as done – so that they can be reprioritized in the Refine Prioritized Product Backlog process and be considered for development in the next Sprint.

Approved Change Requests

Approved Change Requests originating from the program or portfolio are inputs to be added to the list of approved project changes for implementation in future Sprints. Each change can require its own Epic or User Story and could become an input to the Develop Epic(s) process. Approved Change Requests to this process could also come from other Scrum processes

Unapproved Change Requests

Request for changes are usually submitted as Change Requests and remain unapproved until they get formally approved.  Unapproved Change Requests to Develop Epic(s) process could come from Create Deliverables, Conduct Daily Standup and other processes.

Identified Risks

When creating Epics, new risks may be identified and such Identified Risks form an important output of this stage. These risks contribute to the development of the Prioritized Product Backlog (which could also be referred to as the Risk Adjusted Product Backlog).

Updated Program Product Backlog

Similar to the Project Product Backlog, the Program Product Backlog may also undergo periodic refining to incorporate changes and new requirements. Changes to the Program Product Backlog can result from changes in either external or internal conditions. External conditions might include changing business scenarios, technology trends, or legal compliance requirements. Internal factors affecting the Program Product Backlog could be related to modifications in organizational strategy or policies, Identified Risks and other factors. Changes in requirements in the Program Product Backlog often impact the Project Product Backlogs of underlying projects, so they should be taken into account during the Refine Product Backlog process.

Retrospect Sprint Logs

The Retrospect Sprint Log is a record of the opinions, discussions, and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master could facilitate creation of this log with inputs form Scrum Core Team members. The collection of all Sprint Retrospective logs becomes the project diary and details project successes, issues, problems and resolutions. The logs are public documents available to anyone in the organization.

Dependencies

Dependencies describe the relationship and interaction between different tasks in a project and can be classified as mandatory or discretionary; or internal or external.

There are numerous ways to identify, define, and present the tasks and their dependencies. Two common methods involve the use of product flow diagrams and Gantt charts.

Release Planning Schedule

A Release Planning Schedule is one of the key outputs of the Conduct Release Planning process. A Release Planning Schedule states which deliverables are to be released to the customers, along with planned intervals, and dates for releases.

Scrum Guidance Body Recommendations

In Refine Prioritized Product Backlog process, Scrum Guidance Body Recommendations may include best practices about how to systematically understand and collate requirements from Business Stakeholder(s) and Scrum Teams – and then properly prioritize the Product Backlog and communicate updates to all relevant persons involved with the Scrum project.

Tools

Prioritized Product Backlog Review Meetings*

The Product Owner may have multiple and separate meetings with relevant Business Stakeholder(s), the Scrum Master and the Scrum Team to ensure that he/she has enough information to make updates to the Prioritized Product Backlog during the Refine Prioritized Product Backlog process.

The intent of the Prioritized Product Backlog Review Meetings is to ensure that User Stories and Acceptance Criteria are understood and are written properly by the Product Owner so that they reflect the actual Business stakeholder (customer) requirements and priorities; User Stories are understood by everyone in the Scrum Team; and that high priority User Stories are well-refined so that the Scrum Team can properly estimate and commit to such User Stories.

The Prioritized Product Backlog Review Meetings also ensure that irrelevant User Stories are removed and any Approved Change Requests or Identified Risks are incorporated into the Prioritized Product backlog.

Communication Techniques

Scrum promotes accurate and effective communication primarily through colocation of the Scrum Team. Scrum also favors informal, face-to-face interactions over formal written communications. When a Scrum Team needs to be distributed, the Scrum Master should ensure that effective communication techniques are available so that teams can self-organize and work effectively.

Other Prioritized Product Backlog Refine Techniques

Some other Prioritized Product Backlog Refining tools include many of the same tools used for the following processes:

• Develop Epic(s)
• Create Prioritized Product Backlog
• Conduct Release Planning
• Create User Stories
• Approve, Estimate, and Commit User Stories
• Create Tasks
• Estimate Tasks

 Outputs

Updated Prioritized Product Backlog*

Prioritized Product Backlog may be updated with new User Stories, new Change Requests, new Identified Risks, updated User Stories or reprioritization of existing User Stories.

Updated Release Planning Schedule

The Release Planning Schedule may be updated to reflect the impact of new or changed User Stories in the Prioritized Product Backlog.