This article is part of the “Side Projects” mini-series.
For gclimbing and JSXP I use a very simple backlog: It is just a paper notebook. I use one single notbook for planning everything related to gclimbing: The backlog itself, the software design and architecture, web framework (JSXP) issues, UX design, etc. Here are a few example pages from this notebook to show how my backlog is organized:
The TODO lists impose an automatic limit on planned work: I do not allow them to become longer than one page. When I reach the end of the page I have to copy the remaining TODOs to a new page, which is a lot of work when there are many open TODOs. I try to avoid this work by first finishing the TODOs or completely removing items that don’t seem important at the time.
When I copy a backlog item to a new page, I strike that item through and place a little right pointing arrow next to it. On the new TODO list page I place a left pointing arrow next to the item. This helps me to keep track of items that have been long (possibly too long) on the lists.
A backlog item generally is only one line. I won’t add more text (maybe sometimes a second line, but that’s an exception). Only when I start to work on an item I add detail. I will write some more blog entries for this mini series about the detailed design I do.
I remove a lot of the TODOs completely from the list (I simply strike them through). These removed items are not only items that have become obsolete, but also items that are important, but not in the near future. There is no reason to keep them written down - If they are still important a year from now I will remember them. As Andreas Wintersteiger once told me: “If you are creative now you will still be creative in two weeks, so there is no need to write everything down”.
Also, I only try to do one thing at a time. This makes it easy to interrupt work and come back later (you only have to remember one interrupted work item). This also means that I finish items faster - there is no distraction from parallel work items (*).
(*) “Fast” just has a different meaning here: Since I only work on these projects in my spare time, even a simple feature update or bug fix can take some time.
