How to create a Scrum Sprint Report? (Software Development)

Mert Kadir Gursoy

10 min readDec 2, 2021

If you lead a software team, probably you think that how these Jira Reports & Charts should be reviewed.

At the end of the sprint dynamically a few reports are generated.

The following steps below are the ways for you to review this reports and create a report for the sprint that you have.

Sprint Review:

Completed Sprint Goals
Sprint Demonstration
Review Feedback

Scrum Reports:

Burndown
Velocity
Controlchart
QA Failure

Sprint Retrospective:

Retro Q&A

Risk Management:

Identifying Risks
Analyzing Risks
Prioritizing Risks
Developing Risk Reduction or Management Strategies
Monitoring and Updating Risks

Sprint Planning:

Next Sprint Planning

“Completed Sprint Goals”

Let’s start with the “Achieved Sprint Goals”.
These goals are the parts of the product goal.
Simply, “Product Goal” is broken into the “Sprint Goals” to create a desired and competitive product.

“Sprint Demo”

The Presentation: Sprint Demo is a presentation of the completed issues (“Increment”) in the previous sprint.
From: Scrum Team presents their completed works in this meeting to the client / stakeholder.
To: The Slient / Stakeholder approve or reject the completed works in the sprint.

JQL All Team:     
 project in ( [ Project Name ] ) 
 AND Sprint in ( [ Sprint ID Value ] ) 
 AND status was in (Done) during (2021-01-08, 2021-01-09)

JQL Developer Name:    
 project in ( [ Project Name ] ) 
 AND Sprint in ( [ Sprint ID Value ] ) 
 AND status was in (Done) during (2021-01-08, 2021-01-09)  
 AND assignee =  [ Developer Jira User Id ]

--------------------------------------------------------------------

(The last day of the sprint - 2021-01-08, 2021-01-09)

“Review — User Review / Feedback”

The Client / Stakeholder gives their feedback about the “Increment” that Scrum Team developed.
The client may approve or reject this developed new feature of the product.
The client may / not have some new requests regarding to the completed issues.
If the client have some new requests, these requests are created as a story in Jira Backlog and based on the priority, these stories are moved into the next sprint backlogs.
Scrum Team (Product Owner) takes this feedback.

“Sprint Retrospective”

During the Sprint Retrospective, the team discusses:

What went well in Sprint?
What could be improved?
What will we commit to improve in the next Sprint?

Have we added a new issue to sprint after start time ? Why ?
Did we have any trouble with our clients ? Why?
Have we ever been blocked by other teams during the sprint ? Why?

Unfinished User Stories

Do we have ‘’Developed’’ but ‘’Unfinished’’ User Stories in this sprint ?
What are these ‘’Developed’’ but ‘’Unfinished’’ User Stories in this sprint ?
How will they be broken down ?

How can we break down “Developed” but “Unfinished” issues in an “Active Sprint”. and move them into the next sprint backlog?
At the end of the sprint time box, if we have the remaining issues in the following statuses such as Blocked, Review, QA Test, QA Prod;
And if these issues have already been “Developed” but not tested / released yet.
The solution for “Unfinished” issues;
1. “Epic”: Firstly, as “Parent Issue” an “Epic” is created.
2. “Development” / “Analysis”: The summary of the remaining issue in the sprint is renamed as “Analysis” or “Development”.
The story point should be decreased.
Without Review / QA Test / QA Prod or without release, this renamed issue is moved forward to the “Done” status.
3. “Review / QA”: As a child of the Epic parent issue,
Incomplete “Review / QA Test / QA Prod” issue is created in backlog
This new “Review / QA Test / QA Prod” issue is linked to its “Development” issue.

“Product Quality | Definition of Done (D.o.D)”

During the Sprint Retrospective, the team improves “D.o.D”.

Will we add a new D.O.D. item to the list ?
Will we remove a D.O.D. item from the list ?
What are the items of D.O.D ?

“Bottleneck | Roadblock”

JQL results can be displayed and the causes of the roadblocks are discussed. Also the notes are taken to overcome this issues in next sprint.

What are the causes of Blocked User Stories ?

project in (XYZ) AND Sprint in (5) AND status was in ("Blocked") during (2022-12-08, 2022-12-23)

What are the causes of failures in Code Review ?

project in (XYZ) AND Sprint in (5) AND status was in ("Code Review") during (2022-12-08, 2022-12-23) AND status changed from ("Code Review") TO ("To Do", "In Progress") during (2022-12-08, 2022-12-23)

What are the causes of failures in QA Stage ?

project in (XYZ) AND Sprint in (5) AND status was in ("QA Stage") during (2022-12-08, 2022-12-23) AND status changed from ("QA Stage") TO ("To Do", "In Progress") during (2022-12-08, 2022-12-23)

What are the causes of failures in QA Prod ?

project in (XYZ) AND Sprint in (5) AND status was in ("QA Prod") during (2022-12-08, 2022-12-23) AND status changed from ("QA Prod") TO ("To Do", "In Progress") during (2022-12-08, 2022-12-23)

“Sprint Reports”

The following reports are used for Sprint Retrospective .

Burndown Chart
Sprint Report (Jira)
Velocity Chart
Control Chart
Cumulative Work Flow Diagram

“Sprint Report”

The following report results are extremely valuable informations for “Sprint Retrospective”.

Commitment
Completed Issues
Issues Not Completed
Added To Sprint (After Start Time)
Removed From Sprint (After Start Time)

“Burndown Chart”

