When writing tickets for a task to achieve in development or marketing, the results are far better when the ticket is complete and doesnt need a lot of research.
There are tickets for many purposes, support, bugs, requirements, and tasks are just a few of them. This article focuses on requirements and tasks.
For a ticket management to work perfectly it needs to be integrated into the documentation system and revision control. At Tecnostore Group we use the Trac wiki and issue tracking system to achieve this.
The perfect use of such a system eliminates any other flow of information in the development process. Reading a ticket should give the developers and marketing people all the informations needed for the product development.
Defining the requirement
- What should be implemented: A clear specification of the required functionality / output.
- Who is the initiator of the idea: For questions and clarifications, also to notify about changes.
- How should it be implemented: Detailed technical information (e.g. The Ticket “Design splash screen” should contain the desired file format and size)
- The proper estimated task duration should be between 4 and 16 hours (0.5 to 2 work days)
Analysis / Triage
- When should it be closed: The target milestone / version
- How should it be implemented: Detailed technical information (e.g. a Ticket “Design an archive file catalog” could contain the information “Inherit from FileBaseCatalog and write method addToArchive() )
- A more accurate time estimate.
- Tickets that are less work than four hours should be merged with related ones. Our Ticket management system knows the resolution “merged” for this.
- What was done, a small comment on closing at least.
- If there was source created it should also be documented by comments.
- If there were files created that are to be checked into revision control, the log comment has to be linked to the ticket.