After-hours work can hide a capacity problem when delivery promises depend on effort beyond the team's agreed availability. To find out, check what the late activity represents, identify work missing from the plan, and ask what would slip if the additional hours stopped.
A late message is a reason to ask a question. It is not enough to conclude that someone worked a longer day. A person may have shifted their schedule, answered one brief request, or taken on substantial work that nobody included in the forecast.
First, check what “after hours” means
Start with the person's agreed schedule for the period, their time zone, and the reporting rule. Check flexible hours, leave, on-call arrangements and any temporary changes before interpreting a pattern.
Software definitions matter. Microsoft Viva Insights, for example, uses configured Outlook working hours to distinguish work hours from after-hours activity, with a default when those settings are absent. That is a reporting convention, not proof that the settings match someone's current arrangement. Microsoft's working-hours definitions
Also check what the measure actually counts. Viva's “active connected hours” adds half-hour blocks containing qualifying activity. A qualifying event in a block does not establish that someone worked continuously for thirty minutes. Likewise, a first event at 7 p.m. and a last event at 9 p.m. do not establish two hours of uninterrupted work. Microsoft's metric definitions
Start with existing task and commitment records. Explain to the team that the review is about whether the plan fits the available time, then ask the people involved to clarify the work and timing. Use relevant activity records to investigate a specific remaining question, keeping confirmed information separate from estimates and unknowns.
| What you establish | What it means for the investigation |
|---|---|
| Two evening hours replaced two earlier hours | A shifted schedule; those hours are not automatically additional effort |
| Work continued after an otherwise unchanged working day | Possible additional effort; confirm what was done and its duration |
| An automated event or scheduled message appears late | The timestamp alone does not establish that a person was working then |
| The schedule or task cannot be established | Keep the case unresolved rather than counting it as extra hours |
Find the commitment behind the activity
Choose a defined period and one team or recurring workstream. A recent week can be a useful starting point, but check whether a release, incident, holiday or other unusual event makes it a poor guide to future demand.
Bring together the original plan, incoming requests, task records and the team's account of work that occurred. Ask:
- Which planned tasks continued into additional hours?
- Which requests arrived after the plan was agreed, and who accepted them?
- What maintenance, checking, troubleshooting or support was missing?
- Which work is still unfinished, even if the visible deadline was met?
An unplanned task can displace planned work without creating extra hours. Additional hours can also be spent on already-planned work whose effort was underestimated. Record both where the task came from and whether it required added availability; these answer different questions.
Keep each item in one place. If support was already included in a fixed allowance, use or revise that allowance rather than adding the same work a second time. For partially finished tasks, retain the remaining work as well as the effort already spent.
Capacity planning considers workload, availability and skills together. Recording an extra task is only the start: someone suitable must also have time to do it before its deadline. Atlassian's capacity-planning guidance
A worked example: the plan says 30 hours, but delivery used 35
The following example is fictional. An operations specialist has 30 hours available for the week's task list, after the team's other agreed commitments. Those other commitments exclude every task listed below.
The original plan assigns 30 hours of task work. During a review, the specialist and manager confirm the following effort from task records and the specialist's account; these are not durations inferred from application timestamps.
| Task category | Hours in the original plan | Confirmed effort during the week |
|---|---|---|
| Planned deliverables, all completed | 30 | 30 |
| Urgent requests accepted during the week | 0 | 3 |
| Troubleshooting an informal reporting tool | 0 | 2 |
| Total | 30 | 35 |
The categories do not overlap. The specialist confirms that the five unplanned hours were additional to the agreed schedule. The 35 − 30 = 5 hours explain how everything was completed despite the missing work in the plan.
Separately, two hours of planned work happened in the evening instead of that afternoon. Those hours are already part of the 30 planned-work hours. Adding them again would incorrectly turn five extra hours into seven.
Finishing the list therefore does not show that another 30-hour list will fit next week while the extra requests and upkeep continue. Nor does one week establish that exactly five hours will recur.
Suppose the team reviews known requests and the tool's support needs, then provisionally plans three hours for requests and two for upkeep next week. With the same 30 task-hours available, that leaves 30 − 3 − 2 = 25 hours for other deliverables. The manager can move five hours of those deliverables, change their scope, or arrange suitable additional capacity. The decision should name the affected work and confirm the revised commitment with whoever expects it.
If the support estimate is uncertain, show a range and revisit it. If only one person can maintain the tool, spare hours elsewhere in the team do not automatically solve that constraint. The team workload guide provides a fuller worksheet for checking assignments and capacity.
Check whether a side project has become a service
An experiment can be useful without being part of the team's delivery promise. The planning problem changes when other people start relying on its output or sending support requests directly to its creator.
Google's SRE book describes a related risk in its own operational setting: readily absorbing work can establish expectations that the team will keep handling it. That observation is a reason to examine an informal commitment, not evidence that every side project causes overload. Google SRE: Eliminating Toil
Before promising continued availability, establish:
- Users and purpose: Who relies on the result, and what happens if it is unavailable?
- Request ownership: Who decides which changes and support requests the team accepts?
- Ongoing work: What testing, maintenance, documentation and support does it require?
- Absence coverage: What happens when its creator is away? Is there a capable backup, or should users expect a pause?
- Planning decision: Will the team allocate time for the work, reduce its scope, or keep it as an experiment without a service commitment?
Someone's willingness to contribute extra time does not establish that another person can cover the same work. Make the support arrangement explicit before building future promises around it.
Change the plan that depends on extra hours
Match the response to what the review established. If the reporting schedule is wrong, correct it before interpreting the pattern. If unplanned requests recur, decide who can accept them and which planned work will move to make room. If planned work took longer than expected, revisit its estimate, scope or deadline. For a service with no backup, agree who will provide support or what users should expect when its owner is away.
A blanket instruction to stop working late leaves the delivery conflict unresolved if all the same promises remain in place. Agree which commitment changes, who will tell the affected stakeholder, and when to check the result.
After the next period, compare completed and unfinished commitments, confirmed additional effort, and any work transferred to other people. Fewer late events alone do not show that the underlying workload fits. The work may have moved, remained unfinished, or happened outside the systems you can see.
A commitment check you can reuse
For each concern, fill in this short record with the people doing the work:
Period and availability: Which dates, schedule and time zone are we reviewing?
Work and evidence: What happened, according to which records and confirmation? Which durations remain estimated or unknown?
Planning gap: Was the work omitted, underestimated, or already allowed for? What remains unfinished?
Dependence on extra hours: What would move or stop without additional availability?
Support: Who accepts new requests and covers the work when its usual owner is away?
Decision and next check: Which commitment changes, who will communicate it, and what will we review next time?
Take one completed record to the next planning conversation. Name the work that will move, the support time that will be reserved, or the schedule assumption that will be corrected. Record who will communicate that change and when the team will check whether it helped.