I am aware of three common approaches for tracking work:
- Bugs, eg Github issues, JIRA tickets, etc
- Tasks, eg items in a list of things to do
- Goals, eg some end state
There are probably many more, but I commonly see teams struggle to reconcile these three.
Part of the challenge is they’re all related and required in some context, but no one is sufficient. Bugs are required because people external to a team need a way to request work. Further, some of this work is essential, so bugs can’t be ignored. Bugs generally represent unplanned work.
Tasks are required because we need a way to deconstruct large projects into more manageable pieces. Tasks generally represent planned work.
Goals are required to separate implementation details from an objective. One of my colleagues phrased it well: setting goals shouldn’t be controversial.
Sometimes tasks can be represented as bugs, but bugs by nature are relatively formal, which breaks down when tasks change at a high rate. Some teams strive for tasks that take no more than one iteration, which is tedious to represent as bugs. I like the pattern of stating goals for the week, and reviewing progress against those goals at the end of the week, but this is tedious to represent as bugs or tasks.
My fantasy is something like:
- Monday kickoff and Friday review focused on a simple, written (so we can remember on Fri) list of goals for the week
- A support rotation monitors bugs. Active work on bugs is represented as goals for the week
- Large projects have independent task tracking. Active work on tasks is represented as goals for the week
The fact that my goal for the week concerns planned or unplanned work matters less than communicating to the team what I’m working on and how it contributes to the team’s priorities.