PSM I flashcards

Understanding and Applying the Scrum Framework

• Scrum is a lightweight, purposefully incomplete framework for generating value through adaptive solutions to complex problems; its rules guide relationships and interactions, not detailed tasks.
• Scrum is founded on empiricism (knowledge from experience, decisions on what is observed) and lean thinking (reduce waste, focus on the essentials).
• The iterative, incremental approach optimizes predictability and controls risk: each Sprint gives real data and exposes wrong assumptions early.
• The pillars are transparency, inspection and adaptation; transparency enables inspection and inspection enables adaptation.
• Inspection without transparency is misleading and wasteful; inspection without adaptation is pointless.
• Adapt as soon as possible, the moment something new is learned; adaptation is harder when people are not empowered or self-managing.
• The five Scrum Values are commitment, focus, openness, respect and courage; transparency, trust and collaboration are not among them.
• When the team and the people it works with live the values, the pillars come to life and build trust; decisions should reinforce the values, never undermine them.
• Scrum is immutable and exists only in its entirety, but it works well as a container for other practices; Scrum's groups hold skills collectively and share or acquire them as needed.

• A Scrum Team is one Scrum Master, one Product Owner and Developers: one cohesive unit, no sub-teams, no hierarchies, one Product Goal at a time.
• Teams are typically 10 or fewer people; a team that grows too large reorganizes into several cohesive teams that share one Product Goal, Product Backlog and Product Owner.
• Cross-functional means the team together has every skill needed to create value each Sprint, so a Done Increment never waits on an outside group.
• The entire Scrum Team is accountable for a valuable, useful Increment every Sprint and is responsible for all product-related activities, from stakeholder collaboration to operation and R&D.
• Developers are everyone in the team creating any part of the Increment; they own the Sprint plan, build quality in through the Definition of Done, adapt daily and hold each other accountable.
• The Product Owner is accountable for maximizing value and for Product Backlog management; the work can be delegated, the accountability cannot.
• The Product Owner is one person, not a committee; others change the Product Backlog by convincing the Product Owner, and the organization respects those decisions.
• The Scrum Master is accountable for establishing Scrum and for the team's effectiveness, improving practices within the framework, as a true leader who serves.
• The Scrum Master coaches, facilitates and causes impediments to be removed; the Scrum Master never assigns work, orders the backlog or inspects quality for the team.

• The Sprint is fixed length, one month or less, contains all other events, and the next Sprint starts immediately; it neither extends nor ends early.
• During a Sprint the Sprint Goal is protected and quality does not decrease, while scope may be renegotiated with the Product Owner and the Product Backlog refined.
• Only the Product Owner can cancel a Sprint, and only when the Sprint Goal has become obsolete.
• Timeboxes are maximums: 8 h Planning, 4 h Review, 3 h Retrospective for a one-month Sprint (usually less for shorter ones) and 15 minutes for the Daily Scrum; an event ends when its purpose is met.
• Sprint Planning answers why, what and how; the whole team defines the Sprint Goal before Planning ends, the Developers select items with the Product Owner, and how the work is done is solely the Developers' call.
• Past performance, upcoming capacity and the Definition of Done make the Developers' forecast more confident.
• The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; its structure is theirs, and it is not the only time they re-plan.
• The Sprint Review is a working session with stakeholders on what to do next, never a release gate; it inspects the sum of the Sprint's Increments.
• The Retrospective inspects individuals, interactions, processes, tools and the Definition of Done, addresses the most impactful improvements as soon as possible, and concludes the Sprint.

• Each artifact contains one commitment: Product Backlog with the Product Goal, Sprint Backlog with the Sprint Goal, Increment with the Definition of Done.
• Artifacts represent work or value and maximize transparency; commitments add focus against which progress is measured and reinforce empiricism and the Scrum Values.
• The Product Backlog is an emergent, ordered list of what is needed to improve the product and the single source of work; one product has one Product Backlog.
• Refinement is ongoing and adds description, order and size; the Developers who will do the work size items; an item is ready when it can be Done within one Sprint.
• The Product Goal is a future state of the product in the Product Backlog; the team fulfills or abandons one before taking on the next.
• The Sprint Backlog is the Sprint Goal (why), selected items (what) and a plan (how), by and for the Developers, updated throughout the Sprint.
• The Sprint Goal is the single objective for the Sprint, a commitment by the Developers that leaves flexibility in the exact work and creates coherence.
• An Increment is additive, verified to work with all prior Increments and usable; it is born when an item meets the Definition of Done, and several can be created in a Sprint.
• Work that does not meet the Definition of Done cannot be released or presented at the Sprint Review; it returns to the Product Backlog.
• An organizational Definition of Done is a minimum; otherwise the Scrum Team creates one; teams on one product share one; it is inspected at the Sprint Retrospective.

Developing People and Teams

