Dealing with "Shadow Work" in Jira: How do you report on unestimated mid-sprint chaos?

[Max Brüssow]

Hi everyone,

Having worked as a Scrum Master and developer for many years, I rely heavily on time estimations and time-tracking for sprint planning and progress reporting.

Over time, I’ve consistently faced a reporting dilemma with Jira's standard Burndown Chart:

In a typical sprint, we see the Original Estimate line go down, while Time Spent climbs. In reality, Time Spent often shoots far past the original estimate, while the estimate line rarely hits zero because planned scope was left unfinished.

The core issue: The burndown line only jumps upward when estimated tickets are added mid-sprint. However, the majority of unplanned work consists of urgent bugs, ad-hoc support, or small operational requests that are added without an estimate (or with 0h).

A classic example from one of my past sprints (see image above):

• Planned scope started around 270h, but ~80h remained incomplete at sprint end.

• Notice specifically the second week (starting around July 1st): While the remaining estimate line almost stagnates, the Time Spent curve spikes massively all the way up to over 350h.

• In this specific case, that divergence was caused entirely by incoming unestimated tasks, urgent operational requests, and support items that absorbed the team's capacity without moving the planned burndown.

• To an outside stakeholder looking just at remaining estimates, it looks like a missed commitment — while in reality, the team delivered ~350 hours of pure output, mostly absorbed by untracked shadow work.

What I define as "Shadow Work":

By Shadow Work, I mean all the invisible, unestimated tasks and mid-sprint additions that consume real development hours, silently destroy sprint goals, but leave almost no trace in standard burndown analytics.

The Workarounds I've Tried

When planning sprints, I include capacity buffers per person depending on their role. But tracking and isolating where that buffer actually went afterwards remains difficult:

1. Custom JQL Queries: Filters like created > SprintStartDate AND (originalEstimate is EMPTY OR originalEstimate = 0) help catch newly created items, but they completely miss existing backlog tickets dragged into an active sprint (as standard JQL lacks a clean timestamp for sprint assignment).

2. External Spreadsheets (Excel/Sheets): I ended up building spreadsheets that pulled Jira data directly via API/exports. While it gave me the numbers, maintaining external sheets created unnecessary overhead, and constantly jumping between Jira and Excel just to run a retrospective feels disconnected and inefficient.

Analyzing these tickets inside our primary workspace is critical, as they are usually the exact reason a sprint misses its commitment.

My Questions to the Community:

1. How do your teams isolate and visualize unestimated/unplanned work vs. original commitment?

2. Do you rely on custom dashboards/JQL, third-party reporting, or do you also fall back on external tools like Excel?

3. How do you clearly demonstrate to stakeholders that a missed goal was due to absorbed shadow work, not low team output?

Looking forward to your workflows, setups, and perspectives!

[Bevan Williams]

This is such a common thing I've seen across larger organisations. I've definitely used the exact same workarounds in the past. My sense here is that there's more conversation work required that tooling won't solve, it'll more than likely hide the issues more. I'll add thoughts after your questions though:

1. A simple label is the least admin intensive (but most error prone) to have the clearest signal (combined with card colours or swimlanes) but custom fields can suffice too. The simplest visualisation I generally start with is the Sprint Report which shows the burndown, and any changes made during the sprint to work items or estimates. This assumes the work is logged, but it can drive good discussion, i.e. what contributed to this section flatlining, etc.
   • This requires teams set the sprint flag, but if they're good at logging/updating ticket status, then a daily updates check on your team spaces should make it easier for you to catch.
2. Yes, my personal preference these days is custom dashboards in Atlassian Analytics. If you've got db experience you will quickly understand the schema to get access to excellent data. Rovo here is also incredibly helpful. Also, one small feature I love (and turn on by default every time) is the time spent indicator for the sprint board (Board settings).
3. Have a (courageous) conversation with stakeholders and the team to review the sprint, identifying changes, unplanned additions, and unexpected "gotchas" that emerged. The Sprint Review is the most powerful way to demonstrate the complexity of building products by taking stakeholders along on the journey and allowing them to make recommendations early and often.

