PSM IDemo

The Daily Scrum is used to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. To reduce complexity, it is held at the same time and place every working day of the Sprint.

The Product Owner is accountable for maximizing the product’s value and for effective Product Backlog management, so this role needs the clearest understanding of progress toward business objectives and planned releases.

Scrum Teams are self-managing: they internally determine how to organize their work. Scrum also values respect for team members as capable, independent people. Letting teams propose their organization and allowing developers to self-organize uphold those principles, whereas management-directed or Product Owner-directed assignments do not.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The Scrum Master and Product Owner are not required participants unless they are also working as Developers.

Scrum prescribes no gap between Sprints: the next Sprint starts immediately when the preceding Sprint ends. Sprint Planning and other necessary Scrum activities take place within the Sprint.

Adding Scrum Teams to a shared product creates immediate coordination, integration, alignment, and knowledge-transfer overhead for the original team. Multiple teams must work from the same Product Goal, Product Backlog, and Product Owner, and must mutually define and follow the same Definition of Done; consequently, the original team’s short-term productive capacity is likely to decrease.

Keeping existing component teams initially creates less organizational disruption than immediately forming entirely new feature teams. It can give the teams time to learn how Scrum works in their context and reveal how they should reorganize. Component teams do not inherently have all the cross-functional skills needed to deliver a valuable, usable Increment independently, and they typically create cross-team dependencies for end-to-end features.

The Development Team tracks the remaining work in the Sprint Backlog throughout the Sprint so it can manage progress and assess the likelihood of achieving the Sprint Goal. In the current Scrum Guide, this accountability belongs to the Developers, who create and adapt the Sprint Backlog and inspect progress toward the Sprint Goal.

Multiple Scrum Teams working together on a product must jointly define and comply with one shared Definition of Done. This provides a consistent quality standard and transparent, usable product Increment across the teams.

Scrum Teams are cross-functional and self-managing: the people doing the work organize and manage their own work. When a group must be reorganized into multiple teams, enabling the Developers to form the teams supports self-management and avoids functional silos or externally imposed assignments.

The Product Owner is accountable for maximizing the value of the product that results from the Scrum Team’s work.

The Scrum Team is accountable for creating a valuable, useful Increment every Sprint. An Increment must be usable to provide value, so the team should build valuable functionality and create at least one valuable, useful Increment during the first Sprint. Scrum Guide

Multiple Development Teams using one Product Backlog should minimize dependencies between teams, because dependencies increase coordination overhead and can prevent teams from independently delivering a usable Increment.

The Product Owner is one person rather than a committee and is accountable for effective Product Backlog management, including ordering Product Backlog items. The Product Owner may represent many stakeholders and can delegate work, but remains accountable. The Scrum Guide

Developers forecast what is feasible for the Sprint based on their capacity. They can make the Scrum Team aware of the concern, inspect progress after the Sprint begins, and collaborate with the Product Owner to remove or change selected Product Backlog items as more is learned. A Sprint is cancelled only when its Sprint Goal becomes obsolete.

A usable Increment may be delivered before the end of a Sprint, and Scrum does not make the Sprint Review or Sprint end a release gate. The Product Owner determines release timing based on when releasing provides appropriate value and makes sense.

A Scrum Master serves the Scrum Team by facilitating Scrum, coaching participants, and helping remove impediments. A traditional Project Manager generally manages project planning, schedule, scope, budget, and resources, so the roles are distinct.

Scrum requires a usable Increment that meets the Definition of Done at least once every Sprint. It must therefore be available at the end of every Sprint.

Commitment in Scrum is demonstrated through personal effort toward the team’s goals and collaboration that helps other Scrum Team members succeed. A Sprint forecast is a forecast rather than a delivery guarantee, while status reports and working late are not required expressions of the Scrum value of commitment.

A time-box establishes an upper limit on the duration of an event or activity.

The Developers should collaborate with the Product Owner to clarify the requirement and agree on what scope or trade-offs are possible and acceptable. Scrum allows scope to be clarified and renegotiated with the Product Owner as more is learned, while the Product Owner is accountable for ensuring that Product Backlog items are understood clearly enough for the Scrum Team to create value.

Development Teams should self-organize rather than be directed by people outside the team. Allowing existing teams to propose their organization and bringing developers together to self-organize both preserve team autonomy. The Scrum Guide describes Scrum Teams as self-managing, internally deciding who does what, when, and how; the earlier terminology described them as self-organizing.

Scrum relies on self-organizing teams: the people doing the work determine how to organize themselves rather than having teams assigned based on prior working relationships, seniority, or a skills matrix. The current Scrum Guide expresses this as self-managing Scrum Teams that internally decide who does what, when, and how.

The Definition of Done creates transparency by giving everyone a shared understanding of what work was completed as part of an Increment. Developers use it when forecasting how many Product Backlog items they can select, since selected work must be completed to that standard within the Sprint. The Scrum Guide