nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Reporting on a sprint

Gary McDermott_y1jvp3

Hi All,

I work at an I.T. company, we run 2 week sprints across quite a big team (20 people) I am looking for a suggestion as to how to provide more accurate reporting back to the business. My issue is that let's say a ticket starts a sprint with a BA, once reviewed and considered developer ready, it will then form part of the next sprint. The developer will then work on the ticket and pass it onto the QA team, who will test and pass back to a developer if any issues are found. The developer will then address the issue and send back to QA for re-test. My issue is that its common that tickets are overlapping across 2 2 sprints because of some back and forths. I dont know how to best pull a report for this to accurately report back to the business as its hard to pinpoint the total life span of that ticket into a report, from creation, to to BA, to dev, to QA and finally to deployment.

Any suggestions would be welcomed as to how I can use Jira reporting, ideally free versions however if there are paid extensions to make reporting much easier to present etc then I am happy to get some ideas so long as it serves its purpose.

Thanks

Accepted answers

All comments

Antuan Sammak

Hi @Gary McDermott

Welcome to the Atlassian Community!

I would appreciate if you would be willing to give a try for our new application it offers a new approach of reporting that shall help your organization and teams to analyze teams performance and identify potential improvements.

Basically, it allows you to create a release version based on start/end date and a board of your selection. Then it will group all tickets under that board which were resolved during the time range you specified under one version, then a report will be generated based on the tickets data inside your releases.

The report consists of a comparison between Original Estimate / Time Spent during release window only / Overall Time Spent.

So in your case, you can easily create one release for each sprint then at the end you will have a comprehensive graph that shows you the amount of time spent over the last few sprints and can tell you exactly in which ones you had bottlenecks or delays.

Feel free to reach for any further clarification and I would be happy to support.

Hope the above helps!

Bill Sheboy

Hi @Gary McDermott

You describe a large team using Scrum, has some role-silos, has rework, which sometimes carries over work between sprints, and want to improve visibility of "total life span" to stakeholders.

Perhaps first discuss this with the team in a retrospective, performing a 5-whys exercise to better understand the reasons for the rework (back and forth between role-silos) and why things carry over. These may indicate challenges with backlog refinement, sprint planning, focus on the work of the sprint, WIP issues, etc. After this discussion the team may realize there is something to try as an experiment to improve.

The team could immediately make visible the lead time (i.e., duration from create to done) or the build cycle time (i.e., duration from start of work to done) using the built-in control chart report. It has some limitations, so take a look here to learn more: https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-control-chart/

You also describe a couple of types of churn: by role-silo (perhaps indicating rework) and by sprint. These are harder to see with the built-in tools, and so you could consider either marketplace addons or use custom fields and automation rules to track these types of churn so the team can manage them.

Kind regards,
Bill

Valeriia_Havrylenko_SaaSJet

Hi @Gary McDermott 👋
For more accurate reporting back to the business , I suggest you to try Time in Status for Jira Cloud (developed by my SaaSJet team). Our app has a lot of possibilities for Jira reporting. We have 7 types of status time reports such as Time in Status, Assignee Time, Average Time. All the reports you can display as Pie, Bar or Area Charts.

Time in Status .png

Also you can get cycle and lead time to uncover bottlenecks and delays

Cycle_Time_in status.gif

And last, but not least - we have Sprint Performance Report Sprint Performance Report where we have all the metrics for easy reporting.

SP TV (1).png
This add-on has a 30-day free trial version and unfortunately our add-on free up to 10 users.

You can also book a live demo - we'll show you the application inside out and answer all your questions.

Hope it helps 😌
Valeriia

Gary McDermott_y1jvp3

Hi @Valeriia_Havrylenko_SaaSJet that looks fantastic, the only thing is, you say its only 10 users? as i have 20 users this wouldnt quite be fit for purpose as i need to report on all users. Have I understood this correctly? Do you have plans to increase this number? thanks

Gary McDermott_y1jvp3

Hi @Bill Sheboy when we do sprint planning we tend to load the sprint up to 70% capacity to allow for unforeseen issues that will arise from the business. Working in I.T this is inevitable. Should a dev be at 100% capacity, I as TL will if completely unavoidable, swap out a ticket of less significance and similar effort i.e. 3 hours of dev time, for the ticket/issue needing to be done.

Lets say a sprint starts on Mon 4 Dec to Fri 15 Dec......a dev might start the tikcet on 13 Dec, and complete by mid afternoon on Thur 14, that will then need a Pull request before going to QA, lets say that happens on Fri 15 Dec, QA however may not have capacity to pick that ticket up to test until Mon 18 Dec, by which a new sprint has started. Even if that ticket has no issues, it will for reporting purposes take 2 sprints to complete. I am trying to explore a simplified way to report back to the business as the above is a very common scenario. You mention marketplace addons or use custom fields and automation rules to track these types of churn so the team can manage them. Are you able to share any further info on that please?