• A self-managing Scrum Team decides internally who does what, when and how; it is also cross-functional, so it has the skills to act on those decisions.
• The 2020 Scrum Guide moved from a self-organizing Development Team (who and how) to a self-managing Scrum Team (who, how and what).
• There are no sub-teams or hierarchies in a Scrum Team: no member, however senior or however chosen, has the final say over the others' work.
• The Developers decide how to turn items into a Done Increment, who works on what, how they track work and how they run the Daily Scrum.
• The Developers who do the work size it and select Sprint items through discussion with the Product Owner; the Product Owner influences by explaining trade-offs.
• Developers hold each other accountable as professionals and raise problems that threaten the Sprint Goal straight away.
• Self-management stays inside Scrum: the Product Owner orders the Product Backlog, the Definition of Done is met in full, the Sprint Goal is not endangered and the Sprint is not extended.
• Scope is renegotiated with the Product Owner when work turns out bigger than forecast or new work is requested mid-Sprint.
• The Scrum Master coaches self-management and cross-functionality and facilitates decisions rather than making or assigning them.
• Organizations structure and empower Scrum Teams to manage their own work, and the Scrum Team identifies its own improvements.

• A facilitator owns the process; the group owns the outcome and the decisions.
• The Scrum Master ensures events take place and are positive, productive and timeboxed; the Scrum Guide names no required facilitator, so events go ahead without the Scrum Master.
• The Daily Scrum is the Developers' planning event; a Scrum Master collecting status updates turns it into a report, even inside 15 minutes.
• The Sprint Review is a working session, and new requests go to the Product Owner; the Scrum Team chooses its own Retrospective improvements within the timebox.
• Missing knowledge: teach. Knowledge present but stuck: coach. Mentors share experience; facilitators guide a group's process.
• Coaching self-management means handing decisions back: answer with questions, surface risks, let the team try reversible ideas and inspect the result.
• Facilitate conflicts the team can resolve; take causes beyond its control to people who can act.
• Serve the Product Owner and the organization by building their capability and removing barriers, never by taking their accountability or becoming a new go-between.

Managing Products with Agility

• The Product Owner is accountable for maximizing product value; the Scrum Guide does not prescribe how.
• Value is evidenced by outcomes for users, customers and the organization, not by output such as velocity, Done-item counts or plan conformance.
• EBM's four key value areas are Current Value, Unrealized Value, Time to Market and Ability to Innovate; lead time and satisfaction are measures inside them.
• Value depends on context: revenue for some products, mission or citizen outcomes for others, employee outcomes for internal tools.
• Stakeholders are outside the Scrum Team; customers (who buy or adopt) and users (who use) are both stakeholders and can disagree.
• One Product Owner represents many stakeholders; others change the Product Backlog by convincing the Product Owner, whose decisions are visible in its content and order.
• At the Sprint Review, stakeholders and the Scrum Team review results and changes in the environment and collaborate on what to do next; it is not an approval gate.
• The Sprint Goal communicates why the Sprint is valuable to stakeholders; invited advisors at Sprint Planning give advice but decide nothing.
• Developers may talk to users directly; what they learn goes to the Product Owner, who decides ordering.
• Expected value is a hypothesis: release small and early, measure the targeted outcome, and adapt the Product Backlog.

• The Product Backlog is an emergent, ordered list of what is needed to improve the product and the single source of work for the Scrum Team; the Product Goal is in it.
• The Product Owner is accountable for the Product Goal, the items, their order and keeping the backlog transparent, visible and understood: one shared, current backlog, visible to stakeholders, in language its readers understand. Anyone wanting a change convinces the Product Owner.
• No ordering technique is prescribed: value, risk, dependencies and learning can all shape the order, and every item has its own place rather than a shared priority label.
• Refinement is an ongoing activity, not an event: no timebox, no 10% rule since the 2020 Guide, and it happens inside each Sprint with the Developers involved.
• Detail grows as items approach selection; the Developers who will do the work size it, using whatever technique they choose.
• An item is ready when it can be Done within one Sprint; split large items into thin end-to-end slices, not layers or activities. User stories and a Definition of Ready are optional.
• Technical debt, experiments and side requests become visible Product Backlog items; qualities for every Increment belong in the Definition of Done.
• The Product Owner can change the Product Backlog whenever a change is useful; that does not change the current Sprint Backlog, and teams on one product share one Product Backlog and refine together.

• Only what has already happened, mainly Done work from past Sprints, may inform forward-looking decisions; upfront estimates and targets are not evidence.
• Sprints enable predictability by inspecting and adapting progress toward the Product Goal at least every calendar month; their fixed length creates the consistency that keeps Sprints comparable.
• Burn-downs, burn-ups and cumulative flows are optional practices that do not replace empiricism; the 2020 Guide removed the 2017 rules for tracking total work remaining.
• Velocity is not in the Guide: it is team-specific, not comparable across teams, and inflated when made a target.
• Only work meeting the Definition of Done is part of an Increment; there is no partial credit, and counting undone work makes forecasts overstate progress.
• An Increment may be released before the Sprint ends, several Increments may be created per Sprint, and the Sprint Review is never a gate to releasing value.
• Done means usable and releasable, not released; when to release is a value decision within the Product Owner's accountability, which can be delegated while the Product Owner stays accountable.
• Scrum has no release planning event, release or hardening Sprint, or Sprint 0; needing a stabilization Sprint means the Definition of Done is not sufficient.
• With a fixed date, flex scope by ordering for value and make the gap transparent early; never relax the Definition of Done or stretch Sprints.
• A forecast is a range revised every Sprint, not a commitment; several teams on one product forecast from one Product Backlog and count only integrated work meeting a shared Definition of Done.

Yes — the whole PSM I deck is free and needs no account, as is every PSM I revision lesson. Create a free account to save progress and drill practice questions; full-length mock exams are a one-time unlock per certification.