My take, based on the information shared, is that deeper underlying issues in the overall approach are likely causing these problems. I'm sensing that there's a commitment made to a goal that is essentially the work added to the sprint in planning. The risk is that time, cost, and scope are committed. The fact that teams deliver on this "commitment" in some sprints and not others already indicates that when running a fixed iteration (time) with a fixed team/capacity (cost), the scope of what will be delivered will vary. Estimates and our use of them should help stakeholders better understand this by showing alternatives in their language.

Suggestion: Teams should ideally commit to Outcomes not Outputs in planning (the only known at that time is what's important, and that we can't predict the future so the plan will change). Set a goal using language questions like "What will be different at the end of the sprint? How will we know we achieved it? If we delivered every item, what would make our customers celebrate?".

Suggestion: Estimates are a fancy term for a guess, so make ranges explicit. If using points, your velocity is not a single number but a range based on probability:

• Worst: Least points delivered in a sprint
• Avg: Avg points delivered over last x number of sprints
• Best: Most points delivered in a sprint

When forecasting, the script changes from "will be delivered in 4 sprints", to "will be delivered between 2 and 6 sprints, with a high probability being within 4 sprints".

• If working towards a specific release date the question stakeholders should ask is not "is this on track", but "what will I get on release date". This shift and the ranges above can shift the narrative of a burnup: "looking at our estimated backlog, we can deliver between 60-80% of the backlog based on what we know right now. This encourages the PO and stakeholders to ensure the most NB! items are in the 60% and lets them know early that, based on data, anything beyond the 80% in the backlog will not be delivered. Any unplanned changes or new requirements can then be compared to those ranges.

I've tried to illustrate these scenarios below with some dummy data (apologies for the handwriting).

I'm working off a lot of assumptions based on my read of it, so feel free to question/challenge/contextualise in response if I've entirely missed the mark.

[Max Brüssow]

Hi Bevan!

First off, thank you so much for the detailed reply and for taking the time to share those illustrations — really appreciate the perspective!

You hit the nail on the head regarding the cultural aspect: tooling will never replace courageous conversations, and committing strictly to outputs rather than outcomes is a trap many organizations fall into. Forecasting in probabilistic ranges (best/worst/avg) is a fantastic way to reset stakeholder expectations around scope vs. time.

However, where I often see teams get stuck is having the empirical baseline data to even start those conversations effectively, especially when human factors come into play:

The friction with manual labeling: Labels are a great lightweight signal in theory, but they rely 100% on team discipline. When things get stressful, support tickets or ad-hoc requests are quickly pushed into the sprint without the proper labels or flags, which breaks the reporting again.

The barrier of ticket creation: Ticket creation needs to be as low-friction as possible. If the process requires too much categorization or overhead, developers often skip creating a ticket entirely and just do the work "under the table" — which makes the actual data foundation even more distorted.

Data as the foundation for the conversation: To tell stakeholders "we absorbed unexpected complexity", the Scrum Master needs clear, immediate proof. Without clean visualization, retrospectives often turn into subjective debates instead of fact-based reviews.

Operational reality of Time-Tracking: In environments where budgets or client billings are tied to tracked hours, we often can't completely detach from time metrics. Having to manually piece together sprint reports or maintain external analytics dashboards just to see mid-sprint additions adds heavy admin friction.

I really like your point about using the Sprint Report and looking at Atlassian Analytics schemas. But my goal has always been reducing that admin overhead so the team can spend less time wrangling data and more time having exactly the outcome-focused conversations you described.

Thanks again for the great food for thought and the sketches!

[Bevan Williams]

Happy to share perspectives, and it sounds like your team is lucky to have you.

100% agree on the barrier of ticket creation - simpler is always better.

"Admin" in general gets called out a lot in teams. Even in my first time taking on the SM accountabilities as a developer. I ended up spending a weekend setting up a webcam pointed at our physical board and Raspberry Pi to auto-update the board in Jira (not my original idea, there was a fun project someone shared back in the 2010s). 

That reminds me of another valuable activity I like to do when dealing with high levels of interruptions or unplanned work. Once there's enough noise in the team about it, I'd walk around with sticky notes (or get the team to do it as part of a retro) and write down a super short summary. Red for unplanned, blue for planned features, yellow for planned quality fixes, green for technical improvements, etc. At the Review or when possible, I'd take that stack of sticky notes to a conversation with stakeholders so they can see, touch, and visually compare the impact of too much side/shadow work.

