PECB Certified PSM Basic flashcards
PECB Certified PSM Basic · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Empirical process control
- A management approach in which decisions are based on observation, experience, and experimentation rather than on detailed upfront prediction, appropriate when requirements and technology are uncertain.
- Three pillars of Scrum
- Transparency, inspection, and adaptation. Transparency makes work visible, inspection examines it frequently, and adaptation adjusts process or product when deviation is detected.
- Transparency
- The emergent process and work must be visible to those performing it and those receiving it, using a shared definition of done so observers interpret the work consistently.
- Inspection
- Frequent examination of Scrum artifacts and progress toward agreed goals to detect undesirable variances; it should be frequent enough to catch deviation without disrupting work.
- Adaptation
- The adjustment of process or product when inspection reveals that one or more aspects fall outside acceptable limits, performed as soon as possible to minimize further deviation.
- Scrum values
- Commitment, focus, openness, respect, and courage. They shape behavior and decisions and give direction on how the team works together.
- Iterative and incremental
- Iterative development refines a product through repeated cycles; incremental development adds finished, usable pieces. Scrum uses both to build value and receive early feedback.
- Scrum Team composition
- One self-managing team of ten or fewer people with three accountabilities: Product Owner, Scrum Master, and Developers, with no sub-teams or hierarchy inside it.
- Product Owner accountability
- Accountable for maximizing product value and managing the Product Backlog, including ordering items and communicating the Product Goal; may delegate work but not accountability.
- Developers accountability
- Accountable for creating the Increment each Sprint, turning backlog items into value, self-managing their work, and instilling quality through adherence to the Definition of Done.
- Scrum Master accountability
- Accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness, serving the team, the Product Owner, and the organization.
- The Sprint
- A fixed-length event of one month or less that acts as a container for all other events, producing a usable and potentially releasable Increment each cycle.
- Sprint Planning
- The event that opens the Sprint, addressing why the Sprint is valuable (Sprint Goal), what can be done, and how the work will be accomplished; timeboxed to eight hours for a one-month Sprint.
- Daily Scrum
- A 15-minute event for Developers, held at the same time and place each working day, to inspect progress toward the Sprint Goal and adapt the Sprint Backlog.
- Sprint Review
- An event near the end of the Sprint where the team and stakeholders inspect the Increment and outcome, and collaborate on what to do next; timeboxed to four hours for a one-month Sprint.
- Sprint Retrospective
- The closing event where the team inspects how the last Sprint went regarding individuals, interactions, processes, and tools, and identifies improvements; three hours or less for a one-month Sprint.
- Product Goal
- A long-term target for the Scrum Team describing a future state of the product; it is the commitment attached to the Product Backlog and guides what to build.
- Sprint Goal
- A single objective for the Sprint, created during Sprint Planning, that provides coherence and focus; it is the commitment attached to the Sprint Backlog.
- Definition of Done
- A formal description of the state of the Increment when it meets the quality measures required for the product; the commitment attached to the Increment.
- Servant leadership
- A leadership stance whose primary aim is the growth, well-being, and effectiveness of the people served, achieved by removing obstacles and enabling others rather than directing them.
- Scrum Master as coach
- A stance where the Scrum Master asks questions that help the team find its own options, keeping ownership with the team rather than supplying solutions.
- Impediment removal
- Identifying obstacles to progress and helping resolve them; team-resolvable blockers stay with the team, organizational blockers are escalated with evidence rather than blame.
- Teaching versus coaching
- Teaching transfers Scrum knowledge and rules the team lacks; coaching draws out the team's own solutions. The Scrum Master selects the stance the situation requires.
- Facilitation stance
- Designing and guiding events so the group reaches its own decisions and outcomes, while the Scrum Master stays neutral on content and keeps the event within its timebox.
- Scrum Master and authority
- The Scrum Master leads by influence, not command: no task assignment, no control over Developers' technical choices, and no line-management authority over the team.
- Serving the organization
- The Scrum Master leads, trains, and coaches the organization in Scrum adoption, plans and advises implementations, and helps remove barriers between stakeholders and teams.
- Backlog refinement
- The ongoing activity of breaking down and clarifying Product Backlog items into smaller, more precise items that can be completed within a Sprint; not a formal Scrum event.
- Velocity
- A planning indicator derived from the amount of work completed in past Sprints; it is a forecast aid, never a target or individual performance measure.
- Relative estimation
- Sizing backlog items by comparison with known reference items rather than absolute time, performed by the people who will do the work.
- Sprint cancellation
- A rare action available only to the Product Owner when the Sprint Goal becomes obsolete; completed items are reviewed and the remaining backlog is re-planned.
- Definition of Done tightening
- Raising the quality bar over time as the team's capability grows; every Increment must meet the current definition, and no item counts as done until it does.
- Scaling prerequisite
- Before adding coordination structures, ensure single teams function well, share one Product Backlog, and apply a common Definition of Done across teams.