Sprint Reports in Jira: Mastering Retrospectives

[#1]

And now, another sprint has passed, and it's time for a retrospective. It's always stressful and requires incredible concentration. So, let's figure out what it is, why it's necessary, and how to carry out this process with minimal loss of productivity.

What is Retrospective?

I don't need to tell you much about what a retrospective is. Everyone has experienced it. It is a process of reflection and discussion. It is recommended to hold retrospective meetings for at least 60-90 minutes to maintain the team's focus. The moderator of these meetings should control the course of the conversation so that it does not reach a dead end where everyone complains about everything. Constructive dialog among the team is essential.  

Also, don't forget about the main three questions around which the discussion of the previous sprint is formed:

1. What to improve in the development process?
2. What to stop doing?
3. What to start doing?

However, it is always advisable to hold such discussions based on a preliminary analysis of the sprint. Numbers should back everything up. It is equally important that the sprint report has a convenient form of display and coverage of all critical aspects. 

Recently, the Time in Status for Jira app has released an important feature - Sprint Performance Report. So, let's look at it and analyze how this report can help with retrospectives.

Understanding Jira's Sprint Reports

So, let's look at a sprint report that you can automatically generate using the Time in Status for Jira 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. 

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.

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. When you hover over the segments, you can view the corresponding added or removed values. 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 of why the sprint was created in the first place.

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.

Instead of Conclusion

Here are simple tips on analyzing a sprint and conducting a retrospective. A few simple steps: 

📊 Automatically generate a sprint report using the Time in Status for Jira app.

💭 Encourage Open Discussion. Use the data to facilitate open discussions among team members.

🤓 Continuous Improvement. Focus on identifying areas for improvement and action items for the next sprint.

✴️ Celebrate Successes. Acknowledge and celebrate the team's achievements and positive outcomes.

By systematically reviewing each aspect of the Sprint Report, you can foster a collaborative atmosphere and gain actionable insights for continuous improvement in your future sprints. 

Try generating your first sprint report using Time in Status. Here's a free 30-day trial for you.

Enjoy!