If you are a user of Seapine Software’s TestTrack® tool, the work you do in your software development projects generally follows some sort of pre-defined workflow. This workflow usually has a starting point, one or more sets of software work-related events and outcomes, and eventually reaches some ending point. This flow of events and outcomes may take different paths from start to finish, depending on the type of work being done and the success of the work done along the way. In this article, we will look at the original work and rework involved to complete a TestTrack-managed software development task, define some TestTrack metrics you may use to assess the level of effort you have spent on these tasks, and provide examples of TestTrack’s Live Chart graphical reports you may generate to display and use this information.
Original Work vs. Rework
Software development tasks in a TestTrack project typically include development of new features, changes to existing features, and fixing reported feature defects. The journey from start to finish for these tasks may follow different paths described in terms of time spent doing two types of work: original work and rework. Original work in this context is a metric which assesses how much initial (e.g., original) time/effort was spent to develop/change/fix/verify a feature. Rework is a metric which assesses how much repeat (e.g., ‘rework’) time/effort was spent to complete a currently-open-and-active, or a previously-closed-and-reopened, feature/change/defect.
If your TestTrack project item includes any rework, the start of this rework activity can be defined by a workflow rework-trigger event. Depending on how you set up your project workflow, there may be multiple workflow trigger events. All workflow activity after the first rework trigger event for a workflow is defined to be rework activity. All workflow activity before the first rework-trigger event is defined to be original (non-rework) activity.
The following examples illustrate where original work and rework may play a role in your TestTrack workflow. Rework activity in each example is highlighted in red. The first highlighted rework event in each example is the rework-trigger event. In the example labeled Rework Scenario 1 it is the “Re-Open” event. The example labeled Rework Scenario 4 has two Fix events: the first Fix event is part of original work; the rework-trigger event is the “Remove Fix “event, making the second Fix event part of rework.
Original Work (with Customer Verify) (no Rework)
Rework Scenario 1: Original Work and Rework: Re-Open a Closed (Verified) Ticket
Rework Scenario 2: Original Work and Rework: Verify to Re-Open a Ticket released to Testing
Rework Scenario 3: Original Work and Rework: Customer Verify to Re-Open a Ticket Released to Customer Testing
Rework Scenario 4: Original Work and Rework: Remove a Fix from a Ticket
Workflow Metrics
In a previous article, Create Customized TestTrack Metrics to Better Manage Software Projects we looked at how you can configure TestTrack workflow events to include time-tracking fields for the estimated and actual time to work on a TestTrack item such as a Feature Implementation, Change Request, or Product Defect Ticket. We also looked at how you can define customized metrics to assess these work-related times and how you can use TestTrack’s Live Chart report feature to display and assess this time-tracking information.
You will create and use TestTrack custom calculated fields to define the following metrics to determine how much actual time spent on a TestTrack item was associated with original work and how much was associated with rework.
- Rework-Trigger Event Count: This is the total number of rework-trigger events that occurred in a TestTrack item’s workflow. If an item’s workflow has no rework, then the value will be 0.
- First Rework Event Date: This is the date of the first rework trigger event in a TestTrack item’s workflow.
- Actual Hours (Original): This is the sum of all Actual Hours of work performed before the First Rework Event Date.
- Actual Hours (Rework): This is the sum of all Actual Hours of work performed after the First Rework Event Date. If there is no rework, then this value will be 0.
- Actual Hours: This native field is the sum of all configured time-tracking event work hours for a TestTrack item. See Create Customized TestTrack Metrics to Better Manage Software Projects for how you can configure and use time-tracking fields. The following relationship applies:
Actual Hours = Actual Hours (Original) + Actual Hours (Rework)
- Rework Factor: This metric provides a measure of how much of the total actual effort for a TestTrack item (ex: Ticket) may be attributed to rework activity. We will define it as follows:
Rework Factor = Actual Hours (Rework) / Actual Hours
- Rework Load: This metric is the average number of actual hours that were expended per rework-trigger event for a TestTrack item. It provides a measure of the effort load required to address a round of rework activity. We will define it as follows:
Rework Load = Actual Hours (Rework) / Rework-Trigger Event Count
TestTrack calculated custom field formulas use the ECMAScript language, which is a subset of JavaScript. If you are not familiar with ECMAScript, refer to the ECMA-262 Standard Language Specification for information. You may also find descriptions of these formulas in Appendix F: Calculated Custom Field Functions, in the TestTrack User Guide (Version 2013.1 or later), or in TestTrack 2014 online Help topic: Reference: Calculated Custom Field Functions.
Live Chart Reports
With these workflow metrics in place, you can now generate Live Chart (or other) reports to examine the amount of original work and rework performed for your software project.
The following Live Chart report displays the number and type of rework-trigger events for TestTrack Tickets requiring rework. In this example, four events are defined to be rework-trigger events: Re-Open, Remove Fix, Verify (Rework), and Customer Verify (Rework). Most of the Tickets in the report show only one round of rework activity, but some required multiple rounds of rework. Ticket 19 underwent three rounds of rework activity, each triggered by a “Remove Fix” event, before finally reaching satisfactory closure. Ticket 31 underwent five rounds of rework, triggered by a “Re-Open” event, two “Verify Rework” events, and two “Customer Verify Rework” events.
Example: Tickets Requiring Rework (with Rework-Trigger Events)
The following Live Chart report shows the type and duration of actual work performed on Tickets, both original work and rework. Some Tickets show only original work: Ticket 8 with 29 hours of actual work consisting of 25 hours of Fix, 2 hours of Verify and 2 hours of Customer Verify time. Other Tickets show original work and rework: Ticket 18 with 48 hours of actual work consisting of 30 hours of Fix (Original), 5 hours of Verify (Original), 9 hours of Fix (Rework), and 4 hours of Verify (Rework) time.
Example: Tickets – Actual Time Contribution from Original Work and Rework
The following Live Chart report shows the percentage of actual work due to original work and rework for Tickets. From this display you can quickly see that most of the effort for Ticket 23 was spent on rework.
Example: Tickets – % Actual Hours for Original Work and Rework
The following Live Chart report shows the Rework Factor for tickets with rework, as well as the average value across all Tickets with rework. In this example, approximately 47% of all actual time for tickets with rework was spent on rework activity.
Example: Tickets with Rework: Rework Factors
The following Live Chart report shows the Reload Factor for tickets with rework, as well as the average value across all Tickets with rework. In this example, for tickets with rework, an average of 3.5 hours of actual effort is expended per rework-trigger event.
Example: Tickets with Rework : Reload Factors
We have looked at just a few of the ways you can customize TestTrack to help you better manage your software projects. You now have metrics to monitor and manage rework associated with project and its relation to total project effort. You have seen how you can create effective Live Chart reports to display this information for review and assessment.
There is much more you can do to tailor TestTrack to better serve your project management information needs. In another article, Add Story Point Metrics to Your Agile Software Project Toolbox, we look at how you can apply time-tracking metrics to Agile projects.