How to track unproductive work in JIRA which might be productive in other project?

Question

Hello,

My team sometimes get adhoc work which they cannot avoid and thus few sprints get delayed, is there any way to track this unproductive hours?

Even If I label them they might be productive for some other project of workstream how do I track these.? Thank you.

Lisa Forstberg_o85gu4 · Accepted Answer

Hi @ananya pandey ,

Welcome to the community!

I see the pain, the team feel that they are "disturbed" and might feel unproductive for not finishing the scope of a sprint. I think labelling this work "unproductive" might not help...it may very well be productive hours, and the correct decision to take to help other parts of the business as a whole :-D

Anyhow, as a part of the sprint review it might be helpful to produce a filter of issues that was not in the sprint but the team was involved in to get the whole picture of what happened during the time period of a sprint.

Are your team members assigned to these tickets then it will be easy to produce such a jira filter, example:

assignee in (member1, member2) AND updatedDate >= date of the sprint start AND updatedDate <= date of the sprint end

maybe you want to remove those issues that was in the real sprint from the query to get to the ad hoc work.

Best regards

Lisa

Bill Sheboy · Accepted Answer

Hi @ananya pandey -- Welcome to the Atlassian Community!

At the daily scrum (i.e., standup) the team can see what is being worked on and progress toward the sprint goal.  This will be an earlier indicator of unplanned work, without the need for detailed measurement.  Some teams might use lightweight methods, such as "paperclip" to track such things.

At the sprint retrospective, the entire scrum team reviews what happened and how they will experiment to improve.  If the team reviews what they planned relative to what was achieved, they may use root cause methods to identify the possible causes and how to address them.  For example, listing each unplanned and incomplete item to discuss "why did that happen".

And so the variance between the team's sprint goal and delivery is the indicator, and the "what happened" is data to see the other sources of work, team / process challenges, etc.  Using this approach may be more effective to help than creating a tracking / reporting system for work that either should not have been done, or perhaps was missed in refinement and planning.

Kind regards,
Bill