CSO (Other exams) cheat sheet

Scrum is founded on empiricism: knowledge comes from experience and decisions are made on what is observed; transparency, inspection, and adaptation are the three empirical pillars.

Transparency requires a shared, common standard so inspectors interpret artifacts consistently; without it, inspection produces misleading results and adaptation fails.

Inspection must be frequent enough to detect undesirable variance but not so frequent that it disrupts the work being inspected; the five Scrum events exist to provide cadence.

Adaptation follows inspection: if any aspect deviates outside acceptable limits, the process or product must be adjusted as soon as possible to minimize further deviation.

The five Scrum values are commitment, focus, openness, respect, and courage; they guide behavior and are not a checklist or a scoring metric.

Lean thinking principles embedded in Scrum include eliminating waste, focusing on essentials, self-managing teams, and continuous improvement.

Scrum is intentionally incomplete; it defines only the minimum required to realize the benefits of empiricism and leaves specific practices to the team.

Iterative and incremental delivery reduces risk by producing a usable Increment each Sprint, enabling early feedback and course correction.

A Scrum Team is one cohesive unit of professionals: one Scrum Master, one Product Owner, and Developers; there are no sub-teams or hierarchies.

Recommended size is 10 or fewer people; smaller teams communicate better and are more productive, while larger teams need more coordination overhead.

The Scrum Team is cross-functional, meaning it possesses all skills needed to create value each Sprint, and self-managing, meaning it decides internally who does what, when, and how.

The Product Owner is accountable for maximizing product value, owns Product Backlog management, and is the sole person accountable for backlog ordering; the role may delegate work but not accountability.

The Scrum Master is accountable for the Scrum Team's effectiveness, serves the team and organization, and is a true leader who serves rather than a project manager or people manager.

Developers are accountable for creating a plan for the Sprint (Sprint Backlog), instilling quality via the Definition of Done, adapting the plan daily, and holding each other accountable.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint; accountability for the Increment is collective, not delegated to one sub-role.

Role switching within a Sprint is discouraged; a Product Owner should not also act as a Developer mid-Sprint because it blurs accountability and inspection.

The Sprint is the container for all other events and has a fixed length of one month or less; a new Sprint starts immediately after the previous one ends.

Sprint Planning initiates the Sprint by establishing the Sprint Goal, what can be done, and how the work will get done; it is timeboxed to eight hours maximum for a one-month Sprint.

The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; it is not a status report to management.

Sprint Review inspects the Sprint outcome with stakeholders and determines future adaptations; it is timeboxed to four hours for a one-month Sprint and is a working session, not a presentation.

The Sprint Retrospective plans ways to increase quality and effectiveness; it is timeboxed to three hours for a one-month Sprint and closes the Sprint.

Shorter Sprints generally reduce risk and generate more frequent feedback; timebox durations scale proportionally for Sprints shorter than one month.

The Sprint Goal is created during Sprint Planning and is the single objective for the Sprint; it is a commitment of the Sprint Backlog and provides flexibility on scope.

Canceling a Sprint is rare and only the Product Owner may do so; if canceled, completed and potentially releasable work is reviewed and the remainder returns to the Product Backlog.

The Product Backlog is an emergent, ordered list of what is needed to improve the product; the Product Owner is accountable for its content and ordering.

The Product Goal is the commitment of the Product Backlog; it describes a future state of the product and serves as a target for the Scrum Team to plan against.

The Sprint Backlog is composed of the Sprint Goal, the selected Product Backlog items, and the actionable plan to deliver them; it is a highly visible real-time picture of Developers' work.

The Sprint Goal is the commitment of the Sprint Backlog; it gives focus and flexibility, and Developers adapt the Sprint Backlog as more is learned.

The Increment is a concrete stepping stone toward the Product Goal; each Increment is additive to prior Increments and must be usable to be considered complete.

The Definition of Done is the commitment of the Increment; it is a formal description of the state of the Increment when it meets the quality measures required for the product.

If an item does not meet the Definition of Done, it cannot be released or presented at Sprint Review and returns to the Product Backlog for future consideration.

