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.
