Product Backlog and Product Owner

The Product Backlog

• The Product Backlog serves as the single source of truth for all project work.
• The Product Backlog can include stability, performance, product functionality, documentation, and fixes.

Product Owner Responsibilities on the Product Backlog

• Variables considered when ordering the Product Backlog should align with product goals and optimize value delivery.
• Monitoring and sharing progress of the Product Backlog is mandatory for the Product Owner and any practice based on trends of work completed and upcoming work can be used for this.
• Developers are accountable for estimating the effort needed to complete Product Backlog Items.
• The Product Owner, or a delegate, can update the Product Backlog at any time.
• It is not necessary for the Product Owner to have the entire Product Backlog documented in detail before starting the first Sprint.
• The Product Owner can order the Product Backlog using value points or another technique.
• The team adds security concerns to the Definition of Done or as Product Backlog Items for each concern to ensure security.
• Dependencies could influence how the Product Owner orders Product Backlog Items.
• Transparency is ensured by making the Product Backlog available to stakeholders and by keeping it ordered.

Timeboxes

• Timeboxes help minimize risk. They can create opportunities to validate assumptions using feedback from users and the market. They allow Scrum Teams to inspect progress toward the Product Goal and decide whether to pivot or persevere.

The Sprint Goal

• Sprint Backlog results from Sprint Planning and includes the Sprint Goal.
• The Scrum Team is accountable for creating a valuable and usable Increment each Sprint.
• The Product Owner should come to Sprint Planning with a business objective in mind and work with the Developers to craft the Sprint Goal.
• Developers need a Sprint Goal to stay focused with a common yet specific goal.

Transparency

• Scrum is based on empiricism, and transparency of all artifacts ensures accurate inspection.
• The Scrum Team maintains the Product Backlog by continually keeping it up to date with the most recent insights.

What to Add to the Product Backlog

• Non-functional requirements are made visible by adding them to the Product Backlog to ensure transparency. They can also be added to the Definition of Done so the work is accounted for every Sprint.
• Add Items to the Sprint Backlog, after it has started, as soon as possible after identification.

Ordering the Product Backlog

• Value of Product Backlog Items and dependencies between backlog items or to other products are criteria to order the Product Backlog Items.
• Not a valid consideration when ordering a Product Backlog is tools and techniques.
• Product Value is measured by the impact on customer satisfaction, cost, and revenue.
• Some of the things to focus on to ensure the product delivers value, is the amount of the functionality of the product being used, how quickly or easily the product can be absorbed and used by its customers, and direct customer feedback.
• In order to maximize the value of the product, a Product Owner needs competitive research, customer feedback, product vision, and forecasts and feasibility.

The Scrum Team

• The Scrum Team may add the items to the Sprint Backlog for the next Sprint during Sprint Retrospective.
• A Product Owner is just one member of the Scrum Team as the Scrum Team decides the Definition of Done.
• The Scrum Team is accountable for creating a valuable Increment every Sprint.
• The Scrum Team includes, the Scrum Master, Product Owner and Developers.
• The Scrum Team should have all the skills needed to turn Product Backlog Items into a valuable, useful Increment.
• It is each Scrum Team is accountable for developing functionality from beginning to end in order to produce valuable Increments.

Cone of Uncertainty

• The Cone of Uncertainty demonstrates that project forecasts are increasingly less certain as a project lengthens.

Sprint Review

• Share the current impediments and forecast for the Sprint and promote transparency by sharing the Product Backlog and ensuring the Project Manager has access.
• The stakeholder's role is not to reorder the Product Backlog during the Sprint Review.

Communication

• Only fully describe Product Backlog items when it seems likely they will be implemented to minimize waste in developing and sustaining the Product Backlog.
• Remove items from the Product Backlog that have not been addressed in a long time when trying to minimize waste in developing and sustaining the Product Backlog.
• It helps avoid barriers to effective communication and rapid decision-making, it is clear who is accountable for the ultimate value of the product, and it would confuse the stakeholders if they had to work with more than one person, that there is only one Product Owner per product.
• The Scrum Team work with other teams to create an Increment that is inclusive of all five team's work.
• Product Owners actively ask for stakeholder input and expectations to incorporate into the Product Backlog.

