31

I've always had this struggle to get folks to update their issues, both at my company and at work. I've had a few cases when people actually do it from the goodness of their heart, but ~70% of the time I have to be chasing people down.

Being the one that generally does some or other form of management (I am firstmost a developer), the main reason I try to give is that I don't want to be chasing people down and interrupting to query on progress, but I don't think in the end people mind that much being asked. In some rare and extreme cases I end up updating their tickets (when I need to create reports).

So, have you ran into this problem?, how have you encouraged developers to update the issue tracker frequently?, what degree of success have you had?

|improve this question
  • 21
    From personal experience the problem lies in the mentality that updating the issue tracker and keeping proper documentation in general is not as important as coding. And while this is a somewhat natural mentality for a developer, it shouldn't be for management and the company in general. Is your company treating that part of the work as equally important as coding? If not, you should start there, developers are smart and adaptive, if they sense that the company actually considers this a big deal (with praise when done right and consequences when not), they'll soon start doing it right. – yannis Mar 21 '13 at 6:44
  • @YannisRizos This comment is good enough to be an answer – dukeofgaming Mar 21 '13 at 6:47
  • 14
    Ah! I can't even get my boss to use the issue tracker. He walks by, speaks rapidly about "stuff" and leaves. I call that "drive-by bug reports". I actually get ridiculed for using the issue tracker... I sense some frustration in the Force. – MetalMikester Mar 21 '13 at 10:56
  • 3
    imo, most of the 'issue trackers' I've seen suck pretty bad - the ui's end up too cumbersome (so they can handle special cases). So if you were to ask me why I dont use them, thats why. – GrandmasterB Mar 23 '13 at 22:56
  • 1
    Effectively, ensure that you have an application that works well, is easy to use, is fast and do not require too much information to be entered. Also, defects need to be classified like what to do in next release and entered information must be used. For example, if a developer explain everything properly but you are too lazy to read it and instead go ask him, then obviously one would lost the motivation to use the system as it is very frustrating to explain the same thing twice. – Phil1970 Jun 12 '17 at 23:38

10 Answers 10

30

The reason is they don't grok why they should be updating the issue tracker, apart from the fact that you say so.

Why is that? My guess is that updating the tracker doesn't affect their job in any meaningful way, so the solution is probably to implement a tracking system which actually helps them do their job better.

|improve this answer
  • "implement a tracking system which actually helps them do their job better." Can you give an example? Of something that helps them that is, not a specific tracking system. – Burhan Ali Mar 31 '13 at 11:24
  • 2
    @BurhanAli No I'm not in a position to tell them what works for them. They need to figure that out for themselves. Suggestion though: start with something simple and use weekly feedback to improve it. – Martin Wickman Apr 1 '13 at 7:18
  • Your team may vary, but as an example, I started being much better about updating the issue tracker when I started using it as a communication hub so I wouldn't be interrupted as often while deep in the code. – Morgen Jun 16 '17 at 14:47
13

It's hard, because employees clearly feel that updating issue tracker is not important. You have to change that, but there's a catch. Communication is hard. Effective communication is really hard -- way harder than you might think it is. So hard, that communication usually fails, except by accident.

Show, don't tell. Eg. don't tell that you (or your boss) need the data for a report. Show from employees' point of view how up-to-date issue tracker affects and helps them.

Lead by example.

|improve this answer
10

I'm a developer and struggle to use the issue tracker we have at work. This is unfortunate because I am all for them to keep things organized. My solution for the moment is to use a personal tracking tool and reference it to talk about progress at our daily scrums.

Here's what would make me use the tracker all the time:

  • Seamless integration with the IDE and source control. We use some clunky webapp because licenses were already purchased for it. It takes forever to create/update tasks, and has some confusing UI features. Unfortunately using this is beyond our team's control.

  • Simplicity. By this I mean not taking 10 manually populated fields just to add a task. Hourly estimates vs. completion time, manually entering the project/component/etc. in several fields, etc. just increase the amount of time.

  • Only one. Not sure how common this is, but project management uses one tool, support uses another, and development uses a third. If one doesn't get updated, three certainly aren't and synchronizing between them is unlikely to be automated.

|improve this answer
8

First of all: what do you mean with "people updating their progress"?

Do you mean "developers updating the current estimation", or "developers not setting an issue to resolved", or rather "customers/testers not closing a resolved issue", or all together?

From a developer's perspective, it is a mixture of mindset and culture.

  • mindset: when you set an issue to resolved it means you are done, and responsible if it is buggy
  • culture: if the whole company is not very keen to use such tools, but prefer other organisation strategies

My experience is: you need the culture to point in the right direction, at least. What helps next is to define a DoD (definition of 'done') - if a developer (works for other roles, too) can say (s)he fulfilled the whole list it's relieving to mark the issue resolved and move on with no need to look back.

|improve this answer
5

