Sprint Retrospectives in Jira: A Comprehensive Guide

What is Retrospective?

A retrospective is a process of reflection and discussion that typically lasts 60-90 minutes. It is recommended that retrospective meetings be held to maintain the team's focus. The moderator of these meetings should control the course of the conversation to ensure it remains constructive and does not devolve into complaints.

Key Questions for Retrospectives:

1. What to improve in the development process?

2. What to stop doing?

3. What to start doing?

Understanding Sprint Report

So, let's look at a sprint report that you can automatically generate using the Time in Status app.

Note that there is a dropdown in the upper right corner where you can select one of the three parameters for generating a report:

1. Story Points. The report calculates data based on the story points field set for each issue in your sprint.

2. Issue Count. The report calculates data based on the number of issues in your sprint.

3. Original Time. The report calculates data based on the time estimate field set for each issue in your sprint. 

Open

Chart - Velocity 

Displays the team's commitments and completed values for each sprint during the last sprints of the selected one. The selected sprint will always be on the right of the chart. 

• Committed Values. This represents the number of issues or estimated value the team committed to delivering during the sprint planning. It's essentially the forecasted workload for the sprint.

• Completed Values. These are the issues or estimation values that the team successfully finished and moved to the Done or rightmost column on the board by the end of the sprint.

Understanding and interpreting velocity data is the key to adapting and optimizing the team's workflow.  

By tracking team velocity, we can generally see the team's productivity, for example:

• Consistent Velocity. Everything is stable. Planned and executed. There are no alarm bells. We have a predictable workflow.

• Increasing Velocity. The team consistently exceeds its targets, which may indicate improved efficiency or resource planning.

• Fluctuating Velocity. Factors, dependencies, or issues affecting alignment need to be investigated. It is necessary to discuss what factors affect the variability retrospectively.

• Decreasing Velocity. The team may be overworked, facing unexpected challenges, or experiencing burnout. A retrospective can reveal issues that impede progress.

Open

Chart - Workload

The chart illustrates the issues committed, added, and removed (or their estimated values) in the sprint for individual assignees. The percentage of each bar reflects the workload of the assignee during the sprint. The following formula determines the workload for each assignee:

Workload = (Committed + Added - Removed) / Total Sprint Commitment * 100

Here's how you can use the Workload Chart in your retrospective:

1. Balancing Workload.

2. Improving Collaboration.

3. Capacity Planning.

4. Continuous Improvement.

Chart - Scope Change

 The chart illustrates the changes in the number of added or removed issues or their estimated values since the beginning of the sprint. You can view the corresponding added or removed values when you hover over the segments. It presents the percentage by which the initial sprint commitment has been altered, calculated as follows:

Scope change = (Added - Removed) / Total Sprint Commitment * 100% 

Using the insights from the Scope Change chart in the sprint retrospective allows your team to address shifting priorities and expectations proactively. By fostering open communication and process adjustments, you can increase adaptability and improve the team's ability to navigate unexpected changes in scope.

Leveraging Sprint Reports for Retrospectives

Sprint Goals: The main goals and desired results are the basis for the sprint's creation.

Most importantly, you can't just write some general goals. They must be clearly stated and measured by specific metrics. Also, sprint goals should have a realistic time frame. Before setting goals, use insights from your past retrospectives to avoid making mistakes. Ensure your team members understand these goals and how to achieve them. Involve the team in setting goals. 

Flagged Issues, Logged Time, Status Time

Metrics related to flagged issues, logged time, and status time offer a rich data source for analyzing team performance.  

1. Review Flagged Issues. Examine issues that were flagged during the sprint. 

2. Evaluate Logged Time. Analyze the total time spent on the tasks during the sprint. 

3. Assess Status Time. Review the total amount of time spent on issues in each status.

Sprint Structure

Understand which issues were worked on during the sprint. Analyze the percentage of each issue type to identify any trends or imbalances.

Chart - Completion Rate

Analyze how well the team met its commitments. If the carryover percentage is high, discuss reasons for incomplete work and how to address them in the future.

Chart - Completed Issues

Analyze the completed tasks by priority. For example, if high-priority issues are often delayed, discuss how to prioritize and manage them more effectively.