In my experience, I wouldn't shy away from sharing the more subjective data with stakeholders/teams. Worst case, they respond with a request for data showing this more clearly, enabling you to facilitate a "how" conversation between them and the team. One of the biggest lessons I learned is how crucial it is for a Scrum Master to avoid becoming a "go-between" or protecting them from "taking accountability" for their work. There are two conditions needed to create accountability:

1. Responsible Autonomy (with very clear boundaries)
   • In Scrum, this is why the team doing the work must be able to trust that the top of their backlog is the top of the backlog and that only they can create their sprint plan.
2. Real Consequences:
   • If the team made the plan, took on unplanned work, didn't raise any flags or impediments, and then did not achieve their sprint goal, they should 100% bear the brunt of (proportional) stakeholder frustration. These responses should be looked at objectively as qualitative data.

The values we want from this are courage and openness, with the expected behaviour that any change/addition/issue that puts the achievement of our team goal at risk be raised as early as possible, no later than the next daily scrum.

It would be great to see how things shift with your team(s) and what experiments you ended up crafting. No two teams are ever the same so would love to learn more from what ends up working.

[Quentin Sixt]

I've made for myself a "Capacity planner" browser extension to try to anticipate this.

It allows me to put activity percentages for a ressource, so that i can try to estimate a sprint work quantity more accurately.

It's work in progress for me, but it might help you to visualise that.

The browser extension is free, and available for chrome and firefox (it also includes lots of others stuff that i use every week (poker plannig module, administration module, hubspot connection module, etc ...)). You can search "Jira Admin Hub", and asks me if anything is missing.

Hopes it helps you.

[Max Brüssow]

Thanks for sharing this, Quentin! Really impressive feature set — especially love seeing fellow builders tackle Jira’s native UX gaps directly.

A few quick thoughts on your setup:

Having a client-side Capacity Planner for pre-sprint setup makes total sense to dial in realistic workloads early on.

I noticed your Label Manager module as well — which directly connects back to our point above about how quickly manual tagging turns into orphan clutter without dedicated cleanup.

The Tempo enhancements also show you're very familiar with the reality of time-tracking teams!

My main headache remains on the post-sprint retrospective side of things — when the sprint is done, and you need to look back and cleanly isolate: "We planned X capacity, but Y hours were swallowed by untracked shadow work."

I actually went down a very similar rabbit hole and started building a native Forge app (Beam) to automate that retrospective visualization for the exact same reason: getting tired of external spreadsheet workarounds.

I’ll definitely check out Jira Admin Hub — always great to see modular, local-first tools built by practitioners!

[Quentin Sixt]

I can add something for the retrospective functionnality ... i'll check what i can do, and let you know when it's available (probably before the end of the week)

[Quentin Sixt]

I think i got something pretty fonctionnal. I publish, you tell me if it's what you want, and what you need more. It'll be the 1.7.3. It'll be available on firefox in a few minutes, and in chrome in a few hours

[Elita Kalāne - eazyBI Support]

Hello  @Max Brüssow 

(Disclosure: I work at eazyBI).

Thanks for sharing your use case!
The JQL workaround fails for exactly the reason you identified - Jira just doesn't expose sprint assignment timestamps through JQL, so you'll always miss the backlog tickets that get added in mid-sprint. 

However, Jira internally logs every sprint scope change in its issue change history - when an issue was added to a sprint, when it was removed, and the state of estimates at each point. eazyBI reads this history directly, which means you don't need labels, custom fields, or team discipline to catch shadow work. It's already in the data

In practice this means you get measures like Sprint issues committed (what was in the sprint at the moment it was started), Sprint issues added (everything pulled in the sprint after it started), and Sprint issues removed. You can then filter the "added" bucket down to only issues with zero or missing estimates - and that's your shadow work, automatically, with no manual tagging involved.

For the stakeholder communication piece - the time tracking burndown report plots remaining estimated hours and actual hours spent day by day on the same chart. 

If you want to see what this looks like without setting anything up, here is a screenshot of a report from our demo account 


