SCRUMstudy Scrum Video on Groom Prioritized Product Backlog and its inputs, tools and outputs

Groom 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 “servant 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 Groom 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 grooming 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 Groom 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 Groom Prioritized Product Backlog process, Scrum Guidance Body Recommendations may include best practices about how to systematically understand and collate requirements from 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 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 Groom 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 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 Grooming Techniques

 

Some other Prioritized Product Backlog Grooming 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.