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
About the author
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.
