Decomposition of Tasks and Agile Methods with Team Foundation Server
It’s late on a Sunday night and I couldn’t sleep, so I thought I would crank out a blog post discussing my observations on decomposition of coding tasks with Team Foundation Server (TFS). When I deliver training on TFS 2008, I always offer my commentary on this important matter, so I decided to put a few (not all) of my thoughts into writing. This post is not strictly related to TFS, but will discuss in a succinct manner why effective decomposition of tasks is important. First, let’s define what decomposition means so we’re clear on terms. I couldn’t find a suitable definition in the dictionary that didn’t have something to do with the breakdown of something organic in nature (i.e., decay), so here is my working definition of decomposition as it relates to tasks: the separation or resolution into constituent parts or elements.
As a rule, ideally I suggest breaking down coding tasks into units of 8-24 hours. This is a goal, and not a strict requirement on my projects. I typically set an upper limit of 40 hours, which is being very generous even on large projects. It is my view that any task over 40 hours can be broken down into constituent parts.
One clear benefit of task decomposition is that during estimation, decomposition forces developers to think about their approach, and to think in a componentized manner that encourages good design and opportunities for reuse. From the perspective of a project manager, it provides more flexibility in scheduling tasks, and provides much greater visibility of project progress. Let’s say that in order to meet a certain requirement we have a three week task decomposed in chunks of 24, 30, 36, and 30 hours. If things don’t go as expected, the project manager will have a maximum “visibility lag” of 36 hours (the second task, in this scenario), and will be able to respond quickly if the task gets off track. Since the overall task is already decomposed, if the developer gets off track on any task, the project manager can reassign tasks to other available resources and still deliver on the requirement within the three week period.
Another benefit of decomposition is that the decomposed tasks can be effectively prioritized. Sometimes a particular requirement, when broken down into discrete coding tasks, has elements that are not critical but are “nice to haves.” If the task to fulfill the requirement is decomposed not only into logical chunks but also into prioritized chunks, then if the decomposed tasks take longer than expected, the project manager could delay the nice to haves until another release or, with the customer’s blessing, cut the task entirely. This works particularly well in projects that are purely agile or agile oriented with fixed iterations, which would be feature-driven from the “bottom up” instead of plan-driven from the “top down.”
With respect to TFS, for those who use the Work Item tracking features and track project progress with TFS reports, effective decomposition of tasks is one key to success. In TFS 2008, the out of the box reports are unit-based as opposed to being hours-based with respect to work items (e.g., a Bug, Task, or Change Request). There is no out of the box way to track progress of a task based on either the number of hours expended or the number of hours remaining on a given task. Thus, decomposing tasks according to the above guidelines is vital in order to effectively track project progress with TFS reports. TFS 2010 will make a significant shift to an hours-based, purely agile approach in terms of tracking project progress, complete with the burndown charts that agilists are accustomed to. I think this is an outstanding move that will help organizations to transition to more agile methods. From my experience, those who still “formally” have a waterfall model are already doing some sort of overlapping of project phases or are experimenting with iterations, so this will be a help, and not a hindrance.