Scrum Management Training Course

Participants can define a product direction and Product Goal that guides backlog decisions.

• Product vision statements framed around users, needs and outcomes
• Product Goal defined as a measurable long-term delivery objective
• Outcome measures distinguished from outputs, activities and utilisation metrics
• Impact mapping connects business objectives, actors and product changes
• Value hypotheses tested through assumptions, measures and learning cycles
• Stakeholder needs reconciled using explicit product decision criteria

Participants can build and order a Product Backlog around value, risk and learning.

• Product Backlog attributes: description, order, size and clarity
• Backlog items shaped as features, defects, risks and discovery work
• Cost of Delay compares urgency, value and time criticality
• WSJF prioritisation uses weighted cost of delay and job size
• Risk reduction and opportunity enablement included in ordering decisions
• Backlog ordering records rationale, assumptions and stakeholder trade-offs

Participants can write testable backlog items that support shared delivery understanding.

• User story format links user, need and intended benefit
• INVEST criteria assess backlog item quality before Sprint selection
• Acceptance criteria define observable conditions for completed work
• Given-When-Then scenarios express behaviour and business rules
• Story splitting patterns reduce scope without losing user value
• Non-functional requirements expressed through measurable quality attributes

Participants can run backlog refinement that prepares valuable work for Sprint Planning.

• Refinement cadence planned as continuous collaborative backlog work
• Three Amigos conversations align product, delivery and quality perspectives
• Definition of Ready used cautiously as a refinement aid
• Dependencies identified before selection through upstream and downstream mapping
• Spikes timebox research where uncertainty prevents sensible estimation
• Refined items retain traceability to Product Goal and outcomes

Participants can estimate work and produce evidence-based delivery forecasts.

• Relative estimation compares effort, complexity, uncertainty and risk
• Planning Poker exposes assumptions before estimates become commitments
• Affinity estimation rapidly groups large backlogs into relative sizes
• Team capacity accounts for availability, skills and planned absences
• Velocity ranges support forecasts without treating averages as guarantees
• Monte Carlo forecasting models probable completion dates from throughput

Participants can facilitate Sprint Planning that creates a coherent Sprint forecast.

• Sprint Planning addresses why, what and how collaboratively
• Sprint Goals express a single valuable objective for the Sprint
• Selected backlog items tested against capacity and Definition of Done
• Sprint Backlog combines selected work, plan and emergent adjustments
• Technical tasks created by Developers without replacing backlog items
• Scope renegotiated with the Product Owner when conditions change

Participants can use the Daily Scrum to inspect progress and improve flow.

• Daily Scrum focuses on progress toward the Sprint Goal
• Work visualisation makes blocked, waiting and in-progress items visible
• Work-in-progress limits expose bottlenecks and reduce multitasking
• Cumulative flow diagrams reveal queue growth and unstable flow
• Cycle time measures elapsed time from work start to completion
• Developers adapt the daily plan using current delivery evidence

Participants can establish a Definition of Done that protects quality and usability.

• Definition of Done specifies the quality required for usable increments
• Increment quality includes testing, documentation, security and operational readiness
• Technical debt made visible through backlog items and quality indicators
• Quality gates distinguished from team-owned completion criteria
• Regression testing protects existing capability during incremental delivery
• Release readiness assessed from completed increments rather than percentage progress

Participants can conduct Sprint Reviews that inform product and backlog decisions.

• Sprint Review inspects outcomes, market conditions and stakeholder feedback
• Completed increments demonstrated against acceptance criteria and Product Goal
• Stakeholder feedback captured as evidence rather than informal approval
• Product Backlog adapted after reviewing value, risk and opportunities
• Release decisions consider usable increments, readiness and business timing
• Review participants discuss progress using transparent product measures

Participants can facilitate retrospectives that produce focused, owned improvement actions.

• Sprint Retrospective examines people, interactions, process and tools
• Start-Stop-Continue identifies behaviours to change or reinforce
• Five Whys traces recurring delivery problems to contributing causes
• Fishbone analysis groups causes across methods, people and systems
• Improvement experiments define hypothesis, owner, measure and review date
• Retrospective actions enter the Sprint Backlog when work is required

Participants can support Scrum effectiveness through facilitation, coaching and impediment management.

• Scrum Master service to team, Product Owner and organisation
• Facilitation techniques separate participation, decision-making and meeting administration
• Impediment logs distinguish symptoms, causes, owners and escalation paths
• Servant leadership supports accountability without directing technical solutions
• Coaching questions help teams inspect assumptions and choose actions
• Organisational impediments escalated using evidence of product and flow impact

Participants can clarify Product Owner authority and stakeholder decision rights.

• Product Owner accountability for value and Product Backlog ordering
• Decision rights mapped using RAPID for significant product choices
• Stakeholder mapping identifies influence, interest and required engagement
• Product discovery separates problem validation from solution delivery
• Minimum viable product scope tests value with minimum sufficient capability
• Escalation paths protect timely decisions where authority is unclear

Participants can select and communicate delivery measures that support informed decisions.

• Evidence-Based Management connects current value, unrealised value and ability
• Sprint burndown charts show remaining work, not product value
• Burnup charts separate completed scope from changing total scope
• Throughput and cycle time support probabilistic delivery forecasts
• Escaped defects and rework indicate quality performance after release
• Metric narratives explain decisions, constraints, trends and required actions

Participants can manage cross-team dependencies and delivery risks while preserving Scrum accountabilities.

• Dependency mapping identifies prerequisite work, handoffs and shared services
• RAID logs capture risks, assumptions, issues and dependency ownership
• Integration planning aligns interfaces, test environments and release windows
• Cross-team Sprint Goals coordinate outcomes without central task assignment
• Communities of practice improve shared standards and technical consistency
• Risk-based backlog ordering addresses uncertainty before deadlines constrain options

Participants can choose proportionate coordination and governance approaches for larger initiatives.

• Nexus framework coordinates integrated work across multiple Scrum Teams
• Scrum of Scrums addresses cross-team impediments and integration decisions
• Scaled Agile Framework distinguished from Scrum accountabilities and events
• Hybrid governance combines Scrum delivery evidence with portfolio controls
• Stage gates retained only where regulatory, funding or risk decisions require
• PMO reporting designed around outcomes, forecasts, risks and dependencies

Participants can plan a practical Scrum adoption that addresses behaviour, structure and governance.

• Agile maturity assessments identify specific adoption constraints and priorities
• Change impact analysis maps role, process, policy and system effects
• Pilot selection considers product boundaries, leadership support and learning value
• Training plans distinguish framework knowledge from role-specific working practices
• Adoption measures track behaviour change, flow improvement and product outcomes
• Resistance addressed through listening, evidence and explicit decision-making

Participants can build, review and present a complete Scrum delivery pack for a defined initiative.

• Product Goal and outcome measures consolidated into a delivery brief
• Ordered Product Backlog includes stories, acceptance criteria and dependencies
• Release forecast combines capacity assumptions, throughput data and uncertainty
• Sprint plan defines Sprint Goal, selected items and completion criteria
• Metrics dashboard presents flow, quality, value and delivery risks
• Stakeholder review tests decisions, governance needs and improvement actions