Multiple Scrum Teams on one product share the same Product Backlog, Product Owner, Product Goal, and Definition of Done, and produce one integrated Increment.

Servant leadership inverts the pyramid: the leader's job is to remove obstacles and enable the team's success, not to direct tasks or assign work.

Facilitation means designing and guiding group processes so the group owns the outcome; the facilitator remains neutral on content and responsible for process.

Effective facilitation uses a clear purpose, agreed agenda, timeboxes, and visible artifacts (e.g., whiteboard, sticky notes) so all voices can contribute.

Techniques for inclusive decisions include fist-of-five, dot voting, roman voting, and silent writing before discussion to reduce anchoring and groupthink.

Liberating structures and structured formats (round-robin, 1-2-4-all) increase participation and reduce dominance by the most vocal participants.

Retrospective facilitation commonly uses formats such as Start-Stop-Continue, Mad-Sad-Glad, or 4Ls; the format is a tool and can be changed per Sprint.

The Scrum Master facilitates Scrum events as requested or needed; facilitation is a service to the team, not a mandate to control the conversation.

A facilitator should surface conflict and divergence rather than suppress it, then converge using explicit decision rules recorded in the meeting output.

Coaching is non-directive: it uses questions, reflection, and goal-setting to help the coachee find their own answers; mentoring is directive and shares experience and advice.

The GROW model sequences a coaching conversation: Goal, Reality, Options, Will (or Way forward).

Powerful questions are open-ended, short, and free of embedded advice; they start with what or how rather than why, which can trigger defensiveness.

The coaching stance requires active listening, paraphrasing, summarizing, and reflecting back to raise the coachee's self-awareness.

Teams move through stages such as forming, storming, norming, performing, and adjourning; coaching style should shift with the stage and the team's maturity.

A coaching agreement sets the topic, the desired outcome, the session boundaries, and confidentiality before the conversation begins.

Feedback is most useful when specific, behavioral, timely, and focused on observed facts and impact rather than on personality judgments.

The Scrum Master coaches the team in self-management and cross-functionality, and coaches the organization in adopting Scrum empirically.

An impediment is anything blocking the team's progress toward the Sprint Goal; the Scrum Master's accountability includes resolving or escalating them.

Impediments should be made visible (e.g., an impediment board or backlog) and tracked with an owner, an age, and a status so they do not silently persist.

Distinguish impediments (blockers to flow) from improvements (systemic changes) and from problems that the team can resolve itself.

Root-cause analysis tools include the 5 Whys, fishbone (Ishikawa) diagrams, and cause-and-effect mapping; use them to move from symptom to system.

Improvement experiments should be small, timeboxed, and measurable, with an explicit hypothesis and a review date to confirm the effect.

Value stream mapping and cycle-time or lead-time metrics reveal where work waits; queues and handoffs are common sources of delay.

Escalation is a service, not a failure: the Scrum Master removes organizational impediments by influencing policy, structure, and management behavior.

Continuous improvement in Scrum is planned at the Retrospective and executed during the next Sprint; improvements not acted on are not improvements.

A Nexus is a scaling framework for 3 to 9 Scrum Teams working on one product; it adds a Nexus Integration Team accountable for integrated Increments.

Scrum@Scale uses a Scrum of Scrums and a MetaScrum to coordinate many teams while preserving the core Scrum framework.

Large-Scale Scrum (LeSS) applies one Product Owner, one Product Backlog, and one Definition of Done across many teams on one product, with feature teams.

The Scrum of Scrums is a coordination event where delegates from teams synchronize dependencies and integration; it does not replace team-level Daily Scrums.

Scaling frameworks are patterns, not mandates; the underlying principle is to scale Scrum without losing empiricism, self-management, and single-product focus.

Organizational agility requires structural change: funding models, HR policies, and governance must support teams rather than force project-based control.

Dependencies between teams are a primary scaling cost; reduce them by reorganizing teams around value and by increasing technical integration frequency.

A scaled product needs one integrated Increment; separate team increments that are never integrated do not deliver value and hide risk.