This chart is used for the following events “Daily Scrum” & “Sprint Retrospective”

The following topic is discussed based on Burndown chart.

How did the process actually go?

“Velocity Chart”

The following topics are discussed based on Velocity chart.

This chart is used for Sprint Retrospective (Mostly).

What is the capacity of the scrum team?

Sprint 1 =  80 Story Point (Completed)
Sprint 2 =  70 Story Point (Completed)
Sprint 3 =  90 Story Point (Completed)
Sprint 4 =  85 Story Point (Completed)
Sprint 5 =  75 Story Point (Completed)
80 +  70 + 90 + 85 + 75 = 400 / 5 = "80" Story Point / Sprint (Velocity)

What is “Throughput” of the team in Scrum?

Sprint 1 =  10 Ticket (Completed)
Sprint 2 =  15 Ticket (Completed)
Sprint 3 =  15 Ticket (Completed)
Sprint 4 =  20 Ticket (Completed)
Sprint 5 =  50Ticket (Completed)
10 + 15 + 15 + 20 + 50 = 110 / 5 = "27" Task / Sprint (Throughput)

“Control Chart”

Bottleneck || Roadblock

The following topics are discussed based on Control chart.

“ How many issues have taken too long to move to the next status? “

Do we have a ticket/issue with the same ”Story Point” but it has different ”Cycle Time” in “Control Chart” ?

The works may have the same story point. But if the cycle times are different for each issue, this situation indicates the “Story Estimation / Approximation Problem” in planning.

For example;

Some of them are above or some of them are below the average line. The Control Chart Report shows up that issue on chart easily.

It’s viewed by Status selection & Quick Filter (Story Point) based on filtering in Jira Control Chart.

“Bottleneck || Roadblock”

“ How many issues with the same story point have taken much longer to be developed than the others?”

For example;

Select “In Progress” from the columns dropdown firstly.

Then click the green dots and view the cycle time of the ticket.

* The time length can be viewed by filtering from Status / Column drowpdown in Jira Control Chart.

“Risk Management”

Step 1: Identifying Risks Identify potential risks for your software project. These risks can exist in different areas of your project, such as the timeline, budget, quality, and scope. Sample risks may include:

Lack of skills among developers
Risk of using new technology or language
Changing requirements and scope
Risk of data loss or security breach
Risk of external dependencies failing

Step 2: Analyzing Risks Analyze each risk and evaluate their potential impacts and probabilities on your project. This will help determine the severity of the risk. For example, the risk of a lack of developer skills could significantly impact the project’s success, making its severity high.

Step 3: Prioritizing Risks Prioritize the risks. Give priority to risks with high severity and high probability. Address these prioritized risks first and develop measures accordingly.

Step 4: Developing Risk Reduction or Management Strategies Develop reduction or management strategies for each prioritized risk. For instance, to reduce the risk of a lack of developer skills, consider additional training or seeking external assistance.

Step 5: Monitoring and Updating Risks Regularly monitor and update risks throughout the project. New risks may emerge, or the impact of existing risks may change. Therefore, it is essential to continuously review your risk management plan.

Risk Management Report: (Example)

Project Name: Software Development Project
Date: January 18, 2078
Prepared by: [Your Name and Position]

Identifying Risks:

Risk 1: Lack of developer skills
Risk 2: Risk of using new technology
Risk 3: Changing requirements and scope
Risk 4: Risk of data loss or security breach
Risk 5: Risk of external dependencies failing

2. Analyzing Risks:

Risk 1: Lack of developer skills could significantly impact the project. Probability: High, Impact: High
Risk 2: Risk of using new technology could cause project delays. Probability: Moderate, Impact: Moderate
Risk 3: Changing requirements and scope could exceed the project budget. Probability: Moderate, Impact: High
Risk 4: Risk of data loss or security breach could jeopardize the project’s reputation. Probability: Low, Impact:
High Risk 5: Risk of external dependencies failing could lead to project delays. Probability: High, Impact: Moderate

3. Prioritizing Risks:

High-Priority Risks: Risk 1, Risk 3
Moderate-Priority Risks: Risk 2, Risk 5
Low-Priority Risks: Risk 4

4. Developing Risk Reduction or Management Strategies:

Risk 1 (Lack of Developer Skills): Enhance developer skills through additional training and team-based education.
Risk 3 (Changing Requirements and Scope): Improve regular customer communication and enhance processes for better requirement definition.

5. Monitoring and Updating Risks:

Risks will be regularly reviewed in retrospective events, and the risk management plan will be updated based on project progress.

“Next Sprint Goals”

The next sprint goals are determined by product owner.
These goals are the parts of the product goal.

“Sprint Planning”

The story points of the completed sprints are listed in the following table below.
The story point of active / future sprint is also listed in this table.
If the story point of the active sprint is too low or high, scrum team can add or remove a new issue from backlog based on these values.

project in ( [project_name] ) 
AND Sprint in ( [sprint_number] ) 
AND status was in (Done) during (2021-11-24, 2021-11-25) 
AND assignee = [developer_jira_id]

Also you can easly get the sum of the “Total Story Point” value through the following js code snippet below in console while your filtered JQL table is open. (inspect in browser first).


// JIRA TOTAL STORY POINT CALCULATOR //
var rowValues = $('.customfield_10026'), 
sum = 0;

$.each(rowValues, function(value) {
  
  var oneRowValue = parseFloat(rowValues[value].innerHTML);
  sum += oneRowValue ? oneRowValue : 0;

});

console.log('Total Story Point:  ' + sum);