Estimating a dashboard
How to estimate a dashboard: data sources, refresh cadence, time zones, drill-down, permissions. The chart is easy; the data pipeline behind it is the work.
The story that estimates the chart and forgets the data pipeline behind it.
Dashboards are deceptive. The visible part — the chart, the date picker, the filters — looks like a couple of days of frontend work. The invisible part is the data layer: where the numbers come from, how often they’re recomputed, what time zone they’re in, what counts as a unique user, and what happens when finance says the number is wrong on Tuesday morning.
The estimate hinges on whether the data already exists in a queryable shape. If yes, the work is mostly rendering. If no, the work is a data pipeline with a chart on top — and that’s a different number entirely.
What gets said in the room
Frontend: “Chart library can do the rendering. A day or two.”
Backend: “What’s the source of truth for these numbers?”
Data: “Real-time, or is end-of-day fine?”
PM: “Whose time zone are we using for ‘today’?”
Lead: “What happens when finance says the chart is wrong?”
Questions worth asking before voting
- Does the underlying data exist in a queryable form, or do we build the pipeline first?
- Refresh cadence: live, hourly, daily, on-demand?
- Time-zone handling — server time, user time, account time?
- Drill-down: links into raw rows, or just the aggregate?
- Export: CSV, share link, embedded image?
- Permissions: who sees which slice of the data?
- What’s the response when the numbers disagree with another report?
If the data pipeline doesn’t exist yet, the chart isn’t the story — the pipeline is, and it’s worth splitting out and sizing on its own.
Estimate the data layer. If the numbers aren’t queryable yet, the chart is the last five percent.
Like estimating a search feature, the visible UI is the easy part; the data layer is the work. See the other worked estimation examples, or open a free planning poker session when the data question has an answer.