The following article helped me think about work item size.
In summary, one way to determine size is based on how frequently you review progress and who you review progress with (management, peers, or etc).
An example: In my current role as a Solution Architect, I deliver, um, solution architectures for projects. I rarely have a task on my board called “Deliver Solution Architecture for Project X”. That could take weeks to move from WIP to Done and my boss reviews my work every week. Nothing would move. Useless status update, really.
Now, if I have tasks on my board such as, “Build Functional View for Project X”, “Decide front end platform for Project Y”, or “Build architect overview presentation for Project Z”, those tasks will move each week (hopefully).
Also, when you want to go back to understand why Project X’s architecture took eight weeks, you don’t really know exactly what took up the Lion’s Share of your time if the task is too big. Was it the endless meetings with vendors? Was it the countless days mulling over a decision? Was it the tedious and frustrating hours trying to make Visio connectors work properly?
So another rule of thumb I just realized having written the above is: a task should be big enough for you to figure out where you are spending most of your time, since that’s where you probably want to focus on improving.