Adapting Agile’s visible workspaces to the humble to-do list

By Nathan Donaldson

Tags:

For the past three weeks I’ve been trialling a new form of to-do list, inspired by the Agile visible workspace. It’s a literal desktop solution: it involves three pieces of tape, some Post It notes, and the right-hand side of my desk. So far, it’s been awesome. Here’s the story …

Since joining the working world, I’ve tried all sorts of ways of listing and prioritising my work: mentally (yeah, like that was ever going to work), with various online tools (always felt like too much overhead, and like I had to go somewhere to see what I should be doing), by blocking time out in my diary to focus on chunks of work (awesome, right up to the point when someone books over your work time with their meeting time) and paper lists (my favourite, but they have a tendency to breed promiscuously on my desk, resulting in archaeological layers of half-done lists doing double-time as a place to rest my damp-bottomed mug of tea).*

Over that time, I’ve found Agile visible workspaces to be the best form of to-do list for me. The whole point of the Agile board is to show what work has been committed to (through user stories), the priority of each story, the task related to each story, and the stage each story and task is at. (You can read more about how this works in our earlier post on user stories and the Agile development practice.)

Scrum Board by Drew Stephens on Flickr, released under a Creative Commons BY-SA license
Scrum Board by Drew Stephens on Flickr, released under a Creative Commons BY-SA license

My ideal situation then would be working full time on one of our Agile projects. At the moment however, while I contribute to one of our large Agile projects and run a couple of smaller ones, I’m spread over multiple projects and clients. So I started thinking about how I could adapt what I enjoy about the Agile workboard to my own case.

First I thought about what I needed. I wanted:

  • to keep track of the various tasks I needed to complete for each of my projects and clients
  • to see these tasks at all times, but not keep a whiteboard by my desk
  • to know what my backlog of tasks was
  • to be aware of which tasks were ‘blocked’ (for example, where I was waiting on client feedback before making the next set of revisions to wireframes).

I decided on a super-simple solution. I cleared some space on the right-hand side of my desk (to the right of my mouse, so firmly in my peripheral vision). I tore off three bits of blue builders tape (the kind that doesn’t mark surfaces) and used them to create three boxes on my desk top, and used a Vivid to mark these as ‘NOT STARTED’, ‘IN PROGRESS’, and ‘BLOCKED’. Then I wrote down each of my tasks on one of the smallest sizes of Post It note (5x5cm), and stuck these in the ‘Not started’ box. I tried to keep my tasks to about three hours’ work or less (so not prepare workshop but prepare card-sorting exercise; not write strategy but research governance models).

After that, I moved the tasks that I needed to work on that day into ‘In Progress’. There were about 6 of them, which isn’t ideal – not a lot of priority there. When Nathan  (the boss) looked at my new visible workspace, he suggested that I try the Kanban technique of limiting how many tasks can be in progress at any given time. So I got out my Vivid and added (3) to my piece of ‘In progress’ tape.

I’ve trialled my simple visible workspace for the past three weeks. In that time, I’ve prepared and given a user-testing workshop, worked on strategy documents for two clients, worked on wireframes for one of our large Agile projects, overseen some online user-testing for a client, kept the wheels turning on two development projects, and done miscellaneous other stuff. And I’ve found my visible workspace works really well.

I can see at a glance all the work I need to do. I make decisions every morning about which tasks to move into ‘In progress’. When I’m waiting on feedback or decisions, tasks go into ‘Blocked’ (so I don’t forget about them) and new tasks move into ‘In progress’. I haven’t gone to the level of writing acceptance criteria for my stories, as I know these already.

The one thing I miss is done stars. On our big Agile boards, when a story is completed and accepted by the product owner, it gets a lovely big orange star-shaped Post It note slapped on to it during the stand-up and everyone gets to share in the glow of a job well done. When I complete a task, the Post It note gets crumpled up and tossed in the bin. The result is the same – the task moves out of the backlog of work – but the effect is certainly lacking. This reinforced for me how well Agile supports team building and team morale through very simple practices. However, having my own set of gold stars feels a wee bit over-indulgent, so I’m sticking with my more puritanical ways.

*All this makes me sound rather unfocused. I like to think that the amount I angst over my to-do lists is a sign of how much I like to be organised, not how little.

Further reading

Case study on using visible boards to increase risk transparency

Make a bigger impact tomorrow

Talk to us today