Pulse Retroactive View
Analyze past sprints and track team performance with detailed Pulse Retroactive View insights.
The Pulse Retroactive View allows teams to analyze past iterations by selecting a previous sprint or week from the iteration filter at the top of the Pulse page. This provides a detailed report of development activity, enabling teams to evaluate performance, identify trends, and optimize future planning.
Key Metrics in the Retroactive View
1. Planning Accuracy (Scrum Teams)
Planning accuracy measures how well the team adhered to their sprint commitments by comparing planned issues or story points with actual deliveries.
- Formula:(Completed Issues / Planned Issues)×100
- Guidelines:
- < 70% → Potential over-commitment, meaning too much work was planned but not completed.
- > 95% → Possible under-commitment, indicating that the team may not be fully utilizing its capacity.
This percentage is derived from the Delivery metrics, where only completed (not newly added) issues or story points are counted.
2. Capacity Accuracy (Scrum Teams)
Capacity accuracy evaluates how effectively the team completed work in an iteration by comparing all completed work (planned + unplanned) to the original plan.
- Helps answer: “Is my team taking on a reasonable workload?”
- A significant variance suggests that the team may need to adjust its sprint commitments or backlog planning.
3. Velocity (Kanban Teams)
For Kanban teams, velocity is used instead of planning accuracy. It measures the number of issues completed per week, providing:
- An average weekly completion rate
- A breakdown of completed issues per week
Velocity helps teams track efficiency over time and adjust workflow strategies accordingly.
4. Delivery Performance
The Delivery section categorizes work completed during the iteration:
- Completed → Story points or issues that were planned and successfully finished.
- Unplanned → Story points or issues added after the sprint began and completed within the same sprint. (Note: This does not include unplanned issues that were not completed.)
- Uncompleted → Story points or issues that were planned but not finished by the end of the sprint.
- Planned → Story points or issues that were added before or within 24 hours of the sprint's start.
This breakdown helps teams analyze sprint scope, adjust planning processes, and improve predictability.
5. Investment Profile – What Type of Work Was Completed?
The Investment Profile visualizes work distribution based on issue types. It pulls data from your project management tool (Jira or Shortcut) to show how the team’s effort was allocated.
This metric helps teams understand:
- The balance of work types (e.g., new features vs. bug fixes).
- How much effort was spent on different project categories.
- Whether work aligns with priorities set by product and engineering teams.
6. People Effort – How Many Team Members Contributed?
This metric measures the percentage of active contributors in an iteration.
- A team member is counted as "active" if they are assigned to an issue that is moved to "Done" status.
- Formula:(Active Contributors / Total Developers)×100
A low percentage may indicate bottlenecks, uneven workload distribution, or dependency issues.
7. Delivery Breakdown – What Issues Did We Work On?
A detailed list of all issues from the last iteration is displayed on the right side of the Pulse page, categorized by their status.
- Click “View more” next to any segment to expand the list.
- Clicking on an issue redirects you to Jira or Shortcut, where you can see full details, updates, and discussion history.
This section allows teams to review specific tasks, investigate delays, and refine sprint planning.
Summary
The Pulse Retroactive View provides actionable insights into past iterations, helping teams:
✅ Assess planning accuracy and capacity
✅ Measure work distribution and team effort
✅ Optimize sprint planning and Kanban flow
✅ Identify trends and improve efficiency over time
By leveraging these metrics, teams can make data-driven decisions, enhance predictability, and continuously improve their delivery processes. 🚀
For additional help, refer to:
How did we do?
Pulse Naming Conventions – Azure
Understanding Pulse Alerts
