Following on from the design principles and setup procedure/maintenance routines for GHP Kanban, I now wish to address the elephant in the room of the "cold start problem" of scheduling otherwise well-filled out task list items, that is to say the problem of putting an order on them.
It's important to recognise that intention must precede scheduling. This is well-illustrated by a simple example, which you might've experienced, of someone listening to your complaint on a matter and responding in a desire to help: "just set up a daily/weekly time to work on X for just Y hours".
If you're anything like me, you'll flinch at the imposition of someone else circumventing your planning process, namely:
- bug identification: declaring the nature of the problem
- bugfix proposal: considering a course of action to resolve it
- scheduling: deciding the correct amount of time and frequency
This rejection reaction would be accentuated if:
- piecemeal action was not necessarily the best approach
- charging into a work process without planning (execution prep) would hinder success entirely
- (most of all) the task to be undertaken was large, and, especially if unplanned, could easily spiral out of hand and overwhelm other commitments – work doesn't exist in a vacuum.
To reject such advice may seem ungrateful, but arises from an intuition of self-preservation. When someone makes a suggestion that would put upon your schedule directly like this, it ignores how planning requires reflection, and appears to encourage acting arbitrarily, without forethought: even the fundamental thought, Do I desire to do this?
When it comes to matters of autonomy, we want to ensure that we're the ones guiding the process of task commitments, rather than someone else imposing their will – much like you wouldn't enter your password for a stranger to run unexplained commands on your computer without your understanding.
Unlike letting a stranger run unknown commands on your machine with root permissions (where we may assume good intentions and trust their judgement working with your device) in matters of personal planning process, it more likely is unreasonable for someone else to presume they understand your nuances (or even can) when it comes to how you prioritise, plan, and allocate your time, energy, and resources. Even the strategy you would take (e.g. a high r or high k process/breadth or depth?). Especially when those decisions depend on factors only you are fully aware of (such as your goals, limitations, and broader commitments).
Only you can decide what you wish to want to do.
The specific ownership over your process here is in the control you can exert on your intention. What you choose to prioritise is what you will drive to completion. Cui bono?
Looking at a kanban task list (seeking to give a relative priority, as well as to pluck out particular priorities in the short-term), you do have to ask, what are they bringing to the table? How are they going to spend your energy and manpower (including mental focus)? What will contemplation and perseverance on these tasks give rise to within yourself? What will you get for them (not necessarily in monetary payoff, but in a sense of what you'll get for your efforts)? Why would you choose to waste your time? What are you aiming to achieve with this software (I don't mean at the level of features and bug fixes but at a meta level)? What are we doing here?
For that, you may need to reflect on the purpose: is something just for fun, an experiment/proof of concept (an existence proof? a mastery experience as Bandura phrases it?), are you developing your own software/contributing to someone else's, contributing/developing something others want/need, or what you want/need, what would be good for you in the long term?
None of these questions can be answered by looking at decontextualised ticket metadata, it needs to come from a mental model of yourself, not the data model of the issue tracker. Of course this applies less so [far less] in a work context, where the primary value is business goals, which are not (typically) the remit of an Individual Contributor, though we may well have a sense of them in terms of stakeholders (service users, internal/external to the business). This logic is notably the same as that which leads to a ruthless deprioritisation of the "backlog", though I see that more as thoughtless non-process than active decisionmaking outcome, and expect those who do so would agree.