Questions every retrospective asks, answered with data.
Each first vote against the final estimate, with a tendency per person.
Counted in rounds where at least three people disagreed.
Planned and delivered points per sprint, and each owner's share.
The spread of first votes per story, most divergent first, by technique.
How far final estimates move toward them, against everyone else.
Defects, rework and carry-over by owner and by whose estimate was chosen.
Spearman, Pearson and R² between story points and cycle time.
Size drift by sprint, epics against their parts, and time spent estimating.
When will it be done — and what if things change?
A Monte Carlo simulation over the team's real throughput gives 50, 70, 85 and 95% dates. In the planning workspace, change capacity, people, scope, velocity or the focus factor and see the delivery date move against the baseline, with projected flow per sprint and throughput, cycle time and work in progress.
Learn why stories run over.
CHIPS flags every story that ran over its estimate: carried over, not done by the end of its sprint, or more working days or effort than its points. The scrum master gives each one a reason from the team's own list.
- Twelve standard reasons to start from, in six categories, each marked as within the team's control or not. Add, edit and retire your own.
- Bring in past sprints from Jira with a JQL query, or from a spreadsheet, so the review starts with real history.
- Reasons ranked in a Pareto chart, what each one costs, miss rate by story size, person and vote spread, and the risk for the sprint being planned.



