- The team says
- We’re still on the original scope
- The data shows
- 6 added, 2 removed
Scope moves after planning
Work added mid-sprint blends into the original plan, so the completion rate looks fine while the Sprint Goal slips.
Know whether the sprint is at risk, and which work is causing it
AndonPulse is sprint analytics software that puts commitment, scope changes and carryover next to the pull requests and reviews behind them. You see the risk while the sprint is still running.
Read-only connections to the tools your teams already use
Jira
GitHub
GitLab
Linear
Claude Code
Cursor
Codex
BambooHR
Every sprint has a report. Nobody sees the slip until it ends.
The burndown looks fine in the middle of the sprint. The carryover shows up at the retrospective.
- The team says
- We’re on pace to finish
- The data shows
- 27–30 of 38 Issues forecast to finish
The board can’t see the review queue
An Issue stays In Progress while its pull request waits for a reviewer. Jira doesn’t read Git, so the delay surfaces in the last days.
- The team says
- We’ll talk about blockers at the retro
- The data shows
- Partner API rate limits blocked for 6 days
Blockers come up at the retro
Work waits on another team for a week and nobody flags it, so the reason for carryover is found only after the sprint is over.
From a sprint at risk to a decision, in five clicks
Spot the risk
On day 7 of 10, Sprint 46 is likely to finish 27 to 30 of its 38 Issues. Completed work is falling behind the scope, which grew after planning. A risk shows up mid-sprint, while there is still time to act.
See what changed
The team committed to 34 Issues. Six more were added after the start and two were removed. The change history shows which Issues moved in or out and when, so the team can see what displaced planned work.
Find the work at risk
Sort open Issues by time in their current status. Three are In Progress, but their pull requests have waited 3 to 4 days for a first review. One has been blocked by another team for six days.
Find the cause
This sprint, open Issues waited 2.4 days on average for a first review, four times longer than in the last three sprints. Two of the team’s three regular reviewers spent the week on a release. Stages combine your Jira statuses with pull request events.
Check the result
The team set a daily review slot and moved the two Issues added last to the next sprint. Over the next three sprints, carryover went from 9 Issues to 3. AndonPulse doesn’t make the decision. It shows where to act, and then whether the change worked.
What you can do with a sprint analytics platform
What did the sprint commit to, and what changed?
- Today
- You compare the sprint plan with the current board to reconstruct what changed.
- With AndonPulse
- Committed, added, removed, completed and carried-over work on one sprint analytics dashboard for every team: reporting and analytics, sprint by sprint. Scope is counted from the moment the sprint starts, so work added later never hides inside the original plan.
Which work is at risk right now?
- Today
- You scan the board for open Issues and check each one to see how long it has been waiting.
- With AndonPulse
- Open Issues ranked by time in their current status, with blocked time and the state of the linked pull request.
An 80-engineer e-commerce team that started tracking blocked work in AndonPulse cut the median time a task stays blocked on another team from 5 working days to 3.
Where is work taking longer across sprints?
- Today
- You rely on what the team remembers about where work slowed down.
- With AndonPulse
- Compare average time waiting for review, in review and in QA by sprint. See which Phase to investigate before changing the next sprint plan.
What can the team finish by sprint close?
- Today
- You look at the remaining scope and estimate how much the team can finish.
- With AndonPulse
- A sprint burnup shows completed work against current scope and projects how many Issues could be done by sprint close.
How AndonPulse calculates sprint metrics
What did the team plan at sprint start?
Issues in the sprint at the moment it starts. Your team can set a short grace period after the start, so late planning changes don’t count as scope added.
- Counted from
- The sprint field, sprint dates and Issue history in Jira.
- Read it with
- The Sprint Goal. The Scrum Guide lets a team adjust scope during the sprint as long as the goal holds.
What changed after planning?
Issues added to or removed from the sprint after the start, with the day each change happened. Removed Issues are shown separately and never count as done.
- Counted from
- The sprint history of each Issue.
- Read it with
- Work type. An urgent bug fix is a different change from new feature work.
How much of the plan was finished?
Issues that reached your done status by the sprint end, split into committed and added work. The sprint end is the cutoff for both groups.
- Counted from
- Status changes and your done rule.
- Read it with
- Carryover. A 100% completion rate can also mean the team planned too little.
What work was still open at sprint end?
Issues not done by the sprint end, whether they move to the next sprint or go back to the backlog. Cancelled Issues are left out. Each one shows its last status, blocked time and pull request state.
- Counted from
- Sprint history, statuses and linked pull requests.
- Read it with
- Work item age, which shows the risk before the sprint ends.
Will the sprint finish?
The number of Issues likely to be done by the sprint end, shown as a range, such as 27–30 of 38. It is based on the team’s pace in past sprints and the age of open work.
- Counted from
- Completed Issues in past sprints and the current state of open work.
- Read it with
- Scope change. A forecast also drops when work is added, not only when work slows down.
What it doesn’t tell you. Velocity and completion rate are planning aids for one team. They don’t measure how productive a team or a person is, and they can’t compare teams with different workflows. Read them against the team’s own history.
Built around your delivery model
Most sprint reports apply one set of rules to every team. AndonPulse uses yours. You decide when the sprint scope is fixed, which status means done, how subtasks count and which work is unplanned. Each team keeps its own workflow and sprint length.
Try it. Change a rule on the right and watch the numbers move.
Setup is guided: the AndonPulse team maps sprint fields, statuses, Issue types and teams with you and checks them on your data.
How Sprint 45 is counted · Platform team
Planning grace period: 1 day
Issues added on day 1 count as committed
"Ready for release" counts as done
The status before deployment closes the Issue
Count subtasks separately
Each subtask counts as its own Issue
- Issues added after start
- Completion rate
Change a rule and past sprints recalculate, so trends stay comparable.
One platform. Sprint analytics is one of its views.
Connect your tools once. The same delivery model powers every view.
Engineering delivery
AI analytics
Planning & finance
Delivery speed and stability, with the deployments and pull requests behind each change.
Open this view
Which sprint work is at risk before the review, and why it carried over.
Where reviews wait, and who carries the load.
Open this view
See how much of your work involves AI coding tools, by team.
Compare Cycle Time for work with and without AI assistance.
Follow how AI coding tools spread across teams over time.
Put the cost of AI tools next to what they change.
Where engineering capacity goes, compared with the plan.
Audit-ready R&D reports from measured work.
Open this viewUp and running on your data
No new fields and no timesheets. Our customers saw first results in 2 to 4 weeks.
- 5–15 minutesConnect your tools
Connect Jira and GitHub or GitLab, with read-only access. Linear calls its iterations Cycles, and its AndonPulse integration is coming soon.
- Same dayLoad your history
Past sprints come in at once, so each team has a baseline from day one.
- With our teamMap your sprint rules
Sprint fields, statuses, Issue types and teams, checked on your real data.
- Weeks 2 to 4Run a sprint review with data
Commitment, scope change and carryover, with the work behind each number.
- Separate database for each customer
- SSL/TLS and encryption of sensitive data
- Read-only integrations
The math is fully transparent — because we write the rules ourselves in the platform.
Eugene Gusarov
Director of Product and Engineering, NetNationLearn how to run delivery with data
All articles
Questions about sprint analytics in AndonPulse
What is sprint analytics software?
Sprint analytics software reads sprint data from Jira or Linear and shows how each sprint went: what the team committed to, what changed, what was finished and what carried over. Good sprint reporting and analytics also explains why. AndonPulse adds the pull requests and reviews behind each Issue, so a slow sprint leads you to the review queue, blocker or scope change behind it. When you choose a sprint reporting and analytics program, check that it explains carryover as well as counting it.
How does AndonPulse define committed, completed, added, removed and carried-over work?
Committed work is what is in the sprint when it starts. Added and removed work is anything that moves in or out after that. Completed work reached your done status by the sprint end, and carried-over work did not. The exact rules, such as which status means done, are set with you and stay visible next to every number.
How are scope changes tracked during the sprint?
AndonPulse reads the history of each Issue, so it knows when work entered or left the sprint. The sprint analytics dashboard shows scope day by day, so you can see whether a change came on day 2 or in the last days of the sprint.
Is velocity used as a productivity score?
No. Velocity is a planning aid for one team. Story points differ between teams, and turning them into a target invites gaming. AndonPulse shows velocity against the team’s own history and has no team or developer leaderboards.
Can Jira sprint data be connected to Git and pull request activity?
Yes. AndonPulse links Issues to the branches, commits and pull requests that mention them in GitHub or GitLab. That is how an Issue that looks In Progress on the board shows a pull request waiting for its first review.
How does AndonPulse identify work at risk before the sprint ends?
It compares the age of each open Issue with how long work usually stays in that status for this team, and checks blocked time and linked pull requests. Issues that are older than usual, blocked or waiting for review are flagged while there is still time to act.
Can each team use its own workflow and sprint definitions?
Yes. Each team keeps its own statuses, sprint length and done rule, and the AndonPulse team maps them with you during setup. Connecting your tools takes 5–15 minutes. In our customer stories, teams had their first results within 2 to 4 weeks.
Your data. Our help getting started.
Get started with our help
Request free access to AndonPulse. We’ll schedule a guided session and help you get from connected tools to useful insights.
- 01
Tell us about your team
A few details help us tailor the session to your tools and goals.
- 02
Get a guided setup session
We’ll help you connect your tools, set up your workspace, and understand your data.
- 03
Start with free access
Use the free Developer Productivity plan for teams of up to 10, or try paid capabilities free for 14 days.
Connect your existing tools without changing your workflow.
Free access, with a helping hand
Request free access
We’ll email you to arrange a guided session before you receive access.
You’re on your way.
Thanks for requesting access. We’ll email you to arrange your guided setup session and help you choose your free plan or 14-day trial.
We couldn’t send your request. Please try again or email hello@andonpulse.com.