Issue Triage

Architecture Kata “Issue Triage”

Develop a software with which hotline members can report issues to product owners.

Users of a software will contact the hotline in case of problems. If then the hotline doesn’t find a solution and it seems the software shows a bug or is lacking a feature an issue is reported to the software’s product owner.

The following data will be entered for each issue:

  • Product – where did the issue occur?
  • Description – what are the symptoms? What should be improved?
  • Motivation of the user – why should the software be improved in the suggested way?
  • Hints to reproduction – how can a bug be reproduced?
  • Customer name or number
  • Contact at customer
  • Name of hotline member
  • Date

Each hotline member can only see issues reported by her. Product owners see all issues across hotline members.

Product owners comb through the issues to determine what to do. That’s a first quick pass over the issues. They do a triage and classify each issue:

  • Red issue: The issue is useless because important information is missing or it cannot easily be understood.
  • Yellow issue: There is a solution already (the hotline obviously did not know of).
  • Green issue: The issue will be accepted by the product owner for further processing.
  • Black issue: The issue will not be solved, e.g. because it would not be economical to do so.

The assumption behind this is: there are much more issues and requests of all sorts raining on product owners than their teams can possibly handle in a short time. So it’s prudent to focus on what’s feasible and valuable. And it’s important to keep the input quality to story development and coding high. The hotline can help with this by providing detailed information on issues. If that’s the case is checked during triage. If not the issue is bounced.

An overview of issues can be filtered according to date and/or classification, e.g. show only red and yellow issues of last week or only unclassified issues.

Upon classification it needs to be recorded who classified an issue when. In addition a product owner can leave a comment to explain her classification. That’s important for red/yellow/black. For green issues a “weight” can be entered, i.e. some hint as to how many users would benefit from solving the issue or how much money it would save or how much revenue could be made.

A statistic can be generated for a data range  reporting the number of issue per classification per day. It will be exported to a CSV file like this:

Date⇒Red⇒Yello⇒Green⇒Black
2014-10-12⇒3⇒5⇒1⇒4
2014-10-13⇒7⇒2⇒3⇒2
...

Whole issues can be exported into a CSV file (multi-line data enclosed in apostrophe) for further processing with other tools.

Product owners can delete all issues. Hotline members can only delete their own issues while they haven’t been classified yet.

Login/registration can be rather informal. Not much security needed. There is little potential for misuse. Differentiation between hotline member and product owner can be done during deployment.