See also the sequel to this post, Backlog Freshening For Humans, about using this approach for our help docs. This one is focused on programmers.
Last time we talked about the control systems approach to backlogs. Quick recap: make a manual do-more goal where you add a +1 for completing something and keep adjusting the slope of the bright red line such that the backlog keeps steadily shrinking. This works not just for clearing a backlog but for winning the red queen race — dispatching things at roughly the rate they’re coming in at and preventing another backlog from accumulating.
Which is great for clearing and preventing backlogs but there are some backlogs that you never expect to clear. Beeminder has 630 bug reports and feature requests and other open issues in our issue tracker. We call them gissues. For GitHub Issues, that being where they live. (A more common term is “tickets”.) We generate these gissues by the day. And we dispatch them by the day too, but it’s like a hydra. New ones appear slightly faster than we slay them. That’s fine and normal for actively developed software. (Regressions — zombies as we call them — are another story; we talked about those last time as an example of a backlog we very much have to clear and prevent from recurring.) But we also can’t let our bug database just be a black hole.
What to do?
“I think of it as doing spaced repetition on our collection of open Beeminder issues”
The answer is freshening. You keep touching whatever the oldest item is so nothing goes totally out of sight, out of mind. What does “touching” mean? Here are our rules:
- More copyediting of the top-level description as you re-reflect on the gissue.
- Optimize the title for getting you to recall what the gissue is about.
- Are the labels good?
- Often you think of new keywords or related gissues to link to, based on other freshening.
- Split the action items into finer-grained tasks.
- Check one of them off or otherwise make some quantum of progress and mention what you did as a gissue comment.
- There’s always snoozing it [1] if no freshening makes sense and it’s not a priority and is ok to go out of sight out of mind until we go looking for it.
- If you’ve exhausted the previous 7 things and are still agonizing, identify a pre-req gissue. Say you need to freshen gissue G and you’ve found gissue H that should happen first. Edit H to include “unsnooze G” as a checklist item, then snooze G.
- Whine to Danny [2] who can probably do one of the above things for you.
- If even that fails it probably means it’s time for the gissue to actually be the next priority!
The point is to keep curating and improving the items in the backlog. It helps immensely with keeping everything at your fingertips. Before I started doing this, we’d constantly be creating gissues that turned out to be duplicates of ancient existing ones. Now that rarely happens. I think of it as doing spaced repetition on our collection of open Beeminder issues.
Which brings me to the question of spacing and timing and actually beeminding this. First, decide how many days stale you want to let the stalest item in your collection get. We aim for 90 days. And we have 443 open, non-snoozed [1] gissues. Since 443/90 is about 5, I have my gissue-freshening goal dialed to 5 freshenings (aka epsilon improvements) per day.
I just sort the gissues by age, freshen the oldest 5, and enter a +5 on that Beeminder goal. Hewing to the bright red line means I’ll keep cycling through the gissues roughly every 90 days.
Not just for programmers
I’ve focused on Beeminder’s main bug database as the prime example but we’ve been liking this enough to (blog about it for one, and to) start applying it to other things, including in our personal lives. Most recently, Bee and I have created “rolodex” Beeminder goals: we’re gradually adding friends, family, and colleagues to a database and then freshening a contact means, well, contacting them. We’re also applying exactly the above gissue freshening protocol to multiple other GitHub repositories, like the GitHub repository for our household/relationship as well as Beebrain and the dynamic graph editor. We think it’s pretty powerful. For backlogs you have to clear and keep at bay, set up a control system goal. For backlogs that are more like a permanent, curated, perhaps ever-growing collection, a freshening goal is our recommendation.
Footnotes
[1]
Snoozing means putting a gissue in an intermediate state between closed and open.
It’s technically open but with a ZzZ label that means it’s exempt from gissue freshening.
In other words, it’s ok to go out of sight, out of mind.
[2] Or whoever has the role of project manager.