How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

9.6 Update Sprint Backlog

9.6 Update Sprint Backlog
Inputs Tools Outputs

Bold ITTOs are mandatory.

A continuous Scrum activity where the Developers revise task details, remaining work, and discovered tasks so the Sprint Backlog stays accurate and aligned to the Sprint Goal.

Purpose & When to Use

The goal of updating the Sprint Backlog is to keep the team's plan current, transparent, and achievable so the Sprint Goal remains realistic. It reflects real progress, new insights, and capacity changes as the Sprint unfolds.

  • Maintain a single source of truth for the Sprint plan.
  • Expose risks, blockers, and capacity shifts early.
  • Capture newly discovered work needed to meet acceptance criteria and Definition of Done.
  • Keep the Sprint Burndown and task board accurate for forecasting.

Use this process throughout the Sprint—before and after the Daily Standup, whenever work is completed, estimates change, tasks are split/added/removed, or impediments appear.

Mini Flow (How It’s Done)

  • Inputs: Sprint Goal, selected Product Backlog Items (PBIs) with acceptance criteria, Definition of Done, current impediments, team capacity.
  • 1) Review current state: pull latest task board and remaining work figures.
  • 2) Update tasks: mark done/in-progress, adjust remaining hours, and note owners or pairs.
  • 3) Add/split/remove tasks: capture newly discovered work required to complete selected PBIs; remove obsolete tasks.
  • 4) Flag blockers: tag blocked tasks and log issues in the Impediment Log; identify help needed.
  • 5) Re-estimate and check capacity: reconcile remaining work versus available time; rebalance work within the team.
  • 6) Validate Sprint Goal alignment: if at risk, discuss trade-offs; negotiate any PBI changes with the Product Owner.
  • 7) Refresh radiators: update Sprint Burndown and task board for full transparency.
  • Roles: Developers own and update the Sprint Backlog; Scrum Master coaches on process and removes impediments; Product Owner is consulted on scope or PBI swaps.

Quality & Acceptance Checklist

  • Every selected PBI has tasks that cover build, test, integration, and any compliance/docs needed to meet Definition of Done.
  • Tasks are small and testable (ideally 1 day or less); oversized tasks are split.
  • Each task shows remaining effort (not just hours spent or percent complete).
  • Blocked items are clearly flagged with the blocker cause recorded.
  • Dependencies and external handoffs are visible and owned.
  • Changes that affect scope or Sprint Goal are discussed with the Product Owner before committing.
  • Burndown and task board reflect current reality by end of day.
  • Non-functional and testing work is included, not assumed.
  • Ownership is clear (individual or pair) and WIP limits are respected if used.

Common Mistakes & Exam Traps

  • Treating the Sprint Backlog as static; it should evolve daily.
  • Tracking effort spent instead of remaining effort—forecasts require remaining work.
  • Silently adding new PBIs mid-sprint without Product Owner agreement; tasks can change, PBI scope needs PO involvement.
  • Skipping test/QA/refactoring tasks, causing “done” to miss the Definition of Done.
  • Keeping large, vague tasks that mask risk; split them to expose reality.
  • Using percentage complete to look good on burndown; it hides real progress.
  • Confusing Product Backlog (product-wide, ordered by PO) with Sprint Backlog (developers’ plan for the Sprint).
  • Treating the Daily Standup as status reporting to the Scrum Master; it is for the team to plan the next 24 hours and update the Sprint Backlog.

PMP/SCRUM Example Question

During a Sprint, the team discovers additional testing tasks required to meet the Definition of Done for a selected PBI. What should they do next?

  1. Add the tasks to the Product Backlog and defer them to a future Sprint.
  2. Add the tasks to the Sprint Backlog, re-estimate remaining work, and assess impact on the Sprint Goal.
  3. Escalate to the Scrum Master to get approval before changing the Sprint Backlog.
  4. Ask stakeholders for permission to extend the Sprint by one day to complete the tasks.

Correct answer: B. Developers own the Sprint Backlog and should add necessary tasks, update remaining effort, and check capacity; if the Sprint Goal is threatened, they collaborate with the Product Owner on options.

ICS/OT Cybersecurity Fundamentals — Security Built for Industrial Systems

Industrial control systems cannot be secured like ordinary IT. A forced reboot, aggressive scan, or incompatible patch can interrupt production and create real safety consequences. Effective OT security begins with understanding the systems, constraints, and risks unique to industrial environments.

This course gives IT professionals, engineers, operators, and security practitioners a practical foundation in ICS threats, zone and conduit design, risk assessment, passive asset visibility, and vendor evaluation. You will learn how IEC 62443, NIST CSF, and MITRE ATT&CK for ICS apply where availability and safety come first.

Eight reconstructed incidents—including Stuxnet, Triton, Ukraine 2015, Colonial Pipeline, and PIPEDREAM—show how attackers move through OT environments, what they target, and which defenses could have changed the outcome.

Watch the course preview, then build the vocabulary, frameworks, and judgment needed to take credible first steps in ICS/OT cybersecurity.

Explore the Course


ICS/OT Cybersecurity Fundamentals course preview

Build an ICS/OT cybersecurity foundation that fits the real environment

Standard IT controls can disrupt the industrial systems they are meant to protect. Learn how to assess OT risk, design zones and conduits, apply IEC 62443 security levels, use MITRE ATT&CK for ICS, and establish passive asset visibility without risking production. Eight reconstructed incidents connect attacker techniques to the controls that failed, giving you the vocabulary and judgment to make credible security decisions from day one.

Explore the Course