10 reasons why a ticket system is better than email's

The blog post Working with a ticket system provides an overview of the basic idea and structure of ticket systems. If the topic is new, then there is a good introduction.

Writing an email often seems much easier and faster than creating a ticket. At first sight this may be true, but at the latest with the first query it becomes confusing, tough and quickly chaotic. So here are my ultimate 10 reasons why a ticket system beats out email in project work:

• Centralization and collaboration
• Transparency (overview for all)
• Targeted search function
• Customer integration
• Standardization and structuring
• Workflows and quality assurance
• Prioritization
• Automation
• Reporting
• Documentation
• Inbox-Zero

Cent­ral­iz­a­tion and Col­lab­or­a­tion

Several people are involved in the realization of projects. In our projects, it is always at least the responsible team as well as the stakeholders on the customer side who are responsible for the project. Sometimes other service providers are also involved.

Through our ticket system, all project participants have access to all active and past tasks. Nothing disappears into e-mail boxes never to be seen again. If, for example, colleagues fall ill or disappear for four (4!) weeks on vacation, the ticket system is crucial as a central source of information. If in such a case, for example, the coordination of a feature had taken place in a bidirectional e-mail exchange, colleagues who step in as substitutes would not have access to coordinated information. This would result in at least a temporary loss of information and delays. At the latest, when a person leaves the project or the company completely, the information from e-mail conversations would be completely lost. ¯\_(ツ)_/¯

Trans­par­ency

In the ticket system, a ticket shows the status of the associated task and thus the progress. It also shows who made which changes or requests and when. If several people are working on the same problem, it quickly becomes difficult to keep track of individual tasks. If you tried to do this via email, you would have to make sure that the right person always received a copy of the message. This gets out of hand in pure email battlegrounds that no one wants to find in their inbox. ¯\_(ツ)_/¯

Targeted Search Function

While e-mail clients can usually only search for full text and possibly restrictive criteria such as sender and date, current ticket systems offer search functions that can be used to search for specific ticket properties. For example, the search can be narrowed down to a project, a ticket type, an author, or a combination of such properties.

Unfortunately, this does not work in the e-mail program. ¯\_(ツ)_/¯

Customer Engagement

Not only the project team, but also the customer should be able to access his project in the ticket system. In this way, we always provide our customers with a transparent insight into the project status and actively involve them in project development.

In addition, we enable our customers to enter bugs, feauture requests and other tasks in the ticket system themselves. This speeds up the work process and makes responsibilities transparent (who takes on which task?).

This level of involvement cannot be achieved by e-mail. ¯\_(ツ)_/¯

Stand­ard­iz­a­tion and Structuring

For the processing of tasks, it is essential that basic standard information is available. With a well-configured ticket system, information required in a specific context can be requested as mandatory information. For example, a bug ticket could be associated with mandatory information about the system used in which the bug occurred. When submitting a bug via email, this information is often missing, causing unnecessary delays in resolving the issue due to follow-up request loops. ¯\_(ツ)_/¯

Workflows and Quality Assurance

Individual ticket workflows define how a ticket transitions from one status to another. This guarantees that defined processes, e.g. for quality assurance, are adhered to. With us, for example, tickets cannot simply change from "Ready" (prepared for implementation) to "Done" (completed implementation). There is always a quality assurance step. This ensures that the four-eyes principle is adhered to and that no faulty code is played out.

Email software cannot do this. ¯\_(ツ)_/¯

Pri­or­it­iz­a­tion

In the ticket system, the priority for individual tasks can be set and, above all, changed according to importance. In this way, the team quickly becomes aware of urgent tasks. In combination with intelligently defined workflows, work can be optimized even further.

For example, tickets that do not successfully pass quality assurance are automatically moved to the priority level. In this way, we ensure that no new tasks are started until those that have been started have been successfully completed.

Of course, emails can also be sent with "priority high", but this is much more static and therefore only helps to a limited extent. ¯\_(ツ)_/¯

Automation

Since tickets are neatly structured records, this can be used to link other systems well.

Specifically, our version management (How we develop software, Part 1: Version management), which creates issue branches from the ticket IDs and in turn reports crucial changes (e.g. deploy to LIVE) to the ticket, where this is documented as a change.

In addition, the results of unit or acceptance tests can be automatically transferred to tickets.

Another optimization option is the automated creation of tickets for recurring tasks. For example, maintenance tasks are automatically created on a weekly, monthly or quarterly basis - depending on the contractually agreed maintenance conditions.

Some ticket systems also offer the option of automatically recording additional information when creating tasks. For frontend development in particular, the Bugherd tool should be mentioned here, which automatically includes browser information and system data in the ticket when the ticket is created from the website interface.

And last but not least, our ticket system is connected to our accounting department, so that billing processes can be triggered automatically with the completion of certain ticket types and time bookings.

How is that supposed to work with an email client? ¯\_(ツ)_/¯

Reporting

For example, we also record working hours, work areas, story points and run times in our ticket. These variables can be evaluated quite easily and conveniently at the project level, at the team level, or even F7-wide.

The question "How many story points was my team able to implement on average per sprint in project XY in the last quarter?" can thus be answered easily. Thus, projections for future sprints are also reliably possible.

Email... well, let's just leave it like that ¯\_(ツ)_/¯

Doc­u­ment­a­tion

Ask 1000 developers how much they like writing documentation; none will break out in enthusiasm. However, a well-maintained ticket system (in combination with coding standards and some inline comments in the source code) can already reliably fulfill this task, since extensive information is stored here systematically and easily searchable (see above). Thus, even after years, it is still possible to clarify: "Is it a bug, or a feature?". The above-mentioned linking of our version management with the ticket system provides us with additional support here, as it is directly traceable which code change is associated with which ticket.

This is an enormous advantage over any e-mail communication, especially in long-term projects where contact persons also change. ¯\_(ツ)_/¯

In­box-Zero...

... a noble goal that will probably never be achieved as long as there are still e-mails - but that is not that decisive. What is much more decisive, however, is that the "pings" in the inbox are reduced to the essentials and thus work can be done in a better and more focused manner.

After all, it is precisely the effort to implement some of the above-mentioned advantages of a ticket system via e-mail that results in a time-consuming flood of e-mails. In particular, the attempt to create transparency by including all stakeholders potentially (!) to be informed via long CC and e-mail distribution lists creates the opposite: intransparency and waste of resources. The result is an e-mail ping-pong of the highest order, in which, in the worst case, several topics are "coordinated" under one subject with several stakeholders in chronologically unclean order. No one sees through this, no one wants this. ¯\_(ツ)_/¯

Conclusion

Who counted attentively, comes on 11 good reasons; thereby I had promised only 10. So what more can I say? ¯\_(ツ)_/¯