Do you track all work in the sprint?

As a consultant, transparency with the client is essential — they are paying for the work and need full visibility over what is being delivered. The Scrum Board is the source of truth for sprint work, but it only serves that purpose if everything is tracked there.

The client approves work in two ways:

• Sprint Planning — PBIs are selected from the backlog and committed to for the sprint
• Mid-sprint approval — the client explicitly approves additional work after the sprint has started

Any work done outside of these approvals is work the client hasn't signed off on, which can erode trust and cause billing disputes.

The three categories of sprint work

All work during a sprint should fall into one of these categories:

1. Work attached to a PBI The most common case. A PR implements a Product Backlog Item and is linked directly to it.

2. Work attached to a sub-task of a PBI Large PBIs are often broken into smaller tasks. Work should link to the sub-task, which in turn traces back to the parent PBI.

3. Housekeeping chores Small maintenance tasks that arise during the sprint, such as:

• Fixing a broken build
• Updating a package
• Small tweaks to AGENTS.md or other configuration files

These are typically small enough that they don't need an estimate or prior approval. In GitHub, they can be managed solely via a PR linked directly to the Scrum Board, giving the client visibility without the overhead of creating a PBI.

Good and bad examples

❌ Figure: Bad example - Housekeeping PRs with no board visibility

✅ Figure: Good example - Housekeeping PRs linked to the Scrum Board — visible to the client without a dedicated PBI

❌ Figure: Bad example - Feature work completed via an unlinked PR — PBI progress not reflected on the board

✅ Figure: Good example - Feature work linked to its PBI — board reflects actual sprint progress

See Do you link commits, branches, and PRs to a PBI? for the mechanics of how to link work items in GitHub and Azure DevOps.