Sprint Insights
Insights is the reporting page for sprints: how the current one is going, how past ones went, and where the workload actually sits. Pick a sprint at the top and the page reads on it.
Where: Insights in the main menu You need: access to the project
When to use this, and when not to
| The question | Use |
|---|---|
| How is this sprint going, and how did past ones go? | Insights |
| What is on my plate today? | My Work |
| Where is work stuck right now? | The board |
| Where did the team's hours go? | Timelog |
Insights answers planning questions. It is the page to open before committing to the next sprint, not the page to run a standup from.
The sprint at a glance
| Figure | What it tells you |
|---|---|
| Total tickets | The sprint's size |
| Completed | How much is done |
| Created this sprint | Tickets born mid-sprint |
| Scope added after start | Work added after the sprint began |
| Hours logged | Time actually recorded |
The one to watch is scope added after start. A sprint that keeps growing after day one is not failing at delivery, it is failing at planning — and this is the number that makes that visible instead of arguable.
Velocity
The velocity chart shows completion across sprints, so you can see whether throughput is steady, growing, or was flattered by one heroic fortnight.
Velocity is what makes the next sprint plannable: commit to roughly what you actually complete rather than what you hope. Two sprints of velocity is noise; six is a planning tool.
Breakdown and team workload
- By status / by priority — the shape of the sprint: how much is still To Do, how much is Critical
- Team workload — per member: tickets, completed count, hours logged, and a rating
- Epic progress — how far each initiative has come, which is usually the version leadership wants
Use team workload to spot imbalance, not to rank people. One person carrying the sprint is a delivery risk and usually a burnout risk; that is what the view is for.
What Happens Next
Insights changes nothing. What it should produce is a decision:
- Scope creep → tighten what gets committed, or agree that mid-sprint additions are normal and plan for them
- Falling velocity → find out what changed before assuming effort did
- A lopsided workload → rebalance next sprint's assignment
- An epic stalling → decide whether it is still a priority
Reading it honestly
Insights reports what people entered. If time is not logged, hours are fiction. If tickets are not moved to done as they finish, completion lags reality. If sprints are never closed, velocity never builds.
The fix for ugly numbers is sometimes the team — and often just the hygiene in Estimates and logging time and Sprints.
Tips
- Look at it at sprint planning, every time. Insights read once a quarter is a curiosity; read at every planning session it is the thing that stops you over-committing again.
- Compare like with like. A sprint over a holiday period is not evidence of a trend.
- Watch the gap between completed and hours logged. High hours with low completion usually means work is bigger than estimated, or too much is in flight at once.
- Do not manage to the rating. It is a summary, not an assessment, and treating it as one changes how people log their work — which destroys the data.