Improve Productivity with the Humble ToDo List

Micro-Scrum

A week or two ago, I read Stephen Walther’s blog post “Scrum in 5 Minutes” and reading his description of the backlog reminded me of a practice that I’ve been getting a lot of mileage out of lately. My practice, inspired by Kent Beck in his book Test Driven Development By Example, is to keep a simple To-Do list of small development tasks as I work.

The parallels here are rather striking if you omit the portions of Scrum that have to do with collaboration and those types of logistics. When starting on a task, I think of the first few things that I’ll need to do and those go on the list. I prioritize them by putting the most important (usually the ones that will block progress on anything else) at the top, but I don’t really spend a lot of time on this, opting to revise or refine it if and when I need to. Any new item on the list is yellow and when done, I turn it green.

There are no intermediate states and there is no going back. If I have something like “create mortgage calculator class” and I turn it green when I’m happy with the class, I don’t later turn that back yellow or some other color if the mortgage calculator needs to change. This instead becomes a new task. Generally speaking, I try to limit the number of yellow tasks I have (in kind of a nod to Kanban’s WIP limits), though I don’t have a hard-fast rule for this. I just find that my focus gets cluttered when there are too many outstanding tasks.

If I find that a yellow item is taking me a long time, I will delete that item and replace it with several components of it. The aim is always to have my list be a series of tasks that take 5-15 minutes to complete (though they can be less). Items are added both methodically to complete the task and as reminders of things that occur to me when I’m doing something else. For example, if I fire up the application to verify a piece of integration that involves a series of steps and I notice that a button is the wrong color, I won’t drop everything and sidetrack myself by changing the button. I’ll add it to my queue; I don’t want to worry about this now, but I don’t want to forget about it.

I never actually decided on any of these ‘rules’. They all kind of evolved through some evolutionary process algorithm where I kept practices that seemed to help me and dropped ones that didn’t. There will probably be more refinement, but this process is really helping me.

So, What Are the Benefits

Here is a list of benefits that I see, in no particular order:

  1. Forces you to break problem into manageable pieces (which usually simplifies it for you).
  2. Helps prevent inadvertent procrastination because task seems daunting.
  3. Encourages productivity with fast feedback and “wins”.
  4. Prevents you from forgetting things.
  5. Extrapolated estimation is easier since you’re tracking your work at a more granular level.
  6. Helps you explain sources of complexity later if someone needs to know why you were delayed.
  7. Mitigates interruptions (not as much “alright, what on Earth was I doing?”)

Your mileage may vary here, and you might have a better process for all I know (and if you do, please share it!). But I’ve found this to be helpful enough to me that I thought I’d throw it out there in case it helped anyone else too.

  • Leslie Scott

    There are many factors that helps us gain productivity. We cannot say that only the to-do list alone can do the work. Preferred to have gain the end result in a perfect manner and looking ahead with the better output as though the various methodologies helps to gain improvement in the productivity in a much precise manner.

    Better the management better will be the output. All along with the competition, the techniques tells the truth and that is some what helps gain the end result with maximum profitability that is some what we call as the productivity.

    A post that I came across wanna share the same – http://www.replicon.com/blog/how-byod-policies-can-help-cut-time-tracking-costs-and-improve-productivity shows up another technique for a productivity improvement. Completely based on the hardware based strategy it has been mentioned that BYOD helps gain the productivity in a much better and precised manner.

  • http://www.schmonz.com/ Amitai Schlair

    +1 — my most productive-feeling days are the ones where I take a few minutes at the beginning to produce a roughly ordered list of small steps. Not in Excel, though! That would drive me nuts. Instead, I write my list as comments in the test suite, then convert each comment to tests, then make them pass. I commit no more often than is sensible, no less often than is satisfying. Love those kinds of days.

  • http://www.daedtech.com/blog Erik Dietrich

    I think I’d abandon Excel if I were purely a programmer. But Excel lets me put “get that MVC controller up to speed” alongside “call Dave Jones back to setup an interview.” I respond this way with some latent sadness because I think there’s nothing more perfect for the pure programmer mindset than what you’re saying — why bother setting forth some kind of text based to-do list, when I could bake my todo list into a BDD acceptance scenario.

  • http://www.schmonz.com/ Amitai Schlair

    I should have specified that the above was a lament; I hardly ever get code-only days either. So I also have a more generalized implementation of granular to-do to-day, and it’s still not Excel, because I live a mostly Unixy life. For me, the most natural fit (vim, Perl, git, Markdown, etc.) is ikiwiki. Plus I gethave to contribute when it doesn’t quite do what I want. Somehow the occasional yak-shave endears it to me more. :-)

  • Steven Hunt

    It’s funny, I implemented a similar system for myself a couple of weeks ago and it’s made a huge difference for me, especially on Monday mornings when I can’t remember what I was doing last week.

  • http://www.daedtech.com/blog Erik Dietrich

    Yeah, having the tasks somewhere persistent is definitely a huge benefit in eliminating that “what was I doing again?”

  • Pingback: Why Social Situations Exhaust Introverts: A Programmer’s Take | DaedTech