You actually think you’ll finish all of that?
When’s the last time you created a to-do list and actually checked off all the stuff you had on it before you discovered you had more tasks to complete? If you’re using a today and later list, you’re probably closer to this goal but you may still be ending your day with the dissatisfaction of an incomplete list. With dissatisfaction comes attrition, since what else is a productivity tool but a way to make it easier for us to be productive and, thus, allow us to leave our desk with a greater sense of achievement. The problem we deal with when we plan out our days is summed up by Murphy’s Law. Being the optimistic people we are, however, we tend to underestimate the amount of time it’ll take us to complete a given task and we often forget about other little things we need to do throughout our days.
Ideally, a good “today” list is one that’s realistic yet challenging. I have found this ideal difficult to achieve. Instead, I often put many more tasks on my list than I actually am able to complete by the end of the day. For example, I estimated this article would take me less than 2 hours and, at this point, it looks like it’ll take more than that (meta, right?). Yesterday I didn’t factor in the 1 hour unplanned call I had with my business partner. So, my inability to complete my list isn’t for lack of focused work as much as it is for the tendency to underestimate the difficulty of tasks and the number of unexpected interruptions I will face during my day.
This is exactly the same problem we deal with in software development. One solution to software estimation is to spend a lot of time using expensive software and come up with a very detailed specification and estimate. As you might guess, this is not a realistic approach for small businesses with limited budgets and a need to remain agile. So, small businesses often use a style of project management aptly referred to as Agile. One very useful concept that comes from Agile is Velocity – an estimation tool which is best elucidated with an example.
Let’s say you have 100 features you want to program into your new piece of software. Before you get started, you assign each of these either 1, 2, 4 or 8 points based on how difficult you expect it’ll be to actually implement that feature. So, for example, feature 1 might be something simple like “User is able to log in.” You assign that feature 2 points. The second feature maybe something more complex like “User is able to register using Facebook or LinkedIn.” You assign that one 8 points because you think that feature is 4x as complicated. Once you finish estimating all 100 features, you find that you have a total of 500 points.
In your first week of development, you take the first 12 features and say that you’re going to do your best to complete them this week. Those 12 features total 50 points. At the end of the week you find you only managed to complete 10 features and a total of 40 points. When you plan next week, rather than queue up 50 points of work (as you did in the past week), you’ll want to plan to complete 40 points (the amount you actually completed last week). You’re amazingly productive that week though, and actually manage to finish 44 points. So, in the third week you queue up (40 + 44)/2 = 42 points of work (i.e., the average of the past two weeks). From week 4 on, you can average the number of points you completed over the past 3 weeks to come up with your Velocity (i.e, the number of points you complete per week on average).
This Agile concept can also be applied to our daily to-do lists. Instead of just trying to take a best guess at what we can accomplish in a given day, we can assign a number of points to each task and calculate our daily velocity (because tasks are small, I usually use 1 point to represent something that will take between 15 and 30 minutes, 2 to represent 30 to 60, and so on). Velocity is best applied over a larger period, however, as you have more data to average over. In other words, your daily velocity will likely fluctuate much more than your weekly velocity. To mitigate this isssue, I use a weekly velocity and construct a to-do list for the week. Then, I break that list into 5 equal parts (assuming you work 5 days a week) to come up with your daily goals taking into account potential fluctuations in the number of hours you work on a daily basis. Just remember that, if you have to add something to your week’s task list, you should first assign a number of points to that task and transfer a commensurate number of tasks to your “later” list.
Hope this tip helps you to make the most of your work hours. Remember that a good process is one that works for you, so give it a try and then modify it to suit your needs. If you happen to find this tip useful or discover a particularly effective tweak, let me know.