What is a “Lightweight Ticket Process” ?

I mentioned in my previous post the phrase “Lightweight Ticket process”. Let’s look in a bit more detail about what that might mean.

• Tickets are raised for a variety of reasons (e.g. feature request, bug report, request for clarification) throughout the Application Lifecycle (e.g. Project Initiation, UAT, production support…). No single process will answer all these needs and specific processes will need to change over time so be flexible
• Clearly identify what information you need to record in each of the processes. Broadly this can be grouped into two areas although there is a large overlap between them:
  • information required to support the currently active process (e.g. risk, benefit , cost, impacted subsystem, severity, schedule, review comments …)
  • Information required to support metrics (e.g. impacted subsystem, actuals vs. estimates, severity …)

  Because this is a lightweight process we gather the information we need, but no more

• Make the process as simple as possible, but no simpler. Consider the Magical Number 7 as a rule of thumb . Remember that we want a lightweight process, but we still have certain minimum requirements – the trick is working our what they are. In general processes will contain some variation on
  • Gather the initial request
  • Ensure that all required information is present
  • Review the information for benefit, costs, impact and risk, and possibly approve further work
  • Carry out real work i.e. change something
  • Review the work for correctness
  • Implement the change (e.g. roll out to production)
• Document the process in some fashion. A process that is not documented can be very hard to talk about, agree and improve. Brevity is the soul of wit, however the document should cover
  • Purpose and final outcomes
  • Rationale
  • Entry and exit gates
  • Entry and exit conditions on each stage of the process
  • The role responsible for each stage of the process
  • Brief description of the activity at each stage
  • Abnormal process stages or exit gates
• Look for some common gothas
  • No clear separation of roles, for example the people who request a change also approve it and implement it (this tends to make auditors jump up and down a lot)
  • The same role responsible for two consecutive parts of a process often indicates a poor process, but not always.
  • Beware of ticket changing identity half way through a process, for instance a bug report that morphs in a feature request. Depending on the features of your tool, change the ticket so that it becomes the correct type (on the correct process with the correct data capture fields) or close the ticket and open a new ticket of the correct type, ideally with a link back to the first ticket.