Jean's Corner

Tracking in the Agile Project, Or How to Let Go of Task Completion Dates

Often, I am confronted with questions from clients and colleagues about task-level and resource-level tracking in agile software development projects. Specifically, I receive requests to add "Estimated/Required Complete Date" to iteration tasks managed in our Rally tool. This tells me that there is still confusion and fear around letting go of plan-driven approaches shown to cause more harm than good.

Project managers new to agile approaches often feel they must still track the lowest possible level of dependency in order to define "criticality"; that is, for any given task, and the individual assigned to the task, what is the estimated completion date versus the current expected completion date for that task? The assumption is that answering such questions identifies a "Critical Path" of dependencies that can be used to either push delivery dates out or pull them in based on how they re-allocate resources and revise estimates.

This is such a slippery slope on which to stretch our legs despite a desire to nurture traditional software teams through their agile transition by giving them little plan-driven hooks that help maintain their equilibrium. Classically, estimating time to task completion requires tracking the estimated and actual start times; the estimated and actual number of resources assigned; and the estimated resource availability - all at the task level! This sets in motion a risk management strategy that relies on detailed tracking of each individual resource and their estimates of how much they think they have completed. But as Eliyahu Goldratt illuminates in his two books "The Goal" and "Critical Chain", such tracking often leads to sub-optimization of processes and unintended consequences. Teams that focus on "the trees" of how they are doing compared to their estimated completion dates inadvertently build in slop at the task level and sadly lose track of the "forest" of completing the highest priority objectives of the release.

For this reason, the only times that are tracked in agile development projects are the fixed start and end dates of the time boxes - the iterations or sprints - and the release date. We manage iteration stories only by their priority. We measure the status of tasks within a story only in terms of "How much work is left to do," and "Is the work being blocked in any way?" Tracking percent done and estimated completion date does not contribute usefully to either of these measures. As Goldratt and others have discovered, the only measure that matters is having all components delivered in time to accept the release. Additionally, as Rob Austin from the Harvard Business School will tell you, adding more measures to processes only sours individual performance, not enhance or encourage it. So while all of this may seem like fluffy theory to some, these discoveries lie at the heart of why the agile movement has risen out of the traditional plan-driven world to streamline what we track in agile development projects so we can dramatically reduce the cost of change.

We all agree that there is still a need to estimate, with some level of confidence, how much functionality we can deliver within our time box. Therefore, in applying critical chain scheduling to agile projects, we track how much we accomplish from iteration to iteration, and compare that to our estimates from the iteration planning meeting. We manage the unpredictable by focusing on the highest priorities first and aggressively remove blocks that stall our progress. We also can add a buffer iteration at the end of the release to allow all processes and tasks to catch up to one another.

So in summary, in agile projects we measure how much effort remains to reach completion, not the estimated dates of completion. We remove measures of the individual and instead measure the success of the release. We buffer the release with a time box for catching up rather than estimate the exact dates of when functions should progress through their lifecycle. And we react to changes that occur rather than measure success by how well we adhered to a detailed plan.

» Post your comments and questions on this article

For further reading, consider:

• Critical Chain, Eliyahu M. Goldratt, North River Press, 1997.
• The Goal, Eliyahu M. Goldratt, North River Press, 1992.
• Lean Software Development: An Agile Toolkit for Software Development Managers, Mary Poppendieck and Tom Poppendieck, Addison-Wesley, 2003.
• Measuring and Managing Performance in Organizations, Robert D. Austin, Dorset House, 1996.
• Critical Chain Scheduling
• Yahoo! Group: agileprojectmanagement

About Jean

Jean Tabaka has an extensive background as a methodologist, specializing in agile and adaptive software development environments for internal IT departments as well as ISVs and consulting organizations. She has created and implemented both rigorous and agile methodologies for Qwest Communications, Siebel Systems, Sybase Inc. and several smaller firms, including the FastIdeas internet accelerator. She is currently the lead Customer Advisor at Rally Software Development, guiding customers in adopting agile principles and practices. Jean is a Certified ScrumMaster; a Certified Professional Facilitator; a co-author of a book on Physical Database Design; and a member of the Project Management Institute. She is currently writing a book on collaboration practices for software development projects. Jean holds a MS in Computer Science from The Johns Hopkins University. She has been in the IT world long enough to remember creating JCL programs on punch cards and paper tape, sometimes successfully.