Channels ▼
RSS

Tools

Making Issue Tracking Drive the Development Process


The right use of tools can radically improve a development organization's culture and its ability to work well. Products such as defect- and issue-trackers can be transformed into workflow tools if used to their fullest advantage. Here are fundamental good practices for setting up a tracker tool at your organization to be the centerpiece of your project workflow.

Make Contributing Simple

Reducing friction is key to getting rapid adoption from a user base. Start with a URL that is simple for everyone to remember. Good URLs in the form of http://go/<yourapp> make it easy for users to quickly find the system. To make login a seamless experience, find a solution that integrates with your existing directory infrastructure such as LDAP, Active Directory, or Google Apps.

When laying out the issue creation form, every field needs to "earn the right to be seen." It's easy to just add fields for data that a user might "want" to enter. However, extra, unnecessary fields make the system more cumbersome — they're just more clutter to read/scroll through and can be confusing for the user. Don't attempt to future proof; make every field count.

Whether the type of issue being tracked is a bug, a feature request, or a to-do item, try to capture as much information as possible to understand the issue. Engineers, for example, want environment-specific information from inside a product at runtime. For that reason, many issue trackers now have RESTful interfaces that make filing issues in-product easier. Developers can reliably get information about the state of the product in each and every bug when issues are filed RESTfully from the product.

Minimize Ramp-Up and Engage Everyone

Teams that engage their full ecosystem in an issue tracker are better connected to their market. With many issue trackers now running in a hosted service, it's easy to allow beta users and customers to log issues directly into your system. Shortening the distance between an issue and its solution encourages issues to get resolved faster. If customer service issues are logged in one system, then manually transferred to another system for engineering review, it takes more work for a customer's issue to get fixed.

As new users engage with the issue tracker, take some time to get first impressions. Processes — as well as the tools themselves — need to be agile. Proactively seek feedback on how things are working. Often, existing employees suffer from "it's always been that way" syndrome; new users have a short but valuable window where they can give an outside perspective. Take advantage of that window.

Today, many software teams work cross-functionally. When people cross team boundaries, it's helpful to use the same language across teams within the same company. For example, priority schemes (such as Blocker, Critical, Major, etc,. or P1–P4) create a field that conveys relative importance of issues. Some teams have a policy that blockers need to be resolved by end-of-day. Other teams have a less strict definition. Standardizing terminology across teams makes it easier and faster to work together because expectations are consistent.

Dashboards Done Well Incite Action

Everyone on the team wants to know whether the project is going well. One key benefit of a distributed work management tool is that everyone can update his or her part of the project. Project managers can then focus on using the tool to plan forward direction as the team pushes status, rather than pestering everyone on the team for an update. Effective managers can build dashboards that pull real-time stats from work management tools and keep the team in the know. Finally, make the dashboard visible. Link it from the team's intranet home page, and consider creating a simple go URL as well (for example, http:/go/teamstatus).

Dashboards should always incite an action. Team members and stakeholders should know at a glance if things are going well. Resourceful dashboard authors ask project participants for feedback to ensure that all agree on the message of the dashboard. Finally, a user tends to silo his or her "part," focusing on the fact that "my bugs are OK" rather than taking a holistic view of the program. Much like the build team creates the official build, consider tasking the program manager to "own" the project status and reporting for the full team.

Make Your Issue Tracker Work for You!

I've seen many teams struggle with work management solutions as they try to build their process around the tool, rather than build the tool around the process. Each organization has a unique process that it naturally wants to follow. You shouldn't have to build your own issue tracker to create a custom solution. Unfortunately, many teams don't stray far from the vendor's defaults. Spend the time to customize your tool around how your organization gets work done; it's a valuable investment.

Effective workflows help the organization to work together more fluidly. States (new, open, resolved, etc.) indicate work status. The assignee makes it clear across the company who is responsible. Transitions between states inform everyone how work can get done. When the team has the right workflow, the burden of issue tracking fades to the background because it's a natural part of the culture of the organization.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Comments:

ubm_techweb_disqus_sso_-7dd255782dacf0fb823476240bf962ea
2013-09-05T12:43:00

I agree with most of the points you made. Except dashboards, I hate them. :)

But I think you forgot one important aspect: smoothness.
I think the perfect issue tracker is clean, simple and just works.

I see it like a platform on which you are building something. Not an engine which uses people as fuel. Tracking issues should be as simple as possible and it should require minimal attention from me. After all, I want to work on the product, not manage issues for it.

For example, I really like a small new issue tracker called asitrack. I found it by mistake and it's very smooth. It will probably evolve into a behemoth like JIRA, but for now it's simple and clean.

I think that most issue trackers start great with simple concepts and basic functionality. It's the complexity that makes issue trackers unpopular.


Permalink

Video