Create
cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Sprint Reports in Jira: Mastering Retrospectives

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.

giphy (11).gif

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.

Sprint 1.png

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.

Team Velocity.png

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.

workload.png

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.

Scope Change.png

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.

sprint structure.png

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.

Completion.png

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.

completed.png

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!

 

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events