track dependencies and queue time on the agile burnup charts

[rumr1ckey]

I've got a question about agile burnup charts. For our hardware project, we've been using them to track our progress, but I'm trying to figure out how to make them more accurate.

The problem is that our charts don't show a realistic timeline if we don't account for wait periods or dependencies.
How do you all point dependencies and queue time on your burnup charts without skewing the project plan?
It's a tricky balance, I'd love to hear how you've handled this successfully.

Also, what's your process for updating the chart? How often do you review and adjust the projected completion date based on new information about lead times or delays?

 

[Tim Wendell]

We had the same problem on a drone project last year. The chart looked good until parts got delayed. What helped was putting blocked tasks in a separate row and adding notes for wait time. We updated the chart every week, but only changed the finish date if things were slow for two weeks in a row. That gave us a better picture without jumping too fast. Tracking lead time on its own also helped a lot.

 

[5alm0nberry]

hi @rumr1ckey Instead of trying to point the queue time, try to separate your burnup into two charts, which are the Engineering Effort Remaining (the traditional burnup) and the Value Delivered Over Time.
the gap between these two lines clearly visualizes the impact of your lead times and dependencies. if the value line stalls while the effort line keeps dropping, the dependency is the culprit

 

[Sandeep.K]

Good question, this is a common challenge. Burnup charts often look “too smooth” if we don’t make wait times and dependencies visible.

One thing that helps is to treat dependencies and queue time as standalone work items rather than folding them into development tasks. That way, they appear directly on the chart. It keeps the timeline realistic.

Some teams also add a separate marker or note on the chart whenever a delay happens. That way, anyone looking at it understands why progress slowed during that period.

For updates, a weekly review works well. It’s frequent enough to catch changing lead times or new dependencies without constantly redrawing the chart.

The idea isn’t to make the chart perfect, just honest, so it sparks the right conversations early.

 

[Regina spee]

You could track active work separately from blocked time, so your chart reflects actual progress without penalizing the team for things outside their control and yh you could also add a secondary line for cumulative delay to keep visibility without inflating scope.
Daily updates is overkill unless you're in a crisis sprint, most hardware teams I've seen do it weekly with adjustments to the projection line whenever a major dependency shifts

 

[Alan]

Track dependencies and queue time as separate items on the burnup chart. Review weekly and adjust projected completion only if delays persist.