Blending Agility With Finely-Grained Tracking

[article]
Summary:
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.

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.

to0107-1
Figure 1: Example Agile Project Iteration 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.

to0107-2
Figure 2: Velocity After Three Weeks

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.

to0107-3
Figure 3: Using

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03