Scrum Master

• The Scrum Master should coach the team on why the Daily Scrum is important as an opportunity to update the plan, and learn why the Developers want this and work with them to improve the outcome of the Daily Scrum.
• By facilitating Scrum Team decisions and by removing impediments that hinder the Scrum Team, are the two primary ways a Scrum Master helps a Scrum Team work at its highest level of productivity
• If Developers find out during the Sprint that they are not likely to build everything they forecast, the team should Re-negotiate the selected Product Backlog Items with the Developers, ask Developers to re-order Product Backlog so the work involving the external component can be planned in a separate Sprint, and Remind the Product Owner that their primary concern is the flow of value reflected in the ordering of the Product Backlog.
• The Scrum Master does not have the authority to cancel a Sprint.
• If Developers ask their Product Owner to re-order the Product Backlog so the work involving the external component can be planned in a separate Sprint then The Scrum Master should Remind the Product Owner that their primary concern is the flow of value reflected in the ordering of the Product Backlog.

Velocity

• Developers do not need to have enough work to keep all Developers busy, there is benefit of Developers figuring out a solution for themselves, ability of the Scrum Teams to produce integrated Increments and not The desire to maintain a stable velocity.
• It is not a measure of success if there is an increase in team's velocity.

Sprint

• A Sprint starts immediately following the end of the previous Sprint.
• All Sprints must be one month or less.
• All planned work for the Product done by the Scrum Team must originate from the Product Backlog.
• If the Product Backlog is not sufficiently clear at Sprint Planning the Developers will find it difficult to create a Sprint forecast they are confident they can meet.
• The Sprint length is unchanged and the Scrum Team continuously learns and adapts if the Scrum Team cannot complete its work by the end of the Sprint.
• During a Sprint, new work or further decomposition of work are added as soon as possible after it is identified.

Scrum

• Scrum is a framework to generate value through adaptive solutions for complex problems.
• It helps the Scrum Team keep focus and they can weigh any decision against the Product Goal, it is easier to inspect Incremental progress at the Sprint Review, and it provides a good overall direction so Sprints will feel less like isolated pieces of work, the advantages of a Product Owner sharing a clearly defined Product Goal with the Scrum Team.
• There is no such thing as Sprint 0.
• Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.

Daily Scrum

• The Developers are accountable for tracking the remaining work toward the Sprint Goal.
• Developers participate in the Daily Scrum meeting.
• Managers are not required at the Daily Scrum.
• Developers decide who starts the Daily Scrum.
• It is not necessary for the Scrum Master to attend the meeting and/or the Developers have asked the Scrum Master to facilitate the Daily Scrum, is are things that can occur at the Daily Scrum.
• There are Opportunities to inspect and adapt the Sprint Backlog are lost, Impediments are raised and resolved more slowly, and The Sprint Backlog may become inaccurate, are three key concerns if the frequency of Daily Scrums were to be lowered to every two or three days

Definition of Done

• Add security concerns to the Definition of Done or create Product Backlog Items for each concern to ensure security.
• The Definition of Done can affect the product's total cost of ownership and it is a way to have complete transparency into what has been done at the end of each Sprint are important factors on why Product Owners care that the Scrum Team adheres to its Definition of Done.
• The Scrum Team must choose at least one high priority process improvement item, identified during the Sprint Retrospective, and place it in the Sprint Backlog. is false.
• The Definition of Done should only be fully described when it seems likely they will be implemented to minimize waste.
• The Definition of Done guides the Developers in creating a forecast at the Sprint Planning, it creates transparency over the work inspected at the Sprint Review.
• The Sprint must be for 1 month or less duration only.
• The Scrum Team is responsible in writing the definition of Done.
• During the Sprint Retrospective a Scrum Team has identified several high priority process improvements.

The Product Owner

• A new Product Owner is accountable for the Product Backlog.
• The Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum Team.
• The Product Owner invites stakeholders to the Sprint Review to learn how the current state of the marketplace influences what is the most valuable thing to do next and the Product Owner shares the current state of Product Backlog.

Scrum Values

• Respect, Focus, Commitment, Courage and Openness are Scrum Values.