Daily Ticket Update Report

[David Hansen]

I would like to have a report that shows if a list of tickets by Engineer and if they were updated with the progress of the engineer each day over the length of the Sprint. 

Anyone have anything like this?

[Yuliia_Borivets_[SaaSJet]]

Hi @David Hansen 

I suggest two solutions that can help you check the daily report of updates made by an Engineer or any specific user.

1. Activity Stream Gadget – a built-in option you can find on the Jira dashboard. 

You can set a specific date, choose a user, and get all changes as a stream of activities.

2. Issue History for Jira: My team developed an app that allows users to view daily updates in different views (table, stream, gadget) with multiple flters (sprints, dates, fields, etc). Check how it works with a free 30-day trial.

You can customize the report to your needs. For example, choose only specific field/fields (comments, statuses, due dates, etc) and see their updates.

Here, you can see the comments:

[Walter Buggenhout]

Hi @David Hansen,

It would be best to break down your requirement and see what you want to get out of this. "Updates" can be different things: they can be status changes, they can be worklogs being added, they may even be updates to custom fields on the issues. There may even be updates to code or work that is happening outside of Jira that is also progress that you don't see. 

Your question slightly scares me a bit, since it very much goes into the direction of tracking individual productivity, or benchmarking engineers against each other, and that very quickly becomes risky business in a team.

There are several ways to track progress, but at the team level rather than individual. To monitor progress in a sprint, you could leverage existing scrum reports available through your board:

• use the cumulative flow diagram to monitor progress of issues through workflow statuses to identify bottlenecks there;
• Use the sprint report to see if work is progressing as you may expect;
• Use the burnup chart to understand how work is progressing through the sprint;

With those, you are looking at the performance of your team as a whole. They don't show you how individual people may be slowing you down, but they make it clear where you may be off track, information you can use to talk with and address issues as a team.

To discuss progress, there is the daily standup. If everyone shares with the team what they've worked on, what they will be working on and where they need help, you can stay in the loop and adjust where necessary.

You can put information on a dashboard pretty easily, by pulling the issues in your sprint in a filter and then add a few gadgets to slice this:

Project = "My Team's Work" AND sprint in openSprints()

That JQL would dynamically show you a list of issues in the current sprint. A benefit of that filter, is that you don't have to update it when you start a new sprint. You can add a couple of gadgets to your dashboard to build an actual sprint dashboard:

• a sprint health gadget to show the actual progress
• a sprint burndown gadget to display the progress trend
• a two dimensional filter statistics gadget by assignee and status to show who is working on what and what status the work is in
• a filter results gadget with a list of impeded issues
• ...

Focus on the things you want to improve. And use the dashboard in meetings with your team to work on those areas continuously, rather then to report after the facts.

Hope this helps!

[David Hansen]

Im not looking to track individual productivity or pit engineers against each other, I understand the danger there. What I am trying to do is to help my team see if they are meeting their goal of adding comments to their tickets each day about the work completed. 
I currently have a widget that shows if a ticket has been updated in the past 24 hours, and we do use that in our DSU, but I have not been able to come up with a historic view to see how we are doing as a team during our retrospective. 

[Walter Buggenhout]

Glad to hear that, @David Hansen!

If the goal is to have a daily update on issues, I would say that is the interval at which you should follow up as well.

Since you use sprints, you could add 2 simple quick filters to your board. One to list issues that were updated and one with issues without updates:

updated > startOfDay(-1)

and the opposite:

updated < startOfDay(-1)

If you have the board at hand during your standup (or at any time during the day), you will be able to easily see issues that were in progress but not commented. Immediately ask people to provide those updates on an ongoing basis. 

[David Hansen]

I like that idea. To specifically call out those tickets that are missing comments from the previous day and ask for updates. 

But I would still like to come up with some way to show that for our Sprint, we were able to hit 98% daily comments on our tickets or something to that effect. 

[David Hansen]

This is the widget I currently use in our DSU to show those tickets that were updated in the past 24 hours. 

[Walter Buggenhout]

The agile coach in me is now screaming out: @David Hansen, why 😱 ???

I am sure you identified an issue with communication within your team. That happens in the best of teams. But what was the deeper underlying problem you were seeing and are trying to solve by this? 

I suppose the purpose of your team is to deliver working software. Or deliver world class service to customers. And do this on time and at outstanding quality. How would proving you succeed in commenting on 98% of your issues on a daily basis help that real mission forward? I am quite sure some clever folks are soon going to find out they can automate putting a comment on issues to bring that score up to 100%, but does that make your software or service any better?

You could keep an excel file on the side where you make a daily note of how many issues were updated on that day, how many were commented and use the difference between both to calculate the total score for that day. That shouldn't take you more than 5 minutes each day. You may be able to solve this with a reporting tool like EazyBI e.g. so you can eliminate these 5 minutes a day and save about 2 entire days on reporting each year - but how does that improve your team? What does it account for with stakeholders? ... ?

If you would like to invest in reporting tools to display trends, why not focus on the number of quality issues versus the amount of features you deploy? Or on the lead an cycle times of your team's work? Or on customer satisfaction rates? ... ?

Sorry for being a bit persistent on the subject, but I really think it's great if you could think beyond the initial requirement and get to the real problem you're trying to fix.

[David Hansen]

We have identified that not updating your tickets regularly with the progress you have made can be a point of failure. We have had experiences where a team member was out of the office near the end of the Sprint due to unplanned situations. If they had not added their documentation of work completed to the Story, then we as a team are struggling to determine what was done and what still needed to be done to get the Story over the finish line. 

Additionally, daily documentation helps with the DSU adage, "Tell me what I need to know that is not in the ticket."

So, as a team we made the commitment to add comments daily. I want to be able to show the team how they are doing.  You can't improve on what you don't measure.