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.

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.

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.

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.

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

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.

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?

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).

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.

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

• Scrumwise – API

• JIRA Cloud REST API Reference

• Alfresco Content Services REST API