Software development emphasizes delivering superior features to customers within a short period. Thus, teams are focused on enhancing their delivery methods on an ongoing basis. This is where sprint review (or developer productivity) metrics come in. These metrics offer relevant details on productivity, task completion rates, quality control, and other aspects of the development process. As a result, they assist in identifying potential areas for improvement in the delivery processes, analyzing the underlying problems, and devising solutions.
How sprint metrics help identify bottlenecks
For example, assume a team notices a drop in velocity from 25 to 15 story points in two consecutive sprints and an increase in unplanned work. These numbers provide an early indicator of unclear requirements and scope creep, which might lead to bottlenecks. Since the team detects it early, they can quickly mitigate it by improving backlog grooming sessions and enforcing stricter WIP limits.
Likewise, analyzing these metrics can pinpoint specific issues in your workflows, such as:
- Overcommitments
- Resource constraints or technical debt
- Workflow delays
- Scope creep
- Quality issues
Now, let’s see the sprint metrics we can use to identify bottlenecks and how to do so.
1. Say/Do ratio
The Say/Do Ratio measures the percentage of work a team completes compared to what was initially planned. It is calculated as:
Say/Do Ratio (%) = (Completed Story Points / Planned Story Points) * 100
Example:
- Planned Story Points: 40
- Completed Story Points: 30
Say/Do Ratio = (30 / 40) * 100 = 75%
Insights:
- A low ratio (<80%) may indicate scope creep, unclear requirements, or overcommitment. Such deviations suggest bottlenecks caused by poor estimation, changing requirements, or dependency issues.
- A high ratio (>100%) may imply under-commitment or missed opportunities for productivity, pointing to inefficient resource utilization or a lack of challenging goals.
Tools: Jira and Azure DevOps provide built-in reports for Say/Do Ratios.
2. Sprint velocity
Sprint Velocity measures the average amount of work completed in a sprint. This is usually measured in story points and helps teams estimate future workloads.
Velocity = Total Story Points Completed / Number of Sprints
Example:
- Sprint 1: 20 points
- Sprint 2: 25 points
- Sprint 3: 22 points
Velocity = (20 + 25 + 22) / 3 = 22.33 points
Insights:
- If there are sudden decreases in velocity, it may indicate blockers like resource constraints, blockers, or technical debt.
- Consistent performance reflects stable team capacity, which avoids potential bottlenecks.
Tools: Sprint velocity charts are available in Jira, Monday.com, and ClickUp.
3. Cycle time
Cycle Time measures the time taken to complete a task from start to finish. It identifies delays in the development process.
Cycle Time = End Date – Start Date
Example:
If a feature begins on January 1st and ends on January 10th, the cycle time will be
Cycle Time = 10 – 1 = 9 days
Insights:
- Longer cycle times highlight workflow inefficiencies or approval delays, pointing to bottlenecks in development or testing.
- Shorter cycle times indicate efficient processes with minimal delays.
Tools: Trello, Jira, and Asana visualize cycle time through kanban boards.
4. Work in progress (WIP) limits
WIP Limits control the number of tasks a team can handle simultaneously, reducing context switching and inefficiencies.
Example:
- A team sets a WIP limit of 3 tasks per developer.
- Developer 1 handles two tasks.
- Developer 2 exceeds the limit with four tasks.
Insights:
- Exceeding WIP limits can overwhelm teams, causing bottlenecks due to multitasking and context switching.
- Staying within the WIP limits ensures focus, faster completion, and balanced workloads.
Tools: Kanban tools like Jira, Kanbanize, and Monday.com allow WIP limits to be set and tracked.
5. Lead Time
Lead Time calculates the total time taken from task creation to delivery. It highlights bottlenecks in task progression.
Lead Time = Completion Date – Creation Date
Example:
A task created on February 1st is completed by February 15th.
Lead Time = 15 – 1 = 14 days
Insights:
- Long lead times may indicate delays due to approval bottlenecks or dependencies, requiring process optimization.
Tools: Tools like LeanKit and Jira visualize lead times with cumulative flow diagrams.
6. Unplanned work percentage
Unplanned Work Percentage measures the volume of unexpected tasks added during a sprint.
Unplanned Work (%) = (Unplanned Tasks / Total Tasks) * 100
Example:
- Planned Tasks: 20
- Unplanned Tasks: 5
Unplanned Work = (5 / (20 + 5)) * 100 = 20%
Insights:
- High percentages (>20%) often indicate poor planning or changing priorities, resulting in frequent bottlenecks due to interruptions.
Tools: Jira backlog reports and Sprint Reports track planned vs unplanned tasks.
Conclusion
Sprint metrics or developer efficiency metrics allow teams to track performance and identify bottlenecks in their development processes. You can easily capture and monitor these metrics through tools like Jira and Azure DevOps to ensure continuous improvement, leading to better quality and faster delivery.