Agile methodologies enable teams and organizations to support the dynamic nature of business. Short, focused iterations are ideal for accommodating changing requirements and environments. Planning and tracking is low overhead using units like features, stories, or tasks providing high-level visibility into status. While this visibility is better than nothing, there are certainly limits in the depth and breadth of insights this provides. This article will investigate techniques for blending more finely-grained tracking with conventional agile techniques.

What Do We Mean By "Finely Grained" Tracking?
The best way to illustrate what we mean by finely grained tracking is to provide an example. First let's look at an example agile project iteration plan (see Figure 1). Agile projects typically comprise tasks (or stories or features) that have an assigned point value based on estimated size and complexity. As tasks are completed, a velocity of completed points can be derived to determine status against each iteration's plan.

Suppose an agile team accomplished this set of tasks in one week. This team has a velocity of 10 points per week. We can use this as a proxy for estimation future work (see Figure 2).

Although this is a practical and lightweight model for planning, it's fairly abstract. Suppose this week had a large number of meetings or other distractions. Or suppose that it had an unusually small number of meetings. Either way, points and point-based velocity is too high-level to directly answer this.

Some agilists will surely argue that over time the average point-based velocity will accommodate these variances. However, the abstractness of the data makes it challenging to truly understand the root cause behind changes in velocity.

After week three, 12 points is the average velocity that will be used for planning. But is this realistic? What if the estimates for the tasks in week two were wrong? What if the team worked fewer hours in week three due to meetings or other distractions? Fluctuations in velocity are affected by too many variables that aren't visible in this model.
Also, in-process tracking is very limited and difficult. For example, in the middle of the week there's no way to determine if a task or project is on track. Tasks are either complete (which assigns all the points) or incomplete. It#39;s nearly impossible to know whether or not the release plan is reasonable for completion within the current iteration.

Introducing Active Time
Before we look at this {sidebar id=1} example using finely-grained tracking, I'll introduce a concept called Active Time. Active Time is a finely-grained measure encompassing the time spent actively developing an application. This is all the time spent on a computer in an application lifecycle tool. The focus in agile projects is building working software and to build working software time must be spent on a computer in a development environment. Active Time is the measure of this time; therefore, it's very complementary to agile philosophy. At the same time, the gathering of this data needs to be accomplished in an unobtrusive and simple fashion. 6^th Sense Analytics is a tool designed to automate the collection of relevant activity data, including Active Time, that allows development teams to analyze and improve upon the development process.
Active Time has a broad set of dimensions for analysis including type of activity, artifact, and tool. For example, Active Time will tell you that a developer edited c:\source\Foo.java in Eclipse for five minutes on January 3, 2006.

Figure 3 looks at the previous example in terms of Active Time.

Now, we'd create a plan estimating 20 active hours of development. We can then look at our calendar for vacations, meetings, and other activities to determine our expected velocity for the week or weeks. For this example, let's assume we have a velocity of 20 active hours per week. We would then expect to complete the plan in one week.

One of the biggest advantages of Active Time-based planning is in-process visibility. As we work each day, we can track our active hours of development to get an immediate sense of whether our plan for this iteration is feasible. If a task takes longer then the estimated active hours, we can adjust the overall plan and use the finely-grained data to determine the root cause.

For example, adding pictures to the product listing page may have required unexpected database changes. This unplanned activity may extend development on the task beyond the estimated four active hours. Managers and developers can use the finely-grained data to see the cause of the extension and accommodate for it in future estimates. Marrying this detailed, finely-grained data with short agile iterations provides team leaders/agile coaches with unprecedented power to refine their release planning over time.

Other Benefits
In-process visibility and data to refine estimates are the key benefits of blending these two concepts, but the finely-grained data also provides a breadth of insights that's very compelling.

A broad benefit of Active Time is its direct link to time and cost. Active time is simply a subset of total time making it very easy to link to cost or even billing for consulting work. Plus, it's easy to argue that an active hour is more valuable to an organization than a total hour, since the result is something typically more tangible. Either way, it's easy to estimate cost when using active hour as a primary measure for planning.

Active Time By Activity Type
Active Time can be analyzed by the type of activity to get a feel of the performed development process (not to be confused with the "desired" development process). Active Time breaks down into type aligning with development practices (see Figure 4).

A heavy emphasis of agile methodologies is unit testing. More up-front developer-oriented testing leads to much higher quality code and more valuable higher-level testing from QA organizations. However, this discipline is time-consuming and very easy to overlook, especially during tight iterations with little slack time.

Analyzing Active Time by activity type to determine time spent in unit testing provides a number of benefits. First, project managers can audit unit testing time to ensure that it's being done (see Figure 5). Second, project managers can track the time to ensure that they are properly accounting for it in estimates. Holding developers accountable for unit testing without properly planning for it is unfair and may account for situations where it's overlooked.

The previous example illustrates a scenario where the estimate with incorrect only by the time required for unit testing. With deeper visibility, planning can include time for unit testing to prevent further slippages.

Furthermore, stricter methodologies like eXtreme Programming that advocate test-first development will benefit even more from this finely-grained data. The data can be analyzed to determine the order of testing and development activities to ensure that testing is performed first and that sufficient time was invested in the practice.

Is This In Line With Agile Philosophy?
Agilists promote a free-form and organic process model, and finely-grained tracking certainly doesn' sound free-form. Can these be blended? Of course, the answer depends.

The agile philosophy advocates lightweight and quot;just-enoughquot; processes and tools. Processes and tools that impede a developer's ability to deliver working software are not agile. While plan-driven processes like the Personal Software Process (PSP) or Team Software Process (TSP) from the Carnegie Mellon Software Engineering Institute (SEI) that mandate manually captured tracking may be promising, they are not agile by this definition. These processes sincerely require using a stopwatch and notebook to capture all development activities which is clearly neither light-weight nor just-enough. Turning developers into data capture devices distracts them from the primary task of delivering high-quality software.

But there are much easier ways to collect this data. Solutions like 6^th Sense Analytics automate the capture of this finely-grained data giving developers the best of both worlds. 6th Sense automatically and unobtrusively collects activity-based data from developer tools and delivers on-demand analytics to individuals and teams through its hosted environment. This delivers insight into the time spent on specific activities and provides a basis for understanding team effort, productivity, and overall project velocity. Developers can still focus on the primary outcome of delivering working code while the data is being collected in the background. This unobtrusive collection certainly fits the criteria of lightweight and is supportive of agile development processes.

Conclusion
Finely-grained tracking not only blends nicely with agile processes, it provides a number of benefits beyond traditional point-based planning. Although agilists traditionally consider story-based planning as fine-grained, Active Time provides much more depth and breath of data–data that provides a powerful level of insight. Although this data would be expensive and cumbersome to collect manually, newly available automated solutions reduce this barrier to adoption.

One of the four tenets of the Agile Manifesto is "Responding to change over following a plan." Active Time's deeper insights offer agile teams the heightened ability to correctly respond to change.

About the Author
Todd Olson is co-founder and CTO of 6^th Sense Analytics. Prior to co-founding 6^th Sense, Todd was Chief Scientist of the Together business unit at Borland Software after TogetherSoft was acquired in 2002. Before the acquisition, Todd was Vice President of Product Development with responsibility for architecting and developing the Togetherreg; product line. Prior to joining TogetherSoft, Olson was Co-founder and Chief Technology Officer of Cerebellum Software, a leading Internet data integration company that developed solutions to integrate enterprise portal e-business applications and e-commerce projects with corporate data. Todd has a Bachelor of Science degree from Carnegie Mellon University in Electrical and Computer Engineering.