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
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.
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?
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.
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.
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
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
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. :-)
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events