Bill Sheboy

First thing, that description seems to indicate a sprint planning issue: bringing work into the sprint which cannot complete, due to team capacity and the handoffs of work by skill areas. Normally this can happen when unexpected work arrives to disrupt the sprint plan, and can be mitigated by creating smaller work items so they finish faster.

For the reporting needs, you may check the Atlassian Marketplace for addons for JQL as they may allow counting the number of values in a list field, such as Sprint. I do not have experience with those, so I recommend searching for them and perhaps trying some as a trial.

To instead do this with a custom field and automation rules, you could:

Add a custom number field, perhaps named Sprint Count
Create an automation rule triggered on Sprint Completed to update the count. For example:
- trigger: sprint completed
- branch: on issues in sprint
  - action: edit issue, updating the Sprint Count field with this smart value to count the sprints the issue was in
    - {{issue.sprint.size|0}}
If you want data from before you add the above rule...
- Add a temporary, second rule. This one would have a scheduled trigger and JQL to find completed issues which have an empty Sprint Count field. Add an action to set the field, and let the rule run every few minutes until it catches up the data...and then disable this rule.

Valeriia_Havrylenko_SaaSJet

@Gary McDermott Hi again 😌
Of course, you can use our add-on with 20 users. The number of users is not limited; reports will work with any number of users.
I pointed out that our addon is free for up to 10 users.

Mehmet A _Bloompeak_

Hi @Gary McDermott

As an alternative, you can try Status Time Reports app developed by our team. It mainly provides reports and gadgets based on how much time passed in each status.

Here is the online demo link, you can see it in action and try without installing the app. For further details, you can have a look at Status Time Reports How to Videos.

This app has a dynamic status grouping feature so that you can generate various valuable reports as time in status, time in assignee, status entry dates and status counts, cycle time and lead time, average/sum reports by any field(e.g. average in progress time by project, average cycle time by issue creation month).

You can search issues by Project, Issue Type, Status, Assignee, Issue Creation/Resolution Date(and any other Date field) and JQL Query.
Status durations are calculated according to the working calendar you define. Once you enter your working calendar into the app, it takes your working schedule into account too. That is, "In Progress" time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM, will be a few hours rather than 3 days.
You can set different duration formats.
You can export reports in CSV file format and open them in MS Excel.
You can also add this app as a gadget to your Jira dashboards and reach “Status Time” from Issue Detail page.
You can enable/disable access to Status Time reports&gadgets and Issue Detail page per project, users, groups or project role.

If you are looking for a completely free solution, you can try the limited version Status Time Reports Free.

Hope it helps.

Gizem Gökçe (OBSS)

Update on May 9th, 2024: Time in Status by OBSS was recently rebranded as Timepiece. It is still the same capable app with the same dedicated team behind it. The answer below mentions the app as "Time in Status" but you can find the app in the marketplace as "Timepiece (formerly Time in Status)".

Hello @Gary McDermott ,

As far as I understand, your primary choice is not a paid solution, but if you would like to evaluate it, I would like to introduce you to a very advanced tool with which you can easily access the reports you request.

I can recommend Time in Status which is built by my team at OBSS. It is available for both Jira Cloud, and Data Center.

Time in Status mainly allows you to see how much time each issue spent on each status or each assignee.

tisCloud_StatusDuration_LeadTime_with Estimates.png

You can combine the time for multiple statuses to get metrics like Issue Age, Cycle Time, Lead Time, Resolution Time etc.

You can easily use your predefined sprints as filter type and you can create reports calculated specially for your sprints.

Filter Types Sprint.png

For all numeric report types, you can calculate averages and sums of those durations grouped by the issue fields you select. For example total in-progress time per customer or average resolution time per sprint, week, month, issuetype, request type, etc. The ability to group by parts of dates (year, month, week, day, hour) or sprints is particularly useful here since it allows you to compare different time periods or see the trend.

Report Types Any Field Duration 2.png

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well.

Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts. And the app has a REST API so you can get the reports from Jira UI or via REST. Also you can export the reports in to various formats easily.

Visit Time in Status to explore how our JIRA add-on can revolutionize your metrics measurement process. Enjoy a 30-day free trial to experience the full range of features.

If you wish, you can also schedule a live demo. We will provide a comprehensive overview of the application and address any inquiries you may have.

Hope it helps,

Gizem

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

atl-gruland