How to handle time spent not directly related to an Issue

[Harmen Coops]

Currently I run two development teams. Both using Jira. What I see is that if only time directly related to Jira Issues is registered the time reports are not useful for me. The thing I miss are the hours spent on for example refinement, planning, daily stand-ups and so on. Because they're not registered in Jira. In the end it looks like only 35-45% of the actual time available is spent on development and testing. Does any of you have a simple way to solve this using time tracking in Jira? Preferably I do not want to introduce another tool to register the indirect hours.

Thanks for any response that can be useful

[Warren]

Hi Harmen

In my company, we do something which I'm not a fan of, but may solve your issue.

We have a separate Jira project which is used for all non-project time. Until recently each sprint meeting was a separate Jira task that everyone logged time against, but now it's been simplified to one task for sprint meetings, one for other internal meetings, one for training etc.

I hope this helps you

[Harmen Coops]

Hi Warren,

I'm playing with this thought. Why are you not a fan of it?

Cheers!

Harmen

[Warren]

I feel that the ideal Scrum way is that the team's time isn't closely monitored, as long as they are achieving their sprint commitments. My team were spending a fair amount of time logging time against a different task for each of the sprint meetings, plus there were tasks for training, leave, public holidays, external meetings, other internal meetings ..... I wasn't a fan of that, but now it's simplified to only 4 tasks which is better

[Harmen Coops]

Ok. I will give it a thought to implement it like that. Thanks!

Harmen

[Jack Brickey]

I tried a similar method but found it to be busy work for the team. Without going into lots of details we ultimately assessed each persons velocity and worked to book their sprint time accordingly. Typically we booked folks at 80% to account for overhead. If individuals took more than a day of vacation we created a task for it and logged their time. This allowed us to more effectively assess burn down. Unsurprisingly, the long holiday weeks produced a near perfect burn down. :-)

[Harmen Coops]

Thx. I'll find my way to tackle this.

[Boris Berenberg - Atlas Authority]

You can either make generic tickets to track that, or more commonly, you accept that yes, only 35-45% of the time is actually spent on development and there is significant overhead to teamwork and collaboration.

[Harmen Coops]

Thx for the answer Boris.

If I could rely on good registration of the work done. I could accept the outcome of 35-45%. But now I simply don't know where it comes from and if it's right. That's why I'm looking for a simple way that makes it possible to add up the hours to the #hours contracted.

What's your experience, is it common to have about 40% of the hours actually spent on development en testing?

Cheers!

Harmen

[Boris Berenberg - Atlas Authority]

If they go to a standup and talk about 7 issues, where do they log the time? If someone on the team asks them for feedback on a generic concept that spans the project, where does time get logged? Random walkups? Etc etc etc.

It honestly sounds like your team needs to look at culture more than tooling. Try looking at https://www.atlassian.com/team-playbook/health-monitor to help build alignment and shared understanding in the team.

[Harmen Coops]

To start with the first questions; The team doesn't log time at the occasions you've mentioned.

I'm fully aware of the importance of working on the culture aspects. To be honest naturally that has my preference to work on. But I think is this situation we should both. Tooling and Culture. I took a look at the health monitor and for sure I will use that one in the coming week(s). 

I'll keep you posted on the progress.

Cheers!

Harmen