In the last section I described the fields, which define what can be recorded in your GitHub Project for each item. A Project is composed of "Views" on these items, and differ in how the field values are filtered.
Here I'll give an 'operating manual' on to set up a new Project kanban from scratch, with the following Views:
- A columnar Board View (this is what most people think of as a "kanban")
- A timeline Roadmap View
- Table Views sliced by Area and Library fields (for inspection of particular subdomains of work, no filters)
- Specific Table View for an Area of interest using a filter (e.g.
area:development
)
- Specific Table View for an Area of interest using a filter (e.g.
- Table Views filtered by time: for the current week, the next week, this month, next month
- 📆 Weeks
has:"Week" -title:"*NOVIEW*"
- 📆 This Week
has:"Week" -title:"*NOVIEW*" week:<@next
- 📆 Next
has:"Week" -title:"*NOVIEW*" week:@next
- 📆 Months
has:month -title:"*NOVIEW*" week:@next
- 📆 Sep
month:@current
- 📆 Oct
month:@next
- 📆 Dec
month:@next+1
- 📆 Weeks
- Table Views to capture edge cases of interest
- ⏳ Pending
no:status,day,week,month library:pydantic,quill
- Where
pydantic
andquill
are names of libraries you are prioritising work on
- Where
- ⏸ Deferred
no:status,day,week,month -library:x,y,z
- Here you exclude those same libraries with the
-
operator
- Here you exclude those same libraries with the
- 🔒 Past
has:day -day:>=@current
- ⏳ Pending
Kanban setup walkthrough
The setup process in a nutshell is as follows:
- Start with template
- Make any necessary repos (can use drafts but don't want to introduce everything as draft)
- Go to the Pending View to prepare it: add missing field values (this will make the items disappear from the View)
- First prepare the current tasks: give the most immediate tasks a value in the Day field (if "not now", set them as tomorrow, repeat for as many stages of priority as desired)
- Secondly go to This Week View (now populated) and add Status, Library etc. (including labels on issues, convert any drafts to issues so they can be labelled). Tip: use the 'handlebars' (square in bottom right corner of a 'cell', like in spreadsheets) to accelerate
- Put today's date as Start date for anything you're working on, otherwise leave blank (its purpose is to track "lead time" interval from "pickup to put down", DORA metric).
Confirm
Now you should have everything filled out except Start date, so the 'begun tasks' are visible row-by-row.
- Return now to the Pending View and add months to any items without one (any complete unknowns go +3, prioritise others into +1, +2). Do not add month and day values to unplanned tickets, this would be 'false precision' and increase the workload involve to continue shifting them forwards (as a genuine backlog). Any which have not been triaged with labels should be left that way or filled in properly: assigning a label like "future" or "backlog" is redundant, as the distant Month value already declares this. Tip: the term Backlog should really only be given to items which are not planned, and then these items should be closed as not planned and archived from the Project.
- Triage the items without a Status (if/when you have time). If a ticket is a good idea (i.e thought out, ready), mark its Status as such, and it will move into the Ideas View. where you can go to pick up standalone new desired features between feature work, or on any other opportunity.
Tip
These might be 'opportunistic' ideas like "refactor X in Y code" that you could do within work on a given part of the code, or just attempt to fire off to an LLM for an easy/small win.
Make this a regular occurrence
E.g. a Monday morning ritual, to keep the relative bug level low or zero. Once zero, proceed to iterate on triaging out into weekly planning.
When assessing the week's work plan, if you have time check in the bugs and ideas for anything related/duplicated that could do with being folded into the same task.
If any of the work tasks are not viable (e.g. an attempt was made and something blocked its success) mark it as On hold, implying awaiting external dependency/bugfix.
- Hopefully now you have begun putting "on" tasks that you had "put off"; perhaps only passively due to inaction rather than active postponement. Looking over the Pending View again, from the top, you should be able to at least assign Idea or else assign Soon in the Status field to reflect their relative position in the Pending items (again, don't call it a "backlog" as this implies stagnation rather than a proactive Failure Demand posture). You also shouldn't be associating any of this with "tech debt" which is a similarly resigned term assenting to inaction.
- At this point your task list is sufficiently structured to share, and you may want to add a Priority field (e.g. enum of "P0", "P1", "P2") or even scaffold it as a sort order on the many TODO items. The use of Status values of "TODO" vs. "Soon" is often enough to bootstrap this relative ordering.
Do not use a manual rearrangement
Using drag and drop on a Board View to record relative priority, like colouring cells in an Excel spreadsheet, is not a stable way to record metadata, and you may lose work done in this form. It does not 'reside' in the record: make your data visible!
Slow and steady
If any seem daunting on the horizon, don't worry, you can split them out into preparatory work when they arrive and push back the work as necessary, to drive it to completion.
- Once you have given all the Pending items (i.e. those without a fully specified date scheduled) at least a Status and Month, your Pending View is ready!
The Pending View is grouped by Month
The null group (no Month) always rises to the top: so you should always be able to easily find newly ingested items here.
- If you chose to add enum fields like Goal (bug/feat/question) then once all the Status fields are completed, you should be filling out these goals (which either pre-empt labels or can be trivially copied from them if you imported existing issues). In general, following the principle of minimising defects (i.e. tickets with Goal: "bug") should take priority over features (Goal: "feat"). Typically the "long tail" down at this implicitly deprioritised task list is full of ideas for features.
On a final note, especially when it comes to triaging tasks and development work outside of your job, it's actually quite crucial to pay proper attention to the reasoning (or lack thereof) behind how you are prioritising this 'long tail' of Pending tasks. I do not recommend random assignment, or 'filing for bankruptcy' on this list of work items, as much of it will either itself be latent value, or will hint at paused/stalled projects which if given TLC to grow may indeed bear much fruit.