Bug tracking, logged time statistics

[Verbuk Artem]

Hi

It will be a long story. Can't explain it short.

Assume for a minute you came to a great company, which has a great product. The company grows rapidly, and has a code base that becomes a disaster :)

The whole company, starting from 3 developers to 50 in few years, was coding to deliver, without noticing how they forget to refactor and sometimes even design. And in some way they did a great job, product is the leading one, and they grew.

They grew even to employ someone, who sees the problem, and wants just to convince others to start coding in a better manner. This person is convinced, that the company now bears immense cost of development for every small bit of functionality they want to add.

Ideally, this person wants to show something like the following:

During development of release K+2 logged time distributes as

• 10% - develop new features
• 20% - fix bugs found by QA in new features of K+2
• 50% - fix bugs, that were introduced while fixing different bugs during K+1
• 20% - fix bugs, that were introduced while implementing K+1 features

Yep, the company already use JIRA. 

So, the question is:

Assume that the person who fixes the bug is smart enough to find when the bug was introduced. The person will have this information once he knows how to fix the bug, and has Git to find out when and why some code was created/modified.

Can we use JIRA to show such statistics? Even approximation is good.

If JIRA could be used to show those things, what we need to start doing? I mean, probably we need to start linking items, use some tagging etc.

What would you suggest us to do?

Regards

[Jakub Sławiński]

Hi @Verbuk Artem ,

interesting and unfortunately extremely common challenge in the software development industry (tech debt overwhelming dev teams after some time).

Making long story short, we can divide this issue into two areas:

1. Proper time logging.

I saw many different techniques used by different companies. People are using labels, issue types combined with fix versions, epics, components, custom fields like cost centre, etc. At the end you should be able to see that the time logged to issue X should be treated as the time spent on "fixing bugs, that were introduced while fixing different bugs during K+1". Without knowing what is your company's time logging policy it is hard to advice anything.

2. Data visualization.

When you have properly logged time in your Jira, you have to display it. You can use one of the many worklogs apps available on the marketplace, for example Worklogs - Time Reports for Jira

Please let me know if you find a way to avoid/control such overwhelming tech debt crisis ;)

Good luck!

Regards,

  Jakub.