As software engineers we’re all guilty of using ticketing systems as expensive todo lists. We transition tickets from
in progress to
done, but rarely go beyond that functionality. We may have nice integrations which link back to our version control system, or open some dialogue with fellow developers, but thats often the limit of our usage.
I’ve recently started using the ticketing system as my personal journal. In my opinion, a ticketing system should include a record of the trials and tribulations involved in delivering a feature/issue, not just the about our interpretation of the issue/bug. This is often useful when you’re faced with challenges from stakeholders as to why certain things took longer to deliver, but it also serves the purpose of a historical log.
Here’s the structure I like to include:
- Problem - a short description of the immediate problem I want to solve
- Hypothesis - offers an understanding of the problem, and what I think is causing it
- Experiement - how I plan to explore my hypotheis, this often outlines the tests I execute/implement
- Results - records my discoveries during the experiment
- Conclusion - lists the outcomes of this work. It could result in further experiments, or be a plausible solution to the problem