I would like to be able to report on time spent on issue type or issue category without burdening developers with full time tracking.
For example, I may create a field on issues where you select whether it is a new feature, feature iteration, or production fix. From this I should be able to see what proportion of story points are attributed to each category. But I can't attribute time to those categories without getting the developers to log time spent... which seems like overkill.
What I'd like is a way of recording the man days in a sprint. Then I could easily calculate the proportion of man days gets spent on each category. But is anything like this possible?
Any help much appreciated!
John
Hi John,
We make a marketplace app called EasyTime, which is meant to solve the same problem (not wanting to waste developer time / effort on manual time tracking - which is usually not accurate)
However, our solution is completely different from what I think you are asking for and I am just curious for a little more detail on how you think it would work.
Am I right in understanding you are after something that divides the total time in a sprint evenly between issues? For example, if you are running two-week sprints and a developer has ten tasks, then to log 8 hours on each task? I don't quite see how this could possibly give an accurate result?
For contrast, our solution works simply by logging time, whenever a developer views an issue for an extended period of time, comments on the issue, or closes the issue - and seems to give a good starting point.
It will probably help if I explain the 'why?'
I am not really interested in tracking time in detail but I would like to know what proportion of time is spent on what type of work. For example, if a team is spending half its time working on live incidents then that is something I would like to know so that we can look at how we can improve that.
Say I had a sprint with 10 issues - 2 production fixes, 4 iterations of existing functionality, 4 new features - and each issue has a story point value against it - 4 SP of production fixes, 6 SP of iterations and 10 SP of new functionality. From that I could see that the weighting of work was roughly:
20% production fixes
30% iterations of existing functionality
50% new features
But the number of man-days per sprint will vary depending on holidays, sickness etc. If I could save the number of man-days against the sprint I could then work out the approx number of hours/days got spent on each type of work in that sprint.
And, come end of year, I could show the total time and therefore cost of each type of work which would prove very useful in several ways, not least when working out R&D tax credits.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @John Cross ,
Thanks for reaching out, and for any kind of automation in the time tracking you will want to look into marketplace apps that add in this type of functionality.
The following threads have several recommendations on different apps that might work for you here:
Regards,
Earl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.