Stop asking about coding progress (its usually an arbitrary percentage plucked out of thin air anyway) until the ticket is closed give no credit. If the main thing you measure is number of tickets closed it will improve.

Do note however that all metrics can be gamed and metrics tend to work better when teamed up with complementary metrics e.g. you probably also want to look at issues that get reopened as this implies they are being prematurely closed

|improve this answer
5

As pointed out by some other answers, the right question here is probably: why do you have an issue tracker. A good answer to this question (not just from a management perspective but also from a developer perspective) is imperative if you want an issue tracking system to really work and be regularly updated.

In many companies the issue tracking system is mainly used as a management reporting tool. Getting programmers to update issues just so that management can run a report does not work well. And forcing programmers to update issues does not work either - you may have updated issues but you should question the data.

In my experience, the only way to really have developers (and testers, management, etc.) effectively use an issue tracking system is to integrate it into the development process. This means that the output of one part of the process becomes the input to the next part of the process.

To give the bug tracking system authority I would suggest the following:

  • Developers only work on bugs/features logged in the issue tracker and no work is done outside of it. All ideas, refactoring projects, new features, custom tools to be developed, etc. should be logged as well.
  • Issues are worked on in order of priority. The priority should partly be determined by management, but developers should definitely have a say in determining priorities as well. This is especially true when it comes to maintenance and refactoring issues.

As to process, you could use something like the following:

  • status 'new' indicates that an issue has not yet been picked up by a developer and is still in the queue of prioritized issues
  • status 'assigned' indicates that it has been assigned to a developer. This could be done by the developer or someone else such as the team lead. I find it works well to have a few issues assigned to each developer, and usually a mix of 'heavy lifting' such as new features and easy pickings such as simple bugs or some simple maintenance work. This allows developers to choose work depending on their mood.
  • status 'in progress' means that a developer is working on an issue. Only one or two issues per developer should be 'in progress' at any point in time.
  • once an issue has been resolved the developer can change the status of the issue to 'needs testing' and change the owner to the tester. This is an important step, as this is also the work queue of the testers.
  • testers can change the status either to 'failed testing' and change ownership back to the developer which means that it goes to the top of the queue for the developer, or they can change the status to 'ready for deploy'.
  • issues with the status of 'ready to deploy' can then be merged and released according to the release cycle by whoever is responsible for the releases.

In short: make the issue tracking system an essential part of the development process and you won't have to worry about issues not being updated.

|improve this answer
3

Maybe they consider it too much work to open a browser, log in, find the ticket and fill it. Maybe you can try to encourage them with hooks. Nowadays it is common feature that in git/hg message [ I assume you use one of these ] you can type something like liked FIXED #123, and ticket will automagically change once you push your commit. That way it is almost no work for developer [ if he works on each issue in separate branch - he already has ticket id ] and most likely he will add those couple of characters in commit message. If this solution is not enough, maybe it means that tickets' scope is too big, and should be divided into many smaller tickets?

|improve this answer
3

This sounds like a company culture issue more than anything else. Who instituted the need to use the tracker? If this is something one person or group tossed out there, and expects everyone else to just accept and use, good luck. Unless people understand what it is, know how to use it, and accept that it does actually make their lives easier (their lives, NOT yours), they will not use it unless coerced by management. That being said, if using the tracker is a company decision, then it should be on management to enforce it. Unless your role includes the responsibility and authority to get/make people use the tracker (sounds like no, as you indicated you're a developer), you're not going to get very far, regardless of what you do (realistically, IMHO).

|improve this answer
2

This is probably similar to why it's so hard to get people to enter their time regularly. It's a tedious job...

Many issue trackers integrate with the IDE. For example, the TFS Work Item Tracker lets you mark a task as resolved when you perform a check-in. There's even an option to require that a check-in is associated with a task. Making the update of a work item part of the checkin process simplifies things. The alternative being opening up the issue tracker in a separate interface to perform the change.

Another option is having a status meeting (or during the daily standup) where someone opens the tracker and updates tasks as people provide status.

|improve this answer
0

One thing to take into account is the GUI itself being an impediment. For example, some obstacles may include:

  • Too many clicks
  • Unoptimized or underpowered Issue Tracker Application Server
  • Poor usability or accessibility

Exposing an API will allow the issue tracker to be updated via scripting the same as technical artifacts (code coverage, unit test reports, build status, etc).

References

|improve this answer
  • In one of my workplaces we used Jira and the first year and a half were the reason I learnt to hate it - it was slow, it was bloated, the process was poorly defined, I had to mark spent time in Jira, in my own personal time tracking software and in the proprietary software which didn't help. If the bugtrack takes more than a second to update between clicks it's too long. Ultimately I learned to like Jira when better hardware was thrown at it and the process was finalized. – Maurycy Dec 7 '16 at 17:12

protected by gnat Dec 6 '16 at 21:21

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.