Agile Process Framework

The Product Owner is responsible for maximizing the value of the product and prioritizing the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog. The Product owner ensures that the backlog is visible, transparent, clear to the business, and confirms the Development Team understands items in the Product Backlog to the level needed to complete the work. The Product Owner is one person, not a committee. For the Product Owner to succeed, the entire organization must respect their decisions. The Product Owners' decisions are visible in the content and ordering of the Product Backlog.

The Scrum Master is responsible for ensuring the Team adheres to Scrum principles, practices, and rules and ensuring the Product Owner arranges the Product Backlog to maximize value. They often facilitate Scrum events as requested by the team. They coach the Development Team in self-organization and cross-functionality, removing impediments to the Development Teams' progress. They also coach in environments where Scrum is not yet fully adopted and understood, particularly helping employees and Stakeholders understand empirical product development.

The Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Team's overall efficiency and effectiveness. The most effective Teams are self-organizing, persistent, co-located, and cross-functional with all the skills necessary to create an increment. Optimal Development Team size is specified in the Scrum Guide as three to nine members, which is small enough to remain nimble and large enough to complete significant work within a Sprint.

The Product Backlog is an ordered list of everything that is currently considered needed by the business and is the single source of requirements for any changes to be made to the product. A Product Backlog is never complete. The Product Backlog changes as the product and the environment in which it will be used evolves. As a product is used and gains value, and the stakeholders provide feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology will constantly drive changes in the Product Backlog.

Product Backlog refinement is the continuous activity of adding detail, estimates, and priority order to items in the Product Backlog to the specification defined the Definition of Ready. This is an ongoing process in which the Product Owner, Stakeholders, and the Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. Product Backlog items can be updated at any time by the Product Owner, or at the Product Owner's discretion.

The Team is responsible for all estimates. Estimates are based upon the relative level of complexity, uncertainty, and risk. These relative estimates are commonly reflected with Fibonacci numbers rather than absolute numerical values. The Product Owner may influence the Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate. If the PBI is too large to be completed within the Sprint it must be split into smaller stories.

The work to be pulled into the next Sprint from the backlog is determined at the Sprint Planning meeting. This plan is created by the collaborative work of the entire Team answering what can be delivered in the upcoming Sprint and how the work needed to deliver the Increment will be achieved. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. The Product Owner helps clarify the selected Product Backlog items and make trade-offs if necessary. By the end of the Sprint Planning, the Team should be able to explain to the Product Owner and Scrum Master how it intends to accomplish the anticipated Increment

The Daily Standup is a 15-minute time-boxed event for the Team to synchronize activities and create a plan for the next 24 hours. This is a key inspect and adapt meeting. This is done by inspecting the work since the last Daily Standup and forecasting the work to be done before the next one. The Daily Standup is held at the same time and place each day to reduce complexity. Daily Standups improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Team's level of knowledge

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and Stakeholders collaborate on what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for adaptation improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a one hour time-boxed meeting. By the end of the Sprint Retrospective, the Scrum Team should have identified the main improvement they will implement in the next Sprint. Implementing this improvement in the next Sprint is the adaptation to the inspection of the Scrum Team itself.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.

Every day, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog. This is displayed in a downward sloping graph that is on a trajectory to reach "zero effort remaining" by the last day of the Sprint. Hence it is called a Burn Down chart. The horizontal axis of the Sprint Burn Down chart shows the time remaining in the Sprint and the vertical axis shows the amount of work remaining in the Sprint. It shows their progress towards their goal, not in terms of how much time was spent in the past, but in terms of how much work remains to complete the Sprint

The Increment is referred to in two contexts. One is the work completed within the current Sprint. The other is an extension of this includes all Product Backlog items completed during the previous Sprints as well. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team's definition of "Done." It must be in useable condition regardless of whether the Product Owner decides to release it. This is a business decision determined by the Product Owner.

Stories must be immediately actionable when pulled into a Sprint. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story. The Team must understand the "Done" criteria and what tests will be performed to demonstrate the story is complete. "Ready" stories should be clear, concise, and most importantly, actionable. The Team works with the Product Owner during Backlog Refinement to help them get the stories into actionable shape. Only then will the Team be able to estimate how much work any one story will take and how many Points they can take into a Sprint.

When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this varies significantly per Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Team and is used to assess when work is complete on the product Increment. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Team's current Definition of Done.