You can find the eazyBI app here, if you're willing to give it a try - eazyBI for Jira Cloud.
All eazyBI reports can be embedded directly into Jira dashboards as gadgets as well.

Best wishes,

Elita from support@eazybi.com

[Max Brüssow]

Hi Elita,

Thank you so much for the detailed breakdown!

It’s great to see confirmation from the eazyBI team that the root problem is native JQL’s lack of sprint-assignment timestamps — and that reading the issue change history directly is the only reliable way to capture this data without forcing manual tagging onto teams.

eazyBI is obviously an incredible power tool when it comes to enterprise-grade, multi-dimensional BI reporting.

That exact changelog logic is actually what inspired me to build Beam.While full BI suites provide endless customization, my goal was to create a zero-setup, lightweight Forge app tailored specifically for Scrum Masters, Product Owners and Project Managers in retrospectives and sprint reviews.

Instead of configuring custom cubes or formulas, it analyzes the history out of the box:

• Distinct Scope Categories: Clearly separating initial commitment, planned added scope, and unestimated shadow work.
• Adjusted Burndown & Time Breakdown: Visualizing exactly how much of the logged time went into the originally planned scope vs. unplanned mid-sprint additions.
• Multi-Sprint Trend Graphs: Tracking how much unplanned work impacts the team over time to adjust future planning buffers realistically. 

 

Screenshot from a live sprint view: Showing the unbundled burndown on the left with added scope visualised in yellow, and the effort spent on the right cleanly splitting Planned Spent from Shadow Spent so the team can instantly see where time was leaked.

Really appreciate you chiming in with the eazyBI perspective and sharing the demo report!

Best,

Max

[Daria Spizheva_Reliex_]

Hi @Max Brüssow , great write-up! "Shadow work" is such an accurate name for this. A few thoughts:

• The Sprint Report (not the Burndown) lists all issues added after sprint start with an asterisk (*) — this catches backlog items dragged in mid-sprint, which your JQL misses.
• The Burnup Chart shows scope-change events explicitly, which is much easier for stakeholders to read than a burndown spike.
• A lightweight habit that helps: auto-apply a label like unplanned via Automation ("issue added to active sprint → add label"). Then a simple JQL filter (labels = unplanned AND sprint = X) plus a dashboard gadget gives you a clean "shadow work" view — no timestamps needed.

Where ActivityTimeline (our app) adds value on top:

• Worklog Categories — tag logged time as e.g. "Support," "Urgent bugs," or "Unplanned," then group Timesheets by category to show exactly how many of those 350h went to shadow work vs. planned scope.
• Timesheets grouped by Sprint — generate a per-sprint timesheet (Custom tab → group by Sprint), so planned vs. absorbed hours live in one report, right inside your workspace — no Excel juggling.
• Planned vs Actual Report & Chart — compares Original Estimate vs. Time Spent with deviation % and color-coded statuses (On Track / Underestimated), which is a stakeholder-friendly way to prove the "missed" commitment was absorbed effort, not low output.
• Non-Jira interruptions (meetings, ad-hoc support) can be captured via Booking events treated as worklogs, so even work that never becomes a ticket shows up in reports.
• And if you still love your spreadsheets — every report exports to Excel in one click. 🙂

Happy to share setup details if useful — feel free to ping us!

[Max Brüssow]

Hi @Daria Spizheva_Reliex_

Thanks a lot for the comprehensive breakdown and practical tips!

That Jira Automation rule ("issue added to active sprint → auto-apply label") is a clever workaround. It completely solves the human error aspect of manual tagging without relying on developer discipline mid-sprint. The only minor trade-off there is keeping an eye on Jira Cloud automation rule execution limits across larger workspaces.

The Sprint Report asterisk (*) is definitely helpful for raw lists, though turning that list into immediate, visual retrospectives without manual math is where many teams still stumble.

ActivityTimeline looks like a very capable suite for broader resource planning and capacity management. Capturing non-Jira interruptions via booking events is a smart way to account for overhead that never makes it into the backlog.

My main focus has been keeping the friction for the individual developer as close to zero as possible (no extra categorization when logging work, no manual setup for the Scrum Master) while getting that instant clarity during sprint retros.

Really appreciate you sharing the automation idea and the Planned vs Actual chart example!

Best,

Max